Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
You keep using that word but I can't for the life of me see how reliably launching your systems processes is harmful. What harm do you see to FLOSS progress by running daemons in a consistent environment and providing tools for managing them?
Poettering: The Biggest Myths
Posted Jan 28, 2013 5:40 UTC (Mon) by mgb (guest, #3226)
Posted Jan 28, 2013 5:45 UTC (Mon) by raven667 (subscriber, #5198)
Again, what harm are you talking about. I really, really don't understand your point.
Posted Jan 28, 2013 10:07 UTC (Mon) by mgb (guest, #3226)
Posted Jan 28, 2013 11:07 UTC (Mon) by pizza (subscriber, #46)
You seem to have a very different definition of "progress" than everyone else. The way you're writing here, "progress" means "keeping things unchanged"
Taken that way, your argument at least makes sense, but while you're entitled to your opinions, you aren't entitled to your own facts/definitions.
Posted Jan 28, 2013 12:03 UTC (Mon) by heijo (guest, #88363)
Posted Jan 28, 2013 12:28 UTC (Mon) by mgb (guest, #3226)
Which is why the idea of a micro-kernel never completely dies. A micro-kernel would allow faster progress but in the case of the Linux kernel the performance disadvantages are too severe.
While no-one has yet devised an efficient micro-kernel replacement for Linux, implementing UNIXy cgroup monitoring and parallel boot are no more difficult than creating a monolithic unengineered monster to provide the same functionality.
Poettering keeps borging key FLOSS components because it gives him more power, not because his monolith is better. Carefully factored software - the UNIX way - is far more conducive to progress.
Posted Jan 28, 2013 13:01 UTC (Mon) by smurf (subscriber, #17840)
Unless the elements are so tightly coupled that to change one without the other would not make any sense.
Case in point: cgroup monitoring. init needs to do that by itself, in order to know when a daemon's processes have all died. Please demonstrate that compartmentalizing this feature to another process is an advantage in some way, because I can't think of one.
Maybe merging the dbus and systemd repositories was a mistake, maybe not. I don't know; absent any demonstrated technical reasons why it's a bad idea I continue to assume that there have been sound technical reasons to do it. "Avoid a monolith, designed by a power-hungry <whatever>" is not a technical reason.
But you can still build the dbus stuff without systemd, and you can check out the repository and basically ignore all the systemd stuff, so what's your problem?
Posted Jan 28, 2013 13:06 UTC (Mon) by davidstrauss (subscriber, #85867)
Presumably, you mean udev and systemd. D-Bus is still quite independent .
Posted Jan 28, 2013 16:58 UTC (Mon) by raven667 (subscriber, #5198)
That is pretty certainly not true based on the available evidence. You don't have to guess, you can watch his presentations, read his writings and make your decisions based on the technical arguments that he makes. Believing that he is living under a secret base in a volcano cackling at his "power" like a fictional Bond villan, twirling his mustache is your right I guess but just because that's what you believe doesn't mean it has any relation to reality. Making decisions based on opinions which are not real will not have the desired effects.
systemd to absorb cron next
Posted Jan 28, 2013 21:14 UTC (Mon) by dlang (✭ supporter ✭, #313)
Posted Jan 28, 2013 21:36 UTC (Mon) by raven667 (subscriber, #5198)
I don't see how that provides any relevance to "political power play" rhetoric as there are clearly defined technical reasons that have nothing to do with politics or "power" (whatever "power" means in the context of open source projects that are governed openly).
Posted Jan 28, 2013 21:38 UTC (Mon) by BlueLightning (subscriber, #38978)
Posted Jan 29, 2013 8:59 UTC (Tue) by ovitters (subscriber, #27950)
Posted Jan 29, 2013 15:14 UTC (Tue) by mmeehan (subscriber, #72524)
Think of every "batch" out there implmented in cron with overly long timings between jobs, or hacked together with cron, shells, and lockfiles. There's a need for a serious cron replacement, and for a per-user daemon managment system. It looks like systemd is going to fill those shoes, which means they'll have a consistent interface and tools.
Posted Jan 29, 2013 0:42 UTC (Tue) by rgmoore (✭ supporter ✭, #75)
Carefully factored software - the UNIX way - is far more conducive to progress.
An excellent point. Now you just have to show that the current set of software actually is carefully and correctly factored and you'll have proven your point. As it is, you seem to be assuming this point and proceeding directly from that assumption to accusations of bad behavior on the part of Lennart Poettering. In fact the only detailed discussion of factoring that I've seen has come from systemd developers trying to justify their decisions. I think the discussion would be a lot more productive if you could focus on refuting those technical arguments rather than attacking developers' motives.
Posted Jan 28, 2013 16:14 UTC (Mon) by mezcalero (subscriber, #45103)
See, there, you are creating a new myth. Do I now have to update the article with a 31st entry?
Posted Jan 28, 2013 17:18 UTC (Mon) by mgb (guest, #3226)
It would be far better if you spent your time factoring systemd into properly engineered and decoupled projects.
I'm sure you can figure out how to manage a cgroup from other than pid 1.
Posted Jan 28, 2013 17:48 UTC (Mon) by HelloWorld (guest, #56129)
Posted Jan 28, 2013 18:16 UTC (Mon) by mgb (guest, #3226)
Posted Jan 28, 2013 21:22 UTC (Mon) by niner (subscriber, #26151)
Thank you very much to all systemd developers (they are more than one you know).
As soon as we see any contribution by you at all, you may earn our gratitude as well.
Posted Jan 29, 2013 21:42 UTC (Tue) by aleXXX (subscriber, #2742)
Posted Jan 29, 2013 8:54 UTC (Tue) by ovitters (subscriber, #27950)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds