grymoire1

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.

This was before SSH. We had to use NFS.

It was fairly seamless and .... interesting.

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.

The final (Rev 10) version of BusPirate V5 is shipping.

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.

You must be confused.

The Bus Pirate 5 (Preview version) is real and available for sale on the DirtyPCB's site - (same price as the V3) with the caveat that this is a beta and may not be the final version https://dirtypcbs.com/store/designer/details/ian/6621/bus-pi...

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

(stty 9600; cat file)>/dev/tty4

If you ever had to repair a disk using fsck when it had hundreds of errors, you would understand why yes(1) was created.

This was first mentioned in 1994, BTW.

https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

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 myaddress+tag@gmail.com 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.

Stacksmashing was able to get Doom running on an RP2040 with an LCD screen. I'd love to see it running on the Lily-GO board. https://usa.banggood.com/LILYGO-TTGO-T-Display-RP2040-Raspbe...

It has two buttons built-in and support for LiPo batteries. It might be possible to make this a teeny-tiny handheld device.

It might have been https://keycombiner.com/emacs/

No. That's not it. C-h t isn't really interactive. It's just a tutorial you can edit. The program I remember was a typing tutorial just for key binding.

I recall an interactive tutorial and practice tool that helped you learn emacs keybindings. It taught all of the previous/next character/word/expression/line key bindings. It helped develop muscle memory. It was web-based (I think), but I can't find it anywhere. Can anyone help?

>That is more than 50 years of BEING WRONG.

"I'd like to write software for you, but I have to wait 20 years before there's a suitable language to be invented first."

>The complaining gets old, but then again, memory leaks, overrruns and underruns and other C footguns get old, too.

Agreed. C is an old language, but at the time it was a very good language. One can argue the choice nowadays, but comparing it to PL/1?

A quick search on Linkedin:

* 117 Jobs for PL/1 programmers * 300,000+ jobs for C programmers

Personally, I'm tired of people bitching about C. At the time, the choice was C or assembly language for embedded/operating systems. There was no other choice in the 1970's. In fact, it wasn't even an option for most of the 1970's.

If you worked at a company and wanted a team of people to develop on a multi-user system, and port it to a single-user stand-alone system, you were out of luck. Our company sold test equipment based on the Data General minicomputers, and while DG had multi-user systems and single-user systems, they had no common programing language besides FORTRAN. It was so frustrating.

And then Digital came to us and wanted to buy a lot of systems, but it had to be running on a PDP-11. Trouble is, our test system was written in Data General assembly language. We had to re-write the system in a portable high-level language that could run on RSX-11 OS. But how?

We searched for a suitable programming language we could buy support for, and ended up using PASCAL - which was a P-code interpreter. The P-Code was portable across operating systems. So I "ported" an assembly-based system to Pascal, and was able to have equivalent runtime performance, because the DEC system had RAM-based overlays and the DG had disk-based overlays. Otherwise, performance of Pascal over ASM would have made it unfeasible.

A few years later, C was commercially available. Oh I wish it was a choice that was available then. The rule of thumb was that C would run with 90% of the performance of assembly language. And that was before they made incredible strides in compiler technology. PL/1 would have been a disaster, assuming it could run at all on a 16-bit machine.

I successfully used it as a writing/typesetting (NROFF) system. It was the cheapest Unix system I could buy, that the family could also use (it was dual boot). It was expensive, but I used Sun's at work, and I wanted to get as cross as I could.

I remember one C book that described a way to write portable code. There were three phases in the header files: (1) The vendor, (2) The characteristics, (3) a portable layer on the system calls. So the first would define VAX, SUN, etc. The second would use the first section to define LITTLE_ENDIAN, BIG_ENDIAN, HAS_IOCTL, etc. And the third would implement a portable layer on top of the system calls. It was nice to compile because section 1 would often be defined automatically by the pre-processor, and the rest would just be defined properly. No config was needed to compile - you just types "make".

Alas - this was extra work on the developer, and at the time there were a zillion variations, which a developer had to deal with.

And if the device touches the Internet, then you need to have a reality-based update program and security assessment/analysis. There is a 99.999% of a major security flaw. If all it takes is an update that gets installed automatically, good. But chances are there's a architectural flaw that will require major redesign, which means new hardware. Frankly, security has to be designed in before the hardware is designed.

The real problem was the core concept of isolating knowledge, i.e. Layer 2 doesn't know anything about layer 3. That's a flawed concept. The trivial, yet essential protocol ARP break the OSI model, for example. And then there's firewalls...