Minutes 2025-10-09

We have two presentations today!
First, a Computer Rescue Idea by Professor Kiernan!
1. Who is Professor Kiernan?
  1. Worked at Ford
  2. Designed features for vehicles
  3. How users would interact with them
  4. Used Linux since 2007
    1. Linux Mint really impressed him
    2. But driver support was really bad
  5. Saw the potential
    1. Kept checking in on the state of Linux back every year
    2. Eventually things got really good
  6. Teaches some humanities courses at Tech
  7. Been speaking at MTU since 2002
2. Hobby is giving friends' older computers a new life with Linux Mint/ZorinOS
  1. They don't know how to flash installer images onto a USB drive, but he can do that part
  2. Then, using the computer is simple enough and they can handle the rest
3. Has an older MacBook Air with ZorinOS on it
4. Prescient book from 1960
  1. Ahead of its time, predicted a lot
  2. coined "Planned Obsolescence"
5. Apple devices getting worse and worse nowadays
  1. absurdly thin
  2. non-repairable
6. Throw sand in their gears!
  1. 'Computer rescue' akin to a 'pet rescue'
  2. Save old machines from recycling and landfills
7. B.A.S.I.C. group
  1. Run by Professors Steelman (Human Factors) and Wallace
  2. Seems to have been disrupted by the pandemic
8. So many Windows 7/10 machines around that can't easily upgrade to Windows 11
9. Plenty of Intel Mac's still around, can't run more recent versions of macOS
10. Talk about how we might rescue Copper Country computers with Linux
11. Help out a region he loves to keep computers out of the trash
For our second presentation, Pipes by Ron!
1. How water gets around your house
  1. and Super Mario
2. But seriously, pipes are used to send the output of one program to the input of another program
  1. Allow two processes to communicate with each other
  2. prog1 | prog2
3. Can pipe cat to grep (though you shouldn't do that), etc
4. Subtleties
  1. Programs run in a pipe are run concurrently
  2. Demonstrated by running yes | less
  3. Can see that less receives input while yes is still running
  4. ps shows yes and less are still both running
5. Programs are unaware of the pipe
  1. Means we can just use our normal I/O functions without any special considerations
  2. grep just takes from stdin
    1. If you run grep without providing a filename, you can just type into it to have strings recognized
    2. grep doesn't know we're typing its input, it just receives it through stdin
    3. The developers didn't have to do anything special to enable this to happen
6. pipe()
  1. Pipe just takes in an array of integers
  2. Populated the array with two file description
    1. fd[0] (read)
    2. fd[1] (write)
  3. This works because pipes are always unidirectional
  4. Ties into UNIX "everything is a file"
    1. Pipes are just two file descriptors
    2. Interact with them as normal files
7. Using pipes between processes
  1. Fork the child process
  2. Will block reading from the pipe until it is ready
8. Making this work with stdin/out
  1. dup2() allows duplicating file descriptors
  2. Have one file description (oldfd) pretend to be another file descriptor (newfd)
  3. Program that thinks it is writing to stdout is actually writing to the 'inside' of the pipe for another program to receive
9. Adding in exec()
  1. Lets us wipe and replace the child's process in memory with a new process
  2. Forked copy gets copy of all file descriptors
10. Example with a program that runs ls -al but modifies the output before printing to stdout
  1. exec() needs an array with each element being an argument of the command you want to run
  2. last element needs to be NULL
  3. execvp() = uses path, that's what the 'p' is for
11. pipe()-form()-dup()-exec() pattern is so common there's a C library to do it more easily
  1. popen()
12. Takes either "r" or "w" to define which end of the pipe it is supposed to be.
13. Named pipes
  1. Literally files
  2. mkfifo
  3. creates a file in /tmp/
  4. Multiple processes can interact with it because it's just a file
14. Questions
  1. How does popen() handle the inputted command?
    1. Ron checked the manpage
    2. Apparently just passes it to: /bin/sh -c <arg>
  2. What popen() ('r' or 'w') do you start first?
    1. Left side (input) of pipe is the "write" side, and is what you create first
    2. Right side (output) is the "read" side, and is created second
  3. Freya got clickbaited, still doesn't know how to fix her sink
  4. A lot of things in Linux/UNIX 'pretend' to be files
    1. Plant can turn off her GPU by echo 0 > /proc/<some_thing>
    2. KVM pretends to be a file you interact with through ioctl's
  5. Windows named pipes are in \\?<thing>
    1. Related to how NFS is \\<share_name>
Chris swung by just to shill XCP-NG
1. Proxmox has its... 'issues'
2. LUG Proxmox incident earlier today
3. Went down in #general in the LUG discord
4. Three "Proxmox moments" in a row
  1. Random disk I/O lockup on node, VMs froze on all r/w operations
  2. Rebooting that node made the cluster lose quorum since two nodes were already offline
    1. All nodes webUI unavailable
    2. After a while, quorum was finally restored
5. Wiki VM got migrated to a node that didn't have its VM storage image, then failed to start
  1. Required manual intervention
6. Then finally after all that clusterfuck everything is back online
October 8th, 2025 6:55PM: The LUG AI incident
1. Anti-AI versus Pro-AI forces in the LUG discord
2. Sarten X misquoted something, came off as calling someone "princess"
  1. It all went downhill from there
3. Simone submitting an essay on favorite digital space
  1. Chose LUG Discord
  2. Said "ultimately a place where people can put aside their differences"
  3. Then the AI incident happened
  4. Needs to append essay with "except in matters of Artificial Intelligence"

Minutes 2025-10-09

Navigation menu

Search