Re: A few observations about systemd
[ 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
Reply to: