Unix – The Hole Hawg of Operating Systems (1999)(team.net)
team.net
Unix – The Hole Hawg of Operating Systems (1999)
http://www.team.net/mjb/hawg.html
87 comments
:D
That's a poor representation of the big smile I had on my face while reading this.
I've spent 25 years now "messing" with Linux. Installing over-the-air interactive TV Linux-based mpeg stream devices in central London-based TV channels. Managing web servers and compute clusters for US universities. Wrangling SANs and VMware together to create email services for education. Load balancers. Macs. Private compute environments on VMware for developers. Kubernetes clusters for what felt like a million microservices.
All the while, Unix has been there for me to hack on, mess with, debug, wrangle, chase down, curse, and praise.
It's an old, dependable friend now, but has lost none of its vigour. I imagine it will be there long after I'm gone, probably long after any of us are around.
That's a poor representation of the big smile I had on my face while reading this.
I've spent 25 years now "messing" with Linux. Installing over-the-air interactive TV Linux-based mpeg stream devices in central London-based TV channels. Managing web servers and compute clusters for US universities. Wrangling SANs and VMware together to create email services for education. Load balancers. Macs. Private compute environments on VMware for developers. Kubernetes clusters for what felt like a million microservices.
All the while, Unix has been there for me to hack on, mess with, debug, wrangle, chase down, curse, and praise.
It's an old, dependable friend now, but has lost none of its vigour. I imagine it will be there long after I'm gone, probably long after any of us are around.
A bit like those systems written decades ago in COBOL.
Reading Tolkien and playing D&D in grade school primed me for an almost magical realist(?) perspective. Wargames revealed a hidden world of interconnected monoliths designed and guarded by wizards who actually thought of themselves as wizards.
As a young outsider, I could gain access to this world only by breaking in or fast-talking someone. Once inside I'd have my own room and could learn magic at my own pace. I could explore. The wizard might banish me if he finds out.
This was literally half of the books I'd read growing up come to life.
As a young outsider, I could gain access to this world only by breaking in or fast-talking someone. Once inside I'd have my own room and could learn magic at my own pace. I could explore. The wizard might banish me if he finds out.
This was literally half of the books I'd read growing up come to life.
That's beautiful, thank you :)
You have a way with words...
:o)
Since every top-level comment thus far seems to disagree with the Hole Hawg comparison, I will provide an agreement.
My very first programming experience was the integrated shell of Python 2.6, maybe 2.7. I followed wikis and tutorials in order to print various fun little things. Everything past that was further layers of abstraction, buttons, magic, and GUIs.
I was whisked away into the faintly surreal and inexplicable tornado of Android Studio and XCode until my first year of college, at which point a college professor, during the third lecture of class, was asked, "how many students fail out during this course?"
The professor paused for a moment, and said, "I'm not sure -- let me count the number of failing grades from last semester's final," at which point he piped his grade book into a terminal, straight into a series of bash commands that gave him the precise number of final exams that had scored below a 55.
Thinking back, it's not the fact that he could do that -- I sort of knew that was possible, even with a fairly basic understanding of computers. It was the ease, the fluency with which he did it.
Right then, I understood that programming was the closest I was ever going to get to my childhood understanding of alchemy/magic/psionic powers. And maybe even a little bit further than that.
That is what Unix will always mean to me. A genuine, actual, factual spellbook, inexplicably and suddenly laid at my feet.
My very first programming experience was the integrated shell of Python 2.6, maybe 2.7. I followed wikis and tutorials in order to print various fun little things. Everything past that was further layers of abstraction, buttons, magic, and GUIs.
I was whisked away into the faintly surreal and inexplicable tornado of Android Studio and XCode until my first year of college, at which point a college professor, during the third lecture of class, was asked, "how many students fail out during this course?"
The professor paused for a moment, and said, "I'm not sure -- let me count the number of failing grades from last semester's final," at which point he piped his grade book into a terminal, straight into a series of bash commands that gave him the precise number of final exams that had scored below a 55.
Thinking back, it's not the fact that he could do that -- I sort of knew that was possible, even with a fairly basic understanding of computers. It was the ease, the fluency with which he did it.
Right then, I understood that programming was the closest I was ever going to get to my childhood understanding of alchemy/magic/psionic powers. And maybe even a little bit further than that.
That is what Unix will always mean to me. A genuine, actual, factual spellbook, inexplicably and suddenly laid at my feet.
The closest I’ve seen that resembles the command piping power is a master at spreadsheets making them sing. The ability to convert the questions into something the computer can understand and answer is powerful.
Composable, repeatable, piped commands are a huge boon to me.
It really does feel like a spellbook sometimes, or a huge Lego model where brick A can fit onto plate B in a dozen different ways to create anything from a dinosaur to a SHIELD Helicarrier :)
It really does feel like a spellbook sometimes, or a huge Lego model where brick A can fit onto plate B in a dozen different ways to create anything from a dinosaur to a SHIELD Helicarrier :)
cat | grep -i | grep -v | awk '{print $4}' | something | something --else
I sat next to a guy quite awhile back, in a qa role. Cygwin was part of the environment. I "grew up" on Unix, so I'd show him stuff.
As an excellent qa person, he would write everything down, and do that thing, that way, in that situation. Repeatability.
I gradually convinced him, no, it's a composable language. Look, you can put this thing that you know together with this other thing that you know, and get these new and useful results.
And the lights went on.
As an excellent qa person, he would write everything down, and do that thing, that way, in that situation. Repeatability.
I gradually convinced him, no, it's a composable language. Look, you can put this thing that you know together with this other thing that you know, and get these new and useful results.
And the lights went on.
Except there's nothing about that command line that wouldn't work in Windows CMD/PowerShell, Google Fuchsia, or any other OS that has piping, as long as the binaries are there.
This is the most irritating thing about Stephenson's little tract and the "UNIX is the best" mindset that its fans have: the things the he praises is just the user environment, a surface level feature which can be significantly replicated on any modern OS. Now, don't get me wrong; the UNIX user environment deserves its praise but it says nothing about the merits of UNIX/Linux itself at an architectural level. Most people can't even describe the differences between Linux, Windows, OS X, Fuchsia, Haiku, Midori etc. in an architectural sense.
This is the most irritating thing about Stephenson's little tract and the "UNIX is the best" mindset that its fans have: the things the he praises is just the user environment, a surface level feature which can be significantly replicated on any modern OS. Now, don't get me wrong; the UNIX user environment deserves its praise but it says nothing about the merits of UNIX/Linux itself at an architectural level. Most people can't even describe the differences between Linux, Windows, OS X, Fuchsia, Haiku, Midori etc. in an architectural sense.
> Most people can't even describe the differences between Linux, Windows, OS X
That's because Unix won. When he wrote this article Linux was just moving out of the hobbyist realm, we were on OS 9 (or 8?), and Windows was busy "finding itself". The landscape was different.
That's because Unix won. When he wrote this article Linux was just moving out of the hobbyist realm, we were on OS 9 (or 8?), and Windows was busy "finding itself". The landscape was different.
I sincerely hope you're aware that none of those options existed 22 yeara ago when this particular essay was written.
Microsoft were trying to sell Windows NT to chip designers on the premise that they didn't need to use scripts.
MacOS at the time didn't even have a commandline or interactive text-driven shell.
MVS TSO/ISFP had JCL, but the principle mechanism for interprocess communication was DASD and structured datafiles, not piplines. (VM/CMS more closely approached the Unix model, but was far less widely used.) VMS had COMfiles and DCL, but lacked the full nuance of Unix scripts.
And none of those systems were available on commodity x86 hardware. Linux (and numerous proprietary Unix clones) could run on 386s, and in some cases 286 systems. Need a system at low cost and with sufficient flexibility that the disadvantages of low-power were largely obviated? Unix had you covered.
MacOS and Andriod adopted Unix or Linux because the were clearly superior options. Fuschia ... I think ... is following similar lines (I've not followed it closely). Microsoft introduced Powershell after it became clear that no, GUI toolbuilding simply lacks the flexibility of the commandline. (And they still came up with something incompatible. So WSL got bolted on as part of the stock build.)
Microsoft were trying to sell Windows NT to chip designers on the premise that they didn't need to use scripts.
MacOS at the time didn't even have a commandline or interactive text-driven shell.
MVS TSO/ISFP had JCL, but the principle mechanism for interprocess communication was DASD and structured datafiles, not piplines. (VM/CMS more closely approached the Unix model, but was far less widely used.) VMS had COMfiles and DCL, but lacked the full nuance of Unix scripts.
And none of those systems were available on commodity x86 hardware. Linux (and numerous proprietary Unix clones) could run on 386s, and in some cases 286 systems. Need a system at low cost and with sufficient flexibility that the disadvantages of low-power were largely obviated? Unix had you covered.
MacOS and Andriod adopted Unix or Linux because the were clearly superior options. Fuschia ... I think ... is following similar lines (I've not followed it closely). Microsoft introduced Powershell after it became clear that no, GUI toolbuilding simply lacks the flexibility of the commandline. (And they still came up with something incompatible. So WSL got bolted on as part of the stock build.)
I would have sincerely thought it was obvious I was referring to the reposting of "In the Beginning was the Command Line" long, long after its original publication, including this most recent one.
> "MacOS and Andriod adopted Unix or Linux because the were clearly superior options"
If by "superior" you mean "free as in beer", yes, they were the superior option.
> "MacOS and Andriod adopted Unix or Linux because the were clearly superior options"
If by "superior" you mean "free as in beer", yes, they were the superior option.
For what it's worth, no, it was not obvious.
I agree with this. I don't use Linux because of its architecture, but because it provides me the environment I appreciate, on the platforms I want to use, under the terms I can accept. The BSDs are close to the mark, and I would consider them for specific tasks. Linux is just where development is faster.
The real beauty is in the Lisp REPL, Smalltalk transcript window, Mesa/Cedar interactive, Oberon interactive,....
There's definitely beauty in Lisp, for sure. I wish I could spend more time with it instead of Terraform and JavaScript, but at least I get to tweak my Emacs configs with it now and then :)
It never felt like Lego to me. It feels like cheap knockoff Lego. Pieces all sort of fit together. Until they don't. And then the whole thing starts falling apart.
Like, just look at something like the -print0 option to find.
Like, just look at something like the -print0 option to find.
Oh, absolutely! The interaction between find, xargs, and/or parallel has definitely led to some interesting combinations of curse words in my life :)
Couldn't help myself ;)
awk '/[Pp]attern1/ && !/pattern2/ {print $4}' file | \
something --specific
I'm always up for some command line sharing and golfing! I love the ways different approaches can enlighten me to amazing new ways of messing around with text. (and I say "messing around" but I mean it in the most serious way, I adore how much someone can change a stream of text with the command line and a few pipes!)
You've seen https://www.commandlinefu.com , yes?
Yes, but I had forgotten about it, thank you!
This is a chapter from "In the Beginning... Was the Command Line" (1999)
https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
UNIX seems, historically, to focus on utility. There are lockable doors but you get the keys. It becomes your choice to manage your machine(s) at whatever level you need to. Critical utilities and management can almost always be automated because of the philosophy of having a CLI which can be made to work without user interaction and because devices and critical parts of the system are exposed to scripting languages (/proc /dev etc).
Such a philosophy makes it impossible to create a truly easy-to-use system because the "OS" cannot make assumptions about its state. e.g. you have a configuration file and the root user can edit it with a text editor and introduce inconsistencies.
So either you don't allow the user to introduce "not anticipated" states or you let them and on their head be it. That seems to me to be the main UNIX philosophy - "ultimately the choice is yours".
That doesn't mean you can't screw it up and make it something else. I think the corporate interests who are paying for the development of Linux have made choices that have moved it a few steps away. Thanks to open source, however, one can escape their clutches for a price.
Such a philosophy makes it impossible to create a truly easy-to-use system because the "OS" cannot make assumptions about its state. e.g. you have a configuration file and the root user can edit it with a text editor and introduce inconsistencies.
So either you don't allow the user to introduce "not anticipated" states or you let them and on their head be it. That seems to me to be the main UNIX philosophy - "ultimately the choice is yours".
That doesn't mean you can't screw it up and make it something else. I think the corporate interests who are paying for the development of Linux have made choices that have moved it a few steps away. Thanks to open source, however, one can escape their clutches for a price.
Soso. I thinks Dennis Ritchie put it better. Also, if I see non IX OS like Haiku OS, as impressive as they are, in the end I am missing the underlying IX Philosophy and power.
Anti-Foreword By Dennis Ritchie for the Linux Hater Handbook https://web.mit.edu/~simsong/www/ugh.pdf
To the contributers to this book: I have succumbed to the temptation you offered in your preface: I do write you off as envious malcontents and romantic keepers of memories. The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.
Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome. Yet your prison without coherent design continues to imprison you.
How can this be, if it has no strong places? The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.
Your sense of the possible is in no sense pure: sometimes you want the same thing you have, but wish you had done it yourselves; other times you want something different, but can't seem to get people to use it; sometimes one wonders why you just don't shut up and tell people to buy a PC with Windows or a Mac. No Gulag or lice, just a future whose intellectual tone and interaction style is set by Sonic the Hedgehog. You claim to seek progress, but you succeed mainly in whining.
Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.
Bon appetit!
Anti-Foreword By Dennis Ritchie for the Linux Hater Handbook https://web.mit.edu/~simsong/www/ugh.pdf
To the contributers to this book: I have succumbed to the temptation you offered in your preface: I do write you off as envious malcontents and romantic keepers of memories. The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.
Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome. Yet your prison without coherent design continues to imprison you.
How can this be, if it has no strong places? The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.
Your sense of the possible is in no sense pure: sometimes you want the same thing you have, but wish you had done it yourselves; other times you want something different, but can't seem to get people to use it; sometimes one wonders why you just don't shut up and tell people to buy a PC with Windows or a Mac. No Gulag or lice, just a future whose intellectual tone and interaction style is set by Sonic the Hedgehog. You claim to seek progress, but you succeed mainly in whining.
Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.
Bon appetit!
“ Also, if I see non IX OS like Haiku OS, as impressive as they are, in the end I am missing the underlying IX Philosophy and power.”
You may be suprised if you delve into the command line environment in Haiku and see just how intimate you can get with the kernel and resource management.
You may be suprised if you delve into the command line environment in Haiku and see just how intimate you can get with the kernel and resource management.
"Linux Hater Handbook"? Linux != Unix.
I'm not sure this analogy is on point. A professional carpenter would use a drill that was suitable for the job, and not pull out that contraption for everything. Certainly there are way better drills for versatility if you were only allowed one.
One past little thread:
Unix - The Hole Hawg - https://news.ycombinator.com/item?id=2174519 - Feb 2011 (5 comments)
Unix - The Hole Hawg - https://news.ycombinator.com/item?id=2174519 - Feb 2011 (5 comments)
Unix is a bit more general purpose than a hole hawg, which is used by electricians, plumbers, and LV cable installers, almost exclusively for creating penetrations in studs for pipe and wire to pass through. Some electricians use it to drill knockouts into electrical enclosures and I suppose you could use it to spin a paint mixer or concrete mixer, but it has a pretty specific application in mind.
I agree, Unix/Linux is like a Hole Hawg, it puts the full power of the processor and the resources it's hooked to into what ever drill bit (program) you care to use.
Like a hole hawg, that power can rapidly cause things to go awry. Unlike a hole hawg, the extent of the damage can extend across the world.
Like a hole hawg, that power can rapidly cause things to go awry. Unlike a hole hawg, the extent of the damage can extend across the world.
I feel like, modern extensions of the Microsoft command line excluded, I use Linux for one thing and windows for another. I've yet to have a windowing environment that simply works like windows does in Linux. The same is true for my experience in the terminal but visa versa. Different tools for different jobs. But, it's 2021 not 1999. Maybe times were different then.
To me, Linux is closer to "Windows" than Windows 10 are. Using Xubuntu, I have desktop, panel, shortcuts,... Everything WinNT and WinXP (best Windows versions imho) had, and best of all, once I configure it it stays the same. Windows 10 is a joke - installing widgets automatically and tracking users by default is not acceptable in my book, especially for something I paid for.
And then there is shell. Win10 has made big progress here (by using Linux subsystem), but it is still only half useable. For example, I really miss "select to copy & middle click to paste" support.
And then there is shell. Win10 has made big progress here (by using Linux subsystem), but it is still only half useable. For example, I really miss "select to copy & middle click to paste" support.
I gotta give some credit to PowerShell. I haven’t learned it completely (I don’t work in Windows) but it appears to be a full featured powerful shell.
Linux Mint is that "windowing environment that simply works" for me. I've been putting it on my dads computer for about 10 years now (he is turning 66 now) and it was always working very well with minimum support. Definitely much better than Windows with its reboot for each update nightmare.
Inline with other comments here, I think that Mr Stephenson missed the point.
*nix operating systems were and continue to be successful because they are a complete and powerful toolbox for computing at all different levels.
And yes, if I had to identify a "Hole Hawg" of Unix it would probably be the `dd' command. But I certainly don't use it on a daily basis :)
*nix operating systems were and continue to be successful because they are a complete and powerful toolbox for computing at all different levels.
And yes, if I had to identify a "Hole Hawg" of Unix it would probably be the `dd' command. But I certainly don't use it on a daily basis :)
Came to make a similar comment. I think my main gripe with the Hole Hawg analogy is that it's one tool, not a bevy of tools. Unix is more like if you went and looked into the workshop of a Hole Hawg owner, catalogued all the other tools that person uses, and realized that they're all built to interact elegantly with each other.
(I've definitely had my share of being "spun around the hole" with accidental dd misfires.)
(I've definitely had my share of being "spun around the hole" with accidental dd misfires.)
I don't think he missed the point. You should probably read all of this (which the Hole Hawg bit is an excerpt from) to a whole picture of this school of thought:
http://people.cs.georgetown.edu/~clay/classes/spring2010/os/...
http://people.cs.georgetown.edu/~clay/classes/spring2010/os/...
dd is ironically just used as a bad replacement for cp in most cases.
There’s another construction analogy- the tendency to use the tool at hand vs “the right tool in the truck”. You use what you know and are familiar with without stopping to consider the alternatives (which you may not even know about - at least a tool in a truck is visible but when’s the last time you ran ls /bin).
(Milwaukee sells “demolition screwdrivers” designed to be used as prybars and chisels because that’s what people do with them: https://www.homedepot.com/p/Milwaukee-5-16-in-Slotted-6-in-D... - akin to modifying a program for the use case vs the original designed purpose).
(Milwaukee sells “demolition screwdrivers” designed to be used as prybars and chisels because that’s what people do with them: https://www.homedepot.com/p/Milwaukee-5-16-in-Slotted-6-in-D... - akin to modifying a program for the use case vs the original designed purpose).
Any long tool with a flat end is a prybar, some just happen to be able to screw screws as well!
In all seriousness, most enormous flathead screwdrivers are intentionally designed to work as a prying tool. Now, do that with an insulated screwdriver and you might as well prepare yourself for the cable whipping from your senior.
In all seriousness, most enormous flathead screwdrivers are intentionally designed to work as a prying tool. Now, do that with an insulated screwdriver and you might as well prepare yourself for the cable whipping from your senior.
Free beer is highly successful go figure.
There is nothing about the UNIX command line that isn't done better by REPL based environments.
There is nothing about the UNIX command line that isn't done better by REPL based environments.
this article is really old and I think UNIX and links are not just for huge construction
Before the current company that I'm working with (they forced me to use mac for day to day jobs, we can call this Unix as well but I don't like it), I used to use Linux for everything. Literally everything. My da is old but even he is comfortable with Linux distributions... But I liked the way this Author described Unix
> Pre-Hole Hawg, I used to examine the drill selection in hardware stores with what I thought was a judicious eye, scorning the smaller low-end models and hefting the big expensive ones appreciatively, wishing I could afford one of them babies. Now I view them all with such contempt that I do not even consider them to be real drills--merely scaled-up toys designed to exploit the self-delusional tendencies of soft-handed homeowners who want to believe that they have purchased an actual tool.
killshot. this is what unix is like.
killshot. this is what unix is like.
That quote is more a description of a particular sort of UNIX enthusiast than of UNIX itself
as Stephenson describes, almost no one is fit to judge. those who have had the revelations know, and those who critique without having immersed themselves, those who defend their gaudy high end consumer drills: they speak from false positions. they speak without having glimpsed the greater truer thing.
it does describe both unix & the unix enthusiast. we get to know our tools, there is apparent & unadorned solidity to them and a truthfulness in interactions & capabilities beyond what the gussied up consumerized product could create.
but yeah. upvoting ya for sure.
it does describe both unix & the unix enthusiast. we get to know our tools, there is apparent & unadorned solidity to them and a truthfulness in interactions & capabilities beyond what the gussied up consumerized product could create.
but yeah. upvoting ya for sure.
the downvotes are making me laugh. my points are certainly not off topic, they're as on point as it gets. tell me why that's wrong.
If it is, then what is the real ACTUAL OS then?
The attitude is the user.
In Stephenson's analogy, the OS is the Milwaukee drill in question.
In Stephenson's analogy, the OS is the Milwaukee drill in question.
Unix, no?
C language is the Hole Hawg, IMO. UNIX is just the hole(s).
OK, fine, so let's go with it.
Since my impression is that HN people are [a] xNix fans [b] often quite young therefore [c] have little exposure to other OSes, let me try to unpack what Stephenson was getting at, *in context*.
The Hole Hawg is a dangerous and overpowered tool for most non-professionals. It is big and heavy. It can take on big tough jobs with ease, but its size and its brute power mean that it is not suitable for precision work. It has relatively few safety features, so that if used inexpertly, it will hurt its operator.
DIY stores are full of smaller, much less powerful tools. This is for good reasons:
• because for non-professional users, those smaller, less-powerful tools are much safer. A company which sells a tool to untrained users which tends to maim or kill them will go out of business.
• because smaller, less-powerful tools are better for smaller jobs, that a non-professional might undertake, such as hanging a picture, or putting up some shelves.
• professionals know to use the right tool for the job. Surgeons do not operate with chainsaws. Carpenters do not use axes.
The Hole Hawg, as described, is a clumsy tool that needs things attached to it in order to be used, and even then, you need to know the right way or it will hurt you.
Compare with a domestic drill with a pistol grip that is ready to use out of its case. Modern ones are cordless, increasing their convenience.
One is a tool for someone building a house; the other is a _better_ tool for someone _living in that house._
That's the drill part.
Now, let's discuss the OSes talked about in the rest of the 1999 piece from which that's a clipping: https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
There are:
• Linux, before KDE, with no free complete desktop environments yet.
• Windows, meaning Windows 98SE or NT 4.
• Classic MacOS – version 9.
• BeOS.
Stephenson points out that Linux is as powerful as any of them, cheaper, but slower, ugly and unfriendly.
He points out that MacOS 9 is as pretty, friendly, and comprehensible as OSes get, but it doesn't multitask well, it is not very stable, and when a program crashes, your entire computer probably goes with it.
He points out that Windows is overpriced, performs poorly, and is not the best option for anyone – but that everyone runs it and most people just conform with what the mainstream does.
He praises BeOS very highly, which was 100% justified at the time: it was faster than anything else, by a large margin. It has superb multimedia support and integration, better than anything else at the time. It was standards-compliant but not held back by it. For its time, it has a supermodern OS, eliminating tonnes of legacy cruft.
But it didn't have many apps so it was mainly for people in narrow niches, such as music production or maybe video editing.
It was manifestly the future, though. But we're living in the future and it wasn't. This was 23 years ago, nearly a quarter of a century, before KDE and GNOME, before Windows XP, before Mac OS X. You need to know that.
What Unix people interpret as praise here is in fact criticism.
That Unix is very unfriendly and can easily hurt its user. (Think `rm -rf /` here.)
That Unix has a great deal of raw power but maybe more than most people need.
That Unix is, frankly, kinda ugly, and only someone who doesn't care about appearances would choose it.
That something of this brute power is not suitable for fine precision work. (Which it still mostly isn't -- Mac OS X is Unix, tuned and polished, and that's what the creative pros use now.)
Here's a response from 17 years ago: http://garote.bdmonkeys.net/commandline/index.html
Since my impression is that HN people are [a] xNix fans [b] often quite young therefore [c] have little exposure to other OSes, let me try to unpack what Stephenson was getting at, *in context*.
The Hole Hawg is a dangerous and overpowered tool for most non-professionals. It is big and heavy. It can take on big tough jobs with ease, but its size and its brute power mean that it is not suitable for precision work. It has relatively few safety features, so that if used inexpertly, it will hurt its operator.
DIY stores are full of smaller, much less powerful tools. This is for good reasons:
• because for non-professional users, those smaller, less-powerful tools are much safer. A company which sells a tool to untrained users which tends to maim or kill them will go out of business.
• because smaller, less-powerful tools are better for smaller jobs, that a non-professional might undertake, such as hanging a picture, or putting up some shelves.
• professionals know to use the right tool for the job. Surgeons do not operate with chainsaws. Carpenters do not use axes.
The Hole Hawg, as described, is a clumsy tool that needs things attached to it in order to be used, and even then, you need to know the right way or it will hurt you.
Compare with a domestic drill with a pistol grip that is ready to use out of its case. Modern ones are cordless, increasing their convenience.
One is a tool for someone building a house; the other is a _better_ tool for someone _living in that house._
That's the drill part.
Now, let's discuss the OSes talked about in the rest of the 1999 piece from which that's a clipping: https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
There are:
• Linux, before KDE, with no free complete desktop environments yet.
• Windows, meaning Windows 98SE or NT 4.
• Classic MacOS – version 9.
• BeOS.
Stephenson points out that Linux is as powerful as any of them, cheaper, but slower, ugly and unfriendly.
He points out that MacOS 9 is as pretty, friendly, and comprehensible as OSes get, but it doesn't multitask well, it is not very stable, and when a program crashes, your entire computer probably goes with it.
He points out that Windows is overpriced, performs poorly, and is not the best option for anyone – but that everyone runs it and most people just conform with what the mainstream does.
He praises BeOS very highly, which was 100% justified at the time: it was faster than anything else, by a large margin. It has superb multimedia support and integration, better than anything else at the time. It was standards-compliant but not held back by it. For its time, it has a supermodern OS, eliminating tonnes of legacy cruft.
But it didn't have many apps so it was mainly for people in narrow niches, such as music production or maybe video editing.
It was manifestly the future, though. But we're living in the future and it wasn't. This was 23 years ago, nearly a quarter of a century, before KDE and GNOME, before Windows XP, before Mac OS X. You need to know that.
What Unix people interpret as praise here is in fact criticism.
That Unix is very unfriendly and can easily hurt its user. (Think `rm -rf /` here.)
That Unix has a great deal of raw power but maybe more than most people need.
That Unix is, frankly, kinda ugly, and only someone who doesn't care about appearances would choose it.
That something of this brute power is not suitable for fine precision work. (Which it still mostly isn't -- Mac OS X is Unix, tuned and polished, and that's what the creative pros use now.)
Here's a response from 17 years ago: http://garote.bdmonkeys.net/commandline/index.html
Appreciate what you’re saying but you may be interested in the historical origin of the chainsaw; it was indeed invented for surgery. https://youtu.be/Y6zPlk7drac
OK, yes, fair point. I did know this horrifying factoid, although I only learned it very recently.
[deleted]
Careful observers will notice that the Milwaukee Tool Company also sells other tools. I don't think anybody in the drill department of the company thinks that you should use a drill to cut a tree or trim a hedge.
More precisely the Hole Hawg is for a particular kind of hole - large pipe-size holes in framing lumber.
No contractor would use a Hole Hawg to drill 1/4” holes in something - maybe quarter feet. The amount of adapters you’d need to even get it able to reliably hold a 1/4” bit precludes it.
The point of the analogy remains - both tools can do things others can’t and both can easily “get away” from you.
But the real lesson is learning that the normal drill (and operating system) can also get away from you, and you may be less braced for it when it happens.
No contractor would use a Hole Hawg to drill 1/4” holes in something - maybe quarter feet. The amount of adapters you’d need to even get it able to reliably hold a 1/4” bit precludes it.
The point of the analogy remains - both tools can do things others can’t and both can easily “get away” from you.
But the real lesson is learning that the normal drill (and operating system) can also get away from you, and you may be less braced for it when it happens.
If an OS is a drill, what is the equivalent type of software for those construction tools?
Off the top of my head:
- ACID compliant data storage is not something that operating systems excel at, databases are much better. (I've seen some monstrosities where somebody tried to use the filesystem as a database and eventually they always got horrible race conditions and data corruption). This is a table saw; extremely good at one specific thing (rip cuts), can do other types of things in a pinch (cross cuts for table saws, db-as-a-job-queue for databases) and is absolutely rubbish for other things like drilling holes.
- Going up in complexity: Most operating systems I've seen are relatively self-contained on a single box. The OS controls everything on the box and no other OS-es exist on the same server. If you have a large multi-server system the OS typically does not provide too many capabilities except a low level networking stack, something like Erlangs BEAM VM or Kubernetes fills up the gaps to make all the operating systems work together properly. This would be like a CNC machine; large, complex and expensive but very worth it from a certain scale onward.
- Going down in complexity: Embedded systems are often too small for a proper operating system and implement everything they need themselves. Realtime operating systems exist but are often not a good solution for the constraints. This might be something like an impact wrench, super specialized for a specific type of small job.
- ACID compliant data storage is not something that operating systems excel at, databases are much better. (I've seen some monstrosities where somebody tried to use the filesystem as a database and eventually they always got horrible race conditions and data corruption). This is a table saw; extremely good at one specific thing (rip cuts), can do other types of things in a pinch (cross cuts for table saws, db-as-a-job-queue for databases) and is absolutely rubbish for other things like drilling holes.
- Going up in complexity: Most operating systems I've seen are relatively self-contained on a single box. The OS controls everything on the box and no other OS-es exist on the same server. If you have a large multi-server system the OS typically does not provide too many capabilities except a low level networking stack, something like Erlangs BEAM VM or Kubernetes fills up the gaps to make all the operating systems work together properly. This would be like a CNC machine; large, complex and expensive but very worth it from a certain scale onward.
- Going down in complexity: Embedded systems are often too small for a proper operating system and implement everything they need themselves. Realtime operating systems exist but are often not a good solution for the constraints. This might be something like an impact wrench, super specialized for a specific type of small job.
There was a very similar text regarding models of powerful chainsaws and text editors, does anybody have a link to it?
EDIT: found it https://randsinrepose.com/archives/the-foamy-rules-for-rabid...
EDIT: found it https://randsinrepose.com/archives/the-foamy-rules-for-rabid...
Unix is more like a shotgun than a hole hawg. It solves all problems, not necessarily correctly but quickly enough and reliably enough to go home and do something else. Sometimes it hurts you when you fire it and sometimes you lose a couple of toes if you don’t know what you’re doing.
The last line of the article is a killer because I’m writing this on an Apple unix system on a train at the moment after balancing my books.
The last line of the article is a killer because I’m writing this on an Apple unix system on a train at the moment after balancing my books.
> They might use Apple/Microsoft OSes to write letters, play video games, or balance their checkbooks, but they cannot really bring themselves to take these operating systems seriously.
As a pdp11 v7, vax 4.1bsd, 4.2bsd, Cray unicos and Unix 32V user I am slightly bemused by this because to all intents and purposes Darwin is unix
If he means "we feel a bit tawdry using a GUI" well sometimes, yes, except SunView and X10R4 and the blit and gnot and perq are kind of out there. I liked the perq. And Ultrix.
I think Stephenson has kind of walked off the reservation a bit. Even plan9 fanatics use a gui.
"In the beginning was the command line" is better.
As a pdp11 v7, vax 4.1bsd, 4.2bsd, Cray unicos and Unix 32V user I am slightly bemused by this because to all intents and purposes Darwin is unix
If he means "we feel a bit tawdry using a GUI" well sometimes, yes, except SunView and X10R4 and the blit and gnot and perq are kind of out there. I liked the perq. And Ultrix.
I think Stephenson has kind of walked off the reservation a bit. Even plan9 fanatics use a gui.
"In the beginning was the command line" is better.
Neal Stephenson admitted that he had switched to OS X in a 2004 Slashdot interview: https://slashdot.org/story/04/10/20/1518217/neal-stephenson-...
"You guessed right: I embraced OS X as soon as it was available and have never looked back. So a lot of 'In the beginning was the command line' is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely."
Given that Stephenson didn't stick with CLI himself, the repostings of "In the Beginning was the Command Line" really should have ended long ago.
(As an aside, the interview is worth a read, particularly his response to "In a fight between you and William Gibson, who would win?")
"You guessed right: I embraced OS X as soon as it was available and have never looked back. So a lot of 'In the beginning was the command line' is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely."
Given that Stephenson didn't stick with CLI himself, the repostings of "In the Beginning was the Command Line" really should have ended long ago.
(As an aside, the interview is worth a read, particularly his response to "In a fight between you and William Gibson, who would win?")
That is not surprising, you see the cargo cult in Linux circles about the "UNIX way", when the actual UNIX clones, those that actually descend from AT&T and BSD code linage, never followed it to the letter.
Following it to the letter would be a sign of cargo culting.
Which is exactly what happens in GNU/Linux world when something comes out that doesn't do it, and gets bombarded about not being the "UNIX way".
This is from "In the Beginning was the Command Line"; more specifically it's section 11 of such. So this was written by 1999 at the latest, before Apple had released any consumer Darwin-based operating systems...
> I am slightly bemused by this because to all intents and purposes Darwin is unix
The oldest version of this article in the wayback machine is from 2003, but I see a reference from 2001 here:
https://arstechnica.com/civis/viewtopic.php?f=20&t=912937
So I suspect it's from before the introduction of OS X.
The oldest version of this article in the wayback machine is from 2003, but I see a reference from 2001 here:
https://arstechnica.com/civis/viewtopic.php?f=20&t=912937
So I suspect it's from before the introduction of OS X.
The 'article' is just lifted from https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
which was published in 1999
which was published in 1999
Ah that makes sense, it seemed familiar. Shame it's not credited on the page.
[deleted]
In order to engage the subject matter of the article, I'm going to pin down the definition of Unix as some POSIX-compatible server OS with some Unix shell running on top of it. I think this encompasses most of the worlds' server infrastructure that runs some variant of Linux. The article implies that Unix is superior to Windows because people use it for real work as opposed to just diddling about in some graphical application.
This is a massive misrepresentation. While bare-bones Unix is well designed for simple scenarios, like running a server with ethernet and disk access and static hardware and yields itself to implementing Unix-style shells with fork() and pipes, it is not enough OS for a proper desktop environment. In other cases, it is too much OS. I remember designing and writing software for an embedded voice recording system for railway dispatchers, which had things like remote ethernet configuration, writing the recordings to a FAT32-based SD card on a 60MHzish uC with 128k flash and 64k RAM. It had no OS, everything was running on the bare metal. Going back to my previous example, if one images running a single web server process in a VM container, one could just design some hypothetical architecture, that allows you to do this with all the low-level stuff is put into a small statically linked library, and the app is the OS itself.
Imagine plugging in a USB bluetooth dongle to play some music on your headphones. In response the OS needs to load some drivers, start the bluetooth service, tell the audio service to output audio to your headphones etc. Windows can do this out of the box. Linux can be made to do this, either with a massive proprietary Android task or systemd/pulseaudio/bluez/whatever if you're in the open-source world. At this point Linux can be hardly called a Hole-Hawg.
The perceived superiority of Unix also leads to the false conclusion about Android/macOS/Desktop Linux being superior to Windows (or any other hypotethical fully fledged OS). In order to handle the massive complexity imposed by the complex scenarios, the systems themselves have to be complex as well, with varying success. I'm willing to bet, most of the code that allows me to write this comment on macOS on a HW accelerated GUI using a bluetooth keyboard is part of the Apple-monolith and has nothing to do with Unix/POSIX. The same applies to the other "Unixes" I mentioned earlier.
Imagine plugging in a USB bluetooth dongle to play some music on your headphones. In response the OS needs to load some drivers, start the bluetooth service, tell the audio service to output audio to your headphones etc. Windows can do this out of the box. Linux can be made to do this, either with a massive proprietary Android task or systemd/pulseaudio/bluez/whatever if you're in the open-source world. At this point Linux can be hardly called a Hole-Hawg.
The perceived superiority of Unix also leads to the false conclusion about Android/macOS/Desktop Linux being superior to Windows (or any other hypotethical fully fledged OS). In order to handle the massive complexity imposed by the complex scenarios, the systems themselves have to be complex as well, with varying success. I'm willing to bet, most of the code that allows me to write this comment on macOS on a HW accelerated GUI using a bluetooth keyboard is part of the Apple-monolith and has nothing to do with Unix/POSIX. The same applies to the other "Unixes" I mentioned earlier.
This has to be taken in the context of the time. This is the era of Apache on a low end Pentium being able to survive slashdotting whilst IIS on NT 4 would fall over on much grander hardware.
Arguably much of the difference can be attributed to being able to get Windows running easily - forgoing the painful process of having to learn what you’re doing (and at the same time learning how to tune it and where the slowdowns might be).
We’re now in a much different world. (Arguably the main difference remaining is that a Linux comes with “everything” whereas the others need out-of-band installations: in the 90s those things cost money whereas they were free on Linux - compilers used to be a pay product!)
Arguably much of the difference can be attributed to being able to get Windows running easily - forgoing the painful process of having to learn what you’re doing (and at the same time learning how to tune it and where the slowdowns might be).
We’re now in a much different world. (Arguably the main difference remaining is that a Linux comes with “everything” whereas the others need out-of-band installations: in the 90s those things cost money whereas they were free on Linux - compilers used to be a pay product!)
I'm not arguing for the superiority of Windows, I'm pretty sure Linux+Apache was superior back then to Windows+IIS and is superior now. However, you could probably play audio, open a Word document and play 3D accelerated games on said NT box - not necessarily things you'd want to do, but the complexity to support these use cases was there anyway.
My point is, full-fat desktop OS-es are much more complex beasts that a bare-bones Linux server install, that probably is a bunch of init-scripts and a server process on top of the kernel. Once you try to turn a UNIX into a desktop OS, it'll have the same problems as Windows, for the same reasons.
My point is, full-fat desktop OS-es are much more complex beasts that a bare-bones Linux server install, that probably is a bunch of init-scripts and a server process on top of the kernel. Once you try to turn a UNIX into a desktop OS, it'll have the same problems as Windows, for the same reasons.
Personally, I hate the Hole Hawg story. It reeks of pretentiousness and gatekeeping, and worse, the description of the Hole Hawg isn't even accurate. "A cube of metal"? That's not what a quick image search shows. "You screw a second handle in"-- except that the second handle is already there. "It's not sleek" -- again, a image search shows a perfectly normal handle with a perfectly normal grip.
The Unix command line has a lot to recommend it. Notably, the simple ergonomics of the pipeline are indeed great (other OSs have similar pipeline concepts; they just don't get used the same way because they are too clunky).
The Unix command line has a lot to recommend it. Notably, the simple ergonomics of the pipeline are indeed great (other OSs have similar pipeline concepts; they just don't get used the same way because they are too clunky).
Here are a few pics from ebay. Note that the story is 22 years old and he worked in the 1980's so he may be thinking of an even older design than the one I found. It's not like literally a cube but it's notably more cube-like than any consumer drill, and the handle shown here looks like regular pipe with a rubber handle. I really don't think you should take writing like this literally.
https://i.ebayimg.com/images/g/FHcAAOSwLfVg0K4w/s-l640.jpg
https://i.ebayimg.com/images/g/LosAAOSwZS9g2quf/s-l1600.jpg
https://i.ebayimg.com/images/g/c1EAAOSwmAhg~B-F/s-l1600.jpg
https://i.ebayimg.com/images/g/U-kAAOSwT4Ng~B-Z/s-l1600.jpg
https://i.ebayimg.com/images/g/FHcAAOSwLfVg0K4w/s-l640.jpg
https://i.ebayimg.com/images/g/LosAAOSwZS9g2quf/s-l1600.jpg
https://i.ebayimg.com/images/g/c1EAAOSwmAhg~B-F/s-l1600.jpg
https://i.ebayimg.com/images/g/U-kAAOSwT4Ng~B-Z/s-l1600.jpg
As an old electrician, the description was accurate. Look at a Makita HR2470 for comparison to a normal power drill.
The handle has to be removed after every use if you want to put it back in it's case.
The handle is just pipe with a rubber handle at the end, whereas most tools use molded plastic that slides over the chuck.
And yeah, the body is a cube of metal, as opposed to large unibody plastic castings.
The handle has to be removed after every use if you want to put it back in it's case.
The handle is just pipe with a rubber handle at the end, whereas most tools use molded plastic that slides over the chuck.
And yeah, the body is a cube of metal, as opposed to large unibody plastic castings.
Decades have passed and it has gone beyond the cold rooms to our warm pockets. It still works tirelessly. You can still depend on it. It has changed its shape and wears colours if you want it to. But deep down, I know it to have the same kernel of truth. If you want to talk to it in those ancient grunts, it will still answer back. And that to me still is the most beautiful language.