Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Distribution quote of the week
Posted Sep 1, 2012 21:26 UTC (Sat) by dirtyepic (subscriber, #30178)
Posted Sep 2, 2012 3:38 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
Posted Sep 2, 2012 18:14 UTC (Sun) by dirtyepic (subscriber, #30178)
Posted Sep 3, 2012 15:29 UTC (Mon) by bronson (subscriber, #4806)
Posted Sep 3, 2012 19:33 UTC (Mon) by dirtyepic (subscriber, #30178)
It's funny you're concerned about unnecessary fragmentation, because that's exactly what systemd is all about! Consider this: We all worked together for years to develop a fully-featured system stack. It wasn't perfect, but it mostly worked. Then along came systemd with a new take on init systems (and one I like BTW). Fair enough. But then systemd started to grow like some kind of open source katamari ball, picking up system components left and right as it rolled through town. Suddenly the projects that we had been relying on, the software we helped write, were shells of their former selves. Key developers were missing. Contributors had disappeared. The community had been split. So don't tell me that systemd is about reducing fragmentation when one of its key design goals seems to be to screw over everyone not using systemd.
Yes, we can fork all the projects that systemd destroyed, but it's going to be a hell of a lot of work. Do you understand why we might be a little peeved about it? I know, sucks to be us, but try and think about the situation we're in before making your comments.
Posted Sep 3, 2012 20:40 UTC (Mon) by khim (subscriber, #9252)
This is just stupid at this point. Let me translate from English to English.
So don't tell me that systemd is about reducing fragmentation
Don't say systemd authors are trying to reduce fragmentation…
when one of its key design goals seems to be to screw over everyone not using systemd.
…when they are clearly trying to reduce fragmentation.
This is kind of… inconsistent.
The only way to reduce fragmentation is to remove number of possible distinct configrations. One effective way to do that (in fact the only effective way to do that as history shows) is to pick winners and kill losers. All attempts to "reach harmony" by designing a system which reflects "suggestions from all users" don't really work: they usually produce horrible Frankensteins which are even worse then what was before in the "anarchy" period. If they provide anything at all.
Now, if you feel that these particular choices are bad then you can rally and organize support for some other choices. And since…
Key developers were missing. Contributors had disappeared.
You'll be forced to drop support for many-many configurations, too. This means in the end you'll have two or three surviving confugurations—which is exactly how "reduced fragmentation" looks like.
You may protest against "reduced fragmentation" as a goal—that's fair, but to say that systemd authors are somehow not driven by this goal is absurd: they do what people must do to reduce fragmentation. There are no other way: you can not "reduced fragmentation" and "offer bunch of choices". These are direct opposites.
"The ability to build udev without systemd" assumes there are some other init (for how else your system will even boot?) which gives you two configurations right there. If you want to build systemd without dbus then this increases number of configurations to three or may be four. Add choice of dozen of "plumbing" packages—and you are back to the mess we had before introduction of systemd.
Windows developers are pretty outraged by the fact that Microsoft splintered the Windows by offering six main different versions (and few specialized ones)—but differences between all these versions are trivial in comparison to differences between system with systemd and systed without systemd or system with dbus and system without dbus.
Posted Sep 3, 2012 10:00 UTC (Mon) by mpr22 (subscriber, #60784)
The wonderful thing about Free Software is that only the scarcity involved is the natural scarcity of suitable interested labour; there is no "rights holder" directly creating an artificial scarcity in order to exact a rent. As such, if a software project is left to rot on the vine, that means that the supply of suitable interested labour for their maintenance and development is insufficient (in quantity, quality, or both). The remedy is simple:
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds