Hacker News Reader

What is more interesting is that while Linux might be a mess, so is everything else. Neither apple nor Microsoft or IBM managed to put something significantly better out-there at a price that was worth it.

One could consider OpenSolaris as something that could have filled that space in alternative future.

Check out Redox OS, it has many cool concept and is written in Rust.

In many ways Windows is better designed than Linux - although it has its own problems to weigh it down.

Windows has a lot different designs. You can tell when certain API for instance were introduced by how they are structured. The design of the internals is not as clear. It's not open source.

so is everything else.

Amen to that. Nature's biological organisms grow slowly, as does real knowledge. Poor nutritional choices lead to poor health. Natural ecology has adapted over 4 billion years. Hasty applications are wasty.

Many of the most successful organisms are bacteria that grow it incredibly High rates and mutate and evolve quickly

"Worse is better" meets "If you could have invented Facebook, you would have invented Facebook."

Linus was better being "wrong" for 25 years than Tanenbaum and GNU Hurd was being "right" but never shipping anything of non-toy importance.

I always liked the aphorism "Better is the enemy us good".

"Perfect is the enemy of good (enough)"

https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

My favorite take on the old saw is "If my auntie had three axles she'd be a semi-truck tractor".

I don't know. This seems more like post-rationalization than it does anything else. Note that nobody is calling Tanenbaum dumb or unintelligent. I think even Linus still highly respects his work. However, the claim that micro-kernels will be the future has been a near omnipresent claim for a long time now.

It is interesting to think that they would be easier to secure. I'm not convinced we have any evidence of that. Best evidence we have, is if you are willing to cutoff your past support, you can secure your future more easily. Supporting the past, though, has been a constant requirement of Linux the kernel.

So, I wish the Fuschia folks well, but it is hard not to be doubtful on that front.

> and Linux provided that home on the best dollar-for-dollar processors on the planet.

FreeBSD was very competitive. They both were launched around the same time, first version of Linux released in 1991, 386BSD in 1992. They share a lot of features, i386 target, posix compatibility. BSD pioneered some very important technologies, kqueue (epoll was couple years later in Linux), jail (docker was a decade later), etc.

I still don’t understand why everyone uses Linux now, but BSD only stayed in very niche markets.

BSD was subject to legal uncertainty at the time due to its relationship with Unix. By the time those uncertainties were resolved, Linux already had momentum.

What timeframe are we talking about here? Maybe I'm late to the party, but even for "special interest" Linux in the late 90s was already kind of well-known compared to the BSDs. (I was in school back then, no internet, and only learned about Linux from some folks already studying computer science). And I'm just using that point of data because when I came in contact with Linux there wasn't really much about FreeBSD, so either that was my bubble or it was technically competitive but had already lost the popularity contest.

> it was technically competitive but had already lost the popularity contest.

I think that’s the case. It never gained traction outside of niche markets. Most ISPs in late 90s were running a lot of BSD-based servers, companies like Apple, Juniper, Sony, Nintendo are still using BSD kernel and/or other components in their products, but it was and still is relatively little-known OS.

I can’t say I’m happy about that. I’m currently working on an embedded Linux-based firmware, I’d gladly switched to BSD. Maybe it’s just my irrational fears but I feel BSD is more reliable. However, that would require too much work to accomplish. I need stable and reliable GPU and WiFi drivers; hardware vendors (ARM and Realtek, respectively) only ship drivers for Linux, and I don’t think I’m competent in that area to attempt to port them, I never did substantial work on Linux nor BSD device drivers.

The explanation I've always heard is that the AT&T lawsuit [1] kneecapped BSD just as the x86 BSD variants were getting started.

[1] https://en.m.wikipedia.org/wiki/UNIX_System_Laboratories,_In....

> I still don’t understand why everyone uses Linux now, but BSD only stayed in very niche markets.

Myself and others would argue it's because of the GPL. If you can't distribute a binary without releasing the source, more contributions are going to flow upstream.

> I still don’t understand why everyone uses Linux now, but BSD only stayed in very niche markets.

People don't really use Linux, they use GNU. GNU utilities tend to be much more feature rich than their Unix counterparts. GNU and Linux are so intertwined it's easy to forget.

I could be wrong, but I think that GNU could run on top of BSD just as well as on top of Linux. If that's correct, then GNU doesn't explain why Linux beat BSD at all.

I started using Linux in 93. Why not BSD? Linux was user friendlier at the time. Really. I installed BSD as well but out of the box my up arrow did not even give me my previous commands. Also Slackware was easier to install, gave more guidance. Also BSD was for top experts only. Info was harder to find.

I don't remember where I first heard it, but the best formulation that I've heard over the years is that the BSDs are for people that love Unix; Linux is for people that hate Windows.

