81–90 of 155 posts
You can pry my crontab out of my cold, dead hands. Seriously, though, cron has been so utterly reliable for me for so many decades now, it will be really hard for me to ever give it up.
https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…
Then again original cron is also kinda shit. It gets the "one file to define the job" right but that's the only thing that it gets right. There is no holistic view on the jobs so you can't easily say "show me last jobs that failed" and shove that into alert. There is email on failure but only on failure so you can't also do simple "if this mail returns fail, mark check as failed, if it returns okay, mark it as okay".…
With systemd timers, I have to look up how to write a unitfile every. single. time. and it's not a trivial 30-second lookup like every other command, it's a 5-10 minute read through every time. And even then there's weird variations on the timer unit files I don't quite understand, and most of the time it takes more than one try to get right. It fails in some bizarre ways on certain tasks due to internal systemd inconsistencies. (Like using different escape characters in different contexts, wtf?!) And I can't remember how it's set-up so I have to look it up again when I want to administer it or change something and on the whole it's just a huge PITA.
At this point, I've used systemd timers several times MORE than I have cron and I still have no idea how to write a systemd timer unit file without looking it up, and I'd have to start from scratch to write a new one.
About the only positive is that when it fails systemd reports it decently so I can follow up on it, but man, it's not worth it. I've spent a lot more time dicking with the unit files than I have debugging failed cron jobs.
Earlier quoted context omitted.
"tail /var/log/nginx.log" is now "journalctl -fu nginx" or "jouranlctl -eu nginx". Not that much of a difference, it really depends what you grow up with. We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log". A nice feature is that journald gives you flags like "--boot" to see logs only emitted during a specific boot, or "--since '5m ago'" which is…
No, having a special way to tail your special log file isn't a feature, tail is a general utility used system wide for this for decades; breaking this is idiotic no matter what you grew up with.
https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…
Counter argument: Try implementing support for Alpine, Debian and other distros whilst using a cronjob. It's impossible. All that opinionated /etc/crontab and /etc/cron.daily shit can go to hell for all I care. Every opinionated distro uses whatever kind of file format that the next best sh guru came up with, which id also prone for exploitation btw. With systemd there's a failsafe way for maintainers to offer a cros…
https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…
Quoted post unavailable.
I don't understand this idolisation of 70s mainframes that "hardcore" Linux users all seem to fight for. Systemd features can all be turned off if you want them to, but every day more and more alternatives go into maintenance mode because nobody uses them anymore. Inetdwas great when it was invented but we've moved past that point more than ten years ago.
When I'm tinkering, I love the great hacks I can apply by modifying system shell scripts, but I mostly just want my computers to work for me. The old ways of randomly placed dot files, custom service scripts (and formats) and modifying scripts that I shouldn't need to ever touch anyway because they conflict with another cobbled together script have caused me more headaches than systemd ever has. I wish system's docs were easier to find, but even the obscure man page names are better than comments in bash scripts somewhere in /etc/init.d.
Earlier quoted context omitted.
Nix/Guix users would think that way. They've alrady given up on the concept of system libraries or a unified OS. systemd's writing of 2 config files per timer would be right at home for people that have to set up an entire OS environment every time they want to try to compile something somone else hasn't already written a nix script for.
This would be needlessly insulting if it were posted as a top level comment, but as a direct reply to a Nix user it is impossible to read as anything other than the worst of condescension. Can you really say this is a net improvement to the tone of the conversation in this thread?
It's bad policy for desktops even if it's good for you in work environments and so you use it anyway. Normalizing that is bad. I said it like a jerk though. Sorry.
Earlier quoted context omitted.
Well, except for /etc/crontab, /etc/corn.daily|weekly|whatever, /var/spool/crontabs, etc.
/etc/cron.{hourly,daily,weekly,monthly} are just some convenience shortcuts. No one is forcing you to use them.
It’s not that much different than systemd in that sense.
Especially since the /etc/cron.whatever special rules like files with dots in them get ignored (ugh)
Earlier quoted context omitted.
This would be needlessly insulting if it were posted as a top level comment, but as a direct reply to a Nix user it is impossible to read as anything other than the worst of condescension. Can you really say this is a net improvement to the tone of the conversation in this thread?
I'm responding to a Nix user making this about how Nix does timing. I'm relating it to the common thread of cargo cult'ing shared between systemd and users of Nix as desktop operating systems. They both increase the amount of config files necessary to accomplish what should be almost config-less tasks and spread those config files out across many places instead of a single config store that is for the entire OS. It's…
Earlier quoted context omitted.
"tail /var/log/nginx.log" is now "journalctl -fu nginx" or "jouranlctl -eu nginx". Not that much of a difference, it really depends what you grow up with. We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log". A nice feature is that journald gives you flags like "--boot" to see logs only emitted during a specific boot, or "--since '5m ago'" which is…
I'd recommend running strace on that journalctl command, you might be surprised what happens. It's even worse if you actually store journalctl logs on disk (most distros defer to storing it in ram). I have it set to store on disk and keep at most 1GB of logs On my NAS # strace journalctl -u nginx 2>&1 |grep open |wc -l 827 and curiously # strace journalctl -u baked-potato 2>&1 |grep open |wc -l 827 (no i do not have…
> It's DB implementation is utter garbage. It doesn't even organize files by time or really anything useful.
That sounds interesting, can you please elaborate on the internal structure of journald files or link to further documentation? And why would I care if journald handles it for me?