| |||||||||||||
The monoculture of meritocracyThe monoculture of meritocracyPosted Nov 14, 2012 3:02 UTC (Wed) by aryonoco (subscriber, #55563)In reply to: The monoculture of meritocracy by pynm0001 Parent article: Crowding out OpenBSD
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.
(Log in to post comments)
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.
|
|||||||||||||