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