Wow, now I see it is flagged. Lol, I really do not know why, probably people do not know what I was talking about, and I even put the quote marks. Maybe I had to sign who said that? lol But I found it was perfect for these kinds of posts.
As a sibling comment points out, the submission actually quotes from Richard Gabriel's Worse is Better. That, and the snarky tone of the comment may have been what caused people to downvote and/or flag the comment. 'swolchok could also have linked to the original, thus avoiding jwz's HN-referrer redirect.
I think the problem is that Linux developers started abusing the Unix Philosophy to the point that you had to know about a lot of different programs in order to be productive - Sometimes, it's much more convenient if one program can do everything that you want it to do out of the box (it requires less understanding of the system).
The Unix philosophy is essentially the opposite of the Apple philosophy. It gives you flexibility and composability at the cost of simplicity and the overall experience.
The optimal solution tends to be somewhere in-between. If you look at Linux, it's actually a monolithic system (which goes against the Unix philosophy); the popularity of Linux is in itself proof that people do want a single cohesive product - If the Unix philosophy was the best approach, we'd all be using Minix by now.
I didn't find MacOS to be any simpler than newbie-oriented Linux distros like Mint and Ubuntu. It was just filled with a ton of proprietary, bastardized, closed-source garbage and limits that made it more difficult for power users to understand and effectively manage the system.
To be fair Linux distros have improved a LOT in the past 5 years. When I first used Ubuntu many years ago, you couldn't do anything without the command line. Installing software was a pain (I had tons of problem with Ubuntu Software Center and it never seemed to work).
I use Ubuntu (Gnome) these days. The only thing I miss from Windows is Windows Explorer. Nautilus just doesn't cut it in my opinion; I always end up browsing the file system with the command line. That said, I still prefer Nautilus over OSX's Finder.
Of all the things to complain about in Linux, you choose the one thing that Mac OS and Windows still don't have right, and Linux had pretty good even back then?
Installation on Windows was always much easier; all programs had a relatively consistent UI wizard that stepped you through the installation process. Installing software from disks on Windows was really convenient (and disks where the real deal back then).
The fact that Linux relied on people to install stuff with the command line was a massive oversight. UIs are just way more intuitive than shell commands.
Perhaps the issue when comparing Windows and Linux is more one of "dependency management" than just merely installing applications or libraries? Although I've had issues with package managers screwing up dependencies in the past, it hasn't happened in a while and when it would have happened I was warned beforehand.
I've rarely disagreed with something said on HN so strongly (at least among things that, in the grand scheme of things, really don't matter that much, but they matter a lot to my personal experience).
"The fact that Linux relied on people to install stuff with the command line was a massive oversight. UIs are just way more intuitive than shell commands."
This has never been true in the past 12 years. You have to go back even further to find a time when there weren't multiple GUIs for the leading package managers. And, for at least the past decade, the core GUI experience on every major Linux distro has had some sort of "Install Software" user interface that was super easy and provided search and the like.
There's lots of things Linux got wrong (and some that it still gets wrong) that Windows or macOS got right. Software installation really just isn't one of them, IMHO.
It's the thing I miss most when I have to work on Windows or macOS, and I miss it constantly...like multiple times a day. A good package manager is among the greatest time savers and greatest sources of comfort (am I up to date? do I have this installed already? which version? where are the config files? where are the docs? etc.) when I use any system, particularly one I haven't seen in a while.
I just really love a good package manager, and Linux has several. Windows and macOS have none (because if the entire OS didn't come from a package manager, it's useless...you can't know what's going on by querying the package manager, if the package manager only installed a tiny percentage of the code on the system). So, even though there's choco on Windows and Homebrew (shudder...) on macOS, they are broken from the get-go because they are, by necessity, their own tiny little part of the system with little awareness or control over the OS itself.
Also, if your problem with non-Linux package managers is that they only know about and control their own packages, then you must have the same objection to Nix and Guix, right?
What happened to wanting simple tools that do one thing and one thing right? Don't we want package managers to only manage packages, to decouple them as much as possible from the rest of the operating system, and leave system configuration management to other tools?
I've blogged about some of my problems with Homebrew. Generally speaking, Homebrew is a triumph of marketing and beautiful web design over technical merits (there are better options for macOS, but none nearly as popular as brew).
I get that it's easy and lots of people like it, so I mostly try to hold my tongue, but every once in a while I'll see someone suggest something crazy like using Homebrew on Linux (where there is an embarrassment of good and even great package management options) and it makes me shudder. I'm not saying don't use Homebrew on your macOS system if it makes your life easier. I just would never consider it for a production system of any sort. I'm even kinda mistrustful of it on developer workstations (though there are plenty of similarly scary practices in the node/npm, rubygems, etc. worlds, so that ship has kinda sailed and I am resolved to just watch it all unfold).
"What happened to wanting simple tools that do one thing and one thing right?"
I still want that. Doing one thing right in this case means doing more than what packages on macOS or Windows do. One can argue about the complexity of rpm+yum or dpkg+apt, and it's likely that one could come up with simpler and more reliable implementations today, but if you want them to be more focused, I have to ask which feature(s) you'd remove? Dependency resolution? That one's a really complicated feature; a lot of code, and it's been reimplemented multiple times for rpm (up2date, yum, and now dnf). Surely, we can just leave that out. Or, perhaps the notion of a software repository? Is it really necessary for the package manager to download the software for us? I mean, I have a web browser and wget or curl. Verification of packages and the files they install, do we really need it? Can't we just assume that our request to the website won't be tampered with, and that what we're downloading has been vouched for by a party we trust? I dunno...I'm not really seeing a thing we can get rid of without making Linux as dumb as macOS or Windows.
"Don't we want package managers to only manage packages, to decouple them as much as possible from the rest of the operating system, and leave system configuration management to other tools?"
This is the strangest question, to me. Why on earth would we want the OS outside of the package manager? Why would we want to only verify packages that aren't part of the core OS? This is why Linux is so vastly superior to Windows and macOS on this one front. I'm having a hard time thinking of why having the package manager completely ignorant of the core OS would be a good thing. What benefit do you believe that would provide?
And, NixOS does not meet the description you've given. The OS is built with nix the package manager. Running nix as a standalone package manager on macOS does have the failing you've mentioned, but that's not the fault of nix. And, yes, nix is a better option for macOS than brew, but the package selection is much smaller and not as up to date in the general case...so maybe worse is better, in that case.
I get a bit ranty about package management. I spend a lot of time working with them (as a packager, software builder, distributor, etc.) and have strong opinions. But, I believe those strong opinions are backed by at least better than average experience.
> all programs had a relatively consistent UI wizard that stepped you through the installation process
No where near as consistent as installing from a package manager.
> The fact that Linux relied on people to install stuff with the command line was a massive oversight. UIs are just way more intuitive than shell commands.
Every user orientated distro has come with a GUI package manager for at least a decade, probably two.
Installing software from the distro is easy on Linux, but otherwise it's potentially a problem. Whereas Windows has no "distro" but the .msi system works quite well.
Pity Microsoft stopped bothering with .msi installers 10 years ago with Office 2007, and didn't bother to add any free ways to deploy all the new stuff they invented.
Re: macOS: I'm having a hard time seeing how copying a directory with everything necessary contained in it is not a good install procedure. Install a program: copy to the Applications folder. Uninstall a program: Cmd-Delete or drag to trash.
Compare to Linux, where a piece of software is scattered around /usr/bin, /usr/lib, /usr/share, /usr/doc. (Or /usr/local/*, you never know which) Oh, and those fun times where something depends on a libxxx.so.N but all that's on the system is libxxx.so.N.M.O and libxxx.so.N.M for some reason, so you have to make the symlink yourself. Or the distribution has a minimum of version N+1, so your option is to find the source for the library, figure out all the -devel packages it needs, and compile it up (hopefully), or just symlink libxxx.so.N to libxxx.so.N+1 and hope it works. And then the fun of figuring out what the package is named. pdf2text lives in poppler, who would have thought. Need gcc? That will be build-essential on Ubuntu last time I needed it. (Not build-essentials, either)
So, a tarball full of statically linked binaries. You can do that on Linux, too.
And, there are some new package managers that isolate in this way (and go well beyond it by containerizing). Flatpak is probably the most promising, IMHO. And, it still provides all the benefits of a good package manager, like verification, authenticity, downloading automatically from a repo, dependency resolution for core libraries. And, the way Flatpak handles the latter feature is really quite cool (and avoids having to distribute dozens of copies of the same libs).
Your description of installing packages on Linux does not match my experience in the past decade. Dependency resolution is a solved problem on Linux, at least on the major distros with good package managers.
Linux is not a monolithic system. It has a monolithic (sorta) kernel. There's a big difference. You're arguing monolithic kernels vs. microkernels. Microkernels didn't even exist when UNIX was invented, so no, they are not representative of "Unix philosophy". "Unix philosophy" is merely about the user-space tools you use to do stuff, since back in 1970 all they had was the shell (sh), and various tools like grep, ed, awk, etc., to do things.
It's entirely possible to have a microkernel with a Unix-like system; HURD attempts this. Microkernel vs. monolithic is an entirely separate issue.
I think the parent poster is talking about the userspace. A Linux distribution like Ubuntu that uses systemd, GNOME, and NetworkManager is certainly monolithic compared to Slackware circa 1999. NetworkManager alone is a pile of garbage that goes completely against Unix networking conventions, for IMO no good reasons. OpenBSD's approach to integrating WiFi and other network interfaces into the existing BSD network management commands is so much better.
Large monolithic apps can be an ecosystem in their own right that is broadly comparable to an OS. And it is common to find apps that adopt Unix philosophy out of necessity within the ecosystem. This is not obvious to an outsider, and requires an understanding of the domain.
A good example is ArcGIS which on the surface is ridiculously monolithic. But within the toolbox function are several hundred programs that do only one thing and are composable. This approach is also seen in video or image editing workflows where a user works with a particular set of tools. The main difference is that the programs use a types system that is appropriate to the domain rather than just text.
The OS only really exposes an interface for working with OS level objects. That sometimes aligns to a workflow but not always. And we should not expect disciplines to align their techniques to OS level objects if that is not a good fit for the actual domain.
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.
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 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.
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.
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".
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).,
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.
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.
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.
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'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.
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.
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).
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.
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.
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.
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).
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
> 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.
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.
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.
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.
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
> 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.
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.
> 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.
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.
IMHO, a lot of the Unix philosophy boils down to: we do it this way because the neckbeard of my father and the neckbeard of his father and all the neckbeards before him unto the beginning of Unix on January 1, 1970 did it that way and if you want to do it differently, well, you better have a stronger neckbeard, because then we'll have two problems instead of just one.
... i.e. a combination of "It's working, so let's not change it" coupled with a lack of the sort of market pressure having your OS compete in a money-changes-hands we-have-customers marketplace brings to the table to have a holistic, easy-to-convey user experience.
i'm still to see any complainer grown an adecuate amount of facial hair, though. (incompetently) reinventing some bad idea from before you were born does not cut it, you know?
Note: A “file handle” is a FILE *, i.e. a stream as used by a lot of the higher-level functions of the C library. The term you were looking for is probably “file descriptor”. (Or possibly “inode”, “directory entry”, or “file name”? It’s not entirely clear what you mean.)
There's such a problem with immaturity in tech. It's frustrating because it creates barriers to learning from others. No self-respecting person is going to want to learn from someone who has a "holier than thou" or "I'm a rockstar" mindset.
> There's such a problem with immaturity in tech. It's frustrating because it creates barriers to learning from others. No self-respecting person is going to want to learn from someone who has a "holier than thou" or "I'm a rockstar" mindset.
You wouldn't consider it to be immature to not do the right thing just because it was communicated in an unpleasant way that a 'self-respecting person' should have disdain for? I'm not talking about this particular article or defending immaturity, - I just don't see how your position is any better; more so it's just as unhumble as the 'rockstar position' since you would apparently be willing to write worse code just to avoid learning from someone that's an asshole.
It's your prerogative to follow trends to determine what you find worthy of your time or not, but it's not a good thing to suggest that anyone that tolerates that type of language better than you do or even enjoys it, lacks self respect.
A lot of people find that cockiness funny and find the informality welcoming. And many of those tend to find cold formality, fake humility or lack of self-confidence as signs of something being boring, uninteresting or outright creepy.
EDIT: Comment was edited, original:
It's hard to believe this came from a place of humor after reading the otherwise dry article. The article was otherwise fairly interesting, but that certainly left a sour taste in my mouth. He's lucky I read past the first paragraph, if it wasn't so prominent on HN I probably wouldn't have bothered listening to anything he had to say.
I guarantee you would not find it funny if I called you a cunt. Remember none of the rest of the article even remotely matches the tone of the sentences in question, and the content larges comes from a place of ignorance.
Actually there have been a couple of times when people called me a cunt and it was funny in context. Now granted, whether this article is that kind of context, is a different question.
As an hobbyist blogger, I can perfectly empathise with why the author wrote that. People love to crap all over a blogger who dares to post his thoughts on a private blog, without first subjecting it to PhD-thesis-level scrutiny. This really gets on my nerves for the same reasons that engineers get pissed off when they decide to open source a pet project and suddenly start getting "URGENT ASAP" feature requests from entitled users.
The author is taking the time to post his thoughts on a private blog. If you're not happy with the level of rigor, then don't read it, don't share it, and don't believe it. But no, the author has no responsibility to provide you with a comprehensive list of citations and references.
> "If you're not happy with the level of rigor, then don't read it, don't share it, and don't believe it."
What I don't like about that attitude is that it suggests that the blogpost should be excused from criticism of its rigor. But any assertion and opinion by anyone can and should be considered open to criticism.
> "But no, the author has no responsibility to provide you with a comprehensive list of citations and references."
Of course he is not responsible. But if someone expects or wants people to be convinced of their argument, then prefacing with his rude dismissal does not help.
A better way than "This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it." without the unnecessary rudeness and ego boosting could be more along your lines: "This article was written hastily and shouldn't be subject to PhD-thesis-level scrutiny, so I've posted without any expectation that I will improve it or respond to criticism."
> A better way than "This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it." without the unnecessary rudeness and ego boosting could be more along your lines: "This article was written hastily and shouldn't be subject to PhD-thesis-level scrutiny, so I've posted without any expectation that I will improve it or respond to criticism."
Sounds to me like you agree with the substance of what the author said, and just happen to disagree with the delivery. Keep in mind that different people have different writing styles, and people often post things like what you quoted in a tongue-in-cheek manner. Some people prefer a formal, humble style of writing. Others like a more humorous style, and others yet enjoy a Steven Colbert faux-braggadocious style. It would be unfortunate if we browbeat anyone who dares to inject some quirky humor into their writing.
No, he disagrees with the substance. Faux-braggadocio or humorous is fine! But if you earnestly think that's the writer's style after reading the last half of the first paragraph, seriously ponder why then none of the rest of the article matches that perceived tone.
The author makes a bunch of assertions that range from misinformed to straight-up wrong. There is 0% Steven Colbert-style self awareness. No one is lucky that it exists. When you engage in personal endeavors, do them for their own merits. And especially if you're doing something that no one and nothing is compelling you to, please at least try.
My favorite is when somebody makes a blog post "A Great Way to Do X in Unix" and then posts a bash script they wrote.
You can just start the countdown until all the unix greybeards come out and slams them with why it's so wrong and how to do it with some obscure bash feature.
I respectfully disagree with that last part. IMO it's your moral obligation as a distributor of information to, to the best of your ability, ensure its' truth and validity.
I'm not saying it has to be PhD-thesis-level, but if proven wrong you are morally obligated to update the information or remove it. Otherwise you are spreading false knowledge. This doesn't apply to opinions ofc (the bulk of private blogging).
Screw entitled users though, they should fix it themselves :)
Nothing can really be trusted without judgement, and as long it's not claiming to be an authoritative source about a life and death situation, I wouldn't want to put the bar as high as an obligation.
After 20+ years of working in the business and reading ridiculous amounts of articles, and some books, I can quite easily find clear errors or omissions in most everything written about computers and programming, Knuth excluded. If everyone were obliged to update to fix any errors, even only factual, it's likely that much - or even most - of all I've read would never have been posted for me to read in the first place, and I think both the world and I would be poorer for it.
Correctness is important, but so is the ability make judgments of validity, to critique, disseminate, inspire and express ones thoughts, even when they turn out to be wrong.
I'd have much more respect for him if he wrote an entire article about this and explaining his position than prefacing an otherwise unrelated article with his frustrations. I'm not lucky he wrote it. From my perspective he wasted his time writing it, because I don't care enough to read past the first paragraph.
I stopped posting code from side-projects I was done with, when it started taking on a maintenance life of its own, and getting angry emails. There was a simplicity of the time when you could put a tarball on an FTP server and post the path to the appropriate Usenix group: "Here's a tarball. Have at it. Or don't."
I can relate too. I once started a blog post with "if you don't like [it], go jump in a lake."
I was envisioning people nit-picking the lack of formality, when it was merely an enthusiastic, from-the-hip post.
A day later I realized that wasn't the best way to start things off with, and toned it down. But I get where he's coming from. And I'm grateful he took the time to write it. It was an interesting read.
The best thing to do as a "hobbyist/private blogger", sth. which I do on-and-off too, is to not have a comment system. Saves so much hussle. If someone cares enough, they can write an e-mail, which you can later publicise if you (and the correspondent) like.
For good or bad reasons, you made the right choice: the article was full of crap (bad understandings, lack of historical knowledge and just technical knowledge even about current tools versions, bad references, bias, repeating blindly wrong or outdated rants, etc.).
You could also have guessed it when you noticed it was a kid student showing up (and off) with a lengthy critic on the historical evolution of UNIX tools and others OSes and tools that he discovered a couple of years ago, while you possibly were using them and watching them evolve while he was still in his father's bollocks (and some of us (not me) were working on UNIXes while his father was a kid). You know what to expect in this case, especially if you remember having produced the same kind of over-confident and yet uninformed rant in your days :-) (I do :-D )
Yes, anything funny (even absurdist humor) is predicated on a kernel of truth. Quite odd, then, that the article contains so little well informed opinion and even less humor.
What bugged me more was the snippets designed to show how hard it is to write shell scripts. It looked like the author just didn't know enough about their tools:
>How to touch all files in foo (and its subfolders)?
I agree with the other commenters who think it's fine to write whatever you like on your own blog, I just feel that it went from interesting historical warts to bagging on legacy systems because they're complicated.
Although I agree that Unix is a big collection of hacks and well past its prime, the author displays several fundamental misconceptions of what he's talking about. Here's a few examples:
- Dirty hacks in UNIX started to arise when UNIX was released, and it was long before Windows came to the scene, I guess there wasn’t even Microsoft DOS at the time (I guess and I don’t bother to check, so check it yourself). At least he acknowledges that he's being incredibly lazy, and he shows the glimmer of an understanding as to why some of the things mentioned later happened: because Unix is from the early 70s, which were a very different time in computing & culture.
- Almost at the very beginning, there was no /usr folder in UNIX. All binaries were located in /bin and /sbin. /usr was the place for user home directories (there was no /home). Putting /home on a separate partition remains a pretty common thing to this day because users will tend to have greater storage requirements than just the root. /usr/bin and the like are the result of people realizing that this secondary larger disk is an acceptable place to put binaries and other files that aren't needed at bootup.
- In other words, if you’ve captured Ctrl+C from the user’s input, then the operating system, instead of just calling your handler, will interrupt the syscall that was running before and return EINTR error code from the kernel. That's not the kind of interrupt they're talking about.
- I’ve read somewhere that the cp command is called cp not because of copy but because UNIX was developed with the use of terminals that output characters very slowly. Yep, terminals that print on paper are pretty slow, as are 300 baud modems. I'm absolutely crushed I had to learn that 'cp' means 'copy'--it took hours to beat that into my head, and the thousands of keystrokes I've saved over the years are a small comfort (except to my rsi-crippled hands)
- The names of UNIX utilities is another story. For example, grep comes from command g/re/p in the ed text editor. Well, cat comes from concatenation. I hope you already knew it. To top it all up, vmlinuz — gZipped LINUx with Virtual Memory support. 'cat' comes from 'catenate', in fact. What would you name 'grep' instead? "searchregexandprint"?
- at least the main website of C that would be the main entry point for all beginners and would contain not only documentation but also a brief manual on installing C tools on any platform, as well as a manual on creating a simple project in C, and would also contain a user-friendly list of C packages This is one of the most ridiculous ones. You're talking about a programming language defined in the 70s, for Christ's sake. Lot of websites created in the 70s? There is a document with a good introduction to C, project examples, etc. and it's call The C Programming Language, a book by K&R. When Kernighan made another language a few years ago, yeah, he made a website for it--golang.org, it's one of the best project sites I've seen.
The article points out some legit problems in Unix, but even leaving aside the author's ESL challenges it's poorly-written, poorly thought-out, and poorly-defended.
Yeah, I found that one an especially weird gripe. Grepping was a new thing, so we needed a word for it. 'Grep' is short, easy to say and type, and relatively hard to confuse with similar words in the domain. Works for me.
I can unfortunately imagine a modern startup implementing it, and shudder at potential names my imagination is coming up with... Searchlr, the best way to search text! ReadMonkey, your personal pattern recognizer! I'll stop now.
> - Almost at the very beginning, there was no /usr folder in UNIX. All binaries were located in /bin and /sbin. /usr was the place for user home directories (there was no /home). Putting /home on a separate partition remains a pretty common thing to this day because users will tend to have greater storage requirements than just the root. /usr/bin and the like are the result of people realizing that this secondary larger disk is an acceptable place to put binaries and other files that aren't needed at bootup.
While I can't independently confirm Rob's claims, and he doesn't provide any citations, I do find them very believable – /usr was invented at Bell Labs because they were running out of space on their puny 1970s hard disks. (And an RK05 was small even by 1970s standards – the IBM 2314 mainframe hard disk, released in 1965, had a 30MB capacity; the IBM 3330, released in 1970, stored 100MB – of course, these disks would have cost a heck of a lot more than an RK05, and were likely not feasible for the UNIX team given their budget.)
If they had bigger disks (or the facility to make multiple smaller disks appear like one big disk) – it is less likely they would have split the operating system itself across two disks (/ and /usr). (Using separate disks for the OS vs user data was more likely even with bigger disks since that was common practice on systems at the time.)
(Some other operating systems from the same time period already had some ability to make multiple disks appear like one big disk. For example, OS/360 has the concept of a "catalog", which is a directory mapping file names to disk volume names; this means you can move individual files between disks without changing the names by which users access them. In their quest for simplicity, Thompson and Ritchie and co decided to omit such a feature from UNIX.)
If you look at Plan 9, you'll see /usr is once again the location of user home directories, and binaries go in /bin. In fact, /bin is a 'union' directory composed of /386/bin, /rc/bin, /usr/jff/bin, and any other places you've decided to put binaries.
Totally agree. The article doesn't show deep understanding of the actual problems.
- make's TAB "problem" as very first argument is not very convincing.
- The citations to back up the claim that a (possibly binary) registry database was better than small text files are just not backing up. There is nothing to defend a registry there. The quote is about fsync semantics which has nothing to do with registry. Btw. in my perception it's a widely accepted fact that a big-pile-of-crap database is a bad idea. And oh, I haven't ever heard of any problem with passwd/group/shadow/gshadow being text files. And if there were, the access method is actually abstracted away, it's easy to switch backends to something else (NSS). (there is a problem with these files though -- they are denormalized, and not all fields have clear meaning and some programs interpret some fields in weird ways.).
- Zombie processes. What's the problem there? They are just like file handles. Handles have to be closed before they are garbage collected. The actual problem is that you can't really "open" and "close" processes, only spawn new childs and the resulting hierarchy is not typically desired.
- "We call touch in the loop! This means there is a new process for each file. This is extremely inefficient." Yeah and why exactly is the shell to blame that you use touch in a loop? (apart from the fact that it's almost certainly not a problem).
> We call touch in the loop here (I do know that the code can be re-written with xargs, so that touch is called only once; but let’s forget about it for now, okay?)...This means there is a new process for each file. This is extremely inefficient. Code in any other programming language will work faster than this one.
WHAT THE HELL??? Did he just criticize Unix/POSIX for its inefficiency after willfully choosing a less efficient way?
He wrote
find foo -print0 | while IFS="" read -rd "" A; do touch -- "$A"; done
When we could have written the very fast and very readable and very simple
find foo -print0 | xargs -0 touch --
I'll put this up against the equivalent implementation in any language you choose.
Kernighan did not make Go. Go was created by Ken Thompson, Rob Pike, and Robert Griesemer. Kernighan did, however, write a book on Go, The Go Programming Language, with Alan Donovan.
Unix as we know it is almost 50 years of accretion - sh/bash is a great example of this. I think the Unix philosophy is still sound and alive, but the movement of technology means not everything that was universal before, is now.
There's a recurring theme (e.g. [1] among many examples) of comparing the Unix Way to the way of functional programming. Both prefer small things that do one thing and compose well.
What is missing in many cases is a concepts guide, explaining the key ideas, how to combine things, and what's possible in various subject areas.
For GUI programs, menus / toolbars used to be the concept guide: what they show is what's possible, and they offer context help. This is why a GUI feels friendly. It sucks at composability, though. Current mobile interfaces, unfortunately, tend to lack this.
If tiny GUI-oriented programs were easy to compose, had an easy way to save the composed state, and a number of daily-use programs bundled with an OS came in this form, providing example and reference, many people would consider following the suit, I suppose.
> For GUI programs, menus / toolbars used to be the concept guide
This simple fact seems like the key to getting the masses into computing. For something like 6 years (say 12-18) GUIs were the way I interacted with computers. Need to do something and learn about it? Go and explore the UI until you find the option. If the option has a shortcut printed, you will remember it eventually.
Sadly, GUI design is a quite separate discipline from software design. This means much open source software is missing GUIs. Those who write the software aren't always GUI designers. This also creates the mismatch between composing software and composing GUIs. As they are different disciplines, what it means to combine them means different things.
A decent stopgap is massive frameworking and standardization on GUI to make it easier for devs to get a GUI.
To get the really good stuff, commercial entities have the best position. They need their stuff to be usable by everyone, and this finances the hiring of GUI people.
There is the rare gen of a developer that can also do GUI right, but that only has value in the case of small projects. When projects grow, unless all devs have the GUI knack, you're gonna need some dedicated GUI people.
It would be great if we could get more GUI-oriented people into open-source stuff but it seems like they aren't as attracted to open-source as devs are. It might be because devs can be at the ground floor of a project, and GUI, almost by neccesity, comes later.
It's not perfect - I'd love to see a guide with more practical examples - but it does do a good job covering the basic philosophy and some of the history of why certain design decisions were made.
Have you tried the alternatives? They all suffer from various problems. e.g. I use fish but still write bash scripts for production systems - more so fish is perhaps too safe in being too close to POSIX for the improvements to make a great difference (vs the pains of breaking compatibility). Powershell? You might as well write python or ruby at that rate..
What I mean to say is that while there has been a lot of initial inertia from the previous technologies that make it hard to change, it's also true that the new technologies have failed to make large enough gains to warrant the pains of changing - this is precisely the demise of Plan9: it's not that it wasn't better it just that it wasn't better enough to warrant the huge expense of replacing old, working systems.
I'd like to posit that at least part of the problem is we're using a multi-user operating system on machines that are universally single-user. While it may be nice to have that option, is it realistic to think that many people are going to hand over their laptop/desktop machine to another person?
We're trying to use a server OS on a single-user machine, complete with all the management cruft that comes along with a server-based OS. Consequently, we don't bother re-thinking what the user needs vs. a sysop.
Windows did that, and look at the mess that got them into. Eventually they had to introduce UAC, essentially a simplified Unix-style permissions system.
There are many early UNIX design decisions that have outlived their shelf life by decades.
Probably the biggest one is that UNIX is, at bottom, a terminal-oriented multi-user time sharing system. This maps badly to desktop, mobile, and server systems. The protection model is a mismatch for all those purposes. (Programs have the authority of the user. Not so good today as in the 1970s.) The administration model also matches badly. Vast amounts of superstructure have been built to get around that mismatch. (Hello, containers, virtualization, etc.) Interprocess communication came late to UNIX/Linux, and it's still not a core component. (The one-way pipe mindset is too deeply ingrained in the UNIX world.)
Hence why UNIX on mobile is a Pyrrhic victory, as iOS, Android, ChromeOS rely on Objective-C, Java and JavaScript runtimes and their respective frameworks, just with good enough support from POSIX, that could be replaced by what is expected from any ANSI C implementation.
There is no Objective-C "runtime". (Well, there sort of is, but it's just a library, not a heavy-handed thing like you're thinking of). Unlike Android, iOS apps are just normal compiled ARM machine language binaries executing natively.
Yes, you have to use their APIs in order to write graphical programs, but the same is true on any OS with a GUI system.
It's possible to write iOS apps in pure C if you want to. Sure, that'd be a pain, but it's possible. Less painful and actually decently reasonable would be to write all the GUI-specific stuff in Objective-C and any other logic in pure POSIX-conforming C or C++, since you can mix all those languages freely in a project.
> The protection model is a mismatch for all those purposes. (Programs have the authority of the user. Not so good today as in the 1970s.)
I disagree, I think this is still the sweet spot between security and utility. Users have been trained to just click approve on any privilege escalation dialog.
The capability model is much more flexible. See Combex's desktop or "PowerBox's" for how simple it can be gor users to maintain POLA. Older system doing it was KeyKOS on IBM mainframes. KeyKOS + KeySAFE was strong architecture.
Agree, and we're slowly seeing more "capabilities lite" functionality in Unix-like OSes.
I think the next step is a capability runtime OS with a kernel personality for Linux for backwards compatibility. Sort of the converse of what we're doing right now.
> Suppose you were running a capability-secure operation system, or that your mail system was written in a capability-secure programming language. In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard.
In reality, users will get sick of being prompted every 30 seconds and learn to automatically approve every request. Capability security works well in theory, but I've never seen an implementation that works well in practice.
That's the keyword there. They don't actually demonstrate a lot of common apps and how the user is prompted. It sounds a lot like windows UAC with a default lock down. They don't even mention have permissions are permanently granted or not.
I don't think the terminal-based multi-user time sharing model maps poorly to servers, at the very least. In fact if you're going to pick one model for the general class of servers to run under, that's probably going to be the most versatile. Sure supercomputers and data centers may stand to benefit from a model that ignores all the multi-user features and such, but in architectures where each server is acting at least semi-autonomously (i.e. not under the control of what is essentially some distributed operating system such as Yarn, SLURM, etc.) I think you'd struggle to come up with a better model. This shouldn't be surprising as this is basically the exact use case that UNIX was built for.
> Some people think that UNIX is great and perfect
"...great and perfect" is a strawman. Whether "some people" think that is irrelevant.
Some of this article is interesting, but the fact of the matter is 40-year-old systems have signs of being 40 years old. If "fixing" everything were easy, it'd be done. Tabs in Makefiles throw off the uninitiated for 10 minutes, then they learn, shrug and move on. These scars and stories are part of the package.
Reading further, some of this is just incorrect...
>That’s not to mention the fact that critical UNIX files (such as /etc/passwd) that are read upon every (!) call, say, ls -l, are plain text files. The system reads and parses these files again and again, after every single call!
Not on my system.
> It would be much better to use a binary format. Or a database.
On my system, it is ( running "ls -ld ."):
kamloops$ uname -a
NetBSD kamloops 7.99.64 NetBSD 7.99.64 (GENERIC) #26: Thu Mar 2 07:15:26 PST 2017 root@kamloops:/usr/src/sys/arch/amd64/compile/obj/GENERIC amd64
kamloops# dtrace -x nolibs -n ':syscall::open:entry /execname == "ls" / { printf("%s -%s", execname, copyinstr(arg0));}'
dtrace: description ':syscall::open:entry ' matched 1 probe
CPU ID FUNCTION:NAME
0 14 open:entry ls -/etc/ld.so.conf
0 14 open:entry ls -/lib/libutil.so.7
0 14 open:entry ls -/lib/libc.so.12
0 14 open:entry ls -.
0 14 open:entry ls -/etc/nsswitch.conf
0 14 open:entry ls -/lib/nss_compat.so.0
0 14 open:entry ls -/usr/lib/nss_compat.so.0
0 14 open:entry ls -/lib/nss_nis.so.0
0 14 open:entry ls -/usr/lib/nss_nis.so.0
0 14 open:entry ls -/lib/nss_files.so.0
0 14 open:entry ls -/usr/lib/nss_files.so.0
0 14 open:entry ls -/lib/nss_dns.so.0
0 14 open:entry ls -/usr/lib/nss_dns.so.0
0 14 open:entry ls -/etc/pwd.db
0 14 open:entry ls -/etc/group
0 14 open:entry ls -/etc/localtime
0 14 open:entry ls -/usr/share/zoneinfo/posixrules
kamloops# file /etc/pwd.db
/etc/pwd.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)
Now, I see that /etc/group -is- a plain file. This could get the same treatment as /etc/passwd if it becomes a burden. In the meantime, if it's a performance bottleneck, make a memoizing function to lookup groups and use a '-n' switch to ls. Article is probably mostly important as the author thinking deeply about Unix, and part of the developmental process of the user.
...All the bluster (some of which is interesting), then at the end walks it back:
> So, I do not want to say that UNIX – is a bad system. I’m just drawing your attention to the fact that it has tons of drawbacks, just like other systems do. I also do not cancel the “UNIX philosophy”, just trying to say that it’s not an absolute.
Shame about the title... But maybe that's what landed it here on HN (?)
Regarding 'ls', I ran "strace ls" on Linux and didn't see any open on /etc/password; it's important that you run 'ls -l', which should trigger the /etc/password access because it has to map UIDs to usernames.
Understandable. The dtrace command you see is tracing a process "ls" (regardless of switches). I didn't show my work (ls -ld .) that generated the output, so your confusion isn't unfounded. :)
"This could get the same treatment as /etc/passwd if it becomes a burden. In the meantime, if it's a performance bottleneck, make a memoizing function to lookup groups and use a '-n' switch to ls."
Exactly, and this is the sort of thing that can be done with open source software. It may not even be a lot of code depending on how it is approached.
It's not even clear that for small password files, scanning /etc/passwd is any slower than a database. It's likely already in memory, and a full scan of a few kilobytes of text in highly optimized C is likely to take only microseconds.
"This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it. Therefore, I may provide some facts without source links."
I guess I am lucky he wrote this for a pleb like me.
Isn't that contradictory? If you start with the assumption that it's evolutionary, how does it make sense to judge whether selection pressure is "too weak" and that things "should die off?" Selection pressure is what it is.
Selection pressure may or may not be in a feedback loop with the evolutionary process, but you can still view it as a separate component. In case of computing, the (broadly understood) market is the selection pressure. As for the notion of what should happen, this comes from humans who are capable of thinking about the evolutionary process and who value some goals over others. In particular, those humans tend to notice that the selection pressures in software industry do not promote good, efficient, and well thought-out solutions.
"We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy."
>while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
The problem here is that there aren't a lot of alternatives. You could use Windows, which is like listening only to music by MC Hammer, or you could use a Mac, which is like listening only to music by Duran Duran.
Because of software/backwards compatibility concerns, and how dependent everything is on the underlying OS, it's really hard to change anything in the OS, especially the fundamental design. It'd be nice to make a clean-sheet new OS, but good luck getting anyone to adopt it: look at how well Plan9 and BeOS fared.
The thing is UNIX, by definition, is never going to move beyond its original design, meaning POSIX + C.
Whereas Mac OS, Windows, iOS, Android, ChromeOS have moved into more productive language runtimes, with rich frameworks, improving safety across OS layers, even if they have a few bumps along the way.
What do you mean by unix in this context? Everything save for windows bears a strong kinship with Unix and every OS is more than capable of running additional runtimes and frameworks beyond C.
It was an OpenVMS derivative wiyh code copied or clean-slated against a modified form of its behavior. However, I heard the networking stack was from BSD.
That's not true. Windows in particular is greatly limited by past design choices, such as filename limitations, the security model, the fact that many programs have to be run as administrator because that's how they were written years ago, etc.
There's nothing preventing you from running different language runtimes and such on Linux/Unix systems; people do it all the time. Have you not noticed Mono? It's been around for many years. Plus frameworks like Qt; that certainly wasn't around before the late 90s.
>Windows 10 already sorted out the filename limitations.
No, it hasn't. Filenames are still case-insensitive (and in a terrible way, where it seems to remember how they were first typed but that can never be changed), backslashes are still used for path separators instead of escaping characters, and the worst of all is that drive letters are still in use, which is an utterly archaic concept from the days of systems with dual floppy drives. Also, try making a file with a double-quote character in it, or a question mark. I've run into trouble before copying files from a Linux system to a Windows system because of the reserved characters on Windows.
>Mono and Qt don't change the architecture of UNIX and their adoption across UNIX variants isn't a game changer.
Nothing you've mentioned has changed the architecture of Windows. The fundamental architecture of Windows hasn't changed at all since WinNT 4.0 (or maybe 3.5); it just has an ugly new UI slapped on top and some slightly different administration tools.
As for Windows architecture, maybe you should spend some hours reading Windows Internals book series, BUILD and Channel 9 sessions about MinWin, Drawbridge, Picoprocesses, UWP, User Space Drivers, Secure Kernel,....
Google "davec apcobj.c"; that'll point you in the direction of some of Dave's brilliant work that dates back to 1989.
(Three versions of NT have been leaked; NT 4.0, Windows 2000, an the Windows Research Kit (which is Win2k3) -- they are all trivial to find online (first page of Google results).)
Windows NT (the core OS) suffers none of those problems.
The Windows (Win32) environment suffers those limitations. It also suffers 20+ years of strong binary compatibility, broad hardware support, and consistent reliability that systems of similar class (e.g. Linux desktops) can't match.
If it makes you feel any better, drive letters are a convenient illusion made possible by the Win32 subsystem; NT has no such concept and mounts file systems into the object hierarchy (NT is fundamentally object oriented - a more modern and flexible design than is provided by UNIX).
The fundamental architecture of Windows, the kernel, hasn't changed in ages because it doesn't need to; it is far more sophisticated than UNIX will ever be and far more sophisticated than you will ever need. The fundamental architecture of Win32 hasn't changed since 32-bits was an exciting concept and it won't change because the market has said loud and clear that they want Windows-level compatibility. See Windows RT and The Year of the Linux Desktop for evidence that users aren't clamoring to ditch Win32 in favor of something more pure.
> The fundamental architecture of Windows, the kernel, hasn't changed in ages because it doesn't need to; it is far more sophisticated than UNIX will ever be and far more sophisticated than you will ever need.
Another case in point: it allowed MS to write a layer on top of the NT kernel to run unmodified Linux binaries. (Windows subsystem for Linux).
Linux has the same thing, called WINE. It already works quite well, and if they had access to the Windows and Win32 source code and a staff of full-time developers, it'd work flawlessly.
An API translation layer doesn't prove that a kernel is "more sophisticated" than another; that's just fanboyism.
Is there a possibility to use the NT system without the flaws (?) of Win32? I hardly know anything about Windows programming, and I'm a bit curious now, having read your comment.
Windows exposes personalities above the kernel, in the NT days that meant OS/2 1.x, POSIX and Win32.
Nowadays on Windows 10 it means UWP, Win32 and Linux syscalls.
In theory someone could call the ntdll.dll and create a new personality but those APIs are undocumented and only possibly made available to Microsoft partners.
Is that a claim you can substantiate? I admit I stopped paying attention around the time that scale-up of expensive servers with high minimum specs + expensive software licenses was overtaken by scale-out approaches +
open source, but NT never struck me as being particularly stable in the face of badly written software and drivers. Has it improved a lot in this dimension over the past 15 years?
> Windows 10 already sorted out the filename limitations.
Only for new applications. These written for the old ABIs still trip over after the 240th character, even though the FileSystem supports much more.
To put in another words: I belive the inherent unix limitations (process model for terminals, process signalling, lack of structure) are still less limiting than DOS assumptions about the consumer hardware and applications of the 80's.
You are moving the goal posts from OS limitations to limitations of old applications.
Unix applications written using old assumptions (e.g. ?14? characters max for symbol names in libraries, ?16? bit address space, assuming the C library knows of gets) can have problems on modern systems, too.
No one still uses Unix applications from the 1970s.
Lots of people still use Windows applications with the limitations mentioned here, either because they refuse to give up their 1990s Windows applications, or the weird little ISVs refuse to update their code.
It's why everyone focuses on making something on some cross platform abstraction layer or something similar. In many ways, things like amazon lambda are a 'new os'.
The fundamental design of von Neumann architecture is even older and Unix can be treated as just another layer of abstraction on top of it. It cannot really get past its sell-by date.
Is it more like listening to music made with a Stratocaster or Les Paul? Lots of great ideas have been applied to guitars too, but lost of people still use the old ones.
But just because an idea is old doesn't mean it is necessarily bad. Some ideas like Unix Philosophy have stood the test of time. The fact that this statement was made in 2004 and that Unix is still going stronger 13 years later is proof.
Suggesting that Unix has been continuing just by inertia doesn't explain why Apple adopted Unix for macOS or why most newer computers nowadays run a Unix OS.
I suggested nothing of the sort. I am criticizing your use of "still going strong" as proof of good design. And there are many possible explanations of why Apple adopted Unix. Inertia is certainly one of them! (If you want to write a new operating system, and all your programmers are familiar with unix, and you don't have enough money to start from scratch... you start from unix)
Apple failed miserably to create a new OS, decided to buy a company instead and they happened to get the one where Steve Jobs was.
NextSTEP was partly based on UNIX, because it was competing against Solaris and needed some compatibility for easing the port of applications.
It used a micro-kernel like architecture, drivers where written in Objective-C, the whole userspace used the Foundation libraries and the bundles concept, the GUI was based on Postscript engine.
All very little to do with what a UNIX is.
Also if Gassé didn't ask the crazy amount of money he did, Mac OS X would probably be based on BeOS, which didn't have anything to do with UNIX.
On the other hand, the record player he first heard David Cassidy on will still work in the next house he buys. That's because, once we settle on foundational stuff like electricity delivery, we don't break it every time we have good ideas about it. It's the same with everything, like math or computer hardware: after a period of diverse experiments, the foundations solidify and we build immense structures on top of them. It's a net win, overall, even if we get stuck in local maximums for too long sometimes.
In view of that, it's only natural that big segments of software beyond the OS like word processors are also stagnant. We don't actually need a diverse marketplace of competing word processing ideas anymore... the problem is fundamentally solved as far as the public is concerned. It's not as exciting for software developers, but it's totally natural for it to happen.
I think WordPress, wikis and Google (Docs) would disagree with you about word processing being a solved problem. And they seem to do well enough. They offer a fundamentally different notion of what you're trying to do when you're putting prose down. (Personally I hate these systems like Microsoft Word and Google Docs that force you to think in terms of a page. Especially because they don't give you any tools to actually make things lay out properly. But it's okay, because people have been fundamentally rethinking the issue for years now.)
Now if you do want page layout, I think the people who like to do that use something different — not Word. So I don't think they've really cornered any market, unless the market is people who want to use Word.
You must tell us more :-) For my anecdote, I know people who did 10k+ line final year university projects in AWK and Tcl respectively. The AWK one was a particular act of endurance.
The actual product was hosting, more or less, although with some additional constraints that meant more moving parts. The bash grew out of manual scripts to provide automation and a UI for support.
> You must have mastered the bizarreness of bash arrays by the end of that :)
I mastered a lot of the weird corners, though we mostly kept them out of the code. I've forgotten much since.
You're free to take it all and turn it into an OS of your vision.
Next thing - bitch about how Earth works, with every region, country and even, gasp, city is different because a few people a long time ago decided "this is the way to go".
Similarly, our appendices, which are useless to begin with, occasionally decides to become infected, swell, and possibly burst, threatening our lives, just because biology a long time ago decided "this is the way to go."
This is incorrect. People did indeed think appendices were just useless throwbacks for a long time, but more recently the medical community recognizes their usefulness. They're basically like a first-level bootloader for the GI system, used to store bacteria in case of a severe illness like cholera or dysentery. It also serves some other immune functions. See here:
https://en.wikipedia.org/wiki/Appendix_%28anatomy%29#Functio...
I thought it was weird that the appendix-haters didn't see the connection between appendix removal and increased stomach issues (esp diarhhea). All kinds of people I met with the operation had issues after the "useless" organ was removed.
Natural selection ought to quickly do away with an organ that served no purpose but to occasionally kill one of the luckless organisms that possessed it.
It should have been obvious that it was doing something else, or more specifically, that the gene(s) for "having an appendix" were.
Did you miss the part about it being helpful for restoring GI function after a bad disease? Things like dysentery and cholera were pretty common before modern times. An organism that can recover from diseases like this is going to live longer and pass on its genes more often. The downside of it occasionally causing appendicitis and killing the organism is likely a small risk in comparison: how often did people in pre-modern times (before they knew what it was and had the ability to do surgery to remove it) die of appendicitis? Not very often. It wasn't the main killer of people by a very long shot. But people got sick all the time from various things that affected the GI system.
You're uncharitably mis-reading my post, and being quite hostile in your reply.
What I meant was that - in hindsight - the fact that it had some beneficial function like restoring GI function should have been obvious, because otherwise, it would have been selected away.
That is, even a layperson _should_ have looked at the situation and thought "I bet it does something for us". But that's the benefit of hindsight; most (including myself) didn't. We just accepted the folk wisdom that it was useless.
Sorry, you're right, I misread your post. I think you have a good point here, but to be fair I don't think people weren't thinking in evolutionary terms at all. Not everything in our (or other animals') bodies are actually there for a good reason now. I'll give you one good example: horse toes. I don't remember the exact term now, but horses equine ancestors used to have multiple toes, like us and many other mammals. Now they just have one, with a big fingernail, called a "hoof". But if you look closely at the anatomy of their legs, you'll see some of the vestigial toes still there, serving no useful purpose now. Evolution isn't like engineering design, where we improve a design, see something that's not needed any more (like an automotive engine distributor), and just remove it entirely, and everything related to that, in one clean sweep, even mundane small things like bolt holes, and optimize the design for the new system (being coil-on-plug for this analogy). With evolution, it's slow and gradual. Another example is the recurrent sublaryngeal nerve in humans: this nerve apparently takes a rather bewildering and inefficient route, for seemingly no good reason, but when looked at from an evolutionary perspective, it makes sense why it takes that route. (The nerve itself is not vestigial and serves an important purpose, but the route it takes is very sub-optimal and could be called "vestigial" in a way.)
So I think it's entirely reasonable, in the absence of contradictory evidence, to use evolutionary thinking to make an argument that an anatomical structure seems to serve no purpose any more, just like those extra horse toes. Unfortunately, they were obviously wrong about the appendix, and I do think it's a little dangerous because the assumption of vestigiality rests upon the lack of evidence for the part having a modern use, but this can cause people to stop looking for that modern use, and then we wind up with what happened to the appendix, where it took a really long time to learn the truth because we assumed we already knew.
Agreed almost entirely - and I apologise for uncharitably calling your reading uncharitable :)
I think there is a subtle difference between the appendix and the horse toe, though: the appendix regularly kills people due to appendicitis. I _think_ that ought to have been a clue. Unsure though as it's not really my field.
Most of the author's criticisms around the Unix Philosophy™ (aside from perhaps the performance aspect) would be solvable in two steps:
1) Standardize on some structured text serialization format (I like YAML for this)
2) Write a new shell
Both of these things are compatible with the Unix Philosophy™, and thus said Philosophy is nowhere near collapse. Rusty around the edges, sure, and maybe with some asbestos in the ceiling tiles, but certainly renovatable.
The philosophy is already prevalent in the world of "microservices"; an application is split into a whole bunch of independent (usually containerized) programs communicating via something like JSON over HTTP.
I meant that more in terms of IPC (e.g. in pipes), but most of those use cases happen to be adequately handleable by YAML specifically, so yeah, why not?
XML, YAML, JSON and s-expressions are all just flavours of representing trees.
So yeah, any of that would be a much better idea than unstructured text, and yes, you can serialize all those use cases into trees. I'd steer away from XML for sake of efficiency and human-readability though.
Not everything is a tree, and neither XML nor JSON nor sexp are particularly efficient or "beautiful". And there is no canonic representation. You could strip all whitespace or indent all childs, but... And YAML for example has no nice way to put lists of single words on one line.
I'm yet to see a practical data set that could not be encoded as a tree. Maybe if you have a cyclical data structure and you want to save that directly, but then it's a simple meta-level extension. For example, Lisp reader does that when reading S-expressions. If you want to create a list like this:
1 ---> 2 ---> 3-|
^_______________|
you write: #1=(1 2 3 #1#), where #n=OBJECT means "this is the object N", and #n# means "here is the very same object N too".
Yes, you can encode everything "as a tree". You can also encode everything "as binary", "as a big integer", whatever. That doesn't mean it's a good idea.
Unlike "as binary" or "as a big integer", a tree is structured. "As an arbitrarily-formatted string" would be much closer to those two comparison points.
I don't think they're unstructured; rather, I know they're arbitrarily structured, usually requiring a great deal of ad-hockery to deal with them. A standard structure means a lot less work for data consumers and producers alike.
This comment is structured in the sense that it's two paragraphs of more-or-less-correct English. That doesn't make it useful to tools that don't understand English. As far as a tool like 'rm' is concerned, it might as well be unstructured.
1) This is an appealing idea, but my claim is that there's no single serialization format that will work. (Or if there is one, it has yet to be invented.) More detail here:
There's nothing stopping anyone from using structured data over pipes, but I think it's a mistake to assume there will be or needs to be a "standard".
3) I agree that JSON over HTTP is very much in the vein of Unix. The REST architecture has a very large overlap with the Unix philosophy -- in particular, everything is a hierarchical namespace, and you have a limited number of verbs (GET / POST vs. read() / write() ).
"There's nothing stopping anyone from using structured data over pipes, but I think it's a mistake to assume there will be or needs to be a 'standard'."
Then I'm not sure how the problem would be solved. The main reason why "everything should be plaintext" is problematic (aside from being inefficient storage-wise) is that there's no "standard" format. My interpretation of the article's criticisms is that overreliance on tools like awk is the problem, not the solution.
Hence, the recommendation to just standardize on YAML (or some stricter subset thereof). If unstructured data is really needed in the pipeline, then it can easily be encapsulated in an ordinary YAML document. This would unify the strengths of the Unix way (ease of human inspection) and the PowerShell way (ease of plugging arbitrary tools together without needing to stick a bunch of text filters all over the place).
615 comments
[ 5.1 ms ] story [ 383 ms ] threadIf the bottom-up compositional model for computing that largely originated with Unix is fading, this article doesn't go there, or suggest cause.
Now, that's an article I'd like to read...
https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook
Oh! The beauty of censorship by the masses.
Now I can see why jwz would choose to take a stab at HN. He may be right, and even too kind.
That flag is just sad...
The Unix philosophy is essentially the opposite of the Apple philosophy. It gives you flexibility and composability at the cost of simplicity and the overall experience.
The optimal solution tends to be somewhere in-between. If you look at Linux, it's actually a monolithic system (which goes against the Unix philosophy); the popularity of Linux is in itself proof that people do want a single cohesive product - If the Unix philosophy was the best approach, we'd all be using Minix by now.
I use Ubuntu (Gnome) these days. The only thing I miss from Windows is Windows Explorer. Nautilus just doesn't cut it in my opinion; I always end up browsing the file system with the command line. That said, I still prefer Nautilus over OSX's Finder.
Of all the things to complain about in Linux, you choose the one thing that Mac OS and Windows still don't have right, and Linux had pretty good even back then?
The fact that Linux relied on people to install stuff with the command line was a massive oversight. UIs are just way more intuitive than shell commands.
It's when you go to uninstall or upgrade it that you realize what a mess it is.
It's that there are so many different standards for installing software, overlapping in sometimes conflicting ways.
I've rarely disagreed with something said on HN so strongly (at least among things that, in the grand scheme of things, really don't matter that much, but they matter a lot to my personal experience).
"The fact that Linux relied on people to install stuff with the command line was a massive oversight. UIs are just way more intuitive than shell commands."
This has never been true in the past 12 years. You have to go back even further to find a time when there weren't multiple GUIs for the leading package managers. And, for at least the past decade, the core GUI experience on every major Linux distro has had some sort of "Install Software" user interface that was super easy and provided search and the like.
There's lots of things Linux got wrong (and some that it still gets wrong) that Windows or macOS got right. Software installation really just isn't one of them, IMHO.
It's the thing I miss most when I have to work on Windows or macOS, and I miss it constantly...like multiple times a day. A good package manager is among the greatest time savers and greatest sources of comfort (am I up to date? do I have this installed already? which version? where are the config files? where are the docs? etc.) when I use any system, particularly one I haven't seen in a while.
I just really love a good package manager, and Linux has several. Windows and macOS have none (because if the entire OS didn't come from a package manager, it's useless...you can't know what's going on by querying the package manager, if the package manager only installed a tiny percentage of the code on the system). So, even though there's choco on Windows and Homebrew (shudder...) on macOS, they are broken from the get-go because they are, by necessity, their own tiny little part of the system with little awareness or control over the OS itself.
Also, if your problem with non-Linux package managers is that they only know about and control their own packages, then you must have the same objection to Nix and Guix, right?
What happened to wanting simple tools that do one thing and one thing right? Don't we want package managers to only manage packages, to decouple them as much as possible from the rest of the operating system, and leave system configuration management to other tools?
I've blogged about some of my problems with Homebrew. Generally speaking, Homebrew is a triumph of marketing and beautiful web design over technical merits (there are better options for macOS, but none nearly as popular as brew).
The blog post: http://inthebox.webmin.com/homebrew-package-installation-for...
I get that it's easy and lots of people like it, so I mostly try to hold my tongue, but every once in a while I'll see someone suggest something crazy like using Homebrew on Linux (where there is an embarrassment of good and even great package management options) and it makes me shudder. I'm not saying don't use Homebrew on your macOS system if it makes your life easier. I just would never consider it for a production system of any sort. I'm even kinda mistrustful of it on developer workstations (though there are plenty of similarly scary practices in the node/npm, rubygems, etc. worlds, so that ship has kinda sailed and I am resolved to just watch it all unfold).
"What happened to wanting simple tools that do one thing and one thing right?"
I still want that. Doing one thing right in this case means doing more than what packages on macOS or Windows do. One can argue about the complexity of rpm+yum or dpkg+apt, and it's likely that one could come up with simpler and more reliable implementations today, but if you want them to be more focused, I have to ask which feature(s) you'd remove? Dependency resolution? That one's a really complicated feature; a lot of code, and it's been reimplemented multiple times for rpm (up2date, yum, and now dnf). Surely, we can just leave that out. Or, perhaps the notion of a software repository? Is it really necessary for the package manager to download the software for us? I mean, I have a web browser and wget or curl. Verification of packages and the files they install, do we really need it? Can't we just assume that our request to the website won't be tampered with, and that what we're downloading has been vouched for by a party we trust? I dunno...I'm not really seeing a thing we can get rid of without making Linux as dumb as macOS or Windows.
"Don't we want package managers to only manage packages, to decouple them as much as possible from the rest of the operating system, and leave system configuration management to other tools?"
This is the strangest question, to me. Why on earth would we want the OS outside of the package manager? Why would we want to only verify packages that aren't part of the core OS? This is why Linux is so vastly superior to Windows and macOS on this one front. I'm having a hard time thinking of why having the package manager completely ignorant of the core OS would be a good thing. What benefit do you believe that would provide?
And, NixOS does not meet the description you've given. The OS is built with nix the package manager. Running nix as a standalone package manager on macOS does have the failing you've mentioned, but that's not the fault of nix. And, yes, nix is a better option for macOS than brew, but the package selection is much smaller and not as up to date in the general case...so maybe worse is better, in that case.
I get a bit ranty about package management. I spend a lot of time working with them (as a packager, software builder, distributor, etc.) and have strong opinions. But, I believe those strong opinions are backed by at least better than average experience.
No where near as consistent as installing from a package manager.
> The fact that Linux relied on people to install stuff with the command line was a massive oversight. UIs are just way more intuitive than shell commands.
Every user orientated distro has come with a GUI package manager for at least a decade, probably two.
Compare to Linux, where a piece of software is scattered around /usr/bin, /usr/lib, /usr/share, /usr/doc. (Or /usr/local/*, you never know which) Oh, and those fun times where something depends on a libxxx.so.N but all that's on the system is libxxx.so.N.M.O and libxxx.so.N.M for some reason, so you have to make the symlink yourself. Or the distribution has a minimum of version N+1, so your option is to find the source for the library, figure out all the -devel packages it needs, and compile it up (hopefully), or just symlink libxxx.so.N to libxxx.so.N+1 and hope it works. And then the fun of figuring out what the package is named. pdf2text lives in poppler, who would have thought. Need gcc? That will be build-essential on Ubuntu last time I needed it. (Not build-essentials, either)
And, there are some new package managers that isolate in this way (and go well beyond it by containerizing). Flatpak is probably the most promising, IMHO. And, it still provides all the benefits of a good package manager, like verification, authenticity, downloading automatically from a repo, dependency resolution for core libraries. And, the way Flatpak handles the latter feature is really quite cool (and avoids having to distribute dozens of copies of the same libs).
Your description of installing packages on Linux does not match my experience in the past decade. Dependency resolution is a solved problem on Linux, at least on the major distros with good package managers.
It's entirely possible to have a microkernel with a Unix-like system; HURD attempts this. Microkernel vs. monolithic is an entirely separate issue.
A good example is ArcGIS which on the surface is ridiculously monolithic. But within the toolbox function are several hundred programs that do only one thing and are composable. This approach is also seen in video or image editing workflows where a user works with a particular set of tools. The main difference is that the programs use a types system that is appropriate to the domain rather than just text.
The OS only really exposes an interface for working with OS level objects. That sometimes aligns to a workflow but not always. And we should not expect disciplines to align their techniques to OS level objects if that is not a good fit for the actual domain.
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.
As a developer, it was a bit painful, but the whole file versioning was handy sometimes.
http://web.mit.edu/~simsong/www/ugh.pdf
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.
Oh for the days when 750kB was considered "massive" for a binary.
https://rachelbythebay.com/w/2016/04/17/unprotected/ https://news.ycombinator.com/item?id=11517894
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!
The vendors were fighting amongst themselves for supremacy. Take a look at Larry McVoy's "Free Unix" whitepaper.
https://www.landley.net/history/mirror/unix/srcos.html
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.
Really? We used it a lot in payments. But it was paired up with Tandem and/or Unix (AIX, HPUX).
There was certainly a lot of thrashing as mini-computer manufacturers were having their "last hurrah".
Thanks!
There may well have been others. I'm not claiming any particular expertise, just general knowledge, from the industry. And being old.
I can attest to at least one case of VMS being retained in favour of Unix, which was retired. In the mid-1990s.
Go figure.
[1]: https://en.wikipedia.org/wiki/Albert_Hofmann
I think you're suffering from selection bias.
https://www.usenix.org/legacy/event/usenix99/full_papers/ban...
> 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!
Pretty good.
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.
BSD IS UNIX.
Hey, that sounds like Go's line. Oh wait ..
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.
Alas, while it's a mandatory POSIX utility (AFAIU), some Linux distributions have saw fit to remove it from base installs.
yeah, totally have never seen that...
And they'll argue until they're blue in the face why it's a good "compromise", but it would have been better to do one or the other, not both.
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).,
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.
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.
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.
Or strip it up, so to speak, or rather, build it up. Referring to Linux From Scratch.
https://en.wikipedia.org/wiki/Linux_From_Scratch
http://www.linuxfromscratch.org/
On Linux or OpenBSD?
Also, Erlang and Elixir run out of the box on it, so it's suitable for nearly all of my personal projects.
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.
[1] https://en.wikipedia.org/wiki/Royal_Enfield_Bullet
https://www.google.co.in/search?q=royal+enfield+bullet
A Swiss guy, Fritz Egli (IIRC), was/is a fan and modified some of them (Bullets) over there. It was the subject of a magazine article.
I first rode a Bullet in my teens. A real thumper.
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.
[0]: http://theroyalsilkroad.com/bikes.html
If AI matches up to its hype, after some time newborn babies will have to be plugged in to "start" them too :)
When I thought I wanted a bike, I looked around for a Condor A350.
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.
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.
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.
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.
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?
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.
> 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...
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.
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 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.
* 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.
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).
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.
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.
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 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.
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 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.
I eventually got very surprised that not all universities do that.
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.
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.
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.
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...)
Sadly, it doesn't seem like jq will read an environment setting to always specific -C
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).
unless the 'thing' here is "outputting information in the most generally usable way possible"
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.
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:
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.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.
(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.
See Steve McConnell, Code Complete, for a treatment of modular design in software and the flexibility it provides.
(The same logic applies well outside software.)
I don't get what you're trying to say.
"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"?
Only if you use "find" with a query that means "get me all files matching any and all criteria as long as they are in this specific path".
That's a corner case, and a very silly one.
> There's total overlap.
A very silly and far-fetched one.
i'm still to see any complainer grown an adecuate amount of facial hair, though. (incompetently) reinventing some bad idea from before you were born does not cut it, you know?
1969 < 1981.
Heck, in 1969 there wasn't even RT-11 that CP/M was modelled after.
There was a brand new OS/8 that RT-11 was modelled after.
I feel so privileged to read this random guy's blog, and it's terrific that he eschews inflating his ego so well.
You wouldn't consider it to be immature to not do the right thing just because it was communicated in an unpleasant way that a 'self-respecting person' should have disdain for? I'm not talking about this particular article or defending immaturity, - I just don't see how your position is any better; more so it's just as unhumble as the 'rockstar position' since you would apparently be willing to write worse code just to avoid learning from someone that's an asshole.
A lot of people find that cockiness funny and find the informality welcoming. And many of those tend to find cold formality, fake humility or lack of self-confidence as signs of something being boring, uninteresting or outright creepy.
EDIT: Comment was edited, original:
The edit was because I only ended up scanning what I intended on reading and felt the second part of my criticism overly harsh.
The author is taking the time to post his thoughts on a private blog. If you're not happy with the level of rigor, then don't read it, don't share it, and don't believe it. But no, the author has no responsibility to provide you with a comprehensive list of citations and references.
What I don't like about that attitude is that it suggests that the blogpost should be excused from criticism of its rigor. But any assertion and opinion by anyone can and should be considered open to criticism.
> "But no, the author has no responsibility to provide you with a comprehensive list of citations and references."
Of course he is not responsible. But if someone expects or wants people to be convinced of their argument, then prefacing with his rude dismissal does not help.
A better way than "This article was written hastily, and I don’t want to further improve it. You’re lucky I wrote it." without the unnecessary rudeness and ego boosting could be more along your lines: "This article was written hastily and shouldn't be subject to PhD-thesis-level scrutiny, so I've posted without any expectation that I will improve it or respond to criticism."
Sounds to me like you agree with the substance of what the author said, and just happen to disagree with the delivery. Keep in mind that different people have different writing styles, and people often post things like what you quoted in a tongue-in-cheek manner. Some people prefer a formal, humble style of writing. Others like a more humorous style, and others yet enjoy a Steven Colbert faux-braggadocious style. It would be unfortunate if we browbeat anyone who dares to inject some quirky humor into their writing.
The author makes a bunch of assertions that range from misinformed to straight-up wrong. There is 0% Steven Colbert-style self awareness. No one is lucky that it exists. When you engage in personal endeavors, do them for their own merits. And especially if you're doing something that no one and nothing is compelling you to, please at least try.
You can just start the countdown until all the unix greybeards come out and slams them with why it's so wrong and how to do it with some obscure bash feature.
I'm not saying it has to be PhD-thesis-level, but if proven wrong you are morally obligated to update the information or remove it. Otherwise you are spreading false knowledge. This doesn't apply to opinions ofc (the bulk of private blogging).
Screw entitled users though, they should fix it themselves :)
After 20+ years of working in the business and reading ridiculous amounts of articles, and some books, I can quite easily find clear errors or omissions in most everything written about computers and programming, Knuth excluded. If everyone were obliged to update to fix any errors, even only factual, it's likely that much - or even most - of all I've read would never have been posted for me to read in the first place, and I think both the world and I would be poorer for it.
Correctness is important, but so is the ability make judgments of validity, to critique, disseminate, inspire and express ones thoughts, even when they turn out to be wrong.
I was envisioning people nit-picking the lack of formality, when it was merely an enthusiastic, from-the-hip post.
A day later I realized that wasn't the best way to start things off with, and toned it down. But I get where he's coming from. And I'm grateful he took the time to write it. It was an interesting read.
> The provocative tone has been used just to attract your attention.
There's irony in people being insulted by arrogant tone and loudly proclaiming they stopped reading something.
It may be that the author is not actually a self-important asshole, but starting an article like that makes it look like he likely is.
You could also have guessed it when you noticed it was a kid student showing up (and off) with a lengthy critic on the historical evolution of UNIX tools and others OSes and tools that he discovered a couple of years ago, while you possibly were using them and watching them evolve while he was still in his father's bollocks (and some of us (not me) were working on UNIXes while his father was a kid). You know what to expect in this case, especially if you remember having produced the same kind of over-confident and yet uninformed rant in your days :-) (I do :-D )
>How to touch all files in foo (and its subfolders)?
I agree with the other commenters who think it's fine to write whatever you like on your own blog, I just feel that it went from interesting historical warts to bagging on legacy systems because they're complicated.- Dirty hacks in UNIX started to arise when UNIX was released, and it was long before Windows came to the scene, I guess there wasn’t even Microsoft DOS at the time (I guess and I don’t bother to check, so check it yourself). At least he acknowledges that he's being incredibly lazy, and he shows the glimmer of an understanding as to why some of the things mentioned later happened: because Unix is from the early 70s, which were a very different time in computing & culture.
- Almost at the very beginning, there was no /usr folder in UNIX. All binaries were located in /bin and /sbin. /usr was the place for user home directories (there was no /home). Putting /home on a separate partition remains a pretty common thing to this day because users will tend to have greater storage requirements than just the root. /usr/bin and the like are the result of people realizing that this secondary larger disk is an acceptable place to put binaries and other files that aren't needed at bootup.
- In other words, if you’ve captured Ctrl+C from the user’s input, then the operating system, instead of just calling your handler, will interrupt the syscall that was running before and return EINTR error code from the kernel. That's not the kind of interrupt they're talking about.
- I’ve read somewhere that the cp command is called cp not because of copy but because UNIX was developed with the use of terminals that output characters very slowly. Yep, terminals that print on paper are pretty slow, as are 300 baud modems. I'm absolutely crushed I had to learn that 'cp' means 'copy'--it took hours to beat that into my head, and the thousands of keystrokes I've saved over the years are a small comfort (except to my rsi-crippled hands)
- The names of UNIX utilities is another story. For example, grep comes from command g/re/p in the ed text editor. Well, cat comes from concatenation. I hope you already knew it. To top it all up, vmlinuz — gZipped LINUx with Virtual Memory support. 'cat' comes from 'catenate', in fact. What would you name 'grep' instead? "searchregexandprint"?
- at least the main website of C that would be the main entry point for all beginners and would contain not only documentation but also a brief manual on installing C tools on any platform, as well as a manual on creating a simple project in C, and would also contain a user-friendly list of C packages This is one of the most ridiculous ones. You're talking about a programming language defined in the 70s, for Christ's sake. Lot of websites created in the 70s? There is a document with a good introduction to C, project examples, etc. and it's call The C Programming Language, a book by K&R. When Kernighan made another language a few years ago, yeah, he made a website for it--golang.org, it's one of the best project sites I've seen.
The article points out some legit problems in Unix, but even leaving aside the author's ESL challenges it's poorly-written, poorly thought-out, and poorly-defended.
Yeah, I found that one an especially weird gripe. Grepping was a new thing, so we needed a word for it. 'Grep' is short, easy to say and type, and relatively hard to confuse with similar words in the domain. Works for me.
I can unfortunately imagine a modern startup implementing it, and shudder at potential names my imagination is coming up with... Searchlr, the best way to search text! ReadMonkey, your personal pattern recognizer! I'll stop now.
"No, I mean the kind of car that is really big, that you drive on ice rinks to smooth out the ice."
There's always some default subject implied for every command name. For "find" it is files, for "search" it could have been text.
Files, the base type that's consistent across all the basic commands (AFAIK).
The author cites to this post by Rob Landley – http://lists.busybox.net/pipermail/busybox/2010-December/074...
While I can't independently confirm Rob's claims, and he doesn't provide any citations, I do find them very believable – /usr was invented at Bell Labs because they were running out of space on their puny 1970s hard disks. (And an RK05 was small even by 1970s standards – the IBM 2314 mainframe hard disk, released in 1965, had a 30MB capacity; the IBM 3330, released in 1970, stored 100MB – of course, these disks would have cost a heck of a lot more than an RK05, and were likely not feasible for the UNIX team given their budget.)
If they had bigger disks (or the facility to make multiple smaller disks appear like one big disk) – it is less likely they would have split the operating system itself across two disks (/ and /usr). (Using separate disks for the OS vs user data was more likely even with bigger disks since that was common practice on systems at the time.)
(Some other operating systems from the same time period already had some ability to make multiple disks appear like one big disk. For example, OS/360 has the concept of a "catalog", which is a directory mapping file names to disk volume names; this means you can move individual files between disks without changing the names by which users access them. In their quest for simplicity, Thompson and Ritchie and co decided to omit such a feature from UNIX.)
Lisp, Smalltalk, Mesa, Pilot OS and Xerox Development Environment are from the early 70s as well (Lisp even earlier).
- make's TAB "problem" as very first argument is not very convincing.
- The citations to back up the claim that a (possibly binary) registry database was better than small text files are just not backing up. There is nothing to defend a registry there. The quote is about fsync semantics which has nothing to do with registry. Btw. in my perception it's a widely accepted fact that a big-pile-of-crap database is a bad idea. And oh, I haven't ever heard of any problem with passwd/group/shadow/gshadow being text files. And if there were, the access method is actually abstracted away, it's easy to switch backends to something else (NSS). (there is a problem with these files though -- they are denormalized, and not all fields have clear meaning and some programs interpret some fields in weird ways.).
- Zombie processes. What's the problem there? They are just like file handles. Handles have to be closed before they are garbage collected. The actual problem is that you can't really "open" and "close" processes, only spawn new childs and the resulting hierarchy is not typically desired.
- "We call touch in the loop! This means there is a new process for each file. This is extremely inefficient." Yeah and why exactly is the shell to blame that you use touch in a loop? (apart from the fact that it's almost certainly not a problem).
Could go on but have to leave...
> We call touch in the loop here (I do know that the code can be re-written with xargs, so that touch is called only once; but let’s forget about it for now, okay?)...This means there is a new process for each file. This is extremely inefficient. Code in any other programming language will work faster than this one.
WHAT THE HELL??? Did he just criticize Unix/POSIX for its inefficiency after willfully choosing a less efficient way?
He wrote
When we could have written the very fast and very readable and very simple I'll put this up against the equivalent implementation in any language you choose.What is missing in many cases is a concepts guide, explaining the key ideas, how to combine things, and what's possible in various subject areas.
For GUI programs, menus / toolbars used to be the concept guide: what they show is what's possible, and they offer context help. This is why a GUI feels friendly. It sucks at composability, though. Current mobile interfaces, unfortunately, tend to lack this.
If tiny GUI-oriented programs were easy to compose, had an easy way to save the composed state, and a number of daily-use programs bundled with an OS came in this form, providing example and reference, many people would consider following the suit, I suppose.
[1]: http://softwareengineering.stackexchange.com/questions/61814...
This simple fact seems like the key to getting the masses into computing. For something like 6 years (say 12-18) GUIs were the way I interacted with computers. Need to do something and learn about it? Go and explore the UI until you find the option. If the option has a shortcut printed, you will remember it eventually.
Sadly, GUI design is a quite separate discipline from software design. This means much open source software is missing GUIs. Those who write the software aren't always GUI designers. This also creates the mismatch between composing software and composing GUIs. As they are different disciplines, what it means to combine them means different things.
A decent stopgap is massive frameworking and standardization on GUI to make it easier for devs to get a GUI. To get the really good stuff, commercial entities have the best position. They need their stuff to be usable by everyone, and this finances the hiring of GUI people.
There is the rare gen of a developer that can also do GUI right, but that only has value in the case of small projects. When projects grow, unless all devs have the GUI knack, you're gonna need some dedicated GUI people.
It would be great if we could get more GUI-oriented people into open-source stuff but it seems like they aren't as attracted to open-source as devs are. It might be because devs can be at the ground floor of a project, and GUI, almost by neccesity, comes later.
"The Art of Unix Programming"
http://www.catb.org/esr/writings/taoup/html/
It's not perfect - I'd love to see a guide with more practical examples - but it does do a good job covering the basic philosophy and some of the history of why certain design decisions were made.
What I mean to say is that while there has been a lot of initial inertia from the previous technologies that make it hard to change, it's also true that the new technologies have failed to make large enough gains to warrant the pains of changing - this is precisely the demise of Plan9: it's not that it wasn't better it just that it wasn't better enough to warrant the huge expense of replacing old, working systems.
We're trying to use a server OS on a single-user machine, complete with all the management cruft that comes along with a server-based OS. Consequently, we don't bother re-thinking what the user needs vs. a sysop.
Probably the biggest one is that UNIX is, at bottom, a terminal-oriented multi-user time sharing system. This maps badly to desktop, mobile, and server systems. The protection model is a mismatch for all those purposes. (Programs have the authority of the user. Not so good today as in the 1970s.) The administration model also matches badly. Vast amounts of superstructure have been built to get around that mismatch. (Hello, containers, virtualization, etc.) Interprocess communication came late to UNIX/Linux, and it's still not a core component. (The one-way pipe mindset is too deeply ingrained in the UNIX world.)
POSIX is more like the extended runtime that C needs to be portable outside UNIX walls, which isn't being fully implemented on iOS and Android.
http://www.cs.columbia.edu/~vatlidak/resources/POSIXmagazine...
Yes, you have to use their APIs in order to write graphical programs, but the same is true on any OS with a GUI system.
It's possible to write iOS apps in pure C if you want to. Sure, that'd be a pain, but it's possible. Less painful and actually decently reasonable would be to write all the GUI-specific stuff in Objective-C and any other logic in pure POSIX-conforming C or C++, since you can mix all those languages freely in a project.
All programming languages, other than Assembly have runtimes.
From the point of view of compiler design a runtime is everything required to support a programming language execution.
On C's case, calling main (), floating point emulation, initializing globals, parallel code execution, thread locals.
https://source.android.com/devices/tech/dalvik/#AOT_compilat...
Even with Android N, they are interpreted, JIT compiled with PGO, and eventually AOT compiled to native code when the device in not being used.
Also iOS supports LLVM bitcode with AOT compilation at iTune infrastructure since iOS 9.
Language runtimes have APIs, that is how they interact with compiler generated code.
Using pure C on iOS means calling the API entry points of the Objective-C runtime
https://developer.apple.com/reference/objectivec/objective_c...
I disagree, I think this is still the sweet spot between security and utility. Users have been trained to just click approve on any privilege escalation dialog.
I think the next step is a capability runtime OS with a kernel personality for Linux for backwards compatibility. Sort of the converse of what we're doing right now.
From the description of Combex (http://www.skyhunter.com/marcs/capabilityIntro/):
> Suppose you were running a capability-secure operation system, or that your mail system was written in a capability-secure programming language. In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard.
In reality, users will get sick of being prompted every 30 seconds and learn to automatically approve every request. Capability security works well in theory, but I've never seen an implementation that works well in practice.
https://www.combex.com/tech/edesk.html
That's the keyword there. They don't actually demonstrate a lot of common apps and how the user is prompted. It sounds a lot like windows UAC with a default lock down. They don't even mention have permissions are permanently granted or not.
"...great and perfect" is a strawman. Whether "some people" think that is irrelevant.
Some of this article is interesting, but the fact of the matter is 40-year-old systems have signs of being 40 years old. If "fixing" everything were easy, it'd be done. Tabs in Makefiles throw off the uninitiated for 10 minutes, then they learn, shrug and move on. These scars and stories are part of the package.
Reading further, some of this is just incorrect...
>That’s not to mention the fact that critical UNIX files (such as /etc/passwd) that are read upon every (!) call, say, ls -l, are plain text files. The system reads and parses these files again and again, after every single call!
Not on my system.
> It would be much better to use a binary format. Or a database.
On my system, it is ( running "ls -ld ."):
Now, I see that /etc/group -is- a plain file. This could get the same treatment as /etc/passwd if it becomes a burden. In the meantime, if it's a performance bottleneck, make a memoizing function to lookup groups and use a '-n' switch to ls. Article is probably mostly important as the author thinking deeply about Unix, and part of the developmental process of the user....All the bluster (some of which is interesting), then at the end walks it back:
> So, I do not want to say that UNIX – is a bad system. I’m just drawing your attention to the fact that it has tons of drawbacks, just like other systems do. I also do not cancel the “UNIX philosophy”, just trying to say that it’s not an absolute.
Shame about the title... But maybe that's what landed it here on HN (?)
Edit: explain the "ls" command actually run.
Exactly, and this is the sort of thing that can be done with open source software. It may not even be a lot of code depending on how it is approached.
I guess I am lucky he wrote this for a pleb like me.
Rob Pike 2004, https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
The problem here is that there aren't a lot of alternatives. You could use Windows, which is like listening only to music by MC Hammer, or you could use a Mac, which is like listening only to music by Duran Duran.
Because of software/backwards compatibility concerns, and how dependent everything is on the underlying OS, it's really hard to change anything in the OS, especially the fundamental design. It'd be nice to make a clean-sheet new OS, but good luck getting anyone to adopt it: look at how well Plan9 and BeOS fared.
Whereas Mac OS, Windows, iOS, Android, ChromeOS have moved into more productive language runtimes, with rich frameworks, improving safety across OS layers, even if they have a few bumps along the way.
Windows roots are on VMS, not UNIX. There is hardly anything UNIX related on its architecture, regarding kernel design.
https://technet.microsoft.com/en-us/network/bb545475.aspx
https://technet.microsoft.com/en-us/network/bb545475.aspx
What about something like this: https://www.redox-os.org/
Its written in Rust not C. In fact, according to the github stats, there is no C.
>Rust 72.4%
>Shell 13.2%
>Makefile 12.5%
>TeX 1.9%
There's nothing preventing you from running different language runtimes and such on Linux/Unix systems; people do it all the time. Have you not noticed Mono? It's been around for many years. Plus frameworks like Qt; that certainly wasn't around before the late 90s.
A few more releases and in around 10 years, Win32 will be drinking beers with Carbon.
Mono and Qt don't change the architecture of UNIX and their adoption across UNIX variants isn't a game changer.
No, it hasn't. Filenames are still case-insensitive (and in a terrible way, where it seems to remember how they were first typed but that can never be changed), backslashes are still used for path separators instead of escaping characters, and the worst of all is that drive letters are still in use, which is an utterly archaic concept from the days of systems with dual floppy drives. Also, try making a file with a double-quote character in it, or a question mark. I've run into trouble before copying files from a Linux system to a Windows system because of the reserved characters on Windows.
>Mono and Qt don't change the architecture of UNIX and their adoption across UNIX variants isn't a game changer.
Nothing you've mentioned has changed the architecture of Windows. The fundamental architecture of Windows hasn't changed at all since WinNT 4.0 (or maybe 3.5); it just has an ugly new UI slapped on top and some slightly different administration tools.
For us, Windows pathanmes are just fine.
As for Windows architecture, maybe you should spend some hours reading Windows Internals book series, BUILD and Channel 9 sessions about MinWin, Drawbridge, Picoprocesses, UWP, User Space Drivers, Secure Kernel,....
I'd love to read the source code myself to see how it works instead
Not exactly "you can get it if you want it", but not "you can't even get it over our dead body", either.
(Three versions of NT have been leaked; NT 4.0, Windows 2000, an the Windows Research Kit (which is Win2k3) -- they are all trivial to find online (first page of Google results).)
The Windows (Win32) environment suffers those limitations. It also suffers 20+ years of strong binary compatibility, broad hardware support, and consistent reliability that systems of similar class (e.g. Linux desktops) can't match.
If it makes you feel any better, drive letters are a convenient illusion made possible by the Win32 subsystem; NT has no such concept and mounts file systems into the object hierarchy (NT is fundamentally object oriented - a more modern and flexible design than is provided by UNIX).
The fundamental architecture of Windows, the kernel, hasn't changed in ages because it doesn't need to; it is far more sophisticated than UNIX will ever be and far more sophisticated than you will ever need. The fundamental architecture of Win32 hasn't changed since 32-bits was an exciting concept and it won't change because the market has said loud and clear that they want Windows-level compatibility. See Windows RT and The Year of the Linux Desktop for evidence that users aren't clamoring to ditch Win32 in favor of something more pure.
Another case in point: it allowed MS to write a layer on top of the NT kernel to run unmodified Linux binaries. (Windows subsystem for Linux).
An API translation layer doesn't prove that a kernel is "more sophisticated" than another; that's just fanboyism.
Nowadays on Windows 10 it means UWP, Win32 and Linux syscalls.
In theory someone could call the ntdll.dll and create a new personality but those APIs are undocumented and only possibly made available to Microsoft partners.
Is that a claim you can substantiate? I admit I stopped paying attention around the time that scale-up of expensive servers with high minimum specs + expensive software licenses was overtaken by scale-out approaches + open source, but NT never struck me as being particularly stable in the face of badly written software and drivers. Has it improved a lot in this dimension over the past 15 years?
Only for new applications. These written for the old ABIs still trip over after the 240th character, even though the FileSystem supports much more.
To put in another words: I belive the inherent unix limitations (process model for terminals, process signalling, lack of structure) are still less limiting than DOS assumptions about the consumer hardware and applications of the 80's.
Unix applications written using old assumptions (e.g. ?14? characters max for symbol names in libraries, ?16? bit address space, assuming the C library knows of gets) can have problems on modern systems, too.
Lots of people still use Windows applications with the limitations mentioned here, either because they refuse to give up their 1990s Windows applications, or the weird little ISVs refuse to update their code.
All programs of interest have migrated and there is also a compatibility layer redirecting older programs to write to a fake system directory.
You say that like it were a bad thing.
Apple failed miserably to create a new OS, decided to buy a company instead and they happened to get the one where Steve Jobs was.
NextSTEP was partly based on UNIX, because it was competing against Solaris and needed some compatibility for easing the port of applications.
It used a micro-kernel like architecture, drivers where written in Objective-C, the whole userspace used the Foundation libraries and the bundles concept, the GUI was based on Postscript engine.
All very little to do with what a UNIX is.
Also if Gassé didn't ask the crazy amount of money he did, Mac OS X would probably be based on BeOS, which didn't have anything to do with UNIX.
In view of that, it's only natural that big segments of software beyond the OS like word processors are also stagnant. We don't actually need a diverse marketplace of competing word processing ideas anymore... the problem is fundamentally solved as far as the public is concerned. It's not as exciting for software developers, but it's totally natural for it to happen.
Now if you do want page layout, I think the people who like to do that use something different — not Word. So I don't think they've really cornered any market, unless the market is people who want to use Word.
Try and read it this way:
"We really are using a 1970s era operating system ..."
Who the hell 'develops' in shell? It's a glue language, not a development language. I've never heard anyone say "We're a shell shop".
You must have mastered the bizarreness of bash arrays by the end of that :)
> You must have mastered the bizarreness of bash arrays by the end of that :)
I mastered a lot of the weird corners, though we mostly kept them out of the code. I've forgotten much since.
anyway, is something like [this] result of development or gluing things together?
[this] https://github.com/roman-neuhauser/haveopt/blob/master/s/hav...
Next thing - bitch about how Earth works, with every region, country and even, gasp, city is different because a few people a long time ago decided "this is the way to go".
Natural selection ought to quickly do away with an organ that served no purpose but to occasionally kill one of the luckless organisms that possessed it.
It should have been obvious that it was doing something else, or more specifically, that the gene(s) for "having an appendix" were.
What I meant was that - in hindsight - the fact that it had some beneficial function like restoring GI function should have been obvious, because otherwise, it would have been selected away.
That is, even a layperson _should_ have looked at the situation and thought "I bet it does something for us". But that's the benefit of hindsight; most (including myself) didn't. We just accepted the folk wisdom that it was useless.
[1] http://www.thehorse.com/articles/34382/where-did-horses-extr...
[2] https://unzipyourgenes.wordpress.com/2011/03/24/unintelligen...
So I think it's entirely reasonable, in the absence of contradictory evidence, to use evolutionary thinking to make an argument that an anatomical structure seems to serve no purpose any more, just like those extra horse toes. Unfortunately, they were obviously wrong about the appendix, and I do think it's a little dangerous because the assumption of vestigiality rests upon the lack of evidence for the part having a modern use, but this can cause people to stop looking for that modern use, and then we wind up with what happened to the appendix, where it took a really long time to learn the truth because we assumed we already knew.
I think there is a subtle difference between the appendix and the horse toe, though: the appendix regularly kills people due to appendicitis. I _think_ that ought to have been a clue. Unsure though as it's not really my field.
There are two types of languages, the ones everyone complains about, and the ones nobody uses.
1) Standardize on some structured text serialization format (I like YAML for this)
2) Write a new shell
Both of these things are compatible with the Unix Philosophy™, and thus said Philosophy is nowhere near collapse. Rusty around the edges, sure, and maybe with some asbestos in the ceiling tiles, but certainly renovatable.
The philosophy is already prevalent in the world of "microservices"; an application is split into a whole bunch of independent (usually containerized) programs communicating via something like JSON over HTTP.
Great idea! We should use XML for that...
So yeah, any of that would be a much better idea than unstructured text, and yes, you can serialize all those use cases into trees. I'd steer away from XML for sake of efficiency and human-readability though.
This comment is structured in the sense that it's two paragraphs of more-or-less-correct English. That doesn't make it useful to tools that don't understand English. As far as a tool like 'rm' is concerned, it might as well be unstructured.
The terminal is responsible for hacks upon hacks: Colors, ncurses, signals, and whatnot.
1) This is an appealing idea, but my claim is that there's no single serialization format that will work. (Or if there is one, it has yet to be invented.) More detail here:
https://www.reddit.com/r/oilshell/comments/5x5rgg/pipes_in_p...
There's nothing stopping anyone from using structured data over pipes, but I think it's a mistake to assume there will be or needs to be a "standard".
3) I agree that JSON over HTTP is very much in the vein of Unix. The REST architecture has a very large overlap with the Unix philosophy -- in particular, everything is a hierarchical namespace, and you have a limited number of verbs (GET / POST vs. read() / write() ).
Then I'm not sure how the problem would be solved. The main reason why "everything should be plaintext" is problematic (aside from being inefficient storage-wise) is that there's no "standard" format. My interpretation of the article's criticisms is that overreliance on tools like awk is the problem, not the solution.
Hence, the recommendation to just standardize on YAML (or some stricter subset thereof). If unstructured data is really needed in the pipeline, then it can easily be encapsulated in an ordinary YAML document. This would unify the strengths of the Unix way (ease of human inspection) and the PowerShell way (ease of plugging arbitrary tools together without needing to stick a bunch of text filters all over the place).
(More people would probably have read the Unix Haters Handbook if it was as pithy as this.)
Suckless and cat-v.org would disagree. I'd also disagree since I'm a huge fan of plan9port.