Creating more software does not solve anything if that software is mostly a functional duplicate of other software. Or, in other words, all companies re-invent the wheel many times over. It doesn't matter if you 10x the development of software that brings nothing new besides being written in a shiny new framework.
We should, IMHO, start getting rid of most software. Go back to basics: what do you need, make that better, make it complete. Finish a piece of software for once.
You had more periods of stability and low inflation/ZIRP to build wealth and skills.
93-00, 02-08, 2012-2019
Millenials only had the one, and you were pretty SOL if you graduated anywhere between 08 and 2011. Oh and the later period of this (2017-2024) saw astronomical price increases on real estate.
There's a reason we're called the 2nd lost generation.
For command line you won't go wrong with abcde ("A Better CD Encoder") or cdparanoia if you don't need all the bells and whistles. For GUI take a look at asunder.
Software will be even more a commodity than it already is. A hundred apps that do the same thing, what's the point? Rebuilding everything in a new framework every three years, why? The money is gone, or will be very soon.
We've been automating people out of a job for decades. And now we've outfoxed ourselves.
Consider storage requirements. Strings (ASCII? UTF-8?) are not as efficient as integers or UUIDs. You're not storing UUIDs as strings, are you? They are binary, only converted to the string expansion for display and/or export.
Honestly I cannot imagine who expects the original vi and trusts vi to be there. Every Unix/Linux user I have met expects Vim and trusts Vim to be there. If there are users expecting original vi, they must be a very small minority.
A standards-conformant implementation of vi is absolutely required to be present and conformant to standards if the platform is certified by POSIX.2 (or whatever name the standard uses these days).
The latest standard for vi (and the rest of the utilities) can be found here:
Microsoft's native UTF-16 really, really needs an editor that easily saves US7ASCII and UTF-8 correctly, both with LF and CR/LF. The native Windows tools are quite poor in getting this right.
This has been addressed in a few realms, primarily shells.
One bash behavior oddity is that, when it is called as /bin/sh, this will work:
$ cat pbasher
#!/bin/sh
alias p=printf
p hello\ world!\\n
$ ./pbasher
hello world!
However, changing the shebang to #!/bin/bash results in this:
$ ./pbasher
./pbasher: line 3: p: command not found
This is because an alias in a script is a POSIX.2 standard, but this historical bash did not allow this.
Forcing POSIX mode enables the alias:
$ cat pbasher
#!/bin/bash
set -o posix
alias p=printf
p hello\ world!\\n
$ ./pbasher
hello world!
In the same way, platforms that care about POSIX.2 compatibility will adjust the behaviors to obtain certification, as bash has done. I saw HP-UX modify ksh88 into sh-posix, and vim also has a VIM_POSIX environment variable that enables a compliant standard mode.
reply