| |||||||||||||
The monoculture of meritocracyThe monoculture of meritocracyPosted Nov 13, 2012 23:09 UTC (Tue) by geofft (subscriber, #59789)Parent article: Crowding out OpenBSD
I've never been sure how to resolve "monocultures are harmful" with a volunteer-based meritocracy. If there is a "better" solution, how do we motivate people to work on the "worse" one? If Linux works on my laptops and has all the features OpenBSD has, why should I install OpenBSD?
I can see why it would be worth someone like Oracle putting money into both Solaris and Linux, both MySQL and Oracle RDBMS, since they can motivate developers with employment. But why should I, as a potential volunteer who's only motivated by impact and personal interest, work for the underdog?
One possible response is that if I have a crazy new idea for how kernels should work, it would be easier for me to get that done in the BSDs, as smaller projects, than in Linux. (But to counter my own counterargument, I'm much more familiar with how the Linux development process works than how the BSDs work.) I'm curious what other motivations we can come up with.
(Log in to post comments)
The monoculture of meritocracy Posted Nov 13, 2012 23:23 UTC (Tue) by pynm0001 (guest, #18379) [Link]
For KDE we try to at least give the token nod to portability, by using facade patterns to try to map high-level concepts to appropriate low level libraries (something for which we take a lot of flak, btw). For instance with KDE 4.10 we will improve support for a shared-memory cache primitive on OpenBSD (and it should have worked even earlier, but then I can't test on OpenBSD... ;).
That doesn't help OpenBSD horribly much since they (or someone) still has to donate the manpower needed to report bugs, sometimes fix them, and test that the bugs are fixed (and stay fixed). But we at least don't try to call OpenBSD unsupported "by fiat" by locking in low-level required dependencies that are highly Linux-specific (that is, as long as it's reasonably doable without, and obviously Linux-specific utility applications will simply not work elsewhere, but the desktop would still be available).
The monoculture of meritocracy Posted Nov 14, 2012 3:02 UTC (Wed) by aryonoco (subscriber, #55563) [Link]
Every layer of abstraction that you introduce, every layer of mapping that you put in your code, has a cost. It has a cost in implementation, it has a cost in that it reduces readability and maintanability of code, and it has a cost in that every additional layer is a potential new source of bugs.
Obviously there are benefits to it as well, namely expanded number of users, and the ability to run on "other" Unixes.
Time and resources are finite, and that's certainly true for free software projects. Developer of upstream projects, whether they do it explicitly and methodically, or implicitly and without realising, do a cost/benefit analysis to see whether supporting those other systems is worth it. For a long time, the answer was yes, as the BSDs did offer genuine advantages over Linux, and they had a non-insignificant userbase.
With time, things have changed. Research and development is now increasingly happening on Linux and the percentage of non-Linux users has diminished. To incur all those costs just to make life easy for less than 2% of the userbase is a scenario that is increasingly hard to justify for most projects.
The monoculture of meritocracy Posted Nov 14, 2012 5:39 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
maintaining portability to different systems can also end up resulting in better software for every system.
I'll point you to the Linux kernel and it's support of many different CPU types. This requires layers of abstraction, just like supporting different *nix flavors. But, even with this cost, Linus is on record as saying that the kernel is significantly better than it would be if it had remained x86 only. The comment I am thinking of (from several years ago) was that modern kernels are not designed for any existing CPU, they are designed for some theoretical 'perfect' CPU with arch specific helpers to fill the gaps that all existing CPUs have (along with carefully constructed layering violations for the most performance critical sections)
This makes it rather easy for Linux to be ported to a new CPU.
I would like to think that while portability has it's costs, it should also have it's advantages. If the userspace software is modularized properly, just about all of the differences between different *nix (and similar) systems should be out in the periphery of the modules, not in the core logic.
This should not only help them be portable to the BSD family, but also to be better able to take advantage of new features in Linux (and for that matter for people to notice that a lot of programs are implementing similar work-arounds and then propose new features for Linux to avoid the need for them)
I wouldn't be surprised to see that this leads to improved portability to things like Android as well.
The monoculture of meritocracy Posted Nov 14, 2012 9:45 UTC (Wed) by ortalo (subscriber, #4654) [Link]
IMHO, the Linux monoculture prevents sometimes from adressing specific problem areas (at least it slows down things enough to miss the target).
Linux is not yet totally ubiquitous - the most recent example is the Android "port" (which involved a lot of domain specific hacks). It will probably never be because it's probably impossible - nothing wrong per se by the way, it has already gone a long way towards the general usefulness goal.
But some areas may benefit from the immediate availability of an alternate (possibly less versatile) free software solution: security box, wifi boxes, GSM phones (look at the "OS" selected for OsmocomBB), home automation devices, networking equipment; possibly: supercomputers, industrial control systems, industrial embedded systems, etc. [1]
Sounds like political movements are needed: bringing up an alliance between all the "freedom" partners should be on the table, with the objective of settling on a long lasting treaty. It seems to me that this is necessary to refuel some allies again, up to the task.
[1] IIRC, sometime in the 90s, the Fermi lab linear accelerator needed an OS for a VAX. Only a BSD fitted there seriously. That's a single computer in production, but well... only two such scientific equipements have ever been built in human history (Fermi Lab and CERN) so... point gained.
The monoculture of meritocracy Posted Nov 14, 2012 10:05 UTC (Wed) by nhippi (subscriber, #34640) [Link] IMHO, the Linux monoculture prevents sometimes from adressing specific problem areas (at least it slows down things enough to miss the target). Linux is not yet totally ubiquitous - the most recent example is the Android "port" (which involved a lot of domain specific hacks).I don't see how Linux monoculture prevented anything. Quite the opposite, Google was able to leverage Linux when creating Android. If anything, Android proves Linux is not a monoculture.
The monoculture of meritocracy Posted Nov 14, 2012 14:42 UTC (Wed) by ortalo (subscriber, #4654) [Link]
I was speaking of Android modifications only to illustrate the fact that there are no totally ubiquitous OS (or kernel in that case). Alternatives *may* have been a better base.
A BSD was not even considered for projects like Openmoko [1]. They are still not considered for the FreedomBox project even though they share obvious concerns with one of them.
Of course I cannot guess what would have occured for these projects if a BSD had been given a try and if these projects would have been more successful.
[1] However, it seems to me that the BSDs should have been interesting candidates for a smartphone (full networked OS in a single source tree, focus on maintainability, etc.).
The monoculture of meritocracy Posted Nov 15, 2012 16:59 UTC (Thu) by pboddie (subscriber, #50784) [Link]
The issue of which platform to use is mostly concerned with what most of the potential contributors are likely to know and which platform is covered best by most of the available documentation and shared knowledge, so if it's easier to find people who know how to write a Linux driver for some hardware, then a project will choose Linux first and foremost. That hasn't stopped other operating systems being ported to such devices, though:
http://wiki.openmoko.org/wiki/Category:Distributions
And it's perfectly possible that other platforms can take advantage of the work done by Linux developers to get driver support for hardware even if they refuse to port the actual drivers. I'm aware of at least one "from scratch" operating system project for the Ben NanoNote that has presumably been able to take advantage of the fully documented hardware and Free Software drivers already written for Linux, so it's not as if the Linux community is denying others opportunities. In fact, it's very much the opposite of that.
The monoculture of meritocracy Posted Nov 16, 2012 8:35 UTC (Fri) by ortalo (subscriber, #4654) [Link]
I totally agree with the importance of knowledge you outline.
However, I also think alternative OS do not take so much advantage of Linux work (or cooperation) as they suffer from the fact of being considered second class or second hand implementation (and not the full solution, i.e. "maybe better than Linux").
BSD for a smartphone OS Posted Nov 16, 2012 10:11 UTC (Fri) by pboddie (subscriber, #50784) [Link]
Actually, isn't the OS for at least one of the Danger products based on BSD? According to the Wikipedia entry for the Danger Hiptop/Sidekick, they supposedly use NetBSD. Of course, vendors don't have to do anything more than reproduce licensing information for such permissively licensed software, and maybe only in obscure places even then, and so the awareness of a technology in the industry never reaches a point where everyone wants to try it out.
Some people praise permissive licensing and may refer to software licensed in such a way as their "secret weapon" or "competitive advantage", but if they're not willing to share their changes, any wider growth of such technologies is likely to lag behind things like Linux where there is a requirement to share and a resulting culture that does so extensively.
The monoculture of meritocracy Posted Nov 17, 2012 16:53 UTC (Sat) by Jandar (subscriber, #85683) [Link]
> And specifically, Linux should *stop* claiming these targets (because they are for the BSDs).
If anyone using linux has an itch to scratch in these areas, should it be forbidden for him/her to improve linux? Do we patronazingly say: go away, linux has to be awful in this so that *BSD can shine a little?
The monoculture of meritocracy Posted Nov 24, 2012 22:02 UTC (Sat) by mfedyk (guest, #55303) [Link]
I think we should call this initiative "no os left behind".
Unions for the developers would be good too.
The monoculture of set theory Posted Nov 24, 2012 22:28 UTC (Sat) by neilbrown (subscriber, #359) [Link]
> Unions for the developers would be good too.
I prefer intersections. They let you work together without forcing you to.
The monoculture of set theory Posted Nov 25, 2012 3:50 UTC (Sun) by Trelane (subscriber, #56877) [Link]
Personally, I prefer complements. Because I'm a contrarian.
The monoculture of meritocracy Posted Nov 14, 2012 9:12 UTC (Wed) by quintesse (subscriber, #14569) [Link]
> it has a cost in that it reduces readability and maintanability of code
I'm sorry, but this is a myth that always gets thrown about by people who somehow have an allergy to the word "layers". One of the reasons for introducing a layer can be abstraction where you reduce a certain problem to its bare essentials making it *easier* to understand (and implement).
> and it has a cost in that every additional layer is a potential new source of bugs.
Any code you add can improve or reduce readability/maintainability and introduce bugs, it's definitely untrue to say that a layer will always worsen the case.
The monoculture of meritocracy Posted Nov 14, 2012 11:54 UTC (Wed) by dgm (subscriber, #49227) [Link]
All of this is only true if (and only if) the abstraction is correct, in the sense that nothing relevant is omitted. Sometimes this is not the case, and then they make things more complex instead of simpler. Coming up with good abstractions is hard.
And there's always a price to be paid for the abstraction, be it in performance, flexibility or simplicity. As with many things, there's a trade off that has to be considered.
The monoculture of meritocracy Posted Nov 14, 2012 12:06 UTC (Wed) by quintesse (subscriber, #14569) [Link]
Of course, but making things more complex instead of simpler is not something unique to layers. In fact if you just keep adding more and more code to an application without any thought to structure and design you'll probably end up with a mess that nobody but you understands.
The monoculture of meritocracy Posted Nov 14, 2012 14:35 UTC (Wed) by dgm (subscriber, #49227) [Link]
I agree. The problem is that some think (or at least that's what they say) that abstraction is some kind of panacea that solves all problems, for free. Neither is true.
The monoculture of meritocracy Posted Nov 14, 2012 14:40 UTC (Wed) by quintesse (subscriber, #14569) [Link]
You get no beef from me on that point. In fact over-engineering can turn something relatively simple into this hugely complex monster. (I've probably been guilty of that myself a couple of times before learning to KISS)
The monoculture of meritocracy Posted Nov 14, 2012 9:53 UTC (Wed) by mpr22 (subscriber, #60784) [Link] If you think abstraction layers always reduce readability and maintainability, I look forward to seeing your explanation of how a GUI application written in raw Xlib calls is more readable and maintainable than one written using a toolkit.
The monoculture of meritocracy Posted Nov 14, 2012 17:13 UTC (Wed) by alankila (subscriber, #47141) [Link]
*sigh* I'll bite.
Take a look at the size of some commonly used toolkit, oh, GTK+3. That's 14 megabytes of compressed source, though some part of this is bound to be data. Whatever. 14 MB, I'll run with it.
Now suppose you write a hello world application: that's 14 MB + your own source, probably no more than 1 kB. Now write xlib application: it's probably a bit longer with respect to your own code, but eliminates 14 MB of code you did not need. Now, if you wish to understand the total system, you need to understand all your own code, all of GTK+, and then all of Xlib, and whatever is underneath it. If you don't have GTK+, you eliminated that much abstraction you did not need to understand.
Therefore: if I am allowed to stipulate that complexity can be counted this way, any additional code you add is a net loss, because it makes the total system more complex, no matter how pretty the world constructed in the cocoon of this new abstraction. But is this a valid argument? I don't really think so. GTK+ is probably allowing you to avoid having to deal with Xlib entirely, so you never have to learn any bit of it and yet get applications that run in X. And of course it gives you nice features like themeability practically for free. It's actually something better than Xlib for most programmers (which is why practically nobody writes raw xlib programs).
All of this is besides the point. My personal experience when dealing with abstractions that simply wrap some other functionality, is that they always make things worse. Let's call this the "driver pattern". These drivers are never quite as nice as the abstraction's API is, and the abstraction hides information from me which I generally need to make the application work well. Maybe I don't get good error reporting, or can't access all the functionality, or whatever. So I believe criticism of the driver pattern is often justified, because it rarely actually helps; rather, it seems to me that a lot of people are simply deluded to only count the upsides and wave away the downsides.
The monoculture of meritocracy Posted Nov 14, 2012 18:14 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
I challenge you to write a "correct" hello world Xlib in 1kB. "Correct" means: interacts correctly with modern Window & Compositing managers (think resize, think WM hints, think liveness pings, ...); has anti-aliased rendering of the "Hello World" string. For style points: make the "hello world" string selectable for copy/paste.
Once you have banged you head on the table trying to do that and come up with the required ~8000-16000 lines of xlib code, try the same thing with GTK and appreciate that this is really possible in less than 100 lines of source code. You may or may not want to revisit your POV on abstractions...
The monoculture of meritocracy Posted Nov 14, 2012 18:38 UTC (Wed) by alankila (subscriber, #47141) [Link]
You missed the point.
The monoculture of meritocracy Posted Nov 14, 2012 22:53 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
My point is: If you want to get any work done in reasonable time, you have to rely on a lot of leaky abstractions (There are errors that can be caught at the Xlib level, that cannot be caught at the gtk level -- but frankly, no user cares). Prefer to fix an abstraction if it offers almost what you want, but not quite (or file a bug) than working around it.
The second aspect that I did not mention so far: Abstractions help making software better by introducing well-defined interfacing points for testing. A class doing nothing else but wrapping a file descriptor and operations on it is mockable for unit tests. A bare file descriptor is not.
The monoculture of meritocracy Posted Nov 16, 2012 4:33 UTC (Fri) by alankila (subscriber, #47141) [Link]
I have nothing against using abstractions, as long as they are good ones. It's just that not all abstractions are good ones. This kind of discussion is really impossible to conduct properly without either drilling down on the features of good vs. bad abstractions, or talking about specific examples and why or why not they might succeed in what they do.
"A bare file descriptor is not."
Indeed. I quite think that libraries are better than file descriptors as abstractions for functionality. For instance, on java side you usually have a stream, and can easily replace it by your own class. C libraries, in contrast, often want file names or file descriptors, which is frankly inconvenient and irritating.
Heretical, I know.
The monoculture of meritocracy Posted Nov 14, 2012 22:47 UTC (Wed) by jonabbey (subscriber, #2736) [Link]
See http://blog.aerojockey.com/post/iocccsim for a very short Xlib based flight simulator. ;-)
The monoculture of meritocracy Posted Nov 15, 2012 8:13 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
And :
1 it's not < 1k 2 the little text rendered does not satisfy modern constrains (could not check the WM interaction from screenshots)
So it's obviously not an exercise in avoiding unneeded abstractions, since it is not feature-comparable to something that would have used those abstractions.
The monoculture of meritocracy Posted Jan 10, 2013 19:42 UTC (Thu) by zlynx (subscriber, #2285) [Link]
Missing features in abstractions: definitely true for Xlib.
I worked with a project a long time ago that ran on Solaris. It was nifty, and when the X server shut down for any reason (crash, disconnect, shutdown) the application just kept running and you could just go back to the application's command terminal and type "display :0.0" and it would put the GUI right back where it had been. You could put copies of the GUI on as many displays as you liked.
Try doing THAT with GTK.
The monoculture of meritocracy Posted Jan 10, 2013 20:20 UTC (Thu) by nix (subscriber, #2304) [Link]
Indeed, Emacs can do this today (it's how I normally use it). But don't try doing that with Gtk, indeed: it'll coredump.
There's an open bug about this.
It's eleven years old.
which is unfortunate Posted Jan 10, 2013 21:47 UTC (Thu) by renox (subscriber, #23785) [Link]
That is what is annoying me so much with many criticisms related to X: in fact in many case, they should be directed towards the toolkits not against X..
The monoculture of meritocracy Posted Nov 14, 2012 23:01 UTC (Wed) by sebas (subscriber, #51660) [Link]
Yet, we'd be muchos unhappy if work on e.g Firefox or Chrome on Linux would be stalled, while the numbers are probably fairly comparable, relative to Windows...
The monoculture of meritocracy Posted Nov 16, 2012 2:20 UTC (Fri) by sciurus (subscriber, #58832) [Link]
I think the number of Chrome users on desktop Linux is very low, but the umber on Linux is very high due to Android. If Google's ChomeOS is successful, the desktop numbers will rise.
The monoculture of meritocracy Posted Nov 14, 2012 9:22 UTC (Wed) by smcv (subscriber, #53363) [Link]
"""For KDE we try to at least give the token nod to portability, by using facade patterns to try to map high-level concepts to appropriate low level libraries"""
Most projects do, to a lesser or greater extent. GLib wraps a lot of pointlessly different kernel/libc APIs, and the combination of GIO and its plugins wraps libproxy, GNUTLS etc. as well.
One of the problems with that pattern is that there's an art to designing the abstraction so that it has the features you want, and yet can still be implemented on all the OSs you care about. If GLib is anything to go by, it seems that to design such a thing well, you need an in-depth understanding of at least POSIX and Windows, and often Linux-specifics too.
Another is that having the abstraction is no help if you don't have all the implementations. GIO has GFileMonitor, an abstraction for filesystem monitoring (inotify/fam/polling), which should be implementable in terms of *BSD kqueue, but the closest it has got is an unmerged patch: until then, the BSDs get the fam or polling backend. The majority of GIO contributors are on Linux and have no motivation to implement alternative backends that they're never going to run.
GIO kqueue is an interesting case because it seems to be less useful (at least for GLib's use) than inotify: monitoring a filesystem with kqueue prevents it from being unmounted. The proposed patch to implement GFileMonitor adds a configuration file for sysadmins to configure which directories should avoid kqueue and fall back to polling, defaulting to /mnt, /media etc.; the GIO maintainers reviewing the patch, quite understandably, consider this to be a deficiency of the underlying OS, and would rather it be fixed in the kernel.
The monoculture of meritocracy Posted Nov 14, 2012 13:37 UTC (Wed) by walters (subscriber, #7396) [Link]
The GTK+-and-below stack need to be portable to Windows, so various Unix variants are mostly a rounding error.
I think what's under discussion here has always been what functionality GNOME as a larger system (interface, sysadmin tools, etc.) has.
The monoculture of meritocracy Posted Nov 14, 2012 13:56 UTC (Wed) by gwolf (subscriber, #14632) [Link]
From the discussions I have participated of (being a Debian Developer, who turned to Debian after being an OpenBSD guy for some years), it's not only that the different projects offer *BSDs the needed hooks for them to fill in, but it's a deeper philosophical issue: Among the points mentioned by Marc Espie were PAM (correctly characterized as 1990s work by the author) and systemd. It's not that they cannot port them — It's rather that their main developer community feels their usual way does not require it. If we in Debian had giant mail threads regarding how we will manage our init, I can perfectly expect the threads to be even more virulent in *BSD land, where they are not only integrators as we are, but authors of the base infrastructure — "You mean for us to throw out all that well-written code we have improved over the years and replace it with n00b stuff‽"
Who would have thought‽ Posted Nov 14, 2012 20:47 UTC (Wed) by man_ls (subscriber, #15091) [Link] Nifty, didn't know that the interrobang existed. And in Unicode too!
Who would have thought‽ Posted Nov 15, 2012 11:01 UTC (Thu) by jwakely (subscriber, #60262) [Link]
I was impressed too, it's the first interrobang I've ever seen in the wild :)
The monoculture of meritocracy Posted Nov 15, 2012 2:21 UTC (Thu) by pynm0001 (guest, #18379) [Link]
> "You mean for us to throw out all that well-written code we have improved over the years and replace it with n00b stuff‽"
But at the same time, what if they're right, and that their own stuff works better with the rest of their integrated software? The point on PAM is well-taken (although my Linux system uses it as well) but being old design doesn't inherently mean it's broken.
You mention being a Debian Developer, I can only assume that Debian would not take it well if e.g. Ubuntu were to switch to using RPM and try to coerce Debian to make the switch as well "because that's how everyone is doing it". And there would be dozens upon dozens of *good reasons* why Debian would not want to switch (backward compatibility, mounds of existing software written against apt, much of which would have to be ported, all of the various *.debian.org services which would need to at least be reviewed, if not modified, etc.)
Even *just in Linux* it has been prudent for us in KDE to avoid tying directly to low-level libraries. Konqueror can now use WebKit in addition to KHTML, Phonon let us transition nicely to PulseAudio for those who use it even though gstreamer-0.10 was current when KDE 4 was released, Solid has helped us survive the HAL/udev/u{disks,power} insanity, we have an authorization framework which has survived PolicyKit and both of its successors, etc.
It is easy to require very low-level dependencies when all you really have to worry about is making sure that Fedora and RHEL still end up working in time for the release. This isn't to say that we at KDE don't want to have very good support for such libraries when present, just that our policy on such libraries so far has actually worked very well for us.
The monoculture of meritocracy Posted Nov 13, 2012 23:53 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]
Haven't used BSD's too much, especially not lately, but I'd imagine...
Different focus (e.g. security & stability is paramount in OpenBSD), different packaging systems, and different licenses.
Although if security and stability are paramount, I'm not sure why OpenBSD is so worried about pulseaudio, etc. That's stuff you want stripped out if you're building a server anyways..
The monoculture of meritocracy Posted Nov 14, 2012 0:58 UTC (Wed) by intgr (subscriber, #39733) [Link]
> Although if security and stability are paramount, I'm not sure why OpenBSD is so worried about pulseaudio, etc. That's stuff you want stripped out if you're building a server anyways..
Erm? Some people may want a higher security workstation. And people who develop the OS will certainly want to use it on the desktop too.
The monoculture of meritocracy Posted Nov 14, 2012 0:58 UTC (Wed) by geofft (subscriber, #59789) [Link]
I don't know much about "stability" and how to quantify that. I thought about the focus on security, in particular because e.g. Capsicum landed in FreeBSD and not yet in Linux, but there's a ton of security research and security hardening happening in Linux, so as an academic researcher I still prefer to work on Linux, and as an academic researcher with hopes of his work being used by real people, working on Linux is even more compelling. By the sheer size of its community and the number of people caring about it, Linux attracts a number of interesting security efforts -- SELinux came before SEBSD, ASLR hit PaX first and was then ported to OpenBSD, yama is happening on Linux, etc. So OpenBSD doesn't seem to have a huge advantage here, in terms of attracting contributors.
I would, admittedly, like to know why Capsicum was done on FreeBSD, since it seems a textbook example of cool things being done somewhere other than the monoculture kernel.
Regarding PulseAudio, I am a little sad that a hardened and stripped-down PulseAudio for servers is not obvious. I'd like to run the network server on a machine in my apartment hooked up to the living room speakers, but it brings in a ton of dependencies I'd rather not put on a server.
The monoculture of meritocracy Posted Nov 14, 2012 4:21 UTC (Wed) by wahern (subscriber, #37304) [Link]
The security approaches that we know work--code and design simplification, rigorously applying basic security practices like privilege separation, etc--are the areas that Linux fares worst compared to the BSDs. If security could be assessed by name dropping (papers, projects, w'ever), then Windows and other commercial systems would be granite mountains.
The OpenBSD folks don't want to chase features. What they want is to chase minimalism while staying relevant and useful. That's obviously a difficult path. It's made harder because many in the Linux community openly challenge even the pretense of portability, and like evil companies of yore have begun co-opting the standardization process, i.e. POSIX, and adding whatever crap features already in their toolbox regardless of merit.
Also, the idea that the "the BSD folks screwed us in the 1990s with a lack of concern for portability, so it's okay if we screw them now" is a little silly. Regardless of the veracity, it's just plain evil. Linux is not sacred. Not all Linux features are perfect, or worthy of adoption. Innovations which are strong enough to be accepted by other operating systems are likely innovations with far more merit. When you write something which only _you_ think is awesome... that should give you pause.
Monoculture sucks because you lose positive feedback. The bad features soon begin multiplying just as much as the good features, and eventually you end up with a cancerous wreck.
The monoculture of meritocracy Posted Nov 15, 2012 15:16 UTC (Thu) by lacos (subscriber, #70616) [Link]
Thank you, William, great comment.
> chase minimalism while staying relevant and useful
This matches my ideals perfectly. Unfortunately, I can't run *BSD as a home user, because (as much as I ignore "modern desktops") I need my consumer electronics crap to work with my computer. For that I need user base behind my desktop OS. I must go with the gnome3-crazed crowd because they cause new drivers to be written too.
(The logical extrapolation would be to run Windows at home, of course, but I simply can't tolerate it.)
I'm already buying only years old (aka "antique") "consumer technology", both for low price and for better support, but Debian Stable *still* screws me regularly.
The monoculture of meritocracy Posted Nov 15, 2012 18:22 UTC (Thu) by wazoox (subscriber, #69624) [Link]
> Debian Stable *still* screws me regularly.
Slackware, man. Slackware is the way. Antique, battle proven technology (no stinky systemd! no friggin' pam! good ol' *BSD style rc files!) and modern enough stuff. And sbopkg. Even this stupid new phone with mtp storage mode works, thanks dog (new phones don't come with usb-storage anymore, noooo, would be too easy and practical).
The monoculture of meritocracy Posted Nov 14, 2012 0:56 UTC (Wed) by josh (subscriber, #17465) [Link]
The serious answer: in theory, one system may be better on one axis and worse on another. However, in practice it proves easier to take the overall better (or more popular) system and add the features you want to that system, so that you get the best of both worlds.
The less serious answer: some of the people who run less popular environments do so for the same reason people program in esoteric languages: for fun and challenge.
The monoculture of meritocracy Posted Nov 14, 2012 1:02 UTC (Wed) by geofft (subscriber, #59789) [Link]
Yeah, the serious answer is what I'm worried about. See my other, more detailed reply, but with things like SELinux and PaX on Linux weakening the "OpenBSD is where security happens" story, I don't know how to avoid a monoculture that is compellingly better on one axis (community, hardware support, etc.) from eventually outpacing its competitors on every other axis.
Or phrased as an engineering problem: if we believe monocultures are bad, without breaking the constraint that meritocracy is good, how do we structure our projects and communities so that people work on e.g. the BSDs instead of making Linux better than the BSDs on all axes?
The monoculture of meritocracy Posted Nov 14, 2012 1:11 UTC (Wed) by josh (subscriber, #17465) [Link]
I'd rather restate that problem: why do we consider monocultures bad, and based on that, why do we consider Linux a monoculture?
I've heard plenty of arguments against a Windows or OS X monoculture. Most of them amount to lack of alternatives when something doesn't work as desired, and lack of diversity for security purposes. The former simply doesn't apply to Linux: you have an almost excessive number of alternatives even for core OS components, and if you don't like them you can always make more (up to and including forking the kernel). For the latter, I'd personally rather focus on keeping one OS secure rather than two. Any other good reasons?
Let's not repurpose canned arguments summed up by words like "monoculture" without reevaluating those canned arguments against their new targets.
The monoculture of meritocracy Posted Nov 14, 2012 1:18 UTC (Wed) by geofft (subscriber, #59789) [Link] So the article says "Monocultures are unhealthy in general; a Linux monoculture may be the ultimate vindication of our approach to development, but it still would not be a good thing for the world as a whole. As in natural ecosystems, diversity is a source of strength."I'm happy to disagree with that, and say that either Linux isn't a monoculture or that Linux is a good monoculture, and that all the BSD developers should give up and switch. :-) But it's what the article says, so I'm assuming it's representative of our community. Maybe it's not! That said, to give one possible argument, we might find a class of attacks against a certain way of thinking about things in Linux that wouldn't happen against another OS. This sort of thing is certainly common in low-level crypto design (e.g., side-channel attacks from algorithms that aren't carefully designed to do the same operations regardless of the input), and is one of the many motivations for the AES and SHA competitions involving getting lots of different people to propose different ideas and attack each other's ideas, instead of collaborating on a single algorithm. On the software side, I've heard of cases where, e.g., several separate security bugs were found regarding NT's kernel entry ABI, and you couldn't fix those bugs at once without completely redesigning that ABI and possibly API.
The monoculture of meritocracy Posted Nov 15, 2012 14:12 UTC (Thu) by khim (subscriber, #9252) [Link] This sort of thing is certainly common in low-level crypto design (e.g., side-channel attacks from algorithms that aren't carefully designed to do the same operations regardless of the input), and is one of the many motivations for the AES and SHA competitions involving getting lots of different people to propose different ideas and attack each other's ideas, instead of collaborating on a single algorithm. This is good example. Let me rephrase the question: why do you think Linux is a problem while AES and SHA are Ok? IOW: why even have a contest where one winner is picked and then reused everywhere if monoculture is so bad? AFAICS Linux fulfills the same role as AES or SHA: different implementations are offered and one it picked, then used everywhere. If it was a bad decision then later it can be changed (see: DES to AES and MD5 to SHAxxx transitions). We don't support the ability to use some exotic and clever ciphers in our documents and web-servers (only when some cipher wins the contest it's used for "real" programs), why should we support the ability to run "real" programs on experimental OSes like OpenBSD or Haiku? On the software side, I've heard of cases where, e.g., several separate security bugs were found regarding NT's kernel entry ABI, and you couldn't fix those bugs at once without completely redesigning that ABI and possibly API. If that happens then you need to redesign said ABI, it makes no sense to cultivate series of OSes each with it's own problems: sooner or later they all will be compromised if you'll not tighten them up.
The monoculture of meritocracy Posted Dec 1, 2012 19:29 UTC (Sat) by ThinkRob (subscriber, #64513) [Link]
>This is good example. Let me rephrase the question: why do you think Linux is a problem while AES and SHA are Ok? IOW: why even have a contest where one winner is picked and then reused everywhere if monoculture is so bad?
I think there's a simple answer to that, actually: the impact of bugs.
If a kernel that's been out in the wild for some time has a bug due to a lack of attention, then users might hit crashes or lose data. That's bad, but it's fixable. Users may be able to work around it, and a lot of crash bugs are not *that* hard to fix once they're identified (finding/reproducing them is the hard part.)
If a cipher has been out in a while, and is found to have a bug that, say, reduces the key strength from 128 bits to 50 bits, that's also bad. But unlike a kernel bug which can be fixed or worked around, the impact of the bug is retroactive. All of the data encrypted with that broken cipher is now vulnerable. Worse still, there's no way to recall it. Some bad guy intercepted your traffic protected with $BUSTED_CIPHER? Well if he kept a copy around once the bug is found he can go back and decrypt it.
Unlike a kernel bug, a crypto bug can be devastating for *years* after it's been found and fixed, and there's not always a way to mitigate the damage. So while we want solid, bug-free kernels, there is a much, much higher value placed on getting our encryption/hashing algorithms right the first time.
*That* is why I'm OK with people unifying behind one or two ciphers and one or two hashing algos. Yes, it does have the "eggs in one basket" issue, but the cost of getting it wrong can be so very high that we really want to ensure that we have as many eyeballs on it as possible.
The monoculture of meritocracy Posted Dec 10, 2012 12:51 UTC (Mon) by ekj (guest, #1524) [Link]
If you're paranoid about it, you nest ciphers (with unrelated keys!)
You use AES( k2, BLOWFISH( k1, plaintext)) which is secure aslong as *either* blowfish *or* AES survives.
You can do the same thing with hashes, but you need to concatenate or interleave them rather than nest them - the result is a hash that is as large as the sum of the two -- and that remains secure aslong as atleast once of the hashes is secure. (and *possibly* secure even if both hashes are broken)
Even someone who -can- find sha1 and md5 collisions *might* have a harder time finding two distinct documents that collide in both md5 and sha1. (yes I'm aware that md5 has been broken)
The monoculture of meritocracy Posted Nov 14, 2012 11:12 UTC (Wed) by el_presidente (subscriber, #87621) [Link]
> The former simply doesn't apply to Linux: you have an almost excessive number of alternatives even for core OS components
Nobody needs a separate /usr partition, udev without systemd is a dead end, pulseaudio is the future, sloppy focus is for people caught up in the 90s, those who complain about client side decorations don't know what they are talking about, most users don't write their own init scripts, fallback mode is a maintenance burden, the unix philosophy doesn't apply to the modern desktop.
It's pointless to have alternatives.
The monoculture of meritocracy Posted Nov 14, 2012 15:30 UTC (Wed) by ortalo (subscriber, #4654) [Link]
Admittedly, that's an alternative path to world domination, and it does not necessitate any alliance at all (these political discussions are so boring for el_presidente).
But it has already been done as nobody needs something else than M$/Windows.
The monoculture of meritocracy Posted Nov 14, 2012 21:35 UTC (Wed) by ThinkRob (subscriber, #64513) [Link]
That's either an excellent troll or -- if coming from a developer -- a deeply depressing expression of a rather dangerous mindset.
The monoculture of meritocracy Posted Nov 15, 2012 15:29 UTC (Thu) by lacos (subscriber, #70616) [Link]
> That's either an excellent troll or -- if coming from a developer -- a deeply depressing expression of a rather dangerous mindset.
Hm, neither. el_presidente didn't quote everything he responded to.
josh said:
> lack of alternatives when something doesn't work as desired [...] simply doesn't apply to Linux: you have an almost excessive number of alternatives even for core OS components
to which el_presidente replied,
> Nobody needs a separate /usr partition, udev without systemd is a dead end, pulseaudio is the future, sloppy focus is for people caught up in the 90s, those who complain about client side decorations don't know what they are talking about, most users don't write their own init scripts, fallback mode is a maintenance burden, the unix philosophy doesn't apply to the modern desktop.
It is sarcasm, but not a troll. It argues that alternatives are important, and that their number isn't actually "excessive" in Linux.
That's my take, anyway.
The monoculture of meritocracy Posted Dec 16, 2012 5:14 UTC (Sun) by hasard (guest, #47410) [Link] But why should I, as a potential volunteer who's only motivated by impact and personal interest, work for the underdog?It's funny that you say that, considering that according to 99% of computer users, you are already working for the underdog.
|
|||||||||||||