Hacker News Reader

Comment by InTheArena | Hacker News Reader

This is the thread that I read in high school that made me fall in love with software architecture. This was primarily because Tanenbaum’s position was so obviously correct, yet it was also clear to all that Linux was going to roll everyone, even at that early stage.

I still hand this out to younger software engineers to understand the true principle of architecture. I have a print off of it next to my book on how this great new operating system and SDK from Taligent was meant to be coded.

View on HN

But why linux won? We know now it won, but what is the reason. Tanenbaum was theoraticaly correct. İf HN exist back then, I would argue most devs here would say Minix will last longer, monolithics is indeed an old idea that had been tried and tested etc.

Same question for the iphone. There are some link from HN where people saying iphone is dead bcs it does not support flash. But it didnt. Why it didnt?

İs performance really the only key factor when it comes to software design ?

  But why linux won? We know now it won, but what is the reason. Tanenbaum was theoraticaly correct. İf HN exist back then, I would argue most devs here would say Minix will last longer, monolithics is indeed an old idea that had been tried and tested etc.

In every situation where a microkernel is used, a monolithic version would run faster.

  İs performance really the only key factor when it comes to software design ?

Usually people want software to do two things. The first is do what it is expected to do. The second is to do it as fast as possible.

It seems to me that the microkernel idea came from observing that virtual memory protection made life easier and then saying “what would life be like if we applied virtual memory protection to as much of the kernel as we can”. Interestingly, the original email thread shows that they even tried doing microkernels without virtual memory protection in the name of portability, even though there was no real benefit to the idea without virtual memory protection, as you end up with everything being able to write to each other’s memory anyway such that there is no point,

  Same question for the iphone. There are some link from HN where people saying iphone is dead bcs it does not support flash. But it didnt. Why it didnt?

Flash was a security nightmare. Not supporting it was a feature.

>Usually people want software to do two things. The first is do what it is expected to do. The second is to do it as fast as possible.

If performance is second, it seems to be a very, very distant second for most uses. So much software is just absurdly slow.

Yeah I do not buy the reason being performance, we are literally using bloated software, and bolt crap on top of these bloated junk, when we could do much better.

It depends on whether something runs fast enough. Certain software, such as filesystem drivers in the OS kernel, never is fast enough as there is always someone who wants it to run faster, use less memory, etcetera. Efforts to get it as close to 0 overhead as possible (without killing maintainability) tend to be applauded by the community. Here are some patches I have written against kernel filesystem code in the past few years that were merged because people care about performance:

This patch shaved a minuscule number of cycles off a hot code path, and was accepted on the basis that microbenchmarks showed that it made extremely hot loops run a few times faster:

https://github.com/openzfs/zfs/commit/59493b63c18ea223857066...

This patch eliminated a redundant calculation that used 0.8% of CPU time:

https://github.com/openzfs/zfs/commit/3236c0b891d0a09475bef8...

The impact of the following patch was not measured, but it is believed to have made checksum calculations run several times faster by eliminating unnecessary overhead:

https://github.com/openzfs/zfs/commit/59493b63c18ea223857066...

The reason why the impact was not measured is that the code runs with interrupts disabled, which makes it invisible to kernel profilers. Another way of measuring was needed to quantify the improvement, but everyone agreed that it was a good improvement, so there was no need to evaluate the before/after improvement.

Few people are willing to accept the performance impact of moving their filesystem driver into userland and practically no one wants the performance impact of moving almost everything into userland.

Yes, of course, but in general we tend to make the best out of already-existing bloated stuff, I think.

The first link was supposed to be this:

https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...

It depends on whether the software is performance critical. Many of the functions in the OS kernel are performance critical. In many cases in userspace, things are fast enough, rather than performance critical. This is why for example, Java in userspace took off, while Java in the kernel has not.

Torvalds points out in the linked thread that Linux was already freely available and that it was easier to port stuff to it. Convenience often wins over technical superiority when it comes to personal use.

Monolithic systems are faster to design and implement. Systems with decoupled components require more time to design, implement and iterate. A lot more time.

This doesn't just apply to kernels. It applies to anything in software; writing a huge monolith of intertwined code is always going to be faster than writing separate components with clear API boundaries and responsibilities.

Of course, monolithic software ends up being less safe, less reliable, and often messier to maintain. But decoupled design (or micro-kernels) can take SO MUCH longer to develop and implement, that by the time it's close to being ready, the monolithic implementation has become ubiquitous.

