Back in 1989 I worked as a one-man-IT-department for a bunch of ex-academic economists doing econometric modelling on a Digital VAX 11/750. This mini-computer was running VMS - a multi-user operating system. All users had admin rights and each one thought that they could make their models run faster by bumping up the process priority as far as it could go - which of course interfered with the realtime processes needed to manage the effective running of the computer. Unsurprisingly, this had the opposite effect to what they intended. When I discovered this was what was happening, I revoked their privileges and after a system restart, sanity was restored. I was thanked for finally making the system work faster.
Oh, my first internet access was through one of those in 1991 at college! Found a cool exploit that let me anonymously broadcast messages to anyone. Sure freaked out a lot of people. Was fun cause you'd get to see the effects of your action in real time because it was a bunch of people in the same room on shared terminals.
Around '84 doing seismic data. We just got a terminal in the office that would allow you to monitor the jobs running on the IBM mainframes downstairs. Completely new tech to all of us. It had a command line message capability. Because it was quite easy to send to all instead of just your recipient, one marriage ended rather suddenly. Seeing the effects of your actions with new tech in real time indeed.
Working at a hedge fund with multiple locations, the founder insisted that mail to “staff” would reach everyone at the local office and mail to “all” would reach everyone (in all offices).
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@.
I remember someone getting a bit wild with their netsend and accidentally spamming the entire school district, including the administration. We also found out that you could DoS your instructor with enough messages.
On our high-school network, the Guest account had NET SEND privileges. It was somehow less chaotic than one might expect.
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.
This is along the lines of my early days learning about computers at school. I saw executables were filled with weird junk when looked at in a text viewer. So I'd load a little of that junk in a file and add
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.
the key "feature" of the exploit was the ability to send messages anonymously. the unix commands "write" and "wall" allow you to send a message to any users terminal.
apparently "wall" has a switch "-n" to hide the sender
Nice, reminds me of my high school computer lab. I wrote a trojan horse in VB6 and distributed it among the lab PCs somehow, then from mine I would open and close peoples CD trays, turn their monitor off, send them to... questionable websites where they would swear it wasn't them! Haha, good times.
A friend and I were able to phish passwords from nearly the entire school we went to with VB6 - the school (board) used active directory for logins on a shoddy network where some switches would often just drop all traffic to a random port for any length of time, meaning a PC would lose connection to the AD server at random. The kicker was that attempting a login after the connection was dropped greeted you with a "could not connect to //SCHOOL_BOARD//SCHOOL_NAME/PC_NAME" to which the solution was reboot the PC and it would work again (99% of the time, anyways). The other kicker was the background image and login domain were the same for every single computer at a single school. We exploited this; we created a full-screen/un-exitable UI with the same background image behind a form simulating the normal login screen. We would first login to our own account and run the program (there were no login limits either), at which point someone else later through the day would sit down and try to login. The credentials that got typed in were added to a .txt in my own user folder before the user rebooted the "non-functional" system. Of all the dumb shit we did, that's probably the only thing we never got caught doing, and probably because we never did anything nefarious with them.
Ha - did the same phishing thing with our RM Nimbuses in the school computer lab. Wrote a turbo pascal program that showed the same login UI as the Nimbus. Logged into my own account on all machines and ran the program. When someone "logged in", it wrote their username and pw to a text file, and rebooted the machine (which got the user to the real login screen). Never got caught for that either, but also don't remember doing anything malicious with the info - I think it was more about the fun of the challenge :)
There was a system that a bunch of students administered (I was one of the students at the time). We would occasionally prank each other. On this DEC station where memory was scarce, one guy ran emacs.
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.
Somehow I've never considered what will happen on Unix if pid 1 exits!
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!
Occasionally. It wasn't a daily, or even weekly occurrence. But, in all honesty those pranks were some of the things that helped my early sysadmin experience.
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.
We used to play pranks on each other such as logging into the NeWS server on a colleagues machine and manually setting a small rotation in the transformation matrix for a terminal window that someone was typing in....
NeWS had an interactive PostScript shell and almost no security so this kind of mucking about was trivial...
Ah, good times.... we used to do similar things across the HP Apollo workstations at the place where a friend of mine worked (and I unofficially "borrowed" computing facilities for a project of my own -- though I did also contribute a substantial speed optimization to their main product, so nobody seemed to mind).
For april fools' day, on my first job as a troublesome ~16-year-old administering our university lab's firewall (academia was a different land when it comes to trust), I set up some automatic network-wide substring replacement filters for incoming HTTP responses to replace `<body` with something like `<body style="transform: rotate(0.1deg);"`. This was in the time before HTTPS was ubiquitous, so it worked on most websites.
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.
Economy is all about incentives and behaviors. Did they learn any lessons from how they acted during the episode? And hopefully published a whole bunch of papers from it?
Had exactly the same with a bunch of developers who could change the queue priority on a mainframe for their own work. They couldn't work out for themselves that if everybody set their work to the highest priority it had no benefit to any of them. Trying to educate them failed, so we revoked access.
> All users had admin rights and each one thought that they could make their models run faster by bumping up the process priority as far as it could go - which of course interfered with the realtime processes needed to manage the effective running of the computer
It amazes me what the bios and OS or OS api's let you do, even on modern devices.
> 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.
I'm not sure anyone should call VMS "modern", but that's beside the point ;)
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.
We don't typically use multi-user systems, actually - I'm pretty sure Logan meant our personal hardware. For example, we run an i5-12400F at 5.2GHz and run a fairly customized Windows 11 Enterprise, both of which would become impossible if our BIOS and operating system were too much more locked down.
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)
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.
okay, then we don't own computers that are intended to serve multiple physical users. They may run multi-user operating systems but ours are typically configured with only one actual user*.
*ignoring all the system and service users in OSes like Windows and Linux.
I remember going along to a VAX/VMS System Administration workshop. Another bloke and I did a prank where we substituted text of the text editor that would produce blinking "Working" if it got busy. We substituted "or" with "an". The workshop coordinator caught us because we forgot to do something I can't remember and a login was tied to the change in the executable.
In 1993 my freshman CS class was taught in scheme. All of our assignments had to be developed and tested on some shared Digital machine running Ultrix. The scheme interpreter was kind of slow to start, especially when there were 20+ users logged in. Helpfully, our TA taught us how to ctrl-z to suspend the interpreter, then edit our program in vi, and then "fg" to get back into the interpreter.
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.)
I had a similar story with a friend in college in the 2000's. He would always hit Ctrl-z'd to "close" emacs when logged into the server which would've been fine if he wasn't using screen or tmux as well. At some point, he was using a ridiculous amount of RAM on the server and the admins suspended his login to force him to come in.
I had a classmate who did her assignments in Ada. The compiler & linker would bring the school's Data General MV/8000 to it's knees, as it swapped out other processes to make room for it. Every 30-40 minutes we would have a coffee break forced on us.
When I was first learning Linux around 2006 I somehow got the idea that Ctrl-Z was the way to exit programs. For maybe 3 years, I would just Ctrl-z my way out of programs.
Luckily I worked almost entirely over ssh so I presume the suspended threads died with my ssh session exiting each day.
That reminds me of a story from a guy I worked with.
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.
I remember a variant of xroaches: it had crawling babies with diapers. Maybe they wouldn't multiply under windows but they could be just a different bitmap with the same algorithm.
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.
It's funny how many stories from earlier times boil down to "it wasn't meant to be malicious, just funny, but people didn't realize that it would multiply that much or use so many resources". See also: the morris worm (I mean, that arguably was designed as malware, but supposedly wasn't supposed to be nearly as bad as it was)
Calling IT is the right move here. Could have been an intruder or a remote user doing something important.
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.
(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?)
That sounds needlessly disruptive. It is a workstation after all. I restart mine as little as I'm allowed to and once a month sounds way too much already.
You have to close all windows (and possibly tabs in your editor), restart long running jobs you have in the background, restart your SSH sessions, lose your undo tree, lose all the variables you have loaded in your interpreter or bash, among others that I have possibly forgotten.
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.
For a personal machine, it's fine to leave it 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.
For production it's highly dependent on the business needs. But restarting the entire estate every day seems a big enough hit to capacity at the very least that may already be prohibitive without any further consideration.
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.
I doubt Google restarts all their machines once a day. Obviously not all at once, otherwise they'd have massive downtime. But anyway, Google's needs are very different than just about any other company on earth (except for a handful of others like Facebook and Amazon). So, they are usually not the best example.
Yes, once a day was an example. Google uses different frequencies. However I do remember getting automated nagging messages at Google when a service hadn't been redeployed (and thus restarted) for more than two weeks.
Google as a whole might be different from other companies, yes. But smaller departments in Google aren't that different from other companies.
Getting those messages is very different (and a lot more reasonable) from forceful restarting them, which was the initial suggestion.
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.
At least on older hardware, number of reboots was a stronger correlative with failure than hours on.
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
One of the highest stresses on passives and power components occurs when there is an inrush of current (di/dt) or a voltage spike (dv/dt), which can occur on power cycling or plug in. So it is not a myth that hard reboots can be stressful on older hardware, but there is a certain amount of red herring because power cycling is also when an aged or diseased component is likely to show failure due to hours of service.
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.
I don't think that long uptimes is unix culture at all. unix was always about being small, simple and fun to use, A place where having something now is much more valuable than being correct later. A hackers OS. This is also where most of the sins of unix come from.
"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.'"
I'd guess orders for these probably skew to the higher end.
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.
No matter how many times I see it I always read fsck as "(for) fucks sake" and then internally correct to "file system check." I think I've got a flashbulb stressful memory floating around in there.
I once had to troubleshoot the math department director’s PC misbehaving. It turned out that he let prime95 have every spare cycle on a core 2 duo for a decade and the machine would only boot if it had cooled to room temperature.
Looks like the project averaged about one new Mersenne Prime per year for 1996-2009, and then only 4 hits for 2010-2018 with none since 2018.
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.
When the project started, CPU frequency scaling wasn't a thing, so CPUs would run at full speed (and full power draw) 100% of the time. If you weren't making maximal use of the CPU, any remaining capacity would go to waste. Distributed computing projects could make use of that remaining capacity.
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.
For a while I had a Home Assistant automation that would spin up Prime95 on a machine in my homelab when the closet it was in (in an unheated garage) got too cold. The closet also has the water meter, so it has to be kept above freezing. There's also a resistive heater, but I figured I'd rather get a bit of productive use out of those watts.
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.
I don't think that's true. Variable frequency certainly helps efficiency, but like the other commenter said, HLT did exist. The CPU would use less power when told by the OS to do nothing for a short while.
It may have been replaced by a cryptocurrency indeed, for there was PrimeCoin, one of the very few that actually did something that was both productive and unprofitable (critically important for the economics of mining) with its mining cycles, and that is look for prime numbers. Although I don't remember if these were Mersenne Primes. It was one of the very earliest altcoins and by its nature was CPU bound which made it unpopular with large scale mining farms, but extremely popular with CPU cycle thieves working in clueless corporate and educational IT departments.
In the mid-2000ds, there eventually came a time when the xlock (Ex-lock) screen locker disappeared from the last university workstations that still had it. People routinely got puzzled when they could not run it. It was a fun prank to tell them that Ex-Cee-lock was the replacement for it (which would, of course, run the clock application). :)
Xlocking workstations became a problem at our university. People would claim a workstation, lock it, go do something else (lunch, lecture) and then come back to their reserved workstation. So the admins added a button that you could log someone out if the screen had been locked for more than half an hour.
They didn't want to ban xlock because they cared about security.
> So the admins added a button that you could log someone out if the screen had been locked for more than half an hour.
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
Windows NT could always remotely log out the current user when part of a domain. We had tools in place for our lab administrators to logout users if they found locked workstations. With Windows 2000 you could automate this through group policy
In high school I'd reserve workstations for my friends by unplugging the keyboard. The PC would fail to boot with "Keyboard not found, press F1 to continue" which was enough to get it designated broken and avoided.
I did this unintentionally in college once by switching the keyboard layout to Dvorak, which for some reason persisted across logins. I came back later that day to the same lab and the station I had been using was marked "Out of Order". Huh, that's weird. Sat down at the station next to it. Next day both of them were marked "Out of Order". Oh, huh. Is there something weird with the keyboard? I might know what happened...
Sort of a meta-comment about infosec.exchange, so I expect a few downvotes, but while this was a funny dad joke it took more scanning and reading than it was worth. Mastodon UI's are very dated despite being new. I miss interdepartmental unix pranks!
This thing has a side bar even on a mobile device which shrinks the width of the text even more. The text is very difficult to read. You have to acknowledge that Twitter is a carefully designed and mature product at least in terms of UX.
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.
I wish I'd had Linux systems. I was doing the same type of thing with Windows networks since you could effectively run any program as any user with task scheduling so long as they were logged into the system. Pair that with active directory and you have user info. So knowing who was where, open iexplorer at certain site, innocuous word doc, etc. The most malicious case was an automated logout batch script.
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.
Our unix (Gould GLX or something?) with dozens of terminals lacked appropriate permissions on /dev/ttyNN - so we just piped rain directly to the neighbors terminal.
Back in the day we banned using animated xlock to lock your screen. The Sun workstations in the lab ran the X server local and picked a random other machine to run the window manager and clients when you logged in. (Which is kind of an odd way to do it when I think about it now, but also cool that it was possible.) However this was all running over shared 10 Mbps ethernet with probably 100 machines and only 2 or 3 segments. This all worked fine until a few people use animated xlock running remotely over the shared network.
> ran the X server local and picked a random other machine to run the window manager and clients
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.
> There was a program that would sort of melt your screen.
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.
If I recall correctly, the drive light stayed on, the drive was spinning, but the whine came from the speakers, and moved to a higher pitch partway through. It also smoothly ramped down in "RPM" (frequency) at the end, which is not a thing that the floppies could do.
In 6th grade I wrote a fake virus that pretended to format the hard drive and then left the user at a C:\> prompt. I left it on my moms 486DX-33 (with a turbo button) for her to find it on the weekend. Well she never turned her computers on so it promptly left my mind that evening when I went to go play at a friends house. Fast forward to Monday morning I get called to the office over the classroom PA “ooooooh grepfru_it you’re in trouuuuubleeee”. I couldn’t imagine what I did wrong. I get to the office and the principal says I have to urgently call my mom. So I dial the home number and my mom is frantic on the phone “GREPFRU_IT MY COMPUTER ERASED ITSELF FROM A VIRUS! I TOLD YOU NEVER TO INSTALL GAMES ON IT”. Thinking: the last game I installed was a month ago. Then it clicked my fake virus. I laughed so hard I started crying. The principal and school administrators looking at me like I was crazy. I told my mom to eject the floppy disk and restart the computer. She immediately started laughing when she realized she didn’t check if a disk was in the drive. She said never do that again and hung up on me. I couldn’t stop laughing all the way back to class — to which I then pretended like I was getting suspended for getting into a fight (the whole class knew I was lying about that one though)
We had some Apollo Domain machines at school which could also run similar programs - I remember 'Crumble' and 'Melt' being two of them. And you could run them on other peoples' display. So we used to melt/crumble the screens of the engineering students in the next lab over. 'We' in this case had admin privileges, though, and only did it a couple of times.
If someone xhosted my machine I would run xmeltdown back to their display. I wrote in another post in the thread about how and why someone would xhost my machine.
Since I was at college in the second half of the 90s, we still had unix text consoles for reading emails so my favourite prank was to tell others in my dorm that I had worked out how to remotely log in from the dorm (we had to use a computer room back in them days!) and with my 10 line Turbo Pascal program created a fake login screen like looked identical to the normal one. After capturing a password, I would explain to each person that maybe it wasn't quite working so "sorry", so they were none the wiser that they had given me their passwords.
I didn't do anything with the passwords, it was just interesting how easy it was to get away with.
Someone was discovered to be collecting passwords that way on our universities VT terminals (I'm old enough that at Uni plain text terminals were still a thing, though they were generally used just as terminals for email & such when the lab rooms full of PCs were fully occupied) by leaving what looked like a login prompt on-screen. Someone with much tech knowledge immediately saw it wasn't quite right (that is how the issue was found) but these were terminals used by the general populace not just us CompSci students so the vast majority of the users were not at all technical (what we might assume almost everyone knows these days was still new fangled magic to the average student back then, for many arriving at Uni was their first encounter with having an email account for instance).
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.
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.
> Replacing a T-connector with a broken one to sabotage unpopular classes
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.
I believe either my brother or someone he knew once wrote a program that spawned lots of child processes. He did that to test a scheduler or something like that, but it got a bit out of hand and swamped a major server in endless processes. Admins weren't pleased. But also not too upset, because they approved of students experimenting. We had pretty cool admins.
A function called ':' is defined. In its body, it calls itself twice at the same time (':|:') (piping the output of the first call into the second, which doesn't do anything useful) and sends these calls to the background ('&'). After function ':' is finished being defined, it is called.
The first call spawns two clones. Each of those spawn two more. Etc.
:() defines a new function called :
{ :|:& } is the body of the function, where we call the : function recursively, piping (|) its output to another call to :, then backgrounding the whole thing (&)
; indicate the end of a statement and the start of a new one
: and finally the last : calls the function we defined to start the chain
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
IBM 370 mainframe, 80+ programmers, running VM/370 which creates virtual machines, one for each programmer.
I'm one of two systems programmers with "superuser" privs.
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".
I don't understand. I thought # was the prefix for the level 1 VM, not for the level 0 OS (the host). If you used # to send commands to level 0, what was the prefix for level 1?
System admin privilege #cp shutdown works on the real machine (unless the prefix is changed).
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.
Sounds like us used to linux working on solaris. Process got stuck and we were too lazy to look up the PID. So we just called “killall procname”. Machine immediately went dead.
When the sysadmin came over we learned that killall does something different on solaris and we should never use it again.
Must be 20 years ago as Google was a thing and we had a split monitor and kvm with the one computer in the school IT classroom.
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 :-)
I seldomly mistype ls as sl but it always makes me smile when it happens. It also doesn't bothers me because you can quickly circumvent it by sending sl to background with ctrl+z and deal with it later...
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.
On our university lab, the main reason why most of the savy users would have "xhost -" on their login scripts would be to avoid being shown not so convenient images at the wrong times.
269 comments
[ 2.1 ms ] story [ 396 ms ] threadOne 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.
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.
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.'"
https://multicians.org/unix.html
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.
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.
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.
https://infosec.exchange/@paco/110772422266480371/embed
That's ... very obvious, but thanks for the reminder.
There is xroachng though [0], created by: Willem_vermin :-)
[0] https://sourceforge.net/projects/xroachng/
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.
$ rain | wall
This was always really fun with the newcomers to the ops centers ..
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.
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):
sunos came with sound files for laughter and applause, and it was amusing to have all the machines in the group laugh or applaud like a crowd.(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
https://youtu.be/b8Wyvb9GotM
https://github.com/veltzer/xmeltdown
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.
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.
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..
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.
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 :-)
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.