I honestly think there's a latent explosion of interest waiting for the BSDs in the near future. The sprint to bring a "modern UX" to the Linux ecosystem in the last decade has made it extremely easy for newcomers to adopt, but has also made it pretty nigh impossible to figure out what's actually going on in the background if you weren't along for the transitional periods. Whereas with the BSDs, the immediate learning curve is much higher, but at the end of that curve, you have knowledge of a coherent system that obeys legible and documented rules and the feeling, if not the reality, that you, the user, are in control of your computer.

There was a lot of FUD in BSD space back in 90s. People were worried they might get sued out of existence. And the original version of FreeBSD was lacking some critical things because they had to get rid of a lot of proprietary code to avoid the wrath of AT&T and its successors.

Additionally, FSF was in need of a Kernel and they chose Linux. There was a lot of evangelism involved. While BSD was recovering for the its troubled past, Richard Stallman and Co. were pushing Linux to the rest of the world.

Even Apple considered using Linux as a base for what would become Mac OS X — it was called MkLinux.

By the time BSDs managed to get their act together, it was already too late — Linux had gained critical mass.

> I still don’t understand why everyone uses Linux now, but BSD only stayed in very niche markets.

The AT&T and BSD lawsuit shutdown BSD development for a year or so and is cited as a major reason why Linux became the dominant POSIX open source operating system[1]. Marshall Mckusick[2] says at the end of a talk that he asked Linus why he didn't use BSD and his response was the uncertainty of the lawsuit[3].

[1]: https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc..... [2]: https://en.wikipedia.org/wiki/Marshall_Kirk_McKusick [3]: 47:30 https://www.youtube.com/watch?v=bVSXXeiFLgk

I don't do web stuff much at all. But when I think about it from a embedded view point what people do seems all wrong. You almost want the ability to fire off a thread in a language that just does immutable stack allocation. It's a hard constraint, but it'd be fast and easy to debug. Get rid of mutable data, get rid of persistent state and heap allocation.

"Get rid of mutable data" doesn't play well in embedded (at least for many applications). I have worked on an embedded system where the essence of the problem itself was one giant shared mutable state. (It was a video router for television stations.)

I spend a lot of time trying to contain state in event driven software with callbacks, it's a big hassle.

My thought was that there are other cases where you are really just doing batch processing blocks of data and then performing some action. And not holding state internally between runs. That's the usage case.

Thought was if you don't have neither mutable data and don't reuse stack frames. You can see exactly what happened if something goes wrong. And avoiding the heap means it's fast and deterministic.

You're leaving out the other big new trend of today, which is containers like Docker where now people like to run applications from within.

You're right, something is quite wrong, but Minix isn't the answer either, as it doesn't provide the isolation that containers and VMs do.

I think the point of containers is to make the exact needs of your environment configurable and runable in many different context.

That concept is very valuable and in the future this configuration might compiled to a unikernel that runs directly on the hyperwiser. Or maybe in a process on a microkernel OS that runs isolated processes.

For that, chroots (schroot) and tar.gz are almost sufficient.

Containers that just do resource allocation and minimal isolation (masquerading as configuration management somehow) are neglecting the power of strong network and storage layers over BSD Jails (although still maybe up to par with Solaris zones only recently?) that made them indispensable for systems administration at high velocity and scale. The fact we can use pluggable SDN stacks or different filesystem drivers like ZFS and LVM instead of bare bones overlayfs is important for an ecosystem.

In contrast, VMware with its multi-year cycles to release pluggable storage and network that was only available to a few already-entrenched vendors stifled progress under the vSphere ecosystem. I knew it was over for VMware when most of the large-scale customers were simply running containers in ESXi or if they were on OpenStack they did the same thing with an additional layer. With productive organizations, the needs of application developers always supersedes the needs of those managing the applications in production barring something non-negotiable like security / regulations.

Agreed. In addition to the factors you outlined, another reason behind the success of Linux in enterprise is Java. Java essentiallly enables people to ignore the OS altogether. So in essence, Linux becomes a dumb platform which can, in theory, be replaced anything else as long as it supports Java. Android is the same story. It may have Linux underpinnings, but that is out of convenience, not necessity. It has no bearing on the actual applications. Google could replace it with something else (Fuschia if it succeeds, or anything else like BSD, or technically, even Windows) any day with almost no effect.

security is indeed hard. however, people building microkernels at that time were not doing it for security reasons, and it is not clear that the types of microkernels they built (e.g., mach, with a huge unix "personality") had any better security properties than typical kernels. So I think it's a bit generous to look back and say "yeah tannenbaum wasn't incorrect".

the hypervisor part of your argument is more reasonable - the amount of virtualization on a machine these days seems excessive, with each level solving a different problem, and a cleaner solution waiting to burst forth. I suspect, however, with new containerization and other isolation technologies, that we'll come to an answer soon enough, and Linux will still be there underneath, monolithic and all.

> Linux wouldn't have been a solution on those platforms

And why is that? It takes a while for the most popular hardware to change and linux could easily track it.