User: Password:
|
|
Subscribe / Log in / New account

Poettering: The Biggest Myths

Poettering: The Biggest Myths

Posted Jan 28, 2013 12:28 UTC (Mon) by mgb (guest, #3226)
In reply to: Poettering: The Biggest Myths by heijo
Parent article: Poettering: The Biggest Myths

> 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.


(Log in to post comments)

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].

[1] http://cgit.freedesktop.org/dbus/dbus/

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 (subscriber, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds