Companies can bake the cost of one or two maintenance releases and maybe one or two years of security releases into the purchase price. I agree it's not reasonable to expect lifetime updates from a one-time purchase. As long as you're not doing heavy development on these maintenance releases, the company's cost should be very small.
As a user-developer, I'd also be happy with being provided the source (or un-linked object files, or the equivalent for whatever language being used) after the maintenance period was over, so I could continue applying dependency security patches myself.
Depends on whether the bugs are because of preexisting flaws or because the underlying platform has shifted. No one can predict the future, and even OS vendors who once took backward compatibility seriously may not in the future.
The design of MOST non-trivial products is refined over time with no expectation that older versions will be upgraded to the latest and greatest. Yes, material esp. safety defects can lead to recalls but this is relatively rare in the physical world.
To expand on shagie's answer, vi is a separate utility except when it's not (f.g. Linux vi is usually a minimal vim build running in vi-compatible mode). For a more pure taste of vi, install nvi or use vi on *BSD.
Note for mobile users: you can setup quassel server to connect to IRC and use the quassel client on your phone. The quassel server acts as an intermediary that keeps the IRC connection stable.
I thought of OpenBSD too since it includes Perl modules for OpenBSD::Pledge and OpenBSD::Unveil. Now I'm wondering if I can get something to work where these are used before importing CPAN modules to reduce the damage of potentially hostile modules.
To add to this, it's designed to work in conjunction with small programs. You don't write everything using bash (or whatever shell) built-ins. It will feel like a crappier Perl. If there is some part of your script where you're struggling to use an existing tool (f.g. built-ins, system utils), write your own small program to handle that part of the stream and add it in to your pipe. Since shell is a REPL, you get instant feedback and you'll know if it's working properly.
It's also important to learn your system's environment too. This is your "standard library", and it's why POSIX compatibility is important. You will feel shell is limited if you don't learn how to use the system utilities with shell (or if your target system has common utilities missing).
As an example of flexibility, you can use shell and system utilities in combination with CGI and a basic web server to send and receive text messages on an Android phone with termux. Similar to a KDE Connect or Apple's iMessage.
It works quite well. There is a lack of precision trying to drag the cursor around on Android, which is made worse on the <$100 quality devices. Using vim's keyboard commands, I can precisely edit text far easier than anything else I have used on a phone. I never used emacs because I'm not a fan of chords, and this is amplified on the phone. However, people who swipe text may like emacs chords over vim's commands and modes.
Neither would the 8 bit CPU you are salvaging. You don't even really need it anyways, you could get away with integer math. You would be running trading algos for bullets and cigarettes in a shanty bazaar.
I just want a 200LX with a bit more RAM, wifi, and a new-ish CPU. As far as I'm concerned, it could run on a Raspberry 0 W. I haven't seen anything new with that Palmtop style of keyboard. It needs both good keys and a decent layout, but everything new I've seen seems to compromise on both.
More support, better support training, and policies that don't handcuff their dispute resolution options (before lawyers get involved). Excellent support, and even taking it on the chin when appropriate, will do more for a business' image than any finely-tuned damage control press release.
You can easily stow a portable solar panel in a hiking bag that can charge your phone and the other accessories. A laptop would have a harder time getting charged, even if it was a Chromebook. Portable battery packs intended for phones would also be easy to stow. Not only do they fit more compactly, but they are light on your weight budget and not as fragile as lightweight laptops.
