Everyone should, at some point, read The Unix-Haters Handbook. A great deal of it is outdated or simply wrong, but it does have a running theme of a prediction that has largely been borne out: people assuming that all Unix's flaws are actually virtues and that if you don't think so, then you Just Don't Get It.
It's not hard to see how this happened: since pretty much all computers that people normally interact with are either running Windows or a Unix-like system, it has set up a dichotomy in people's minds. When the Unix-Haters Handbook was released, there were still other operating systems which could have a plausible claim to being better, but they have all faded away, leaving only these two. And since the "Real Hackers" prefer Unix, Unix and all its decisions must be the right ones.
Unix is great, but people need to be more realistic about its shortcomings instead of mindlessly repeating mantras about "The Unix Way" without critical examination.
I love motorcycles too. I've owned many sophisticated bikes: Ducatis with their strange Desmodromic heads. With the ability to dial an exchange of torque to horsepower at the handlebars. Buells with their fuel-in-frame chassis. My current Suzuki even has 4 sensors in the airbox alone. One that measures the air input pressure. One that measures the oxygen level. One that measures the air temperature. Really amazing performance. It will be in a junkyard within ten years though. I won't be able to find those sensors in a few years.
So all that new and advanced technology doesn't really interest me anymore. I'm looking for a 1969 Honda CL350 right now. They're still around and running fine. They're much simpler and much more maintainable. No Engine Computer. No sensors. Everything really easy to understand.
I kinda want my OS like that too. With all its warts I can keep it running.
> It will be in a junkyard within ten years though. I won't be able to find those sensors in a few years.
Not true. You will be able to get an aftermarket ECU that can just ignore the sensors and run in open-loop mode. That will be exactly the same as running with carburetors: fixed fuel/air ratio that is almost always wrong. This is also the failure mode for OBDII cars - sensor failures lead to the ECU running in open-loop mode, which lowers MPG and increases emissions, which will eventually foul the catalytic converters.
> I'm looking for a 1969 Honda CL350 right now. They're still around and running fine. They're much simpler and much more maintainable.
My wife has owned a CB175 and a CB550. Both required tons of work and were maintenance nightmares. They really are piece of shit bikes when it comes to reliability when compared to most Japanese bikes from 1990 onward. The prices old Honda bikes command on the market are completely out of whack with what you get because of strong demand from both the vintage bike enthusiast and hipster demographics. I would not ride one if it was given to me for free.
Maintenance "headaches" are part of the appeal of old bikes. It's much easier to learn how an internal combustion powered vehicle works on an old Honda bike than a new one, or on a new car.
Compared to other bikes of their day these are very simple to maintain and they were designed from the start to be kept running by the average person. It really depends on what you are looking for in a bike.
If enjoying turning a wrench on a Saturday makes me a hipster then pass the beard wax.
There is weekend wrenching and there is dealing with design flaws and poor manufacturing. Problems with the CB175 and CB550 that were not regular maintenance (carburetor/timing/valve/etc/etc) related:
* fast cylinder wear (poor materials/manufacturing, engine rebuilds all around)
* unreliable electric system ("mostly" fixed on CB550 with Charlie's solid state ignition and rectifier)
* Leaking gaskets (design flaw)
I know a lot of vintage Honda collectors and a few racers, and also a lot of vintage BMW collectors. BMW motorcycles from the same era do not have these problems.
What gaskets leaked? Side covers? I haven't had a problem with side cover gaskets but I did have some replacement non-JIS screws back out because they were not torqued properly. Can't speak to cylinder wear, my bike has close to 10k hard miles and doesn't compression test real well but does work fine.
Old side cover gaskets did, those were easy to replace. Something else was leaking before the engine rebuild, and then something else entirely started leaking after the rebuild.
I used to share your opinion, but hours of searching for no longer-made parts and obscure wrench sizes and other tools that often simply don't exist anymore cooled my enthusiasm somewhat (fixing 1960s camera lenses)
All the fasteners I have seen are standard metric sizes, what speciality tools are you referring to? The side cover screws can be stubborn but even a Philips #3 with an impact driver ($20.00 at the pawn shop) pops them right off. Conversion kits to standard allen head screws are cheap, on the order of $50.00 for the whole engine.
There is a special nut on the oil spinner but that's the only specialty tool I can think of on the bike until you start actually disassembling the whole thing and you don't even have to remove it to do an oil service. I guess the shock/steering head adjuster is a specialty tool? But that was included with the bike so not hard to find either.
Parts can be a bit harder but since these things were so popular it's a lot easier than any other bike from 1969. Also the aftermarket is huge if you don't care about staying totally stock.
To clarify, using three easy outs instead of the right tool is kind of like saying config files are flawed because they have to be edited. Tools are created for a job and it is up to us as engineers to use them properly.
i should really say the PO who stripped the engine bolts with a phillips head instead of a JIS driver made it kind of inevitable. 40 year old machines are interesting.
Most of the screws I have seen are trashed from people using screwdrivers instead of impact drivers. Even with the proper JIS bit the screws will still be ruined if you don't use an impact type tool. There's just no way to apply enough axial force to the fastener with a normal hand tool, even if the shape is correct.
That's what the impact driver is for. I didn't have to convert any bolts to metric, all those are already metric. Only the screws need to be converted.
Newer than 1990 doesn't mean fuel injected and sensors out the wazoo. I have a 2001 Bandit and it's brilliant, same power and fuel economy as the current model and pure old fashioned air cooled carbie goodness. Nearly 70k kms and the mechanic reckons it'll be good for as much again.
Exactly. 1990s carbureted Japanese bikes are far superior to 1970s ones in reliability both in terms of design and manufacturing quality. But CL550s go for more than Super Blackbirds. The only reason is the steep vintage/hipster markup.
The Bandit is a good example that parts availability has nothing to do with the technology used and everything to do with the market. My bike is actually a 2001 Bandit 600. The 2nd generation 1200 sold well in the United States, the 2nd generation 600 never did. The 1st generation 600 did sell. So there are a ton of aftermarket 1st generation 600 parts availabe in the US, but pretty much the only new replacement parts you can get for the 2nd generation 600 here (that are not in common with the 1200 or SV650, if you can figure out which ones those are) are rebuild kits for the off-the-shelf brakes and carbs, and you can get the gaskets cut. Everything else you either have to import from the UK or get custom-made, which usually ends up being cheaper (things I have had custom made: throttle cables, fork tube).
Did Honda even build a CL550? Was that a huge parallel twin or a four cylinder scrambler? Never heard of either of those configurations from Honda.
Do you mean CB550? If so they demand a higher price because they are 1) older and 2) look way better. Super Nighthawk performance isn't much to write home about relative to newer bikes for the same price and vintage bikes look really nice.
Now is probably a great time to pick up a Super Nighthawk because as with almost all vehicles their value drops off continually for their first 20 or so years until they are truly part of a previous generation of vehicles that is no longer available. Then the value starts to rise again due to scarcity.
We saw the same thing in the 90s with 1970s domestic cars which peaked in the 2000s. It's happening now with 1980s Japanese cars and has been happening to 1970s and 80s Japanese bikes.
As it stands, the Suzi's input pressure sensor is malfunctioning (a $200 part where available) and the bike backfires and splutters badly. So I'm not convinced that an open loop mode ECU won't end up with an engine fire or a hole in the piston.
Other folks have mentioned that the mechanical points can be swapped out for a solid state ignition on the CL, closing that loop of maintenance for starters.
My solution to carburetor issues on my CL was to replace the carburetors with another design from Mikuni. You do have the option to swap a megasquirt system on to your bike and then use sensors that are cheaper or more readily available. I'm not sure if that would be easier or not but it is an option and it is something that will become increasingly more common as "new" bikes become "old" over the next 10 or so years.
Interesting comment. Got to say I agree with the direction of it, to some extent - stable and powerful over newfangled and weak / unstable / buggy / done for glory rather than substance.
Do you know about the Royal Enfield Bullet [1] from India?
It is not at all as technologically sophisticated as the bikes you mention and others, but it is a fantastic bike to ride.
They are selling it in the West, too, from some years. Originally from the Enfield company, UK, then was manufactured in India for many decades (maybe starting around WWII), as the same standard model. Then a decade or more back, the new managing director invigorated the company with better quality, newer models, higher engine capacity (cc) models (like 500 cc), etc. - though I would not be surprised that some fans prefer the old one still - maybe me too, except not ridden it enough, I rode a 250 cc Yezdi much more - also a great bike, almost maintenance free, a successor to the classic Ideal Jawa bike from Czechoslovakia, and also made in India for many years. Yezdi was stopped some years ago, last I read, but the Bullet is still going strong and even being exported, a good amount, to the West.
My cousin and two of his friends recently did New Delhi - Brussels[0] on 1971, 1973 and 1974 Royal Enfields.They made it but they got a lot of mechanical problems. I guess that was part of the fun ;)
I almost bought a Bullet Classic 500 (sold with injection in Europe). It is probably much more reliable but it is probably a bit too limited for a 100km daily commute.
I went with a modern Triumph Street Twin instead. The mechanic told me he had to plug the bike to the computer to start it the first time. I don't know if he was joking but it made me feel uneasy.
Hey, Royal Enfield! My uncle was behind the company that was the sole distributor of Royal Enfield for Australia/NZ for a good decade or so (sold the business a few years ago).
I have a 1973 CL350 which I am currently getting back on the road. They are fantastic bikes, largely because they are robust, dead simple and Honda made tens of thousands of them. Having said that, they did have some components that have not aged well.
The number one flaw on these bikes in my opinion is the stock carburetors. Honda used a constant velocity type carburetor which in theory provides very smooth throttle action and is easier to ride. In reality the vacuum diaphragm is a very delicate part that frequently fails with tiny air holes that leak vacuum, causing a mismatch in the throttle input between the cylinders (twin carb two cylinder, one per cylinder). This is a similar failure mode to your modern Suzuki air pressure sensor failing.
The other pain point is the mechanical points in the ignition system. This is an area of constant fiddling with adjustment and new condensers. It's much preferred to simply replace the points system with a "modern" (1980s technology) electronic ignition system. This removes the moving parts and greatly extends the life of a tune-up.
Old bikes are super cool and the 350 platform is a fantastic one but even back then bikes had "high tech" parts that did not age well and gaps where better tech had not been invented. The great thing about the 350 platform is that due to its popularity people are still coming up with solutions. In this way a Honda 350 is similar to Unix.
What OS would be analogous to the Honda in your example? OpenBSD? Plan9?
Not Linux, surely. That would be more like the Suzuki, but it used to be an older bike so they left the carburetor in there and next year someone will add an electric motor too.
Any free software OS can meet his requirements as they all are transparent to anyone with the time to learn, just like the older bikes. The problem with modern bikes is that all the advanced tech is proprietary and you have no way of understanding it or tinkering with it.
IMO you can take any modern distro and strip it down to something understandable. It just takes some time to learn how to strip it down and how what's left works (and this is ongoing, as things are always changing). I'm not saying it's trivial, but neither is learning how to rebuild a motorcycle.
All systemd related processes (dbus, systemd-*, init, etc) running on my system are using < 25Mb of memory. So that is a bit excessive, even if exaggerating for effect.
I don't normally get into these, but this is blatantly false, I'm running systemd on multiple older/smaller computers like an OG Raspberry Pi and an old netbook, and I don't even notice its memory consumption.
I still have my 75 MHz Pentium 12MB EDO RAM laptop running Windows 95 and holding my old BBS sitting in my drawer. Battery is shot but plug it in and it still works.
I've used OpenBSD in the past and found it much simpler than Linux. But didn't always support what I needed to do. These days I'm doing less but doing it better.
I've always found the problem with alt os's is that I have to pick my device to match the OS. I just want a small but adequately powerful laptop, so Linux is my only real choice.
Occasionally when I run out of analogies for why convoluted systems are not 'flexible', I reach for a half-remembered homage, that I encountered as a teenager, about the Chevy Straight 6.
This was not a fancy engine. It was not a particularly powerful engine. Not a single thing on it or about it was exceptional. Because it was easy to work on and with add-ons and modifications it could be coaxed into doing things it wasn't really meant to do. It was just solid and got out of your way. So engineers and hobbyists tinkered and tinkered and got something over 2.5x the original horsepower out of the thing.
Unix commands might be solid, but the 'get out of your way' bit is what troubles me. People will lament otherwise good engines that are hard to work on because of a design flaw or the way they're laid out. Unix is falling down here. It's just that everyone else is at least as bad. But a guy can dream.
The single most disastrous failing of UNIX is the assumption that everyone wants to be a programmer - or if they don't want to be a programmer, they damn well should become a programmer anyway.
It's nonsense. Programming as it's done today - which is strongly influenced by UNIX ideas - is the last thing most users want to do. They have absolutely no interest in the concepts, the ideas, the assumptions, the mindset, the technology, or the practical difficulties of writing software.
UNIX set human-accessible computing back by decades. It eventually settled into a kind of compromise at Apple, where BSD supplied the plumbing and infrastructure and NeXT/Apple's built a simplified app creation system on top of it, which could then be used to build relatively friendly applications.
But it's still not right, because the two things that make UNIX powerful - interoperability and composability - didn't survive.
They were implemented in a way that's absolutely incomprehensible to non-programmers. Opaque documentation, zero standardisation for command options, and ridiculous command name choices all make UNIX incredibly user hostile. Meanwhile the underlying OS details, including the file systems and process model - never mind security - fall somewhat short of OS perfection.
The real effect of UNIX has been to keep programming professional and to keep user-friendly concepts well away from commercial and academic development.
Programming could have been made much more accessible, and there's consistent evidence from BASIC, Hypercard, VBA, the HTML web, and even Delphi (at a push) that the more accessible a development environment is made, the more non-developers will use it to get fun and/or useful things done.
UNIX has always worked hard to be the opposite - an impenetrably hostile wall of developer exceptionalism that makes the learning curve for development so brutally steep it might as well be vertical.
UNIX people like to talk about commercial walled gardens as if they're the worst possible thing. But UNIX is a walled garden itself, designed - whether consciously or not - to lock out non-professional non-developer users and make sure they don't go poking at things they shouldn't try to understand.
But it has to be. Linux can be super powerful. You can get very close to the metal. While a lot of people want to use it as an appliance, it really isn't. Just like all the other trades there is history which begets convention which begets culture. And like any good power tool you've got to know what you're doing, or you could get yourself into trouble.
The problem, I think, is that we seem to have trouble conceptualizing the schism that exists between the computing-as-a-tool users (aka the elites, power users, and programmers) and computing-as-an-appliance users (aka the computing mainstream). Both camps have wildly different wants, needs, and expectations.
Why can't both continue to exist separately? The elites don't want their tools weakened, and the mainstream just wants stuff to work. Split computing down the middle at desktops+laptops vs tablets+mobile+consoles and keep the separation clean. Now that we have iPads and whatnot there's no reason to keep nontechnicals on a PC if they don't want to be there... so why not let PCs return to the nerds?
> UNIX set human-accessible computing back by decades. [...]
I do not agree at all. Closed-garden non-free eco systems like Windows set back computing.
> Programming could have been made much more accessible, and there's consistent evidence from BASIC, Hypercard, VBA, the HTML web, and even Delphi (at a push) that the more accessible a development environment is made, the more non-developers will use it to get fun and/or useful things done.
So why are they not going strong? There are implementations for BASIC for most systems and even Delphi is still available.
> [...] But UNIX is a walled garden itself, designed - whether consciously or not - to lock out non-professional non-developer users [...]
Assuming with UNIX you mean implementations today (like Linux) this is not true at all.
I do not want to say Unix (with BSDs and Linux today) is the absolute best we can do, but I am pretty sure that it is on a local optimum in the operating systems space.
I agree with a lot of what you wrote. It's true that there is a "keep it for the elite" mindset in the back of many programmers' mind. For years at forums I've seen that while I tried hard to explain basic concepts to newbies, others were happier with the RTFM answer.
Still I'm not so sure that UNIX (or programmers) is the source of it. I started with DOS (later Windows) and TP (later Delphi) so please don't think I'm biased here.
I have recently bought an Acer convertible for my mother with Windows 10 and so I'm getting a reality check on the sad state of computer usability in 2017. Teaching her to use an Android phone was difficult, but this is not better.
IMHO the reason of user-hostility is not some guild mindset, it's just that computer adoption is needed much faster than the time it would take to develop decent GUIs. The RTFM knee-jerk reaction comes later from people with some deep insecurities and not much imagination.
Totally agree on that UNIX is also a sort of walled garden. I'd say the same thing about GPL'd ecosystem, in this case for license issues.
I'd guess that much of this depends on who's writing the software. FOSS was (and still is to a great degree) driven by "nerds" in their spare time. If there's no Steve Jobs that smacks programmers about for neglecting the user experience for non-technical users, it won't make much progress. At other places (say Redhat) there's no big need to focus on non-technical users for business reasons when it comes to much of development. And so on and so forth.
If you can accredit Apple with one thing, it would be that they got this mainly right.
When it comes to Windows... I guess that's the result if one main player has a de facto monopoly over a certain software space. That, and "legacy reasons". It's like Adobe who couldn't even get their hotkeys merged between various of their big applications.
I've only owned a Mac and honestly I hasn't found it really better. Actually I was surprised to find there are unsolvable user hostility problems like font size. For most Windows annoyances there were usually some registry key that you can touch.
Yeah... I've found Mac/iOS to be quite frustrating actually. Especially nowadays that their UI's a designed by designers who like things to be pretty — and you just can't change something no matter how bad it is (unless you want the touchpad to move the scrollbar instead of the page. they'll let you do that, even tho it's completely useless. they're not opposed to choice or flexibility, just opposed to ones that make things understandable or powerful at the expense of pretty).
all of your arguments here - pro or con - are reflections of philosophy and have nothing to do with computers
> The single most disastrous failing of UNIX is the assumption that everyone wants to be a programmer - or if they don't want to be a programmer, they damn well should become a programmer anyway.
this presumes programming (which itself is simply logical thinking) is something obscure and 'scary'. Elementary school computer literacy courses in the mid-late 80s/ early 90s routinely taught more programming know-how to adolescents than college graduates have today. Is this because kids are stupid? or has the goal of curricula been relegated from 'high level understdanding and knowledge' to 'economic productivity within the present system'?
> The real effect of UNIX has been to keep programming professional and to keep user-friendly concepts well away from commercial and academic development.
really? is that why UNIX minis rapidly displaced mainframes in the late 70s/early 80s, with major advances primarily being derived from the cross-compatibility of most unix flavors being shared within industry and academia? Or is this another argument towards 'economic productivity within the current sytem' ?
> Programming could have been made much more accessible, and there's consistent evidence from BASIC, Hypercard, VBA, the HTML web, and even Delphi (at a push) that the more accessible a development environment is made, the more non-developers will use it to get fun and/or useful things done.
a) by evidence, you're referring to cross-linked excel spreadsheet nightmares?
b) by evidence, why does this not include all of the literally millions of interpreted
programs in say shell, awk, TCL, and so on written by unix users in professional
settings across time?
c) compare shell scripting to batch scripting. seriously. Also, the web was invented
on Unix.
d) See also use of lisp, etc. in the 80s for pretty much the same things
I argue that the issues you are speaking about here primarily derive as a result
of the workstation Unix market focusing on the higher end, while the low end grew
on the PC side - which has nothing to due with the Unix tradition itself, which
due to licensing issues with AT&T, etc. was relegated to somewhat obscurity
during the heavy capitialization of the PC market of the 80s.
> UNIX has always worked hard to be the opposite - an impenetrably hostile wall of developer exceptionalism that makes the learning curve for development so brutally steep it might as well be vertical.
Really? Is that why, from nearly day 1, the entire system was distributed on
a single tape with complete binaries, sources, and manual pages contained on
the same, self-hosting installation?
Again - while lesser users will use their knowledge of the system as some
narcissistic playing card, this is their own personality flaws being interjected
into the philosophical difference I mentioned previously (achieving knowledge vs
brutish ad-hoc productivity)
> UNIX people like to talk about commercial walled gardens as if they're the worst possible thing. But UNIX is a walled garden itself, designed - whether consciously or not - to lock out non-professional non-developer users and make sure they don't go poking at things they shouldn't try to understand.
Again, I think this supposition is derived from the growth of the commercial
Unix market, which deliberately split source code and documentation into tiny
little fragments, only some of which could be even attained in the first place,
and could only be run on proprietary hardware. Unix itself (the portable software system)
grew in a mostly obscure, tangential lineage that was then 'walled off' from naive
end users through marketing efforts of proprietary vendors. See also BSD UNIX.
> Opaque documentation, zero standardisation for command options, and ridiculous command name choices all make UNIX incredibly user hostile.
yes, things are inconsistent. but that is because the system grew organically.
I give much kudos to VMS for being very solid and coherent in this regard -
but that was just as much a walled garden as anything else, and still is (though
interesting things could still come from the OpenVMS company)
nothing precluded anyone from bolting on a coherent addon to the unix base,
and indeed many did. However they failed because unix is not a product,
but a product of organic human culture -
and so ones qualms with unix are really ones unresolved qualms with human endeavor itself.
Like my Moto Guzzi from the 1970ies. It is so simple built, you can adjust the valves during a gas stop.
There is a great virtue in simple design, it seems to be forgotten nowadays. Like the famous Russian rocket engineer Koroljow (built Sputnik) said: Everyone can build complicated
I did similar with cars, though I still have the ECU to deal with. Eventually I'll replace that with a Megasquirt, because I can repair/replace all the components and know how the whole system works.
When I thought I wanted a bike, I looked around for a Condor A350.
This kind of thing comes up a lot in discussions of operating systems, and while you and I might want to get "under the hood" the majority of users never want to do that, and know they don't know what they'd be doing if they got there. And accept that a sealed system might be safer (more secure) for them. Being able to maintain it yourself is a benefit, but having to maintain it when there's another maintenance-free option is unappealing.
Hence UNIX (of a sort) is actually quite popular on both iPhones and Android - but not in ways accessible to the user. Even if you do have to replace Android devices every few years because the manufacturer won't maintain them either.
I have a Kawasaki KLR 650. Kawasaki has been selling pretty much the same bike since 1987. No fuel injection or ABS. They are very inexpensive (new ones can be had for about $6000). There's a running joke in the community that every year the main update on the new model is bold new graphics.
Spare parts are easy to find and there are a lot of aftermarket parts.
The downside is that the bike is basically a late '80's bike. 40ish horsepower, poor fuel economy, weak brakes, poor handling, etc...
But, like lots of people say, it's more fun to drive a slow bike fast than a fast bike slowly. I love it.
The famous "each tool does just one thing well" mantra is also a depressingly overblown myth. Among the current Unix tools, there is a ridiculous amount of overlap.
That's why we have both "ls" and "find", even though they do the same thing conceptually. "ps" has column output, but the way it formats, sorts, selects etc. columns is reinvented and not transferable to other tools such as "lsof" and "netstat", not to mention "top", which of course is just a self-updating "ps". Every tool invents filtering, sorting, formatting etc. in their own unique way. The various flags are not translatable to other tools.
I've never used Powershell, but it seems to get one thing right that Unix never bothered to. Tools should emit data, or consume data, or display data, but tools should never do all three, because they will invariably reimplement something poorly that has been done elsewhere.
Powershell did one thing wrong, in that its tools emit objects, not data. In other words, they emit data with behavior (methods). This, in turn, imposes the CLR object and memory model on the whole thing, and makes the pipeline impossible to use between distinct processes.
The right way to do this is to pick some reasonable text-based structured interchange format - s-exprs, JSON, whatever. Actually, it wouldn't be a bad thing to have a binary protocol as well, so long as all that complexity is negotiable, and is implemented by the standard library.
The problem here is that most unix tools (ls being the exception) do double duty, they both emit output for other programs and output for the user. Which one you get and how the user output is presented being controlled by flags.
If you want them to only emit data in a standardized format you are implicitly cutting out the user.
Since direct use by a human is arguably the main use case, output formatting needs to be reindtroduced somehow. You could make some adapter that you always pipe into that handles most formatting concerns but it's unlikely that it will be truly general.
The only general way to do that is for the tool to output, along with the data, also some code that can be used to properly format the data.
So there are only three ways to solve this:
* Unix solution, with tools doing double duty and each tool having its own incompatible set of flags
* Actual programming language solution, tools emit pure data. Great for programming, bad for interactive use.
* Powershell solution, programs emit data+code: you are locked into some VM.
> If you want them to only emit data in a standardized format you are implicitly cutting out the user.
This is only true if your shell just dumps the raw output as is. But it doesn't have to do that! If we have a standard structured data format for the output, then the shell can be the one to format it. The key point here is that formatting only needs to happen at the very last step of the pipeline, when it is known that the output is about to be displayed to the user.
Indeed, this is exactly what PowerShell does, and that bit does not require data + code. It just formats lists of objects into neat tables, using their metadata to generate headers.
Note also that this doesn't need to be baked into the shell itself. It can be a separate utility, that sucks in structured data, and outputs formatted user-friendly representation. So in a legacy shell, you could still do:
$ ls | fmt
and get more or less the same output that you see from ls today (but if you were to do just ls, you'd get JSON). Whereas in a new and fancy shell, you'd get |fmt appended automatically at the end.
This, by the way, is also how PowerShell does it, except that fmt is called Out-Default.
Another option is to check what stdout is hooked up to – if it is hooked up to a terminal output something human readable, if it is hooked up to a pipe output something machine readable like JSON. (Actually, a number of utilities do this terminal-vs-nonterminal check already – e.g. GNU ls with --color=auto).
One problem I've seen with this approach in practice, is sometimes you want the human readable output to go to a pipe. For example, when you use jq, it does syntax highlighting of JSON when talking to a terminal, and omits it when talking to a pipe or a file, but then you want to use a pager which understands ANSI escape sequences (e.g. less -R), so now you have to pass an option to tell the command to output ANSI escape sequences even though it is talking to a pipe not a terminal (e.g. jq -C).
I wish there was a standard mechanism in Unix for the two ends of a pipe to negotiate about what data format goes down the pipe – MIME type, character set, etc. Then if I was piping jq to less, jq could ask less "do you understand ANSI color escapes?" And less could reply "yes I do please send them". Then I wouldn't need to remember to pass -C to jq and -R to less. (Maybe this could be implemented as ioctls at each end, by which the sender transmits a list of MIME types it supports, and the receiver replies by choosing one of them...)
Less supports setting options in the LESS environment variable, so if you set LESS='-R' in your .bashrc/whatever, you don't have to pass -R to less. (If you do `jq foo | LESS='' less` for the rare times you need less to not behave that way.)
Sadly, it doesn't seem like jq will read an environment setting to always specific -C
There's an easy solution for that, although it requires a richer pipe API.
Let each pipe actor, including the terminal/shell, decide what to do. Between each stream, they can rely on a MIME type and additional metadata to make decisions. For example, if you do:
generate_data | parse_csv | sort
Here, generate_data produces text/csv, parse_csv consumes it and emits application/json or whatever, and sort consumes it. The hypothetical "sort" command wouldn't know what to do with text/csv, so it could default to line-based text.
"sort" then emits JSON again, and rather than displaying unfriendly JSON, the terminal/shell combo would see that the final output stream is JSON and invoke a pre-defined presentation handler. For example, there could be a global handler installed that rendered JSON as a table.
Or you could insert a different formatter yourself:
Since fancy_table_formatter emits text (probably some specific terminal MIME type so we can signal that it can include things like ANSI escape codes), the shell doesn't need to do anything except display it.
> most unix tools (ls being the exception) do double duty, they both emit output for other programs and output for the user. Which one you get and how the user output is presented being controlled by flags.
Which is where they fundamentally break the principle of "doing one thing, and doing it well". Formatting output for user should be a separate step (even if implicitly handled by your shell).
You just need to output formating instructions, not code.
Read that imagining "formating instructions" as data that will be consumed by a default visualizer that the shell automatically pipes at the end of your command in interactive sessions.
I'm sure there's a general architecture for such thing. If no better choice is available, it can be done with plugins.
Agreed. One huge benefit to a text format is that you can generate small "ad hoc" snippets (e.g. echo) easily. Otherwise I'd love something like Protocol Buffers here.
You would have to be prepared for a flood of data then, if I type get-printer I get a handful of useful properties, if I add ConvertTo-Json then I get 385 lines.
"Each tool does just one thing well" doesn't mean "just one tool does one thing". In fact, ETDJOTW means that interoperable alternative tools -- loose coupling -- is more readily supported. So that, say, you can transparently migrate from unsecured rsh to secured ssh. Actually: you can even gain capabilities, since rsh is (misfeature) limited to the 512 low-numbered ports, and hence, a maximum of 512 outbound connections. SSH has no such limitation, and can scale far higher as a management tool.
(That bug, and option, was what finally convinced one old-time shop to swap in SSH for RSH for such tasks, after I identified the problem and the solution.)
A better example would be "one tools" that do many things. Rob Pike suggested Perl, though IMO that's kind of foolish: Perl is Yet Another Programming Language, and programming languages, rather by design, tend to do multiple things (not always, or not always easily: see sed as an example of both caveats -- text replacement or branching code).
Other examples are generally nexus points of complex interactions. Editors (most especially Emacs). Email management (communications protocols, format protocols, ties to DNS, anti-spam, filtering, remote-access (POP and IMAP), extensions, authentication (at various levels), encryption (at various levels). The problem domain is complex, so the tools are complex.
The tool you're very likely using right now to read this would be another case in point: the Web browser. Not just for CERN any more.
That's one interpretation, but it's not really what people mean when they refer to "one tool". The progenitor of the expression is Doug McIlroy:
This is the Unix philosophy: Write programs that do one
thing and do it well. Write programs to work together.
Write programs to handle text streams, because that is a
universal interface.
Interoperability is part of DOTADIW idea, but it flows from the "one thing": If each tool does one thing, you can compose them using pipes. Of course, interoperability also implies tools can be swapped out, though as with DOTADIW, it's more of a myth than reality, because reality isn't that simple.
"ls" lists files in a specific path while "find" searches for objects in a file system that match a specific query.
Are you sure you're not confused and somehow assuming that "does just one thing well" should mean "another tool must not accomplish anything that might be remotely achievable by misusing another tool"?
Both "ls" and "find" "list files in a specific path" and "search for objects that match a specific query". There's total overlap. The difference is that "ls" is a presentation-oriented tool, whereas "find" is geared towards pipelines.
It even has an anti-foreword by Dennis Ritchie which kinda reminds me of the Metropolitan Police spokesman's blurb on the back of Banksy's book.
BTW, it starts off with an anonymous quote that I've never heard, Two of the most famous products of Berkeley are LSD and Unix. Unix is of course from Bell Labs. And anyone who knew anything would have said instead, Two of the most famous products of Berkeley are LSD and BSD which at least would have been funny if still inaccurate. Anyways, it seems like a fun rant of a book which I'd never heard of.
The above point about not getting it can be applied to Linux as well. Lessons learned elsewhere are stupid until Linus finally understands them and then they're obvious.
The whole document is great but the anti-forward is so good I'm going to risk downvotes by reproducing it in its (short) entirety here, emphasis mine:
From: dmr@plan9.research.att.com
Date: Tue, 15 Mar 1994 00:38:07 EST
Subject: anti-foreword
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 com- patible 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!
Thank you for posting this here; I absolutely love that anti-foreward, and it was life-changing for me in that it offered shelter to those of us who were defending Unix during a very, very dark time (namely, the mid-1990s). I have also (shamelessly) cribbed dmr's beautiful closing metaphor of a fecal pie and its "undigested nuggets of nutrition" -- it seems to just describe so much that is not entirely devoid of value, but it utterly foul nonetheless.
How were the mid-90s a dark time for Unix? Every engineers desk at every place I worked and every d/c I deployed to, it was the the only option (I avoided the AS-400, workhorse that it may well have been). Now, which Unix (HPUX, Solaris, AIX, IRIX) caused some angst, depending on the use-case...
IBM had developed OS/2, but was unable to effectively market it, in large part due to the intransigence of its development partner, Microsoft, who had other designs.
Microsoft was of course pushing Windows NT as the full and total replacement for Unix at the mid-server level. I'd actually bought that as my own first personal computer OS, and found it utterly and totally inadequate. Installing Redhat from a bookstore CD started me on my path (though I'd previously used Unix at uni and various jobs).
AT&T were busily suing the crap out of BSD over 1-800-ITS-UNIX, and losing, but setting back both commercial and BSD Unix by about 4-5 years.
Linux emerged during this period under constant FUD assaults by Microsoft, most of the mainstream Unix vendors, and pretty much everyone else.
And Apple was very much in its Dark Age, with OSX (Now MacOS) not due for release until 2002.
Unix was in use, especially in technical shops: scientific, software design, areospace, chips, etc. But it was deprecated in much of the corporate world over mainframes, minis (I cut my professional teeth on VMS), and early Microsoft variants. AS/400 was more an industrial and controls system.
And yes, proliferation of somewhat incompatible Unix variants (and how and/or where you installed the GNU toolchain on same) was another question.
That's not what I was trying to communicate. Rather that the options for online systems were generally: Mainframe, Mini (usually DEC), or Unix. Also, this was pre-Web "online", meaning for the most part in-house processing support.
I can attest to at least one case of VMS being retained in favour of Unix, which was retired. In the mid-1990s.
> 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.
Research Unix, yes. But the culture of unix is much bigger than some single copyright holder... this is why the entire thing is plain stupid. Study the levenez family tree. Read the archived Usenet posts and get a copy of the Cuckoos Egg.
> since pretty much all computers that people normally interact with are either running Windows or a Unix-like system, it has set up a dichotomy in people's minds
I really wish undergraduate Software Engineering programs included a course that was a survey of operating systems, where you'd write the same program (that did a lot of IPC) on, say, base WinNT (kernel objects with ACLs!); base Darwin (Mach ports!); a unikernel framework like MirageOS; something realtime like QNX; the Java Card platform for smart-cards; and so forth. Maybe even include something novel, like http://genode.org.
There are interesting parallels between operating systems and political parties here, and this is not a coincidence: both operating systems and political parties are infrastructure, and infrastructure is really hard both to build and to replace once it has become established. So in both cases you see a lot of rationalization about how the existing solutions are perfectly OK even though they are not simply because no one wants to do the heavy lifting (and in both cases it is very heavy lifting) required to actually come up with something better.
Political parties present an abstract view of how society works that simplifies the complexity of the underlying system. It offers a set of interfaces that allow a large mass of untrusted individuals to influence the whole.
Interestingly, nearly all third parties differentiate themselves by offering up even more simplistic abstractions, even more inflexible and unfalsifiable. It seems to be a core part of human nature to look for comfort in such abstractions.
Well, if you don't get that someone else might see something as a flaw then perhaps you wouldn't understand that you may be defending a bad design choice.
I use Rust. There's a bunch of things I do not like about Rust. Its macro language is nigh on unusable. A macro language should be an expedient; it should allow you to get textual things done, committing necessary atrocities along the way knowing that the result must still pass muster with the compiler. It isn't supposed to remind you of a 61A midterm.
I like the safety and that is why I use Rust. I don't get adding functional programming to a systems programming language.
M4 is a standard POSIX utility and it's Turing complete. It's difficult to out-class recursive string macro expansion for sheer simplicity and sheer ability to confuse the heck out of yourself.
Alas, while it's a mandatory POSIX utility (AFAIU), some Linux distributions have saw fit to remove it from base installs.
I never said Rustaceans don't see flaws or that they don't defend bad choices. But I've never seen someone say "if you don't think so, then you Just Don't Get It" or any variant thereof in the Rust community.
It exists, although it's often phrased more kindly. For example, complaining about lifetimes is often met with a comment that you probably don't understand them yet.
I'm prefacing this by saying I think Rust is a very well-designed language, and AFAIK the best-designed language that currently exists in its problem space. Nevertheless there are aspects I'd consider design flaws and that fans have been known to dismiss with hand-waving or condescending lectures about type theory. That's a human problem, very much not a problem with the Rust community; in particular I'm quite impressed by how polite and helpful members of the Rust core team are — and not just Steve Klabnik — in every interaction I've seen them in.
1) The syntax is pretty bad; I would put it around the same level as Perl. It's simultaneously ugly, verbose and cryptic. It's especially indefensible given the obvious ML influence on the language. The superficial similarity to C++ syntax is more misleading than helpful and I think actually increases the learning curve.
2) Like the other guy said, the macro system might be technically impressive, but I feel like you shouldn't have to be some kind of Lex/Yacc guru to write or even read a macro definition. Sure, it's fully type-safe, but so is template metaprogramming — compared to which Rust macros somehow manage to be even less readable. There should at least be an easier syntax for simple, C-like macros.
Ok, they're aimed at a different problem space than C macros — they let library authors create sophisticated DSLs — but my impression's the current consensus is "non-idiomatic embedded DSLs considered harmful." Also, Rust is soon to have at least two other macro languages (attributes, and generics with specialization and value parameters), which is a whole lot of cognitive overhead to introduce.
3) All the `.iter()` and `.iter_mut()` is verbose and could easily be inferred from context by both humans and the compiler. If it truly must be explicit — and allowing implicitness as an option doesn't preclude allowing explicitness as well — then introduce new method call operators to go along with the dot operator.
4) I don't think there were compelling enough reasons to abandon the most technically amazing achievement of C++ compilers: zero-cost exceptions. It's the one case I can think of where Rust forces a solution with a runtime cost compared to C++, even in unsafe code. It's also one of the few places where C++ offers higher-level abstractions than Rust. (I'd consider exceptions a higher-level abstraction than Results; of course, higher-level != better).
Arguments based on purity are borderline nonsensical since Rust is not a pure language, the type system isn't aware of side effects, and it's the only case where purity is prioritized over performance. I can respect the idea that errors are either nonserious and so should be handled in the normal control flow of the program, or serious enough to merit a full-blown panic, but I also lean towards the view that it's better to trust the programmer than remove tools from their toolbox.
5) Related to 4, I think Rust should've been designed with C++ binary compatibility as a first-class goal. Yes, this is very difficult, and would require compromising aspects of the language design. But it would be an enormous boon to Rust's adoption rate (and especially the goal of replacing unsafe code in the wild with safe code) if C++ projects could easily be incrementally rewritten in Rust, and it were possible for Rust to directly use C++ libraries and APIs.
---
(Yes, this list of issues is not internally consistent; the point is that addressing any of them in isolation would be an improvement).
> All the `.iter()` and `.iter_mut()` is verbose and could easily be inferred from context ... If it truly must be explicit — and allowing implicitness as an option doesn't preclude allowing explicitness as well — then introduce new method call operators to go along with the dot operator.
When you design your language based on feel on not based on principles that guide what should be defaulted to, you end up with a language that fits only very specific people. Designing based on principles allows people to learn the principles and then use intuition to guide them to in the direction of the correct feature or solution.
You pointed out the list is inconsistent. In my experience, when people have inconsistent feeling a about something that was designed with a consistent methodology, that's because they haven't yet grasped or accepted that methodology and are trying to shoehorn their ideas from other systems into it without recognizing there may already have been a very conscientious decision made about exactly those issues, and likely with more information to base the decision on.
> Rust should've been designed with C++ binary compatibility as a first-class goal. Yes, this is very difficult, and would require compromising aspects of the language design. But it would be an enormous boon to Rust's adoption rate
There are plenty of languages that sacrifice in the name of adoption. Too much and it's useful in the short term, but a losing proposition in the long term. Too little and you may never see enough adoption for it to matter (barring other sources of adoption).,
IIRC the reason not to detect overflow by default in release builds isn't any variant of "You Just Don't Get It", it's rather "yes we'd like to do that but unfortunately there is a trade-off with a significant runtime performance hit, so we don't, for now".
To defend VMS, if you have to have an always up with hot backup and multi-machine cluster that you can upgrade without affecting the cluster, OpenVMS is quite nice.
As a developer, it was a bit painful, but the whole file versioning was handy sometimes.
It's not hard to see how this happened: since pretty much all computers that people normally interact with are either running Windows or a Unix-like system, it has set up a dichotomy in people's minds. When the Unix-Haters Handbook was released, there were still other operating systems which could have a plausible claim to being better, but they have all faded away, leaving only these two. And since the "Real Hackers" prefer Unix, Unix and all its decisions must be the right ones.
Unix is great, but people need to be more realistic about its shortcomings instead of mindlessly repeating mantras about "The Unix Way" without critical examination.