I learned Dartmouth BASIC on DTSS and later had Commodore PETs at school and an Apple ][+. In college, I had DOS and GW-BASIC. I also learned Fortran, Pascal and .BAT files.

At the end of college, I had started using spreadsheets. Faster than calculators for engineering formulas and quicker to get up & running than writing programs that saved/loaded data, etc. That's probably when I stopped using BASIC. I went on to C then Unix tools on DOS before going all Unix with shell, perl, python, etc.

The Zenith Z100 had ZDOS. It was mostly compatible. I ran Turbo Pascal and many other PC programs on it. There was a software emulator called ZPC that remap PC's RAM layout to the 768k the Z100 had to get graphic working.

The Z100 had an 8088 and an 8085 with a S100 bus. The graphics was 640x225 with 8 colors. There was an interlace mode that could do 640x500. It flickered unless you had a CRT with long persistent phosphors. The keyboard had 13 function keys (F0-F12) a dedicated help key, a number keypad and dedicated cursor keys. The serial ports used completely different chips than PCs. The Opus BBS system, with a FOSSIL driver to adapt the serial port, ran just fine on the Z. And there was a lightpen option.

In addition to ZDOS, there were versions of CPM-85, CPM-86, MP/M, Concurrent CP/M and UCSD pSystem. And, Microsoft ported Windows 1.0 to it. The serial ports didn't work, but everything else did.

I know if a contractor is working for the post office, there are some exemptions. Ex: When buying the paint and other materials for the job, the state taxes are not charged.

There have been very few automatic motorcycles.
Hondamatic (I think hydrostatic)
Rokon (snowmobile)
Husqvarna (4 speed automatic)
Some have CVT transmissions
Honda (Z50) was clutch less but you still shifted
There are auto clutches for dirt bikes (Rekluse, others)
And electric motorcycles are single speed

EV on motorcyles has a limit. Weight greatly affects handling so you can't just add more batteries. You'll probably never see a hybrid.

I used exmh, procmail and fetchmail for a long time.
exmh was a wrapper w/ a GUI around the MH mail system. It was written in tcl/tk, had lots of add ons and activity. There was one that would see how you moved files from your inbox and start moving them for you (1998 I think)

Procmail was an amazing filtering system. I wish gmail filtering was anywhere close. I especially miss being able to edit it in a text editor and have the order mean something. I was even able to run a small mailing list with it.

The MH system was all CLI and each message was a file named a number for its position in the folder/directory. You could use all the unix tools on them because they were seperate files. It was very useful for searching, moving, archiving, filtering email. xmh was the 1st GUI wrapper for it.

I miss the days of doing everything in email. It was usually fast enough for a small group to use instead of irc/chat/slack. People would have long (technical) discussions in it. The Linux Kernel mailing list could not be done in chat. Email is standard enough to have tools for archiving, searching, threading, indexing. Even services were done in email

Before the web, I had email but I did not have FTP. I was able to get all the patch diffs for Minix via a mail to FTP server that would uuencode everything and I could save it & check for errors.

Isn't it nice to be able to find that kind of info about how software was built? Open Source tends to expose that information. You won't find that with proprietary software.

Most open source is not written by an individual independent of their job.

At its core, its about collaboration. When you collaborate w/ people outside your group/work you get things you would not have thought of. Why else would companies pay people to work on open source?

If Linux (the kernel) was only Linus, it wouldn't be as good as it is. There are hundreds of active contributors. Each of them has their own agenda. It may be getting support for a device your company makes. Or proving new ideas in scheduling, performance, filesystem in use. Maybe you sell support and your customers need feature, security fixes, etc. Getting that into the kernel means you don't need to maintain your changes against the development direction. All that is worth it to companies paying salaries to have them work on it.

You can do local, on-prem cloud with Openstack and/or Kubernetes/Openshift. You can later deploy the app you developed to a few clouds that run Openstack or many of the Kubernetes/Openshift options.

Let's try that again...

If you're small, you should absolutely not host your own email and web server. You will have to deal with a deluge of spam. You'll have to keep up with security of your server on the internet, including monitoring. To do that, you need an experienced, dedicated staff. If uptime is important, you'll have to spend on providing redundancy.

Better to outsource email / web to a provider that has teams dedicated to each item that will likely be better at it than your IT team. Sign a SLA that matches your needs.

If you're larger, you might be able to justify the costs of providing that staff, but many larger companies outsource email too. I'm at a place w/ 20k users around the world that does so.

There is https://vscodium.com/ that is compiled without the telemetry and non-open source stuff that Microsoft adds to VS Code.

It's unofficially available as a flatpak: flatpak install flathub com.vscodium.codium
There are repo for deb/rpm and others as well

I ran across an HP-UX system on a 68k system back in the day too.

I went through lots of "The Unix Programming Environment" using DOS. People had ported/written unix tools for DOS that were similar enough to the Unix ones. I remember awk, sed, grep, lex, vi (elvis, stevie, calvin), emacs (freemacs, jove, miniemacs?), make, tar, gnuplot, shell. The GNU tools had the GNUish project, but didn't run on an 8088.

Microsoft created Xenix and sold it to SCO. There was even an 8088 version.

Minix (https://en.wikipedia.org/wiki/Minix) was a very different beast created by Andrew Tanenbaum. It was a microkernel like Mach, created to teach systems programming to students. It cloned the Unix version 7 API and didn't need a Unix license (>$1000 at the time). Its unix tools were similar (or ported versions?) of the DOS tools I had used because their source was available and Minix only did the 64k I & D on 8088. Just like the DOS "small" model. The "proper" unix tools needed more RAM than that.

Yes. When I was a Unix sysadmin, we'd compile a whole suite of GNU and other tools for SunOS, Solaris, Irix, Ultrix, DEC OSF/1, HP-UX and AIX. There were lots of tiny API differences for each OS. Linux often just implemented more than one API to make porting easier. X11 was one example.

I don't miss chasing down dependencies back then. Linux really did packaging with Slakware, .deb and .rpm that the unixen didn't as much. Debian added dependency with apt and .rpm systems didn't really have it until yum came along.

Most (xfce certainly) can have launchers that you can tie to a program/shell script. Can be in an application menu, on a tool bar. Or on the desktop.

I run xfce nowadays too. I turn off the harebrained "click to focus" that MacOS and Windows used to do to get the focus follows mouse that I had back in the olwm/twm/fvwm2/CDE days. When I was forced to run Windows , I found apps that could mostly turn on focus follows mouse. I never found one for Macintosh System 7. Its nice to have choices.

You also get your choice of butt-ugly styling themes instead of what Steve Jobs or the UI group at Microsoft decided (Windows 8, everything is a tablet?). FVWM was really the 1st that people did it with. You could do some theming with earlier WM but it was very complicated.

I used to be able to run dual screens with a different window manager on each. It was very handy to have a different set of workspaces for each screen. One screen could have my IDE while the other switched workspaces between other programs/collection of terminals. I couldn't drag between screens, but it was better in every other way.