Linux won in large part because it was in the right place, at the right time: freely available, and rapidly improving in functionality and utility, and it ran on hardware people had access to at home.

BSD was mired in legal issues, the commercial Unix vendors were by and large determined to stay proprietary (only Solaris made a go of this and by that time it was years too late), and things like Hurd were bogged down in second-system perfectionism.

Had Linux started, maybe, 9 months later BSD may have won instead. Had Larry McVoy's "sourceware" proposal for SunOS been adopted by Sun, perhaps it would have won out. Of course, all of this is impossible to predict. But, by the time BSD (for example) was out of the lawsuit woods, Linux had gained a foothold and the adoption gap was impossible to overcome.

At the end of the day, I think technical details had very little to do with it.

And most commercial UNIXes would still be around, taking as they please out of BSD systems.

They are still around. And not taking much from BSD it does not seem.

Solaris, AIX, HP-UX, and UnixWare could all use a shot of BSD. I was playing with UnixWare earlier today. Time capsule.

They are around, struggling, a shadow of the greatness they once were before everyone went Linux.

Additionally, Apple and Sony have already taken what they needed.

In early 1992 I emailed BSDI asking about the possibility of buying a copy of BSD/386 as a student - the $1000 they wanted was a little too high for me. I got an email back pointing me at an 'upstart OS' called linux that would probably suit a CS student more, and was completely free, that week I think it was 0.13 I downloaded that week, it got renamed 0.95 a few weeks later, there was no X (I think 0.99pl6 was the first time I ran X on it, from a yggdrasil disc in august 1992) but it was freedom from MSDOS.

Ironically, 386BSD would have been brewing at the same time with a roughly similar status.

I installed 386BSD for my university admin in 1991 I think. They paid my to do it but it was otherwise free.

I installed 386BSD for my university admin in 1992 I think. They paid my to do it but otherwise it was free. Linux was not yet version 1.0 if I remember correctly.

Yes, 386BSD was free, and the precursor to FreeBSD, NetBSD and OpenBSD. BSD/386 was a different, commercial product though, available a few months earlier.

All 3 projects, BSD/386, Linux and 386BSD gained recognition over the span of about 6 months in 1992.

Yes, I know. Interesting that BSD/386 was pointing people at Linux. I guess they knew that 386BSD would eat their lunch. Perhaps they did not see Linux as real competition.

Linux was free. You see that Linus says Tanenbaum charges for Minix.

I started running Linux in October 1994.

One of the main reasons I chose Linux over Free/NetBSD was the hardware support. Linux supported tons of cheap PC hardware and had bug workarounds very quickly.

I had this IDE chip and Linux got a workaround quickly. The FreeBSD people told me to stop using cheap hardware and buy a SCSI card, SCSI hard drive, and SCSI CD-ROM. That would have been another $800 and I was a broke college student.

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

Linux even supported the $10 software based "WinModem" I got for free.

I started running linux in 1992 or so. I converted to FreeBSD right around the time you were starting with Linux because I had the opposite experience:

I was new *nix sysadmin, and I needed good NFS performance (replacing DEC ULTRIX workstations in an academic dept with PCs running some kind of *nix). I attended the 1994 Boston USENIX and spoke to Linus at the Linux BOF, where he basically told me to pound sand. He said NFS performance was not important. So I went down the hall to the FreeBSD BOF and they assured me NFS would work as well in FreeBSD as it did in ULTRIX, and they were right.

I've been a FreeBSD user for over 30 years now, and a src committer for roughly 25 years. I often wonder about the alternate universe in which I was able to convince Linus of the need for good NFS performance..

When I started college in 1993 about half the computer lab were DEC Ultrix machines. By the time I graduated it had transitioned to Solaris and HP-UX.

I had a summer internship in 1995 and the Win 3.1 machine was so unstable for running an X server to the Suns, 3270 mainframe emulator, and browser using the Win32s (environment for running 32-bit application on 16-bit Win 3.1)

We found the supply closet with over 200 old 486 machines. The other intern and I installed Linux on some and it worked far better than the Win3.1 setup. The older guys saw it and wanted one too. We set up an assembly line with a Linux NFS server with the Slackware disk images to avoid swapping floppies. At least over a 10 Mbit network we found the NFS performance to be fine.

A couple of years later at my job after graduation I convinced our manager to buy PCs to use as X terminals with larger monitors and move the Suns to the closet for the chip design jobs.

