On the scalability of Linus | Hacker News Reader

On the scalability of Linus

lwn.net

82 pointsjpablo36 comments

The problem is that ARM is a licensable architecture, so there are lots of minor variations in sub-architectures.

The companies maintaining these have no motivation to consider the problem of maintaining /all/ of these, they're happy to basically copy/paste some other code until their CPU work.

Linus is saying that that's not going to work anymore, that they're going to have to come up with a way to consolidate their codebases.

That's probably the right solution, but it's a hard problem. NetBSD is probably the kernel that goes to the most effort to make clean, modular, orthogonal abstractions across hardware families and components, but it took them a lot of design effort up front, and continual policing of the abstraction boundaries and debugging of weird variants to make things actually work that way.

I don't think it's any coincidence at all that the most successful open source effort ever is the same one where there is the greatest force of personality in charge, who insists on maintaining top-down control. I'm not convinced that lateral organization between developers can ever work very well.

Besides your hyperbole "most successful" I point to FreeBSD for a quite successful open source project which is not controlled top-down by one person. Apache httpd (or other apache projects) also come to mind.

I have no idea how FreeBSD is managed. Is it explained anywhere? I'd love to see how it compares to linux.

They gave a presentation with an accompanying paper a few years ago to explain how the project works:

http://video.google.com/videoplay?docid=-4400856579609253323

http://www.watson.org/~robert/freebsd/2006eurobsdcon/eurobsd...

There's a Core Team reelected each 2 years. Btw it just changed:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=11461+0+/usr/lo...

Btw, they have an excellent practice of quarter reports, here's the latest: http://www.freebsd.org/news/status/report-2010-04-2010-06.ht...

I wish every opensource community had such clean summary of what they do.

While I think FreeBSD has created a great piece of software I don't think you can say that they are as successful as Linux.

You can't really compare the two. If you want to compare you'd have to look at GNU/Linux. Attributing that success to just the genius of Linus goes a bit too far.

While the FreeBSD people didn't have their momentum to market themselves in a way Linux community had, they still manage to produce better system.

The other thing is that most people, even who consider themselves OS hackers, don't need such sophisticated and cohesive system. Or they don't have an opportunity to really dive in to see the difference.

Wouldn't "hyperbole" imply that the statement isn't literally true?

Singling out Linux as the most successful open source project is not literally true in my opinion. It is successful, other projects are successful too - how do you want to determine "most successful"?

It is successful, other projects are successful too - how do you want to determine "most successful"?

Most mindshare? Most impact? Most users?

I wonder what metric you'd come up with that doesn't have Linux come out on top.

I'd believe more users have heard of Firefox than have heard of Linux.

Agreed. That's one (valid) metric.

But I think once you take at least two into account...

IMO if you count servers installed with Linux as "users" then Linux may have more users than Firefox (no hard data to back this up though)

And yet more users are using services running on top of Linux than are using Firefox.

The best infrastructure software is the one you don't even know it exists ;)

for the sake of just finding a counterproof to something I agree with: maybe perl for the second?

There is basically no *nix without perl (I recall it was also part of the MS build system for rotor), it has influenced basically every programming language in the last decade and it's been a dependency of the linux kernel build for a long time, though I seem to recall it's now removed :)

Ironically perl too basically has a benevolent dictator for life.

re: Apache, I don't believe that most people understand the scope of the current Apache Foundation. From a recent members meeting:

  Projects: 84
  Incubating: 36
  Labs: 30
  Committers: 2359
  Members: 298
  iCLAs on file: 3583
  SVN Revisions: r962795

While some of those 84 Top Level Projects aren't well known, many of them are the standard implementation used in their respective places -- and many of them have strong communities years after their project started.

I think Apache is important in this sense, because its building up new projects with similar community expectations, rather than just being held up as a 'good way' to do things.

If you include the personality-driven schism between FreeBSD, OpenBSD, and NetBSD, it's not so clear the 'core-team' maintainer model works so well. That's what Ted Tso was warning the Linux community about back in '98.

What personality-driven schism? (I'm serious: you could reasonably argue that the OpenBSD/NetBSD split was personality-driven, but to the best of my knowledge, FreeBSD has no personality conflicts with either.)

and the arguably most successful company (apple) has the same force of personality.

> who insists on maintaining top-down control

This is quite the opposite of what he insists on. He insists on good code, not control. He maintains control because of the former. He went so far as to design git to avoid top-down control and make sure that anyone can fork the code at any time.

The funny thing about the ARM "blow up" is that all the ARM devs for the most part agree with him. Things needed to change, he knew it and they knew it. He just provided the push.

People use Linus' kernel version because of his track record. Don't like it? Fork it.

The day Linus starts failing miserably is the day another mainline will emerge, and everyone will switch to that. Nothing here to worry about.

There might be comparable forks to Linux out there right now. Does anyone switch? No. Linux is the windows of Unices. You can't dethrone it just by coming up with a better fork.

There's a difference between being slightly better than something that's still satisfactory, and being good in comparison to something that's no longer satisfactory. Look at X11: everyone used XFree86, even though forks were possible—until they decided to go in a direction people didn't like. Then people started using X.Org pretty damned fast.

While I agree with what you are saying, your analogy is not completely accurate. Switching GUI is nowhere near switching the kernel in terms of risk and the hassle that might come with the change. The main reasons for inertia are the linux servers and the development stack that's built on top of linux servers. Most deployed Linuces have neither X.Org nor XFree86 installed on them.

The kernel is already evolving constantly, and a major version upgrade has to be thoroughly tested before rolling it out on a production system. A fork won't be that different - if Linus switches the license tomorrow, most kernel devs will just move to the forked codebase.

A license change is a bad example. Nobody can switch the license for Linux. It has always been GPLv2-only, you'd need the approval of all contributors to the kernel to switch.

That was something of a palace coup, though--- x.org wasn't really an upstart fork, but a secession of a large portion of the XFree86 core team. They also managed to get the X Consortium to hand over the old x.org domain to them and bless their version as the new official reference implementation, which cemented their new status.

Most distros patches their kernels, though.

Like android did.

This explanation, while popular, always seems to willfully avoid taking social capital into account.

"There's there door, you can leave any time" isn't an answer to the people who are invested in a community and actively seeking ways to ensure its success.

Of course there is also a limit in our time about how much the kernel community can grow.

That limit probably increases somewhat asymptotically to the human population. The actual kernel community size will probably increase slower, though. I think that increase is lower than the increase of how development in IT will simplify things.

I.e., if my assumption stays true, there wont be any problem.

Like Windows, Facebook, and others; it is the platform that makes Linux scalable. With that being, we'd like to create a platform for other developers to collaborate and develop their own.

Reply on news.ycombinator.com