Got called to a professor’s office after a complaint his SPARC4 was running slow
infosec.exchange
infosec.exchange
Since the hospital was quite big, it took me about 10 minutes to reach her workstation, where she exclaimed that "the window closed on its own a minute ago. I swear it was on there for half an hour".
That, coupled with the layout of the desk, the description of the window led me to a hypothesis. I pressed the button on the monitor (which she had unknowingly pressed with the corner of her keyboard) which called up the system menu of the display. It showed 100% sun (brightness). The mouse would go under it.
Then, I hiked back another 10 minutes to await the next phone call.
I'm not accusing you of anything. Just noting my own perception that IT people tend to be very smug and see the world from an IT-centric perspective. Nurses aren't dumb and they certainly aren't lazy. They just have better things to do with their time than deal with inconsequential IT issues.
As I recall everything in the hospital that was actually critical to providing care had some specialist that maintained the system. The computer running the MRI machine wasn't bound to Active Directory and might not even be on the network. Issues with it were routed to GE, not the guy that fixes printers.
1) The parent comment seems completely neutral and non-judgmental. Seems quite just "I had this experience", essentially a set of facts (compared to frequent enough comments that possibly really ought to generate a response / "note of approbation").
2) Stereotypes are the epitome of judgmental thinking, language, attitudes, etc. That may sound judgmental itself, and I apologize for that - that's due, in part, to connotation "issues" with words we use (although, I can't, obviously, claim that even removing those removes all of that issue - I am literally labeling and characterizing strictly in denotation). To be fair, people, in general, can be very smug.
In my experience, there has been an "enrichment" of that in "IT", but, for example, try talking to some of the especially high-ranking surgeons, say ... or, certain professors. In particular, I've personally come across a somewhat bimodal distribution, I think. Some people who reach "very high levels of expertise" are very humble ("right-sized" - not subservient or etc.) and super nice (surprisingly willing to help and talk to even "the layman" / "novice"). Then, there are the outright "arrogant bastards".
So, to add some kind of summation - calling out "IT people" specifically, and especially the parent comment ... well, what's the point? Again - not meant to be rhetorical or aggressive ... but, I think many would agree that people in general should cut that $h1t out.
This opinion brought to you by my "Big Giant Head... remember, when you're thinking of giant heads, think [my] Big Giant Head..."**
* Which, we all know is likely to be comparable to ... something else everyone's got. Though, I'm telling myself, of course, that I've got something useful to say. "Caveat lector". :)
** With apologies to the writers and other people involved in making "3rd Rock from the Sun"
Somebody got burned too many times with IT people, I think.
I'm sure you'd find the same in any similar field. Engineers. Pilots. Mechanics. Nurses.
And yes, everyone looks at the world from their personally centric view of the world. It's the only way we, as humans, know how. After all, how would you get to your oh-so-important job if not for the road engineer, or the mechanic who built your car, or the city designer who designed the routes that you use every day.
Some are more aware of main character syndrome [1] than others... and some are just less assholes than others.
[1] https://www.cxomedia.id/human-stories/20220722170529-74-1756...
I understand a nurse shouldn't need to be a computer expert, but where to draw the line? I'm not a car guy, but I am expected to maintain a working vehicle and obey the rules of the road. I'm not a nurse, but am expected to comply with their instructions and understand to some degree what they're doing while under their care.
But the winshield wiper control might be anywhere and take any form, and because of that it's frequently got wrong and fumbled.
This monitor setting menu button is just the stupid widshield wiper knob. Neither the nurse nor the monitor manufacturer nor the IT industry as a whole needs to do anything about it, for this particular example.
But there are infinite other examples where the random haphazard thoughtless unaccountable inconsiderate nature of everything in IT is at fault and not all the users.
In no other engineering discipline would this shit fly; imagine building a bridge and just constructing it from rocks, old cars and whatever scrap they happened to have lying around the construction site and then fixing it on the go as some of that crap quite predictably falls apart. This is basically what all of computer/software industry is doing.
General purpose computers with general purpose operating systems on them are exactly what it sounds: general purpose. A PC would be comparable to a CNC mill in metal workshop. Operator needs certain base level of knowledge and skill to use the machine safely and purposefully. In fact, general purpose computers, "enterprise" controls on them and end user programs are so unimaginably good and miraculously robust that people with little to no formal training and very vague understanding of operational concerns of the system can use the system to consistently yield net positive result. Even when users actively try to bend the systems in ways they are explicitly not expected to be bent. I don't know whether this is because of or despite the systems being duck taped from scrap, but nevertheless these systems are amazingly resilient and fool proof.
> In no other engineering discipline would this shit fly; imagine building a bridge and just constructing it from rocks, old cars and whatever scrap they happened to have lying around the construction site and then fixing it on the go as some of that crap quite predictably falls apart. This is basically what all of computer/software industry is doing.
On the other hand, in no other engineering discipline engineers and operators are expected to provide a pedestrian bridge that is movable, can quickly scale to support military column and be able to support opening parade before foundation is poured. In no other engineering discipline you start building a façade and figure out internals later, based on use. The more I understand inner workings of computer systems, the more I am amazed at how they do not collapse under their own weight and remain operational.
I guess it is a new discipline suddenly in the world.
Whilst unlike in my youth where 99% programmer ever live still alive, we still have lots of them still alive. Still remember the first time to hear a programmer or IT guy died, he was shot down by the Soviet Union in a korean airplane.
... after destroying the keyboard, swearing to kill the guy who made such a parody of a program after decades of GUI experience was thrown out of the window.
Yes, i can use Windows and the accompanying Microsoft SW "to consistently yield net positive result", but at the expense of my mental health.
> Nurses aren't dumb and they certainly aren't lazy. They just have better things to do with their time than deal with inconsequential IT issues.
I don't want to reduce this discussion to name calling. Absolute majority of my tickets were along the lines of "user entered shit data and now they are getting shit data out, help". A minority of users would put in effort to thoroughly document actual state of affairs. Huge portion of users just did the bare minimum to tick a mental box "I did a thing". If they could find a way to discharge patient from their unit with lowest number of clicks/keypresses they would do that, even if it meant marking the patient as deceased (not much of a hyperbole, by the way).
> Nurses are busy doing things like saving lives and caring for people experiencing the worst day of their life.
That's the problem with medical personnel. They see the immediate act of "saving lives", e.g. putting a patient in a scanner ASAP, as their only job. All the documentation stuff is usually seen as a hindrance, sometimes as a way to cover someone's ass. Under very rare circumstances it is seen as an integral part of patient care. How do I know that? Every implementation of rule checks would be met with backlash rather than appreciation for an extra pair of robotic eyes.
That's a classic, not only in hospital IT. Apparently you expect the user to serve the process and not the other way around. That's not how it works. If the goal of the user (or the organisation) is to do as much of X as possible (maybe even incentivized) the process better facilitates that or it will be abused and/or circumvented.
One of the ways to classify process control is by degrees of freedom: closed-loop, semi-closed-loop, open-loop. Anything but closed-loop processes require users to serve the process. That's by definition and there is no way to escape that fully. Sometimes you can make manual state adjustments to the process, sometimes you can "correct" aggregated data fed to outer process, sometimes you can't do anything about it.
In SCL/OL user is the oracle. Every business process management system (ERP) will be at least as complex as the process it models. The more generic the system, the less context-aware it is and thus typically the more complex.
You can pretend that SCL/OL control system should try and infer things to help users, but in fact that impedes correctness, because users are less likely to enter purposefully wrong value (mental default or validation-passing gibberish) than they are likely to agree with prefilled default value despite it being somewhat incorrect. Especially if the inferred default value is usually mostly correct.
A very crude example. Think of e.g. compass based boat steering control system. It will need occasional course correcting input to account for wind/current drift. Suppose you implement periodic prompt for course correction. Empty prompt will be more likely be filled with non-zero value. Default zero value will be more likely to be accepted unmodified, resulting in more jaggy course.
Less farcical, you are talking about means, I am talking about ends. Ask yourself what a successful organization needs to take care of.
On the topic of forcing users (ie. require) to adhere to the process you better have a good explanation why the process requires hindering the user in completing the task at hand. I know there exist good reasons why we ask users to jump through this hoop or that, but we need to make sure the user knows these reasons and sees why they are not a hindrance in completing the task but part of the completed task.
You see, these things are not necessarily separate, but many people fail to understand that. Continuing shopping analogy, imagine shop sells some candies in multiple flavors. Do you need to weigh them separately when customer takes multiple flavors? The process requires you to weigh them separately. Nothing wrong will happen if you don't. Although, eventually managers will resupply you with a single flavor.
> but we need to make sure the user knows these reasons and sees why they are not a hindrance in completing the task but part of the completed task.
So what's the task at hand? Is it to simply sell candies to customer or maybe keep shop operational, properly stocked and then sell candies? For the shopkeeper the process may seem to start at customer entry and end at customer paying. For the shop that is just part of a grander process.
It seems to me that you argue for single-person scoped processes to be treated as standalone and microoptimized, regardless of how that fits into master process. I try to argue that it is the master process you have to care about.
Thankfully, we have reasonable people in the management: people who understand that it is maintaining proper documentation (and properly shifting liability) is the one and true purpose of the system; the "medical caring" (or whatever it's called) is simply a by-product that would fall out of it naturally. If only that stupid line personnel (and they are stupid because why else would they have applied to such lowly-paid job?) would understand that and would start to change the world so that it would to match the written documents and instructions (not the other way around, that'd be blasphemous).
Again to all SW engineers out there: If there is only 1 (one) input field on the application which has focus ( in A.D. 2023, 55 after the Mother of all demos was presented, according to Wikipedia), why do i have to click on this field before typing so that the characters typed do not go somewhere else ?
Real programmers don't comment their code. If it was hard to write, it should be hard to read.
> Every implementation of rule checks would be met with backlash rather than appreciation for an extra pair of robotic eyes.
When you are under pressure, the last thing you want is "an extra pair of robotic eyes" which constantly gets in your way.
In fact the nurse gave a quite accurate description of events i might add.
One afternoon (in the middle of the trading day), we got a weird email with an empty body and a bunch of nonsense email addresses. Turns out some poor trader wrote an online dating email, but pasted/wrote the mail in the cc line, resulting in all of us learning that he thought “you don’t seem like all the other girls”, which was sent to you@, don’t@, seem@, and the dreaded all@.
We had a single shared T1 pipe for the whole district. Which was enough for email and stuff, but when web browsers got popular, it was suddenly woefully inadequate.
So I figured out I could NET SEND * SERVER ROOM POWER FAILURE - 9 MINUTES OF BATTERY REMAIN - SAVE YOUR WORK AND LOG OUT and after a flurry of traffic, the network fell to nearly-idle. I could max out the T1 with whatever I needed to do for a few minutes, then NET SEND * SERVER ROOM POWER RESTORED and nobody would be the wiser.
The admin did go check on the "flaky UPS" a few times before looking closely at the message. Had a good laugh and told me not to use it too often.
CRITICAL DISK ERROR. TURN OFF SYSTEM TO AVOID CATASTROPHIC DATA LOSS
and then printed it out to a system printer students didn't have access too. So you got a page of random symbols and that error.
Little did I know the company adding more computers to the network was there that day and the guy panicked and had the system shut down, it was down the next day too. I never did ask what happened to bring attention to myself, and this was before we had individual accounts in the system.
apparently "wall" has a switch "-n" to hide the sender
https://unix.stackexchange.com/questions/99460/sending-messa...
for windows there was "net send" which could be exploited by a tool called NetSendFaker, but this was 1991, so i doubt that already existed.
Making write/wall sgid, and restricting tty write access to that group, was a significant security upgrade back in the day.
Another guy wrote a program that forked 1000 copies of itself, nice itself to 19, did a sleep(0) and then exit. As soon as it got any cpu time, it would exit, but it never would as long as emacs was running. Meanwhile, the load (as displayed by xload) became a solid black box.
So the emacs guy would run 'ps -ef | grep procname | xargs kill' as root.
This meant that it had to get some cpu time to handle the kill, which took longer than a sleep(0) and was largely ineffective.
The second time this prank was done, the process was named 'ema'... which promptly also killed all instances of emacs too.
The third time this prank was done, the process was named 'et'. This happened to have also matched /etc/initd and the machine rebooted rather suddenly.
Even though I'm pretty sure I've run with init=/bin/sh and then typed "exit" at some point in my single-user session, I have absolutely no recollection of the results. I should try it on a few OSes and see!
Of course, his method of preparing to move offices (a common occurrence at IBM) was to
1. Take his (RS-6000) workstation home with him the night of the move.
2. Otherwise, just lock his desk.
He didn't have anything in his office but his chair, desk, and workstation.
Sync is not synchronous. When it is back to the shell there is no guarantee that data in memory is fully copied to disk.
However, it sets a flag that is reset when the copying is done. Sync will hang if the flag is set.
So the first sync arms the copy and sets the flag and is back to the shell.
The second sync starts, blocks at the flag. The flag gets reset and it is back to the shell.
So the 2nd sync going back to the shell is a guarantee that the first sync is fine and data is safe
When you have nice, well behaved users you'll not have problems that need solving. When things go awry - that's when you'll need to solve problems... sometimes even without pranks.
Before we had yp set up on the machines, we just copied the password file between them with a note "make sure you change your password on foo" since that was the one we regarded as authoritative and would copy that to bar.
One time, while adding a person to the /etc/groups file for write access to the web server, someone did rcp /etc/groups bar:/etc/password (I suspect it was muscle memory) and, well, now bar was unhappy and wouldn't let anyone log in... or even su to root to fix it. Found someone who had an open terminal and had them do a while 1 sync... and then powered the machine down and brought it back up. It wasn't happy, so started up in single user mode. Just needed to get the password file in there... but the terminal was 300h which didn't have a proper termcap entry for vi or emacs to work. I was a mudder and knew how to use ed... so ed /etc/password and then the contents of the minimal password file were dictated to me. When done, we got it back up and then copied the password and groups files to the proper spots.
Another time (and this was a prank), someone left themselves logged in and someone else created a directory path that was about 3000 characters long. /user/jsmith/I/will/not/leave/myself/logged/in/I/will/not/leave/myself/logged/in/ ... The problem with this is that `rm -rf` won't handle paths longer than 2048 characters long. So it didn't get removed "I'll do it later." You know what else doesn't like paths longer than 2048 characters long? fsck. So when the machine was rebooted/crashed at some point, the root volume (yea, user directories were on the root volume) failed to fsck... and failed to mount. Stuck in single user mode with the backup partition and reading the man pages for mount on the other machine we found how to force a mount without fsck and then had the guy who did the extremely long path fix it (and promise not to do it again) and got machines working.
NeWS had an interactive PostScript shell and almost no security so this kind of mucking about was trivial...
Unfortunately, it broke some pages that lab users needed for school. I later learned one colleague wasn't able to complete a homework assignment because of my prank.
It amazes me what the bios and OS or OS api's let you do, even on modern devices.
Same, but not necessarily in a negative way. I like pushing my hardware and software to the limits, becoming unable to push those limits would be pretty disappointing.
VMS has a very comprehensive system of quotas and limits, so a "properly" configured system wouldn't suffer those issues.
And furthermore, VMS isn't intended to be used "interactively" as such. You should be submitting work to the built-in batch queues - each with various attributes that can include the priority level. This allows the system to intelligently manage work based on a comprehensive view of the entire system - something a single user in a multi-user system can't have. If you like pushing a multi-user system to its limits, you'd be impressed with what VMS could do even way back in the 1990s.
I mean, our motherboard has an external clock generator almost entirely dedicated to pointing and laughing at CPUs with a "locked multiplier". (It's also used for PCIe 5.0)
-Emily (see HN profile for details)
Overclocking. Profile explains why. For security I prefer single cores, but have to work with whats available.
Not sure whether you're referring to your or our profile, but yes, we do overclock to a significant degree. Our motherboard has a setting to downgrade the CPU microcode to an older version that doesn't try to detect higher clock speeds and shut down. Clearly, stuff is already getting more and more locked down even as we enjoy our relative freedom in the present.
-Emily
Isn't pretty much every "cloud" nothing more than an elaborate multi-user system?
*ignoring all the system and service users in OSes like Windows and Linux.
-Emily
Its a problem I'm facing at the moment, trying to keep the data as it moves around the hw, tamper proof.
Intel CPUs are designed with certain characteristics, which can highlight thread priority attacks.
Cant comment on ARM or AMD yet, havent tested them.
Happy System Administrator's Day!
Unfortunately the fg part of the equation was lost on about 2/3 of our class... after editing they would start another scheme instance! I recall being in the terminal lab the night one of our first assignments was due, and the machine slowed to an absolute crawl. Can't remember exactly how it was resolved but I do recall being taught how to look for classmates running two or more instances of scheme to remind them about fg. (Also not helpful to machine load: "solutions" to the 8 queens problem with infinite recursion. The real lesson here was, in later years, to not be logged in on nights when CS 401 had assignments due.)
Luckily I worked almost entirely over ssh so I presume the suspended threads died with my ssh session exiting each day.
I'm not sure where he worked but it involved a queue of people. He said someone asked him if they could be given priority for their problem to be looked at before others in the queue. In other words jump to the head of the queue.
He said "Sure!" to the surprise of the person asking "But you do realize I will do that for anyone else who asks the same thing?"
So they person chose to remain in their place in line.
Digging into the manuals I figured out how to launch the compiler as a background process so I could still have a working system while waiting for it. Brought the whole classroom to a halt.
More digging revealed that the background priority was set well above user priority. AFIAK no malice involved, just someone who didn't know how to set the system up and left that landmine for me to find.
Mine were in the early 2000s. Back then, the computers at the lab at my uni were not very powerful, so people would do work at a Linux console, saving themselves the hassle of running a bulky X session.
Some time around 2001 I read the console_ioctl(4) manpage and found it replete with prank possibilities. I wrote little programs that would flip the console font so that all the characters were upside down; or swap capital letters with small letters, again by way of manipulating the font; or flash patterns on the keyboard LEDs; or fade to black and back by manipulating the palette.
I then added a server component so that I could leave it running at an innocuously-looking terminal, wait for a victim, fire up these effects remotely from another box in the same room, and watch what happens. Fortunately, I soon discovered that the coding part was more fun than the watching-people-slip part, so I gave up on the latter.
Another prank I used to do was simulate a successful root login on these terminals by just typing in what would be printed, including the motd, at the getty login prompt, simulating newlines with tabs/spaces (and never ever pressing RET), ending in `[root@mailhost root]# `. Then, again, step back and watch what happens. Some people would curiously type in `whoami` and be puzzled why they got a password prompt; some would step back in terror without touching anything, switch terminals and email the sysadmin.
People eventually caught on to the approach and tried to replicate the remote execution but executing as themselves instead of that user so when the IT admins came around there was a very obvious trail to who had been running it. I stopped playing around but eventually IT then SWE became my profession. I sometimes wonder how it'd have gone if I'd been reprimanded though.
In the virtual machine you normally ran CMS but you could run anything. Some machines ran MVS.
To direct a command to the virtual machine itself you would prefix the command with a special character which by default was # but any chosen character could be the magic prefix. So #cp ... would be a command to the virtual machine.
Bored one day I wondered if a virtual machine could run VM itself, on the "second level". I booted it up, changed the prefix character to ! (so, !cp). I could create new virtual machines inside this new VM.
So, could a second level virtual machine run VM? I booted it up on the "third level", changed the prefix to @ (so, @cp)...
I got 8 levels deep. So, yes, VM could run VM, could run VM, could run VM... etc.
Game over. Time to start shutting down these embedded levels.
Out of habit I typed "#cp shutdown" ... and it did. The REAL VM on the REAL machine shut down. Panic run to the machine room to push the start button on the console.
Of course the system keeps a log ... and the other systems programmer showed up at my door ... and said "don't do that again".
Fun times.
I set the first virtual level system prefix to be !cp, second level to @cp, third level to $cp (look at the top of your number keys to see the sequence).
I SHOULD have walked backward $cp shutdown ... @cp shutdown ... !cp shutdown but habit caused me to type #cp shutdown. Sigh.
When I was at college back in the 80's we had access as students to the college's VAX 11/750 (an 8750 Systime clone) to work on our coding projects. The student terminals were on one half of a large divided room, the other half being used by the college IT folks. Often, if there wasn't a spare terminal on the IT admin half of the room, one or two of the IT folks would use two of the nearest terminals just over the divider.
One day, bored out of my mind waiting for my COBOL project to compile, I wondered if I could capture the sys admin's username and password. I wrote a script using the CLI to perfectly simulate the login prompt complete with beeps, messages and all. All it did was clear the screen, sit there waiting for user to enter their username and password, when they did the script would mail me said username and password, display a username/password error then logout to the real login process.
After trying the script out on a couple of unsuspecting classmates and having a bit of anonymous tomfoolery I decided it was time to try this out for real with the sysadmins. I logged into both terminals the IT folks normally used and left the script running. A few hours later I returned and to my surprise and mild anxiety I found out that I'd captured the SYSTEM login password :o. For about a month or so I'd full control of that machine, and would re-run the script occasionally whenever the SYSTEM password changed. I told no-one and on my last day at college logged in and deleted the script, just in case (this was around the time the law in the UK was getting a bit heavy with regards to unauthorised computer access).
Combined with access to the huge set of manuals for that machine I spent a heap of time exploring and learning about VMS and no-one had a clue.
Big surprise now I program for a living.
Oddly, me too :)
For those who don't remember, "break" was not an ASCII character but a literal long unmaskable pause in transmission, and couldn't be generated in software or by reading the paper tape punch, nor could it be read on the host side into an input buffer as it wasn't a character.
The sysadmin for my high school computer lab had written a text-mode DOS login screen that would start Windows 3.11 for workgroups after the user logged in. A few of us kids figured out we could just Ctrl+Break out of it and install/play DOOM, Descent 2, etc. He wised up and wrote a trap for the Ctrl+Break sequence, but I discovered the Alt+3 trick and we continued on our merry way. I don't think he ever figured out how we did it.
(We also hid our games inside a directory named Alt+255, which appeared as a space. A single space was not allowed as a directory name, so it felt like magic to us.)
What got me in the end was that a "friend" used the same trick and started copying peoples files from their network account to his own. My suspicion is that when he eventually maxed his quota, the system must've warned the network admin... a cursory look would later reveal he copied some teacher's thesis files, and that was a big no no.
Eventually this incident would land me my first computer related job as a junior tech support/network admin.
My friend's name was Brian, one of the smartest people I've had the privilege of knowing. Ten years later, we created mobygames.com.
One day, my group of friends and I decided to have some fun. We concocted an idea inspired by the famous 'fortune' command that prints out random adages. We wrote a simple shell script that would take a random line from a text file full of humorous and nonsensical messages we'd written, then mail it to a random user in the computer science department. The script was set up as a cron job, scheduled to send one of these messages every hour.
Initially, it was just a harmless prank. People found the messages funny and would often share them in the lab. The source of these messages became the talk of the department, but nobody knew where they were coming from. We took great pleasure in watching our peers and professors speculating about the mysterious sender.
However, things started to get out of hand when the Dean received an especially absurd message that read, "Why do computer scientists confuse Christmas and Halloween? Because Oct 31 == Dec 25!" He found the joke incomprehensible and thought it was some sort of cryptic message or even a potential threat.
The campus IT team was called in to investigate, and a week-long frenzy ensued as they tried to trace the source of the emails. My friends and I watched in trepidation, wondering if we'd be found out and expelled for our seemingly harmless prank.
Finally, after several sleepless nights, we decided to turn ourselves in. We went to the Dean and confessed. After an anxious silence, he started laughing. Apparently, he had been let in on the joke by one of the Computer Science professors and was waiting to see how long it would take for us to come forward. He was good-natured about the prank and found our initiative creative, although he warned us about the unintended consequences of such pranks.
Looking back, it was a fun, memorable prank that gave us a valuable lesson about the ethics of technology use. It's a story I often recount when I'm teaching my own Computer Science students about the importance of ethical conduct in the digital world.
Obviously the tflops::hit difficulty ratio is ramping up as the numbers get larger, but I can't help wondering if the cryptocurrency craze dampened their work rate.
They're reporting 78,012 tflops of work done today, but my five minutes of investigation wasn't enough to find a historical chart of tflops/day and five minutes is about the limit of my curiosity on this matter for now.
Today, CPUs are built with power efficiency in mind, and will attempt to scale down rapidly when not fully in use. Thus there is no longer such a thing as "spare CPU time". Any time spent on distributed computing projects is paid for in electricity costs. Some choose to continue anyway, but many have been disincentivized.
Are some instructions cooler than others?
Then I realized that the computers heated the closet plenty without artificially pegging CPUs, so I didn't bother reimplementing it when I did a migration.
echo sleep -1 >> .login
After a while we decided that adding one second per login was too subtle...
echo "echo sleep 1 >> ~/.login" >> ~/.loginEvery time the server slowed down, someone would go back there and restart the software, or reboot the whole computer, and it'd be fine for another hour.
Sure enough, after an hour, some fancy ass 3D screen saver came on and pegged the CPU. It was some shareware thing that someone downloaded because it looked cool. I ended up turning the screensaver off and just set the monitor to go to sleep after 10 minutes.
They didn't want to ban xlock because they cared about security.
In our CS labs the PCs re-imaged themselves on boot⁰, from a choice of OS images¹, so you didn't have to worry about causing corruption of the machine by just power-cycling it to get around the locked status. This meant that locking a workstation to reserve it didn't work.
My workaround to that² was to set the wallpaper which displayed behind the unlock prompt to an image of a bluescreen indicating a hardware error and move the window containing the lock prompt to the for bottom right of the screen, so it was just a single pixel and not easily noticed. Hey presto: a locked machine that no one wanted to claim by restarting because it looked faulty. Obviously anyone with half a brain watching me unlock the machine a short while later would immediately work out the trick, so the knowledge spread soon enough and the ruse stopped being as effective. It was very effective for a while.
--
[0] from the same shared network drive, which was initially a problem (this was the first year that lab had been in operation) if several machines re-imaged at the same time as head thrashing caused IO throughout to fall through the floor. Later revisions of the setup helped by tweaking cache settings, and giving the server more RAM, so that the second and subsequent read of an image in a given period would come from cache, also the images were compressed for the same reason and also to reduce the second bottleneck: the glut of traffic through the server's single 100mbit NIC.
[1] usually just Windows NT and the local Linux build, but sometimes other options were present
[2] which I used very occasionally, partly to not be a dick but mainly so as to not give the game away to quickly
I don't know why this is so funny. Probably because it's a catch-22 since you need a keyboard anyway in order to press F1.
There was a program that would sort of melt your screen.
There was another one that would animate a little character at the bottom who would then push your desktop off the side of the screen.
and there was a way to take all the workstations in the group, and play sounds on them.
So (nearest I can vaguely recall):
for i in machine1 machine2 machine3 ...
do
rsh $i "play applause.au &"
done
(well it was amusing the first few times anyway...)
This existed for PCs, too. It was called "drip". When idle, individual characters would "drip" down your screen like raindrops, at random times, for random distances.
Another one I remember was "drain". In the very early PC days, you could add this program to the AUTOEXEC.BAT of an unsuspecting victim's computer, so that it would run at startup. It would start flashing "SYSTEM ERROR 0304-B" for a moment, then add "Water detected in disk drive A:". Another moment, then "Now draining", and it would play this gurgling sound out of the speakers (as best you could, on the speakers of the original PC). That would peter out, then "Now starting spin dry cycle", and it would play this whining sound for a bit, ramp that down, and then tell you that it was OK to use the system now.
In those days, there weren't "logins" to PCs. If you saw a PC without the normal user present, you could do anything to it.
Ahhhh to be a kid too smart for his time again
Turn on -squish and set the -rgc (roach gut color) and you can make your screen look disgusting! It was great in college in the mid 1990's
Then there were the jokes about "SEE ALSO" for xroachmotel and xddt
https://manpages.opensuse.org/Tumbleweed/xroach/xroach.1x.en...
-rc roach_color Use the given string as the color for the bugs instead of the default "black".
-speed roach_speed Use the given speed for the insects instead of the default 1.0. For example, in winter the speed should be set to 0.1. In summer, 2.0 might be about right.
-roaches num_roaches This is the number of the little critters. Default is 10.
-squish Enables roach squishing. Point and shoot with any mouse button.
-rgc roach_gut_color Sets color of the guts that spill out of squished roaches. We recommend yellowgreen.
SEE ALSO
xroachmotel(1), xddt(1)
I didn't do anything with the passwords, it was just interesting how easy it was to get away with.
To my knowledge they never worked out who did it, or how long it had been going on for other than “may have been months”, because the fake login app would exit and logout after sending off the captured credential, and next time it was run it was done from one of the captured accounts, so only the very first capture would have been done by the culprit's own account (even that maybe not if they'd guessed or stolen a password by other means first). Captured credentials were sent to a popular high volume usenet newsgroup so they couldn't track who was reading the result that way. Also, no evidence of the attacker actually using the compromised credentials for anything else, so it was possibly someone “playing” to see what they could do rather than a more malicious intent.
It became standard practise (“enforced” by notices in large all caps text) to reset terminals before logging in to be more sure that was a real login prompt.
Your home dir would be mounted as /school/login
The directory paths would be really long like /afs/school/math/maple/maple5.3 so there were 2 commands named add and attach to mount dirs to /school
add maple5.3 and you would have /school/maple5.3 and it would source .environment script in that dir to set up the tool and it /school/maple5.3/bin to your PATH
The attach command did the same thing but did NOT source the .environment file
If you needed to access another student's dir it was explicitly written in the intro computing class book to use attach and not add
I had a lot of scripts and utilities that friends would use. They told other random people that I didn't know.
So of course I made a file that would be updated any time I logged in showing my current machine name. Then I made a .environment file that would xhost + my_machine and send me a Zephyr message saying "I just added and xhosted your machine"
I would wait a few minutes and then run xflip and xmeltdown and set the -display to their machine. If they were in the same computer lab as me I would see them start to freak out. These programs basically froze your display for a few seconds while inverting the screen or causing everything to appear to melt to the bottom.
https://github.com/veltzer/xmeltdown
No real harm but it was pretty funny when I was 19
For the last 25 years at 8 different jobs everything is over NFS. Every company uses Unix groups and some have used groups to manage project access. Sometimes it can take 3 days to get added to a group.
When I started college in 1993 we learned in the "Intro to Computing Environment" class our first semester how to create ACL groups.
I have a degree in computer engineering so I understand binary, octal, hexadecimal, but chmod 755 or 644 or whatever is not exactly intuitive.
AFS permissions are much easier to understand. When we had a group project we would all make a directory for that project and only give access to the other people in our group. We could give them read or write and everything worked great.
I know NFSv4 has ACL support but I've never seen it actually used anywhere.
I drove out to do the manual install a stack of media in hand. Got to the customer site - and watched in horror as they put the CD-ROM in the 5.25" floppy drive. It fits.
Another fun one, not targeted at professors, but at our student compute lab. We had a lab of 25 Sparc Ultra 60s that was pretty well utilized. Well one day, before I became a sysadmin, I was thinking to myself "all of these servers are rsh enabled, what if I logged into all of them". So I wrote a script that would cut up an AU file (sun's audio format) into tiny parts and then wrote a program that would synchronize with each other and play a different part out of a different workstation. I vividly remember playing a screaming sound in a ring around the entire room at a low volume before playing the entire sound out of the three middle workstations at full volume a few seconds later. The lab was full. At least 15 people immediately noped out. I was sitting in the back cracking up.
Another time the sysadmins of the same computer lab left rwalld running. So I sent an rwall "The system will shutdown in 5 minutes" or whatever the shutdown message was. The professor at the time got angry "they always do this, they perform maintenance whenever the g.d. please" and he stormed out of the room. Suddenly the professor and an angry IT administrator was peering in the door and pointing at me. They threatened to revoke all of my access which would cause me to fail out. I just shrugged, I knew what they were up against and instead asked to work for them. The anger turned to surprise and I worked there for almost 6 years before leaving for greener pastures.
Ahh the SunOS days were really the days of yore
:(){ :|:& };:The first call spawns two clones. Each of those spawn two more. Etc.
Essentially each time the function is ran, it creates 2 new copies of itself, which each create 2 copies of themselves, etc. until your OS stops responding and crashes.
Nowadays many shells recognize this particular fork bomb and refuse to execute it
Nice try!
Though, do they really? I quickly checked if I would find something like this in bash, zsh or tcsh and failed, but I only spent a minute or so..
It's a different relationship. The department workstations were much closer to the refrigerator or copy machine. If it's broken you don't touch it and just call somebody.
In modern money these machines were between $7,000-$10,000 each depending on configuration.
To put it in context, pretend you work somewhere where they provide you with a half height rack and a Precision 7960 https://www.dell.com/en-us/shop/workstations-isv-certified/p...
And it starts acting up. What do you do?
(As an aside, I've always wondered how many maxed out configuration orders they get - you know, when you kick that price up to $100k - what's the threshold where they ask if they could put someone on a plane to visit you? 10 of them?)
Just so that I know that there are no unexpected surprises happening when I need to reboot it in an emergency.
All recoverable, but annoying. I can't imagine doing that every day. It's fine for a home computer, but for a workstation, I just want it always on. Though these days even my personal laptop is essentially always on.
> All recoverable, but annoying.
For a machine that other people are supposed to rely upon, I'd rather exercise this recovery you are talking about regularly. So I know it works, when I need it.
For a production system, I rather live through it's first day of uptime 10,000 days in a row, than making new uptime records every day. In production, you don't want to do anything for the first time, if you can avoid it.
Not to count that would require every service to be prepared to be restarted daily, which could require a more complex system than you'd need otherwise.
Basically, whatever eg Google is doing.
Google as a whole might be different from other companies, yes. But smaller departments in Google aren't that different from other companies.
The restarting risk is normally so small, that there are several other things that are more important than constantly restarting to test that restart works. Continuous delivery, security patching and hardware failure will likely cause enough restarts anyway.
I'll readily admit this may have been apocryphal. It was a common adage when I was a child in the 80s and now that I'm actually qualified enough to suss out such a statement I've never cracked open the historical literature at archive.org on this one to actually check.
It could just be a portage from incandescent lightbulbs (where this is true) and older cars (where this is also true). The idea of non-technicals thinking magical computer dust having the same problem is understandable
Modern devices and standards are able, at a low cost, to implement ripple, transient, reverse voltage, inrush limiting and the like. So failures are more isolated.
Nowadays, with stuff like USB there is inrush limiting, reverse voltage protection, transient suppression and it costs very little to implement, so it's mostly going to be power supplies.
"We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out. If there's an error, we have this routine called panic(), and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"
If you're putting workstations in racks it's either to share them, or due for power/cooling/noise reasons, and the fact that you've got a workload that justifies having those kind of problems probably means all your other costs will still dwarf hardware.
There's usually a large premium on whatever the current largest size dimms, ssds and the top 10% or so of cpus and video cards. So I expect they sell a lot of machines that are "50%" size ( either max physical capacity with 50% size components, or half physical capacity, with 90-100% components ), and a fair number of maxed out just because it will often be cheaper to have 1 maxed out option then 3 smaller ones, and budgets don't matter except they do.
Places who cost engineering time at $100k/hour won't blink at $100k computers if it gets the job done.
Replacing a T-connector with a broken one to sabotage unpopular classes... Or binary searching it with a terminator to save one you liked...
Learning that pinging Windows 3.1 with a big payload would BSOD it and writing a script to perform a rolling BSOD of the entire lab while sitting in the back...
Sending random insults to random spots on ttys while people read their mail using Elm...
Writing a trojan to steal and then delete the MUD accounts of the dudes hogging the only 2 computers with Internet access available to undergrads...
And being caught and let go with a not so stern warning. Simpler times.
Receiving such a write and tracking down the offender for a face to face "you got a problem man!?!?" ;-)
When I started working in academia they had mostly phased out 10BASE2. Every now and then we'd get reports of network being broken and would have to get out the break detector to track down where. Inevitably we'd find a student had unplugged a T-connector in a classroom, disrupting the others on the same loop.
It wasn't our fault professors typically ran "xhosts +" in order to make their lives easier.
Source: my 25 year-ago mischievous self ... Sparc. Miss those days.
Are you sure they were full workstations and not more dumb terminals (just enough processing power to be an X display) with all your logins being to a central beefy server (or one of a few) rather than some random machine?
If that were the case then an animated xlock would potentially chew up an unfair amount of CPU time as well as clogging the network spitting the results out to your local X display.
The best machines were the few HP PA-RISC ones though. Blazing fast.
I did all my mischief on the Unix machines: 3B2s with dumb terminals, and diskless SPARCstation SLCs.
There is xroachng though [0], created by: Willem_vermin :-)
echo "sleep 1" >> ~/.bashrc
https://git.datenwolf.net/codesamples/tree/samples/X11/x11at...
We just used to add an alias for 'ls' which introduced a subtle, but ever increasing delay each time it was run.
But now that I think about it I wonder if you can prevent the job manager from back-grounding a task, would be quite the addition to sl heheh.
However, it still leaves ABRT on the table that can be with ctrl-4 and ctrl-\. For that you'd need to disable the binding e.g. with stty and then handle TSTOP the same way I suppose—or just put it in raw mode.
That's ... very obvious, but thanks for the reminder.
We'd go in, wipe the thick layer of dust off the screen, and it'd be as good as new.
So most folks just start tearing the thing apart trying to get it done first. The way you solve it is by plugging it in an switching it on.
The idea is to check the basic stuff first before going deeper.
My colleague types hello into the Google search box from the next room. The student then typed who's this? Colleague types, Jimi Hendrix...student turns computer off at the plug :-)
In other news, I'm pretty sure I once cleaned a keyboard containing live roaches because an engineer ate messy hamburgers over it for lunch every day without cleaning them. It smelled and looked like a dumpster. There was no swapping keyboards for political and economic concerns. If you're a badass nuclear/electrical engineer, businesses tend to tolerate quite a lot.
In other other news, I once ran johntheripper against a NIS password hash dump (`getent passwd`) from my university's CS department's computer lab network. Within about 3 minutes, I had the login passwords of 5 professors, a dozen grad students, and about 40 students.
while (fork()) {
while (malloc(1000)) {
}
}
while (true) {} // or whatever true was in good old C ;)
Case in point: Many years ago, I happened to look at the source of a project running on our cluster. It was written in Free Pascal. The argument of the professor responsible for the project was that algorithmic complexity is all that counts when thinking about runtime. Compilers optimizing for a target architecture was not part of his understanding of the world. And since I had nothing to do on the weekend, I reimplemented their code in C++. And yes, the resulting code was 5x faster, just by making use of a battle-tested compiler. Turns out a speedup of 5x is relevant to a project that was projected to use 5000000 hours CPU-core time...
I was rather young at that time, which surprised me even more. It was pretty clear to me that this rewrite would bring a noticeable performance boost. To this day, I sort of wonder how you can end up with so much theoretical knowledge that you tstart to completely ignore reality.
https://en.wikipedia.org/wiki/Neko_(software)
Unlike many of the things people talk about on this website that I didn't experience growing up, I actually did download this on Windows Vista once. It might have been a version with malware, but I don't remember.
$ rain | wall
This was always really fun with the newcomers to the ops centers ..
Anyway, in addition to the BBS there was also an IBM mainframe (?) running VM/SP that you could connect to, and somehow that was how you got to IRC.
One night several of us spent hours chatting on IRC, and the next day we got called into the campus computing service where it was patiently explained that some professor's overnight batch job running stats had failed because it was constantly being interrupted by interactive-priority jobs ... i.e., our chat sessions. Which we should now stop.
I remember writing a passionate open letter using my vague knowledge that had trickled out about "hacker culture" in places like Berkeley where students were surely right now exploring these new things called "Usenet" and "the Internet", arguing that even though we weren't doing anything fancy like running stats for an economics paper, and even though we didn't know what any of it would actually amount to, the important thing for our education was that we had the chance to experiment with it for ourselves...
He was using the good ol' mailx MUA.
He never deleted emails.
He never moved emails out of his inbox.
He had been doing this for many years.
His .mbox file was many, many megabytes.
Apparently, he had never noticed the problem before because he very rarely logged out, but IIRC some system work meant he needed to do so several times just prior to his complaint.
Probably the story would sound more funny to me if I knew more about xwindows and SPARCs?
I think one of my most simple - yet evil - prank was to LD_PRELOAD a modified `malloc()` on a colleague's computer. Except where the common practice was usually to have it blow up the memory or not return enough, I had mine to work mostly correctly: in most cases it would allocate as requested, and in occasional cases it would allocate slightly less than requested, and in rare cases it would blow up the memory.
You could think I shouldn't be proud of that one, considering some classmates probably went crazy wondering why their systems behaved erratically, and that it probably didn't help with some of their assignments. Generally our pranks were rather tame at school, and if I recall I had reserved that particular one to only 2 guys that were extremely d-ckish. Can't even recall their names now.
Other pranks were your usual stuff: switch keyboard mapping to Dvorak, swap LTR to RTL, randomly modified clocktime by a few minutes (also rather mean when you need to handover assignments, I suppose...), bind some keys to the most annoying shortcuts possible, unsecured xdisplay accesses, open cdroom on ssh-accessible machines... Basic stuff.
I also grabbed all the login/passwords for an entire promotion once. To my defence, I didn't exactly use the accounts for anything else but to change the default passwords (so, technically and legally, I did access the accounts, I suppose). I was just making a point to IT that assigning default passwords with guessable sequences (if I recall, major + year of promotion) was a bad idea and that for some students it could take weeks before they'd change it and leave some accounts open for abuse (e.g. for students who dropped, were sick on the first days, or would simply not use the labs that much). They weren't pleased by the surge of people contacting them to ask why their passwords didn't work.
When scientific distributed computing came rather prominent, I also clustered an entire classroom (didn't want to hit the whole school network, only rooms that were underutilized). That got noticed by an admin though, but he didn't know what it was and I just said this was one of my projets for graphics computing (which was indeed a real project for which distributed comp was authorized).
I miss these lab setups.
Took him a week to figure it out, he was not pleased. :)