I remember having some NFS issues and Trond Myklebust (Linux NFS guy) had me trying some NFS version 3 patches that improved performance between a Linux client and Solaris server.

The NFS issue that I had was that I was working for a math/stats department, and the profs made heavy use of LaTeX. Disks were tiny, and the fonts they required were huge. So we had fonts centrally available from an ULTRIX NFS server with a "lot" of disk space (for the time). When running xdvi on Linux, it would take minutes to render a page, with each character showing up one by one. I eventually figured out that xdvi was seeking around byte-by-byte in the font files. Since Linux didn't have any NFS caching, each new read for a few bytes ended up as a slow round-trip over 10Mbs ethernet. DEC ULTRIX (and FreeBSD) rendered the page in seconds, due to having working caching for NFS.

I remember various issues with NFS file locking and I always thought the security and permissions were crap.

I remember in my intro operating systems class we learned that you could open a file for read or write and they had a file offset pointer etc. Then I learned that NFS (v1 and v2) were stateless. The joke I heard was that Sun servers were so unstable in the 1980's that the system was stateless so that it could crash and reboot and didn't need to worry about the client's file state.

My college used AFS (Andrew File System) and the DCE Distributed Computing Environment. It was great as a normal user being able to create my own ACL Access Control Lists of other groups of students and give them read access to some files and make directories for class projects and give another student write access to a single directory in my home dir. NFS with groups is so limiting in comparison.

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

I haven't used LaTeX in a long time but I was always impressed how it could make integral symbols over fractions with summations and everything else look perfect.

In 1992, I used both 386BSD and Linux. There is no doubt that BSD was the better technology at the time. It was not even close. But Linux had better consumer hardware support even then. I have used Linux continuously since then while I stopped using BSD before FreeBSD even came out.

My favourite distro right now is Chimera Linux which is Linux/BSD hybrid of sorts.

> Tanenbaum was theoraticaly correct.

He was only correct in a world where programmer and cpu time is free and infinite.

Care to elaborate how working in a microkernel instead of a monolithic one wastes programmer time? Because AFAIK, every single evidence we have points the exact opposite.

Also, microkernels only waste CPU time because modern CPUs go to great lengths to punish them, for no comparable gain for monolithic kernels, apparently because that's the design that they always used.

I understand CPU time, as micro-kernels tend to be less efficient, but why do you include programmer time?

My understanding is that it's easier to develop drivers for a micro-kernel. If you look at FUSE (filesystem in user space), and NUSE (network in user space), as well as the work with user-space graphics drivers, you see that developers are able more rapidly implement a working driver and solve more complicated problems in user space than in kernel space. These essentially treat Linux as a micro-kernel, moving driver code out of the kernel.

A microkernel only gives you scheduling, IPC and virtual memory. You and others get to implement everything else on top of that. That means there are no NUSE or FUSE interfaces and if you want them, you get to implement them as part of userland servers. There is no kernel in between to say “this is how it is done”. How it is done is a consensus among the userland components with the kernel abandoning any role for telling them how to things beyond providing the IPC used to communicate.

With NUSE and FUSE, the kernel is very much going in between userland processes and saying “do things this way”. Microkernels do not have a monopoly on the idea of moving code into userspace. There are terms for other designs that push things into userspace, such as the exokernel, which goes well beyond the microkernel by handling only protection and multiplexing.

I think the term library OS has been proposed for what FUSE/NUSE do. It is a style of doing things that turns what were kernel functions into libraries that can either be accessed the old way through system calls redirected to daemons via shims or as libraries in the process address space. This is an extension of monolithic/hybrid kernels, rather than a microkernel. Closely related would be the anykernel concept as demonstrated through rump kernels, which supports the same code being compiled for both in kernel and in userspace uses:

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

Earlier work in this area can be found in OpenSolaris, where various kernel code were compiled both as userspace libraries and kernel modules. The most famous example is ZFS (it was/is used to make development faster via stochastic testing), but other things like the kernel encryption module received the same treatment.

I went to an advanced high school then that had Internet access. We had multiple Sun3/4 and IBM AIX system. I really wanted a Unix system for myself but they were so expensive. The students who graduated a year ahead of me and started college started emailing me about this cool new thing called Linux. Just reading about it was exciting even though I didn't even own a PC to install it. I saved up all my money in 1994 to buy a PC just to run Linux.

Reply on news.ycombinator.com