LP makes something faster and more featureful than syslog. says you can keep using syslog. and you are cross when he points out that syslog is slowing down your computer? thats the point.
if your distro decides thats fast and new is better than old and slow, and you disagree then maybe you are using the wrong distro for your needs.
Posted May 22, 2012 13:17 UTC (Tue) by nix (subscriber, #2304)
[Link]
I'm not using a distro at all, because I think that stability is paramount but *also* need to use some bleeding-edge stuff (mostly toolchain stuff). Which means that every wacko idea Lennart comes up with, I have to track in case it might be useful.
But, more featureful? Sorry, I'm using syslog-ng. The journal is *enormously* less flexible than syslog-ng, and I'm not running a log farm that needs to log a million messages a second so performance is not that crucial for me. Not that syslog-ng has a problem with performance either. Also I don't want to lose my logs merely because I choose to use a different init system.
Also I'm logging over the network, which last I heard the journal doesn't support, which makes its claims of high performance bizarre because next to nobody needs high logging performance on a single host. But that's not what 'high performance' seems to mean in the journal world: apparently the only performance attribute which matters is boot time. Now I boot my systems once every few weeks. I don't much care about boot time, and 80% of my boot time is spent in the BIOS as it is so no matter what anyone does my systems will be booting slowly. I can see how boot time matters if you're using a tiny tablet or something, but not everyone is using tablets or laptops, even today.
So as far as I can see the journal provides me with a bit of useful security functionality (coming to a syslog daemon near you soon, perhaps) combined with boot time improvements I don't need, a massive reduction in functionality and a wholly unnecessary tie to a fantastically involved and recomplicated init system which is taking over more of the system every day -- and making me less and less desirous of switching to it as it does, because who knows what the heck it'll take over next?
I liked the idea of systemd when it was just a much better init. Now it's a better init and cron and session manager and daemonize() and syslogd and who knows what the hell else -- I stopped keeping track -- there's no *way* I'm going anywhere near it. Boot-critical subsystems with feature creep this severe scare the hell out of me.
I *liked* PulseAudio. It didn't have feature creep. It knew what it did and it did it much better than anything else out there. systemd? I have no idea *what* it's for anymore, other than 'everything critical to system function in one basket ready to drop'. It gives me kitchen-sink fear, and as an Emacs user I'm almost immune to that.
Security quotes of the week
Posted May 22, 2012 17:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
You can run syslog[-ng] along with the Journal. It's supported and it JustWorks.
It's really of the "Why didn't we already do this 15 years ago?" kind.
Security quotes of the week
Posted May 24, 2012 0:22 UTC (Thu) by nix (subscriber, #2304)
[Link]
Yes, it's supported. Now. I no longer trust that things that are supported now will remain supported. There have been too many cases of things supported by Lennart's stuff suddenly becoming deprecated without warning, and I'm not willing to trust system-critical components that exhibit that sort of fragility and lack of back-compatibility.
Security quotes of the week
Posted May 24, 2012 16:56 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
"Too many cases"?
Currently that number is exactly 1. The full list of abandoned projects is:
1) ConsoleKit
Which was obsoleted by systemd and had its maintenance passed to another developer in an orderly fashion.
udev is going to be supported well into 2020 at least because it's used in RHELs.
Security quotes of the week
Posted May 28, 2012 13:37 UTC (Mon) by nix (subscriber, #2304)
[Link]
Other replaced projects, or projects whose replacement has been mooted, include cron, syslogd... it's true that those projects still exist for people not using systemd, but if you're using systemd all of a sudden you had to consider whether your syslogd (or whatever) was compatible with systemd in ways that you didn't have to before. And this keeps happening. Disruptive change after disruptive change.
Security quotes of the week
Posted May 28, 2012 13:39 UTC (Mon) by nix (subscriber, #2304)
[Link]
To reiterate: I don't think Lennart is wrong to work on systemd. I think systemd is almost certainly better than what it replaces (God knows that's not hard, sysvinit is awful and Lennart's code is rarely awful). It's just too scope-creepy for *me* to be comfortable using. I've seen too many systems with this degree of scope creep flame out and leave all sorts of chaos behind: even if systemd never flames out that would still cost me a degree of peace of mind, were I using it.
Security quotes of the week
Posted May 28, 2012 14:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
[Link]
Again, systemd is extremely careful to preserve compatibility with syslog and other daemons. Your existing infrastructure can remain totally unchanged.
Yes, it might be argued that systemd has too much scope. But this argument is clearly subjective.
Security quotes of the week
Posted May 24, 2012 12:06 UTC (Thu) by ovitters (subscriber, #27950)
[Link]
You're not even using a distribution? Damn..
Security quotes of the week
Posted May 25, 2012 14:24 UTC (Fri) by TRauMa (guest, #16483)
[Link]
Some people can tolerate all the pain in the world if it is self inflicted, but when the world deals them even a minor blow they cannot sleep until it is avenged. It's the sysadmin flavor of NIH.
Security quotes of the week
Posted May 28, 2012 13:35 UTC (Mon) by nix (subscriber, #2304)
[Link]
Nah. I'm just a flaming control freak regarding my own systems. (Also, this way, if something goes wrong I can generally fix it very fast indeed, and my job depends on me knowing how the guts of the system works.)
The admin overhead once you get things spinning properly is minimal, until someone throws a major change like this into the works. systemd et al is clearly better than init, but... I just can't trust that it won't keep expanding in scope until it's eaten things I rely on. :( Scope creep is a terrible thing, and systemd seems to have a really serious case of it.