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.
If work on a house was specified like a typical software project, no builder would even return your call.
"I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".
Sure, for roofing jobs or other large repairs, that’s true. But for remodeling it’s pretty different.
When I’ve engaged with a contractor for remodeling, I usually have some vague idea like “we should do something about this porch and deck and we’d like it to look nice.”
The contractor then talks to you about _requirements_, _options_, and _costs_. They then charges for architectural plans and the option to proceed with a budget and rough timeline.
Then they discover problems (perhaps “legacy construction”) and the scope creeps a bit.
And often the timeline slips by weeks or months for no discernible reason.
Which sounds exactly like a lot of software projects. But half of your house is torn up so you can’t easily cut scope.
reply