I have always made /home a separate partition.
This makes it so much easier to reinstall and/or wipe out a distro and install a new one. All of my files are left undisturbed.
One complication caused by shared libraries was the security threat. An executable using a shared library allowed the user to execute with a different (updated) library without recompilation.
This is a security threat, especially with SETUID programs. If you could change the library, you could install new code and gain privileged access.
This was why /usr/sbin was created - all of the programs there were compiled with static libraries.
Some people think today's file hierarchy is complicated. .That's amusing.
I worked at an R&D center where we had hundreds of UNIX systems orf all types(i.e. Sun, Ultrix, HP, Symbolics, etc.) We also had Sun 2's , 3's and 4's - each with different CPU's/architectures and incompatible binaries. Some Suns had no disks at all. And with hundreds of systems, we literally had a hundred different servers across the entire site.
I would compile a program for a Sun 3, and needed a way to install the program once, for use on hundreds of computers. Also teams of people on dozens of different computers needed to share files with each other.
Summary: The temperature will continue to rise after removing meat from a grill. The thicker the meat, the more temperature is retained. You want the cut the meat when the proper temperature is reached.
So if the meat is at the target temperature - slice it right away.
If the temperature is below the target temp, and the meat is thick, wait until the target temperature is reached, then slice it.
The trick is knowing how thick the meat is, how much the temperature will continue to rise after removal, and therefore when to remove the meat.
While Gibson is overly pompous, I should point out that SpinRite works below the file system structure, and not all filesystems are robust like ZFS, etc. Second - there are two main SpinRite modes - Read/Check and Read/Write/Correct. SSD's should obviously never use the second mode. I suppose the first mode might be used to check if there are problems on a SSD.
SpinRite - last time I used it, was painfully slow - like days or even weeks to run. He's been working on a faster SpinRite 6.1 for at least 10 years now. FWIW, here's the current (2021) roadmap - https://www.grc.com/miscfiles/GRC-Development-Roadmap.pdf
I remember connecting in 1983/84. It was a trial by fire. I started learning Unix by using the Eunice emulator on VMS. I was doing such a good job on documentation (using nroff), that I convinced my company to buy a Sun workstation. I poured through the manual, especially the section on UUCP, and first con a connection to a local college using a modem. I was able to use UUCP to copy the mail and news software. In those days, the standard response to a question was RTFM - in other words, read the source code and follow the instructions. If you can't do that - you shouldn't try to connect to the 'Net.
So you had to slowly bootstrap yourself in technology. Once you were able to read and post news, you next needed to send email to people. And that meant you had to master UUCP mail. Unlike domains, it was a route. You had to specify each step in the relay. So you might need to specify 5 or 6 specific systems by name to reach the desired person. And hope they could find a route back to you.
Most of all - the great part of the early days was respect, and the ration of information to noise. Inaccurate information didn't remain unchallenged. If you asked a question, it was very likely the author of the technology or program would answer you. Often others would pipe in answering simple questions, so that the program creator wouldn't have to be distracted from important work.
It was a humbling experience, especially when you said something that was factually inaccurate, or technically naive. One learned to think and research before responding to anything.
Until the freshmen classes came to college in September......
Normally there was a very formal process to creating newsgroups, but the alt.* distribution was uncontrolled, and a system that had a well regulated and automated process for the creation of newsgroups evolved into newsgroup creation/deletion wars.
And then we had the first spam. And then we had trolls. And anti-spam filters cause anti-anti-spam generators to be created. And then the web was implemented.
Usenet wasn't an app. It was a protocol. The programs we used were, as I recall, readnews (the official program), and rn - written by Larry Wall who later created perl. Rn was a wonderful interface. Besides blocking and filtering, it has threaded conversations - much like reddit.
Debugging, prototyping, hacking, and reverse engineering electronics.
There are many other boards, such as the Tigard, Bruschetta Board, GreatFET, Glasgow, and many other boards. Most of them are FT2232H and FT232 based boards - which wrap the chip with level shifters, switches and interfaces.
The thing I love about the Bus Pirate is that you don't need to install any software to use it. Just connect to the serial port. The Glasgow is cool as hell but you have to use Python and to really master it you have to master Amaranth HDL to make use of the FPGA.
Ian has said the old 15-year-old site is so archaic he didn't want to work with it anymore. And buspirate.com is a better domain name. The web site has a lot of information on it. I spend an hour reading about the new development on Bus Pirate. For instance, the section on test probes was very interesting.
I would ssh into remote systems, start emacs as my first command, and do everything inside of that emacs window - editing (scripts, config files, code), running shell scripts and programs, reading man pages, executing make, compiling, etc.)
Others would use tramp mode, and open multiple remote sessions within a single emacs. This makes it easy to cut and paste between systems.
The first BASIC I used (1976?) was designed to run in a machine with 4K of memory (a 16-bit minicomputer). There was no operating system, nor no disk. You installed the program using a paper tape reader.
At this time, the best "full screen" editor we could find was actually a very expensive CRT terminal that did all of the editing in the terminal's memory. It required an operating system and a disk. The program read 1K of data into terminal memory, and using keys built into the terminal, you could move the cursor around and cut and paste. When done, it write the memory into a file, and read the next 1K of data.
The computer it was attached to had an editor like TECO (DEC), NSPEED (Data General), or EX (AT&T Unix). These were editors designed to be used on dumb terminals or even hard copy terminals (Like a TeleType ASR33, Silent 700, or DECWriter).
A full screen editor would need an operating system with support for files (Floppy or the outrageously expensive hard disk), and enough memory to support a program on top of the operating system, on top of the program you are editing.
Nope. As someone who administered a VAX with 50 simultaneous users, it's not a problem. It only affect that process and that user during that session. A logout resets everything. A more interesting problem was trying to read or write to a serial port that was hardwired to use a different baud rate.
You could type "stty 9600 /dev/tty4"; cat file >/dev/tty4" and it wouldn't work because when stty exited, the system would reset the terminal baud rate.
The proper way to do this (assuming you weren't the sysadmin and couldn't modify the default per-terminal baud rate), was to type the following
I run an AWS instance that hosts my own domain mail server.
I have hundreds of email addresses, and each of them is forwarded to a gmail account. (I use the [email protected] to make each one unique.
I do this to identify and squash spam - if one email address becomes contaminated, I delete it and change my email on the compromised company's server.
I also run a mailing list server.
So my email is usually sent from a gmail.com address, and I usually receive email on my own domain.
Some lessons - sending email from your own domain is difficult as you have to not only make it accepting to spammer-averse sites. You also have to protect it from sites that would LOVE to relay email through your server.
As for receiving and reading email on your own domain - you have to provide your own spam filters - and this is VERY DIFFICULT. 320 billion spam emails are sent every day, and 94% of malware is delivered in those emails. That's one reason I use gmail as the way I read email.