[ Sending this late reply now, which I had around as a draft, but with the latest incarnation of this debate it's become relevant again. ]
Hi! On the "other kernels lack of features" I'll just point to the “Functionality Equivalence” section in the Porting Guidelines draft I've been preparing at <http://www.hadrons.org/~guillem/debian/ports/porting>. Most of the features listed as required for systemd are either already present on other systems or have been long before they even appeared on GNU/Linux. Some are not even GNU/Linux specific but GNU/* generic by way of (e)glibc. And some are clearly optional given that not even on GNU/Linux they are always active (for example SELinux). While upstreams are obviously entitled to not care at *all* about portability for their pet projects (at the risk of being either ignored or forked, I guess), trying to push so hard for the adoption of those projects as either foundation blocks or hard dependencies on other upstream projects seems quite arrogant and irrespectful to all the people interested in portability or to members and users of other operating systems or other implementations of the functionality such new projects are trying to displace. Something to remember is that GNU/Linux has not always been as dominant as today, and these things always change, given time. I guess one of the problems with this kind of upstream attitude is that it polarizes people's positions, in really non productive ways, due to trying to control the direction and actively undermining the support other people care about on the collective wealth of free software around them in detriment to other collectives. As part of the GNU/Hurd and GNU/kFreeBSD we have ported to and from those systems to GNU/Linux, take for example ufsutils (FreeBSD → GNU/*), util-linux (GNU/Linux → GNU/*), etc. Someone mentioned freebsd-utils, and while I think we'd be best served by having some of the commands there in a generic and portable package, I guess for now it's easier to take those from the FreeBSD tree, and patch them slightly. So there is and I think always there's been willingness to port, but with projects that are amenable to merge such changes, life's too short to deal with hostile upstreams. Obviously others can decide to maintain a permanent fork w/o forseeable chance of seeing it integrated back, if I'd be interested in doing the work I'd rather spend my time elsewhere, for example in porting launchd (now with a saner license, Apache 2.0), which given its Mach/FreeBSD roots it seems might be easier to add any missing functionality deemed necessary, than maintaining the aforementioned fork. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120224171311.ga18...@gaara.hadrons.org
