Comment by marios | Hacker News Reader

Comment by marios | Hacker News Reader

Two sentences from the article struck me:

> Linus Torvalds once famously said that there is no design behind the Linux kernel.

Reminds of a talk/interview where Bryan Cantrill (of Solaris/Illumos/Joyent fame) said: "You can't evolve your way to containers". Sure evolution is nice and can lead to nice results, but I refuse to think that not designing things is a good idea. From my (limited) experience, a properly designed system helps you. When dealing with poor design, you have to fight whatever abstraction the idea evolved to.

> One could perhaps make an argument that the lack of a proper container object was necessary in the early days, when the community was still trying to figure out how containers should work in general.

I don't think that's an argument, really. The phrasing suggests Linux pioneered containers, which is simply untrue. Containers existed before, in the form of FreeBSD jails and Solaris Zones. Linux suffers from sever NIH in this case IMHO. Was the design of these other systems even considered ? Were there limitations that made them impractical ?

> Containers existed before, in the form of FreeBSD jails and Solaris Zones.

Even earlier, depending on what variant of mainframe virtualisation you are prepared to count.

> Were there limitations that made them impractical ?

Not being up close with LKML workings, I can only speculate that it's due to Conway's Law. Having a kernel-level concept of "a container" requires changes cutting across a number of subsystems worked on by very distinct groups of people.

Cathedral-style development can achieve that kind of a change. The organisation responsible for Solaris saw the vision, worked out what had to be changed to create a uniform mechanism, then changed it. They achieved broadly the same with ZFS.

That said, there is container-as-a-runtime, in which I think having a consistent concept a la Zones has enormous value for consistency, security and performance optimisation opportunities. But there's also container-as-ecosystem. More accurately, _images_ are containers, worthy of that name, because they created such a simple way to take advantage of complex low-level APIs.

Cantrill is quite right. There are many examples where the lack of design hurt Linux, and Cantrill will list many of them for you!

E.g., epoll -(what a disaster). Or inotify. Or containers (the subject of TFA). Or kernel debuggers (never mind). Or tracing frameworks (actually, here Linux has finally evolved something similar to DTrace, namely all the ebpftrace stuff). Or cgroups. Or the kernel keyring. Or...

Lack of design is not a virtue, not now.

Sure, design and design review comes with the grave danger of bikeshedding. (I'm using "design" here loosely to mean what we called "architecture" at Sun.) And it has higher initial cost to not designing. But in the long run it pays (it certainly wasn't the cause of Sun's demise).

Some people really mean “the code is the design” when they say “there is no design.” The point being that it’s easy to come up with a vague “design” that falls apart (or comes together, but as an unmaintainable mess) when you try to implement it.

Reply on news.ycombinator.com