[naquad]

Could somebody please remove Lennart Poettering? This systemd thing is a mess that tries to do way too much. I've had a huge pain rewriting couple dozens of init.d scripts with custom logic to service files. Friends of mine complained on that too. I'm really glad that systemd is not adopted Debian so I won't have this pain on servers. Also journalctl is not a convinient tool, less and bunch of files were working much better for me.

[darklajid]

Could someone please remove Lennart Poettering

- 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.

[naquad]

Oh! Indeed we forgot to talk about moral in UNIX-like OS software discussion. Oh my, how could we?..

[darklajid]

You consider 'Remove that person please' a software discussion? In what world?

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").

[lawl]

Would you tell me what title you'd expect? I honestly don't know what you think is wrong with it. I don't think ranting against the title without providing a reason and/or better suggestion is very constructive.

[darklajid]

I considered that obvious.

"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)

[pbsdp]

I don't really understand what is low about it. Systemd didn't just appear one day; Poettering has written and advocated for it strongly.

[darklajid]

- systemd isn't relevant to the discussion. Fedora already uses systemd (and the journal)

- 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?

[Tobu]

systemd's philosophy seems to be “bundle everything, attack anything we haven't assimilated”. The source is relevant.

[darklajid]

Really..? 'Attack'?

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.

[Tobu]

journald was enabled in Fedora very recently, on the premises that no one would feel a thing, just an implementation detail of systemd. Now systemd's syslog compat is seen as unnecessary overhead, and at some point the goalposts will move again and alternatives to the systemd journal won't be supported.

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.

[the_mitsuhiko]

> less and bunch of files were working much better for me

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.

[Karunamon]

>The mess of log files below /var/log has been a problem for a long time.

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)

[bitwize]

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?

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."

[naquad]

> 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.

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?

[tenfingers]

systemd is somewhat better than upstart on some fronts, and equally bad or worse in others.

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.

[lucian1900]

Could somebody please remove all the people that hate Lennart Poettering? This systemd thing is precisely what we all need! sysvinit is archaic and upstart is quite buggy and lacks good tools.

Have you even seen the systemd and Journal tools? I've wanted that for years.

[naquad]

Then go for it. Use it yourself, I don't mind that. Fork Debian/Arch/Ubuntu whatever and be happy. I don't want that.

[jvreeland]

Arch uses systemd by default

[_delirium]

Debian is likely to switch to systemd as the default in the next release, fwiw, though you will have the option to use sysvinit if you wish.

[bbanyc]

It's far from decided, and controversial to say the least. The systemd package maintainers are certainly acting like they're going to be the default, but it isn't their call.

[bitwize]

When ksystemd is released they'll have no choice!

[naquad]

The fact that systemd is spreading is depressing me. Thank god there'll be at least alternative.