| |||||||||||||
Poettering: The Biggest MythsPoettering: The Biggest MythsPosted Jan 28, 2013 5:05 UTC (Mon) by mgb (guest, #3226)Parent article: Poettering: The Biggest Myths The problem is not change per se. Us "old fogeys" have successfully administered and programmed numerous radically different operating systems. We love to learn new techniques. But good change is good and bad change is bad. And purporting to refute a stack of straw myths doesn't make a bad change any better. The problem with systemd is that it is politically monolithic and controlling and therefore harmful to FLOSS progress. Stick it in a DSL router and sell a billion units - no problem. Stick it in the main branch and throttle Linux progress - big problem.
(Log in to post comments)
Poettering: The Biggest Myths Posted Jan 28, 2013 5:32 UTC (Mon) by raven667 (subscriber, #5198) [Link]
What harm?
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) [Link] ... politically monolithic and controlling and therefore harmful ...
Poettering: The Biggest Myths Posted Jan 28, 2013 5:45 UTC (Mon) by raven667 (subscriber, #5198) [Link]
But there is no "therefore", the fact that systemd is in a single source tree which is maintained by an open community of developers from several different companies or individuals dosen't imply or logically lead to any "therefore harmful" that I can understand.
Again, what harm are you talking about. I really, really don't understand your point.
Poettering: The Biggest Myths Posted Jan 28, 2013 10:07 UTC (Mon) by mgb (guest, #3226) [Link] I am so glad to hear that systemd is no longer monolithic. But I'll believe it when they split their monolith into separate uncoupled GitHub projects so that FLOSS can easily use the best and replace the worst. This will be easy as systemd is no longer monolithic: systemd has one small UNIXy library for parsing unit files, a small UNIXy binary whose sole function is to control a cgroup, a small Unixy udev, small UNIXy tools for serial and for parallel startup, a small UNIXy inetd, and a small UNIXy init. And they are all as elegantly factored, modularized, and uncoupled as any good software engineer would insist. Not. Sadly that's not how Poettering works. He uses political control of critical elements to push his unUNIXy monolithic ideas. systemd is not UNIX. It is the opposite of UNIX. Now systemd in Fedora and Redhat is not a problem - other distros will continue to progress. But if systemd were simultaneously blocking the progress of key distros such as Debian, Fedora, and Ubuntu that would seriously harm FLOSS.
Poettering: The Biggest Myths Posted Jan 28, 2013 11:07 UTC (Mon) by pizza (subscriber, #46) [Link]
>Now systemd in Fedora and Redhat is not a problem - other distros will continue to progress. But if systemd were simultaneously blocking the progress of key distros such as Debian, Fedora, and Ubuntu that would seriously harm FLOSS.
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.
Poettering: The Biggest Myths Posted Jan 28, 2013 12:03 UTC (Mon) by heijo (guest, #88363) [Link]
The Linux kernel is also an "unUNIXy monolithic idea", "not UNIX" and "the opposite of UNIX" according to these criteria.
Poettering: The Biggest Myths Posted Jan 28, 2013 12:28 UTC (Mon) by mgb (guest, #3226) [Link]
> The Linux kernel is also an "unUNIXy monolithic idea", "not UNIX" and "the opposite of UNIX" according to these criteria.
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.
Poettering: The Biggest Myths Posted Jan 28, 2013 13:01 UTC (Mon) by smurf (subscriber, #17840) [Link]
> Carefully factored software - the UNIX way - is far more conducive to progress.
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?
Poettering: The Biggest Myths Posted Jan 28, 2013 13:06 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]
> Maybe merging the dbus and systemd repositories was a mistake, maybe not.
Presumably, you mean udev and systemd. D-Bus is still quite independent [1].
Poettering: The Biggest Myths Posted Jan 28, 2013 16:58 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> Poettering keeps borging key FLOSS components because it gives him more power, not because his monolith is [technically] better.
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) [Link]
at least according to an article on phronix, they are looking at having systemd do the job that cron has been doing for decades next
systemd to absorb cron next Posted Jan 28, 2013 21:36 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Well I take anything said on phoronix with a grain or two of salt but I don't see any reason that cron/at and functionality can't be part of systemd as long as it can parse the existing format files. systemd already has all the infrastructure for starting processes in a defined environment on-demand, the only difference is being time activated instead of socket activated. It seems like it would result in a net reduction of complexity of the OS while increasing capability which I think is a very good thing indeed.
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).
systemd to absorb cron next Posted Jan 28, 2013 21:38 UTC (Mon) by BlueLightning (subscriber, #38978) [Link]
Honestly I'm surprised they haven't already done this. If there's value in tracking processes and putting them into cgroups for daemons, surely the same thing applies to things started as scheduled tasks.
systemd to absorb cron next Posted Jan 29, 2013 8:59 UTC (Tue) by ovitters (subscriber, #27950) [Link]
That would allow any package to provide the systemd service file as well as any time/timer file (=cron) which it needs as well. Makes packaging much easier, avoids that a distribution might forget about cron as well as making things more consistent across distributions. IMO the goal should be to do as little changes during packaging as possible (meaning: bugs should be fixed upstream).
systemd to absorb cron next Posted Jan 29, 2013 15:14 UTC (Tue) by mmeehan (subscriber, #72524) [Link]
As it should. Cron doesn't meausure up well in 2013. No way to detect job failures, establish job dependencies, or allocate processes to cgroups. In any important environment it's already been replaced with full-scale enterprise batch managment suites because basic cron is a liability.
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.
Poettering: The Biggest Myths Posted Jan 29, 2013 0:42 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] 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.
Poettering: The Biggest Myths Posted Jan 28, 2013 16:14 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
systemd never was monolithic. Hence we couldn't turn it into something that "is no longer monolithic".
See, there, you are creating a new myth. Do I now have to update the article with a 31st entry?
Poettering: The Biggest Myths Posted Jan 28, 2013 17:18 UTC (Mon) by mgb (guest, #3226) [Link]
> Do I now have to update the article with a 31st entry?
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.
Poettering: The Biggest Myths Posted Jan 28, 2013 17:48 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Dude, if you think it's so easy to provide the set of features that systemd does in a significantly less-coupled and modular way, go ahead and do it. But if you can't, then stop telling other people how to do their job. Because unlike you, they are actually doing something *useful* instead of bitching about other people's work.
Poettering: The Biggest Myths Posted Jan 28, 2013 18:16 UTC (Mon) by mgb (guest, #3226) [Link] We don't need to create a well-engineered decoupled solution because most distros still have it. Udev modularity has gone from many distros but there is no engineering reason for that, just the usual Poettering Power Play. Read up on cgroups if you want to see how easy it is to not include the cgroups functionality in init.
Poettering: The Biggest Myths Posted Jan 28, 2013 21:22 UTC (Mon) by niner (subscriber, #26151) [Link]
I just can't tell you how glad I am that this "well-engineered decoupled" piece of crap that's SysV init is no longer in my distribution of choice. Because _finally_ we got rid of the serious flaws.
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.
Poettering: The Biggest Myths Posted Jan 29, 2013 21:42 UTC (Tue) by aleXXX (subscriber, #2742) [Link]
Please stop calling people "Dude".
Alex
Poettering: The Biggest Myths Posted Jan 29, 2013 8:54 UTC (Tue) by ovitters (subscriber, #27950) [Link]
I assume you never used sysvinit on a distribution where /bin/sh does not point to bash? Obviously if you use /bin/sh you should not use any bash features. However, real life is different. I prefer systemd over anything that you call well engineered :P
|
|||||||||||||