| |||||||||||||
Poettering: The Biggest MythsPoettering: The Biggest MythsPosted Jan 28, 2013 16:58 UTC (Mon) by raven667 (subscriber, #5198)In reply to: Poettering: The Biggest Myths by mgb Parent article: Poettering: The Biggest Myths
> 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.
(Log in to post comments)
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.
|
|||||||||||||