• tourist@lemmy.world
    link
    fedilink
    arrow-up
    62
    ·
    1 year ago

    I assume most of those students weren’t “officially” given admin priveleges, which makes it extra funny

    • atzanteol@sh.itjust.works
      link
      fedilink
      arrow-up
      77
      ·
      1 year ago

      They may have been, things were far more trusting back then.

      X servers, for example, would accept any connections. So we would often “export DISPLAY=friendscomputer:0.0” in the computer lab and then open windows of embarrassing content. Which at the time would likely be ASCII art…

      • tankplanker@lemmy.world
        link
        fedilink
        arrow-up
        30
        ·
        1 year ago

        One of my favourite wars was to open audio files on other people’s SPARCs, somebody had the loudest bag pipe music that usually ended things.

        Access to the SPARCs was normally restricted to third year but if you knew the right person you could get an account created pretty easily. Had the fastest access to the internet at the time within the uni as well.

        • guleblanc@lemmy.world
          link
          fedilink
          arrow-up
          13
          ·
          1 year ago

          I used to work at a company that did distributed QA. Other people’s tests would run on your desktop. It worked surprisingly well. But occasionally a test of some audio resource would play on your speakers “The discrete cosine is a real, discrete version of the fast Fourier transform.”

  • wvstolzing@lemmy.ml
    link
    fedilink
    arrow-up
    60
    arrow-down
    5
    ·
    1 year ago

    Little known fact: A Stanford mainframe kept logs of the activities of the ‘wheels’ in a journal – the ‘journal of the wheels’. Young George Lucas, who briefly attended the university, found that journal, and became fascinated with the ‘Wheel Wars’. He later drafted a document that he called ‘Journal of the Whills’, based largely on what he read on those logs; this is the draft that later became ‘Whill Wars’, and ultimately, of course, ‘Star Wars’.

  • billwashere@lemmy.world
    link
    fedilink
    English
    arrow-up
    44
    ·
    1 year ago

    In my freshman year of computer science our main computer lab was filled with Sage IV machines. Basically a Motorola 68k series with 4 or 5 serial terminals. Most people were writing Pascal code or using a simple word processor. But god forbid you were on there with someone taking assembly language. Because they could write really stupid code with super tight loops that never allowed any other code to run, and the only thing you could do was reboot. So if you hadn’t saved your code you were fucked.

    So I never purposely wrote really bad code that would overwrite unprotected shared memory with random quotes from Marvin from HHGTG to mess with other people. I would never do that. That would have been unethical and shit… 🤔

    I did learn a lot of basic hardware and operating systems though so there’s that.

    https://en.m.wikipedia.org/wiki/Sage_Computer_Technology

  • bleistift2@feddit.de
    link
    fedilink
    English
    arrow-up
    43
    ·
    edit-2
    1 year ago

    The best part of working in a meat grinder startup were the Linux masters teaching you stuff like

    cat /dev/random > /dev/pty23
    

    or

    su _otheruser_
    chsh -s /bin/false
    
      • nicoweio@lemmy.world
        link
        fedilink
        arrow-up
        9
        arrow-down
        28
        ·
        1 year ago

        What OP said. But here’s a more detailed answer courtesy of GPT-4:

        Adding cat /dev/random > /dev/pty23 to your .profile would result in an interesting situation whenever you start a login shell.

        1. Behavior of the Command: The command cat /dev/random continuously reads random data from the /dev/random device file, which generates an endless stream of random bytes. Redirecting this to /dev/pty23 means it attempts to write this data to the pseudo-terminal device /dev/pty23.

        2. Impact on Shell Startup: When you add this to your .profile, every time you start a login shell (like when you open a new terminal session), it will execute this command. Since /dev/random produces an endless stream of data, the cat command will not terminate on its own. This means your shell will be stuck executing this command, and you won’t get a prompt to enter new commands.

        3. Interactive Shell Issue: The shell remains technically interactive, but because the cat command doesn’t complete, you won’t get a chance to interact with it. The shell is effectively blocked by the cat command continuously running.

        4. Potential Problems: There’s a possibility that /dev/pty23 might not exist on your system, or you might not have the permission to write to it. In such cases, the command would fail, but it would still block the shell if it doesn’t exit properly.

        5. Fixing the Issue: To regain control of your shell, you might need to edit your .profile from a different context where it doesn’t get executed, like using a non-login shell or booting into a recovery mode.

        In summary, it’s a kind of a “prank” command that can render your login shell unusable until you remove it from your .profile. It’s an example of how powerful shell startup scripts can be, and also a reminder to be cautious about what gets added to them!

  • KISSmyOS@lemmy.world
    link
    fedilink
    arrow-up
    33
    ·
    1 year ago

    In my town’s school classes during Covid lockdown were held in Microsoft Teams. But there was a severe lack of IT knowledge. In the beginning, for some reason all participants ended up with moderator rights, so kids kept kicking the teacher out of their lecture.

    • qaz@lemmy.world
      link
      fedilink
      arrow-up
      15
      ·
      1 year ago

      We had similar issues and they disabled kicking participants. However, they didn’t disable muting teachers for another week.

  • Thatoneguy@sh.itjust.works
    link
    fedilink
    arrow-up
    31
    ·
    1 year ago

    I remember back in college we would abuse the wall command on our shared Linux server so much that IT had to disable it

  • mrbn@lemmy.ca
    link
    fedilink
    arrow-up
    28
    ·
    1 year ago

    Reminds me of the “Op” wars on IRC. All users would be given @ status and the point was to kick everyone before you got kicked. Writing scripts for this was my first “taste” at programming.

  • palordrolap@kbin.social
    link
    fedilink
    arrow-up
    21
    ·
    1 year ago

    Reminds me of the test server shenanigans I had at an old job versus a colleague. All in fun. Nothing in production.

    One was the faux Bash shell that kind of worked OK until you pushed it or tried to do anything fancy. It was the default shell for the user called “root”, but that wasn’t the UID 0 user. It had been, but I renamed it. Then created a new “root” with a different UID. Of course, the faux shell would tell “root” that it was UID 0.

    The other was the simple background loop that would detect any rival admin sessions and SIGHUP their shell process. First user on the box to run that pretty much had free reign, and everyone else was logged off instantly.

  • fl42v@lemmy.ml
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    1 year ago

    Why declare a war over it? Just sudo sed -i 's/%wheel/$(whoami)/' /etc/sudoers or smth like that

  • cerement@slrpnk.net
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    1 year ago

    got a similar situation in MUDs, someone finds a way to frob everyone else up to wizard level and the whole round of the game just becomes a mess of shouts