[sophacles]

Total n00b here. My first linux install was pretty recently, in late 1996 or early 1997 (sometime that winter).

I just don't get it. Like is the core sentiment "How dare they address obvious system shortcomings"? Is it "I learned once and how dare you think I'm capable of learning again"? Is it "I want others to suffer the way I did to learn job scheduling"?

cron did a job, but had shortcomings. Systemd addresses many of those shortcomings. One day something else will come along and address the shortcomings of systemd, and no one will care about systemd nostolgia. This is how technology is supposed to work: making progress and fixing the shortcomings of the past generation. It's not a religion, we don't have to maintain the weird old ways from the 80's, your soul won't be saved by cron or corrupted by systemd.

[gh02t]

Yeah, I certainly have my complaints about systemd but the parent's point is undermined by the fact that cron still works. If you prefer it, carry on I doubt seriously it's going anywhere. I still do sometimes.

[thomashabets2]

I am not agreeing with egorfine. Indeed, why not improve what we can improve?

> cron did a job, but had shortcomings. Systemd addresses many of those shortcomings

Right, but what are those "many" shortcomings? The article lists four, and fully half of them seem to be nonsense, per my comment. (time spec syntax appears to be equally complex in systemd timers, and I have no idea what they mean about PATH, as it seems equal too)

The remaining two are fairly good points, kind of. Sending mail is a black hole until you look there, sure. Believing that emails get meaningfully delivered on a non-email server is very anachronistic. But isn't logging a black hole until you look there too?

So from the article that leaves "Execution history is difficult to follow and interrogate", which I super agree with. I would argue it's not inherent to cron, and one could have written a small tool that allows following and interrogating.

And… surely that goes for logging too? cron does log to syslog, right?

Maybe there's some integration with other stuff that is better, that I'm not aware of?

I'm not disputing that it's better. I'm sure it is. But where's that list? If it's literally only the `list-timers` command, then that's very underwhelming. Is it the randomness to scheduling? I've never needed it (I just spread them out over an hour by fixed start time), but sure that would have value in other cases where coordination is not possible. You could add it to cron, but not in a nice way.

To me it seems like engineers do what engineers like to do: enjoy greenfield implementations. It's open source. Nobody's going to ding your quarterly performance evaluation for going off on a amusement coding session without a requirements doc. I know that I have written a lot of tooling for amusement and to work the way I want it to work. I certainly understand the engineering mind that would rather write something from scratch than understand the previous system.

I don't mind learning new things, but this article seems to fawn over stuff you can do in systemd timers, where… yeah that was always an option (in cron). I don't have faith that the article writer actually knew cron before they trash it in favor of something else.

On a tangent, I do agree with egorfine that Lennartware inherently has a disdain for users and their workloads (e.g. kills user processes inside a screen/tmux arbitrarily), and that audio on linux was set back 5-10 years just from the mere disastrously bad quality of the pulseaudio implementation. It makes sense that he works for Microsoft.

[sophacles]

Well theres a few more:

* coalescing jobs with control over the granularity of it. That means you can say "i want this job run on at 14:30:02 exactly" and I want these jobs run at 19:21 or so, 19:22 or so: and 19:23 and set your resoultion to 10m and they'll all run at once. Great on laptops and other scenarios where you want to reduce power draw.

* System wakeup - you can wake a system from sleep various sleep modes (details depend on hw support) and run a job.

* cohesion with the rest of the system. this is a big deal when you stop playing with just your desktop and pet server and have to deal with 10^4 or more servers. having to deal with the wierd quirks of cron vs inittab vs whatever is frustrating and when there are many people working on it, someone is always going to do something quirky and fragile. Yes you have to know the systemd things, but that's it - a timer starts a unit, any unit, without all the bullshit (e.g, oh im stating with cron, these magic invocations are neeeded, oh im starting it with runit and these different invocations are needed, etc)

I literally never experienced any of the problems people complain about for pulseaudio - at the time it was released it was the smoothest audio experience i ever had on linux. I think some people just want to look cool and complain about the new thing.... But also I read manuals and think for 3 or 4 seconds before doing things, so maybe it has something to do with that.

[thomashabets2]

I agree that's a good list. You did a better job than the article.

As for pulse audio: no, it has absolutely nothing to do with that. That's just being condescending and smug. I've never had a lithium battery fire, so that must mean manufacturing defects never cause them?

[sophacles]

I get it. Some software had a couple bugs at first, as does all new software. And now some whiny people who have never, don't currently, and will never provide value to the open source ecosystem have spent more years whining and complaining about the bugs than the entire piece of software was in widespread use.

[thomashabets2]

Ok, now that you're just commenting cope and ad hominem I think we're done here.

[egorfine]

> How dare they address obvious system shortcomings

I'm all for it.

However the trust in systemd brand and its leader is deeply negative, so anything that comes from systemd folks is an immediate no.

[sophacles]

Wierd. I like systemd. It's given me more stability and control over my systems than anything before provided. I like pulseaudio - it made the linux audio experience better than anything that came before it.

I don't live in terror of new things though, so I don't really understand the propaganda.

[egorfine]

> pulseaudio - it made the linux audio experience better

This is a take that is so drastically different to what I (and many other people) have experienced that it now makes sense that systemd is to your liking.

[sophacles]

Yeah, it's sad that a few dozen very vocal people got upset that they would have to read the manual and maybe get rid of some of the hacky nonsense they cobbled together to get an equivalent experience to what default pulse provided. Those people have spent decades whining about imagined issues and preventing reasonable discourse about actually good software.