Live data from Hacker News

The Collapse of the Unix Philosophy

kukuruku.co

331–340 of 616 posts

Re: The Collapse of the Unix Philosophy

#331
post #49

"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." Rob Pike 2004, h…

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.

Re: The Collapse of the Unix Philosophy

#332
post #189

Earlier quoted context omitted.

it's a joke. Last sentence of the article is > The provocative tone has been used just to attract your attention.

That's a pity because of that tone I abandoned reading after few sentences and did't go to last sentence.

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 )

Re: The Collapse of the Unix Philosophy

#333

I wish Symbolics had a better run. The Windows registry/powershell approach has the niceness of passing pieces of data instead of one big blob of text that has to be re-parsed at every step, but with the drawback of verbosity and fussy static typing. Being able to directly pass s-expressions between between programs without the format/parse/typing hokey-pokey of Unix and Windows would be nice.

> Being able to directly pass s-expressions between between programs without the format/parse/typing hokey-pokey of Unix and Windows would be nice.

Genera did not have programs, it is all just function calls.

There was a multi-user LMI Lisp machine that ran Unix concurrently, that used streams to communicate between the two Lisp and one Unix processors: http://www.1000bit.it/ad/bro/lmi/LISP-MachinePR_Photo.pdf

Formats for inter-process communication are hard and far from a solved problem. Just look at what has come out in the past 10 years: Thrift, Protocol Buffers, Cap'n Proto, FlatBuffers, SBE, probably twice as many others I haven't heard of.

Re: The Collapse of the Unix Philosophy

#334

Earlier quoted context omitted.

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 b…

"Installing software was a mess." 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?

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)

Re: The Collapse of the Unix Philosophy

#335

I've always wondered why a new open-source OS has not arisen to claim the mantle of UNIX / Linux. There are so many ancient design decisions, piled up upon each other, which spawn millions of man-hours of frustration. It continues perhaps because of its esoteric nature. People don't want to throw away all the weird stuff they've learnt.

And also, because backwards compatibility matters once something is deployed on as large scale as Unix was. (Windows also has a similar problem.)

Maybe a parallel system needs to be implemented, like how OS X originally had a Classic OS 9 system running alongside. Once everyone had come to OS X, the classic environment was dropped.

Re: The Collapse of the Unix Philosophy

#336
post #96

Earlier quoted context omitted.

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…

That common opinion is odd, in hindsight.

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.

Re: The Collapse of the Unix Philosophy

#337

Earlier quoted context omitted.

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 wha…

Just remove systemd that is looking like an electronic injection that now requires 4Gb of RAM and a full OS to work and screaming for more.

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.

Re: The Collapse of the Unix Philosophy

#338

Earlier quoted context omitted.

"Installation on Windows was always much easier" 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…

Why don't you like homebrew? 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 l…

"Why don't you like homebrew?"

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.

Re: The Collapse of the Unix Philosophy

#339
post #123

Earlier quoted context omitted.

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.

UNIX and C are symbiotic, regardless of whatever runs on top, only POSIX and C are common to any UNIX. Windows roots are on VMS, not UNIX. There is hardly anything UNIX related on its architecture, regarding kernel design.

>only POSIX and C are common to any UNIX.

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%

Re: The Collapse of the Unix Philosophy

#340

Earlier quoted context omitted.

"Installing software was a mess." 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?

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 so…

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.

Post reply on HN