Too bad some of this is wrong and the parts that are right don’t bother to consider how things would work if they were different. Ah well, the collapse of the anti unix rant.
Certainly I will note none of the many unix systems I am herding are showing any signs of collapse….
I will note there have been many many problems over the decades with various unix systems… but most of them problems have gone away with time.
That said, there indeed are unlovely corners of Unix.
But the vast millstone of legacy, the vast millstone of hardware bizarrities leave us with two choices….
Slowly slowly nibble away at the fugly, and yes, every time I upgrade systems to the latest version of the distro I use…. hundreds of little niggles and rough edges are shaved away.
Start with a clean sheet. Except you can’t. The hardware is anything but clean and a clean sheet starts with zero software. That said, I keep an eye on http://wiki.osdev.org/Main_Page Interesting things are on the boil there.
A few good points stood out, like about /bin/ and /sbin/ which are being addressed in some Linux distros, I believe.
Powershell got a nice shout-out, but dealing with object APIs has its own drawbacks. Similar to using another language in scripting and its APIs then.
An interesting rant for someone who doesn’t know this already.
Funny you mention sbin. Why does sbin stand for “static bin” when it predates dynamic linking by many years?
I was going for the split with /usr/ and /usr/local/ with my comment.
Having a mount point and a search path can be convenient sometimes, but what we got isn’t as great as having the mount point(s) flat and searching from those.
I’m going to guess because it stores the files on “static” media that isn’t meant to change, unlike a tape drive or hard disc pack?
Because the s doesn’t stand for static.
Ah c'mon, don’t hold out. What’s it stand for then?
Sadistic? Sometimes-functional? Sorta-documented?
Superuser. Exactly what the link says it doesn’t. (Or maybe system. Not much distinction. But unrelated to linking.)
Wasn’t there a tradition that the stuff under /bin and /sbin was statically linked and the stuff under /usr/bin and /usr/sbin was dynamic? Or something like that? Certainly no longer is the case, the only statically linked binary in /bin on this Ubuntu machine is /bin/busybox
Yes. I think this is a case where familiarity with systems other than the hottest flavor of linux help. The OpenBSD system I’m using to type this still has static /bin and /sbin and dynamic /usr, as has been tradition for 30 years. Now, according to the linked article, sbin is (was) static and bin is dynamic. Which means at some point in OpenBSD’s history /bin was dynamic and was changed to be static? When exactly did that happen? Why? Doesn’t make any sense.
If you look at more than one descendant, you get a much better idea of shared ancestry and what theories about past evolution are plausible and what aren’t.
Back in The Very Bad Old Days of Sun and Apollo workstations, they came with hideously tiny disk drives.
You could use them as X Window workstations to display the results of something you were doing on some Big Brother system.
Or you could use them as the forerunners of desktops and do real stuff on them yourself.
If you bought a bigger disk drive.
So usually you added a disk drive, rather than replacing the one it had. (Usually adding a cheaper aftermarket one..)
So the bare bits that you needed to get the thing booting and be able to mount another drive lived on the little drive.
The rest lived on Big Disk.
So /bin, /sbin lived on little disk. /usr lived on Big Disk.
… and when Big Disk wouldn’t mount, because it was in an external SCSI enclosure and some idiot had rearranged the SCSI chain without terminating the right colour of chicken, /bin and /sbin were still available to run stuff in single user mode while you worked out what the hell was going on.
Or at least, that’s how I remember it from ~ sun4 era … maybe you could even NFS mount /usr so your workstations didn’t need a bigger disk?
Yup. Pretty much.
Though last time I tried NFS in that realm it seemed hideously slow.
So I guess you could in principle, especially as /usr is essentially read only mostly stuff in there is mmap’d and only actually read as needed.
Ah The Good Old Bad Old Days…. they sucked sooo much.
The machines in question (SparcStation 20s, perhaps?) would have been on a shared 10Mbit/s thick ethernet run (vampire taps!) so yeah, hideously slow on a good morning before anyone else got in :-)
Can’t remember the model, but I can remember (Oh The Pain) of scuzzy terminators and laying thick ethernet (oh the joy when thin ethernet arrived and would actually bend)
I also just remembered another great one: the first time we hooked up a >1gB (or maybe it was >2GB) volume, we discovered a bug in PC-NFS which would cause the PC to continuously retry on disk full error instead of failing, causing a cascading failure as dozens of PCs all hammered the NFS server with “well is there any disk now?” messages until I yanked their ethernet segment :-)
Tell that to kids these days, etc, etc …
also, having to run lockd on all the servers so that that file locking on nfs would sort of work some of the time, discovering that a thinnet ethernet terminator ‘had gone bad’, or in the case of apollo, having the token get lost and having to manually regenerate it whenever the elevator went up to the 5th floor because the token ring cable had been run down the side of the elevator shaft.
With reference to his rant about “make”….
I will note a counterpoint.
# Oh yippee, a new build system, it's sooo cooool I could eat my own
# foot. inlining=on lets the compiler choose, I think. At least this
# stuff is documented...
# NOTE: if you leave <debug-symbols>on then in a debug build the build sys
# objcopy will be invoked, and that won't work. Building debug apparently
# requires hacking gcc-tools.jam
# Sometimes I wake up screaming. Famous figures are gathered in the nightmare,
# Steve Bourne, Larry Wall, the whole of the ANSI C committee. They're just
# standing there, waiting, but the truely terrifying thing is what they carry
# in their hands. At first sight each seems to bear the same thing, but it is
# not so for the forms in their grasp are ever so slightly different one from
# the other. Each is twisted in some grotesque way from the other to make each
# an unspeakable perversion impossible to perceive without the onset of madness.
# True insanity awaits anyone who perceives all of these horrors together.
# Quotation marks, there might be an easier way to do this, but I can't find
# it. The problem is that the user.hpp configuration file must receive a
# pre-processor macro defined as the appropriate string - complete with "'s
# around it. (<> is a possibility here but the danger to that is that the
# failure case interprets the < and > as shell redirections, creating
# random files in the source tree.)
git blame blames one Richard Purdie…
For a bit of context… this guy is working on OpenEmbedded which is just a huge collection of recipes of how to build things. There are standard recipes for the common build systems….
…but this poor blokes job is to write a recipes to get every build system for every darn package anywhere to cross compile for an embedded environment.
I think he is taking strain.
I once developed a CMake-based build system for an existing C++ project, complete with auto-downloading and auto-building of dependencies, and the ability to create a nice, portable install/deploy folder. Afterwards, I would describe the experience as “taking a leisurely stroll through Azathoth’s living room” because of the sparse and confusing documentation, weird corner cases, bugs in the CMake build scripts of the dependencies, and bugs in CMake itself, that had been around so long as to be unfixable.
This guy? He’s gone far deeper into the eldritch horrors than I ever want to go.
When faced with the annoyances of make, some people say, “I know, I’ll build a better build system!”
And now they have a system whose asymptotic behavior is, oddly enough, only building more problems.
Suggest historical tag, because there are some nifty bits of historical trivia in there.
Suggest rant because, let’s face it, that’s what it devolves into.