- from the f..ing thread title?
- from the discussion?
That's beyond insane. Leave the man alone. Disagree all you like, but this "Ah, that guy that ruined my life with Pulseaudio is now going to take over other stuff" whining, this crappy attitude _really_ needs to go.
Start arguments against the technology, take part in the projects (-> here, Fedora) and vote against decisions you don't like, but don't start running around with pitchforks.
That's really, really low.
Did you even discuss software? I see just an attack against a person and some vague anecdotes, "friends complain too", waive hand.
Note that your post is infuriating, but the submission is worse. This thread is why title moderation has a right to exist (for future reference, given that I hope someone's going to fix the title: It was "Lennart Poettering wants to remove syslogd; use systemd journal instead").
"F20 System Wide Change: No Default Syslog" would be a good choice: It's the subject (both 'the mail header called subject' and 'the subject to discuss') of the thread you linked to.
Rephrasing that a la "Proposal to remove a syslog from Fedora default installations" would be fine.
Dragging a person into the title is just asking for trouble and attacks and serves no purpose. The proposal is technical, the discussion should be technical.
You deliberately put his name into the title. Why? And why just him, not both owners:
Change owner(s): Lennart Poettering, Matthew Miller
You had an agenda, even if it wasn't a conscious decision. That's just wrong (and not constructive either ;-p)
- why in the world would you attack a person for writing software and lobbying for its usage? Even if you don't want to use it? I guess you could attack half of HN in that case
And finally:
- the linked thread is a proposal to remove a single package from the default installation of all Fedora distros. The package is still available for installation, just won't be installed automatically.
That's the topic. Not the person behind the proposal, not the software that is already running on all current Fedora systems. That's just not the point.
I'm a systemd fan, not that happy about journald/journalctl (mostly, because I'm not yet used to it and really just use journalctl -b or journalctl -f, which .. gives not enough benefits to make it 'nice' for me). So - should I insult Lennart, call for his 'removal'?
It's low, because it distracts from the technical subject. Imagine your next proposal at work would lead to a 'Can someone please remove pbsdp' comment. Is there _ever_ a time when such a statement is acceptable? Would that count as taking part in a discussion?
Again: journal is already part of Fedora, enabled by default and doing its job. The whole discussion is whether a separate syslogd is going to be provided by default. Most people here _love_ Chef/Puppet etc. -> Just override the default and make sure that a syslogd is installed. Done.
Nobody 'attacks' anything. Proponents of one module want to remove a redundancy. That's not an attack.
Anecdote: I happen to know a thing or two about Tomboy (note taking app, written for Mono). Someone thought that Mono is 'teh ev!l' and created GNote, a more or less line by line port of Tomboy to a different language. Some distributions replaced Tomboy with GNote, after being convinced that it's the better choice. That's not an attack, it's potentially lobbying - or just plainly a matter of choice.
I'm writing this because I've been seeing the same sort of shifting promises when systemd assimilated udev. At first it was a trivial repository merge, just something to make the developers more comfortable, no impact to anyone else. Now building udev without systemd is unsupported, and some “cleanups” are made to tie udev to systemd and kmod. This doesn't benefit systemd but it hurts anyone who uses an alternative.
The same kind of breakage of alternatives is pushed on gnome via logind, and the kernel via cgroups. It would be myopic to focus on promises made in a particular thread and ignore most of systemd's history.
1) "journald was enabled in Fedora very recently"
systemd includes journald (and - as the thread that this whole discussion is about explains - journald is really a ~hard~ dependency for systemd: That's where early boot messages go, for example).
Systemd is in Fedora for quite some time already [1].
2) "Now systemd's syslog compat is seen as unnecessary overhead"
NO! Not at all! That's going to stay, that's not even mentioned anywhere in this discussion. Really, the thread even talks about improved integration between journald and for example rsyslogd (the latter moved from the simple 'receive log messages from journald' interface to the 'let me ask journald for messages and import them as good as I can' it seems). No one, certainly not in that thread, wants to remove the syslog compatibility.
The discussion is just about _not_ installing a syslog daemon by default. It's still supported, the compatibility (from systemd/journald) is there and going to stay. You just don't run a syslog daemon without installing it explicitly.
3) The trend, what you perceive about the slippery slope of things
This is hard to argue about. There are no hard facts to prove/reject. You don't seem to like a number of recent changes in the linux ecosystem. That's - okay. Natural. But I still think that you should take a step back and reconsider your opinion on the developers' goals: Are they really trying to 'attack' stuff or are they offering something they genuinely consider superior? Are they single-handedly changing the stuff around you, or are boards/committees convinced that these ideas are worth pursuing?
1: https://fedoraproject.org/wiki/Systemd#What_is_the_status_of...
Conceded.
> 2) "Now systemd's syslog compat is seen as unnecessary overhead"
I can't believe rsyslog compat won't suffer, well-meaning reassurances from a third-party can't trump the documented attitudes of core developers who aren't bound by them.
> 3) The trend, what you perceive about the slippery slope of things
I've illustrated a lot, I could easily find more.
I do in fact believe Lennart et al are developing and promoting a system (distinct from the Linux ecosystem) that they consider genuinely superior. It's what being an open-source developer is all about. It doesn't mean they aren't engaging in some ends-justifies-the-means politicking on the way to world domination. I'm fed up with the latter, and with having the bad forced with the good.
Just because it works for you does not mean it works for everybody else. The mess of log files below /var/log has been a problem for a long time. The format is not descriptive enough, there timestamps are second resolution only, no timezone information, and yet the times are in local timezone.
Please don't hold on /var/log/messages just because it has been like that for ages. That should not be the justification for it existing.
> I've had a huge pain rewriting couple dozens of init.d scripts with custom logic to service files.
That's funny, because my experience has been that writing init.d scripts is painful and even package maintainers sometimes get it wrong.
Have you ever tried to actually configure your syslog?
> Please don't hold on /var/log/messages just because it has been like that for ages. That should not be the justification for it existing.
Seriously, did you ever try to configure it?
> That's funny, because my experience has been that writing init.d scripts is painful and even package maintainers sometimes get it wrong.
For simple cases init.d script is mostly overkill, personally I had to write generator for this stuff. Solved 99% of probles in simple cases. But in complex cases where you split configuration (hello /etc/{conf.d,default}/*) or need to make custom actions (no matter which), service files lose. Now you have to write a wrapper that will be actually started by systemd. Who were saying what about redunant entities?
How so? It follows the *NIX "everything is a file" philosophy, so they can easily be processed by other utilities that everybody already knows.
>The format is not descriptive enough
You mean the standard filepath? /var/log/(daemon name).
You mean the actual textual format of a syslog message? Timestamp, daemon, facility.severity, message. If your messages are useless, isn't that a function of what's creating them, rather than what's capturing them? What additional data do you want that you're not seeing?
>no timezone information, and yet the times are in local timezone
What other timezone should they be in? Personally I think it's easier to look at the system clock (actually, I usually don't even have to do that, since I have a clock in the corner of my screen session) and make a mental note what timezone you're in rather than add two bytes to every message.
>Please don't hold on /var/log/messages just because it has been like that for ages. That should not be the justification for it existing.
It's the thing that wants to change the way it's always been done that has to justify itself, not the other way around. What does the systemd journal give us that's worth throwing out decades of knowledge and muscle memory?
Configuring syslog isn't exactly a great feat of skill either.. pick your favorite daemon, it still follows the general format of (messages from this thing) (with this characteristic) (go here)
That's how modern systems are developed. That's all the justification you need, really. Define the use cases you and your CADT buddies considered as "modern" and everything else as "legacy", then you can say "That worked fine in the 1970s, but modern systems don't work like that anymore."
For instance, I like upstart init files much better that systemd "services". Their ini-like syntax is very limiting if you need embedded scripts. I'm looking at you, PreExec. Wrapping everything through "sh -c" looks hideous, and it's not an advantage.
upstart init files with logrotate's syntax are way more readable. The "script" blocks avoid the "sh -c" escaping madness for you.
both upstart and systemd don't "get" live system debugging. I complained loudly both on debian and on the systemd mailing list, but people don't seem to grasp the concept:
If my system doesn't boot (no console), I'm f$#@. The daemon is waiting for some event to occur, but I have no clue which one.
With standard init, there are very few commands to respawn. The system is much more robust. getty on a local tty is part of them, and as such I never had a system where I couldn't debug startup issues.
With upstart/system, if I have an issue with udev (very common between updates), I do not get anything, even though the system is ready enough to start one.
What I need is a sysrq like binding for "force-start a getty now please". I need to be able to query init and ask "what even target are you /going/ to, which events are requisites and still not met? There are the obvious things you need to debug dependency-based systems.
But you don't have them.
No. But instead you can kill the running system, and reboot with "verbose boot". Because a scrolling terminal with 20 lines/sec helps apparently (hint: it doesn't - the system will still hang). So after that you can reboot once more, with init=/bin/sh and boot yourself.
The same issues go for shutdown.
I have nothing against systemd. Dependency-based boot is great. But both init systems seem to miss that a critical piece like init needs to be small, robust and debuggable.
I'm running systemd on unstable. I've lost count of the times that the system didn't boot properly because of an udev change that incurs in a dependency loop. This should never happen. Shutdown doesn't work since two months if you have a cryptsetup system, again because of a stupid unmet dependency.
Plus, again, systemd ini-file scripts are fugly. You need external scripts just to run Pre/Postexec.
Many of the design decisions behind Lennarh are, IMHO, regrettable. This goes way beyond systemd in general.
Fortunately systemd seems to be going forward somewhat, thanks to debian mostly, and like I said before, dependency-based boot is nice.
Have you even seen the systemd and Journal tools? I've wanted that for years.