Comment by peterwwillis | Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Parent Full thread

Side effects:

- The journal has limitations, like what files it stores the journal in and the [default] size of the journal, which is only 10% of the filesystem size. Which sounds retarded to anyone who has ever created a /var partition for logs, but anyway. (Configuring multiple syslog files is an efficient hack to spread log data load across filesystems, which AFAIK systemd does not support)

- All applications that were developed specifically with syslog support (such as using the glibc syslog functions, or the command-line tools, or the flat log files) will break. The fix is to reinstall syslog and configure it to use a journal device that systemd exports [once you configure it to].

- Any devices that this host was collecting syslogs for, or any syslog collection servers this host was sending its logs to, will break. (Syslog is the only de-facto standard [enterprise or otherwise] for sending or collecting logs on a network, besides maybe snmp, but that's not really logging)

- Systemd's programming-oriented control over log journals means you can only do things it lets you do. For example, there is built-in log rotation based both time and disk space used, but no function (that I know of) to tell it to rotate on-demand, which is a common sysadmin task. You are removing all the previous flexibility of syslog logs by using these binary journals.

- If you support more than one operating system, or hell, more than one Linux distro, you have to install syslogd and configure systemd to use it, or you'll be doing twice the work just to support Fedora's mandatory new logging system along with every other system's syslogd. (Even if every distro switches overnight you have legacy systems and code to deal with)

Weird how Fedora already had a project to fix logging. I wonder what happened to that. https://fedorahosted.org/lumberjack/

The basic proposal seems to be: I have this new logging system, so remove your old system because mine is better. Which is no better an argument than: I have this old stable logging system that works great, so your new system needs to chill the fuck out until it supports all the legacy stuff.

It doesn't seem like there is any need to remove syslog. The guy just wants it to disappear.

Which sounds retarded to anyone who has ever created a /var partition for log

Oh, but don't you know? You shouldn't need more than one partition; they're getting rid of separate /var (I only half joke; after they broke separate /usr by linking boot/system things to it, they declared separate /usr to be "deprecated").

If you support more than one operating system,

Another one of Poettering's favorite ideas is that nothing besides Linux matters. I may agree with him for my own personal computing setup, I think it's flat out unprofessional to eschew portability and cross-platform standards. Even ignoring the obvious benefits, making things portable can reveal bugs and unstated assumptions in your design which will trip you up later.

It doesn't seem like there is any need to remove syslog. The guy just wants it to disappear.

If there's one thing that strikes me about Lennart (and others, such as those working on Wayland), it's what appears to be a severe case of myopia, or just flat out willful ignorance, of systems that have come before. The egotism is astounding.

Granted, sound under Linux was far from perfect (so I've heard; it has always just worked for me), and PulseAudio eventually got stable and efficient enough to be be acceptable. That being said, it does feel a whole lot like "here's how we're going to do it, shut up and take it." It would be more palatable if they identified problems, proposed solutions, and then canvassed the community. Hell, even just proposing solutions as patches or wholly separate projects and letting the community vote with their feet would be preferable to this dictatorship mentality.

EDIT: Just to be clear, I distrust Lennart (and Sievers') approach to system software because they don't seem to think of the bigger picture or be aware of the past. Do you know why so many people are attached to the "legacy" "deprecated" ways of doing things? Because they work, across multiple platforms, multiple OSes and multiple paradigms (embedded, server, desktop, cluster, mobile, and future ones we can't even imagine). Because other ways have been tried (eg, binary logging on Windows) and failed. Yes, some things could be improved (dependency based boot is a good idea). But other things, such as the core modularity principle in UNIX, are there for a reason, and should not be lightly tossed aside.

My understanding is that it's fine to have a separate /usr, it just needs to be mounted by your initrd. Trying to ensure that everything that could possibly be needed to mount /usr is in / turned out to be a lot more difficult than building an initrd with the relevant tools in it.

There may be ways to do it right now, but it's hard to fight the fact that Lennart doesn't want it to be supported. He's already thinking of deprecating initramfs builders that don't have systemd running inside (which causes trouble for Arch). If systemd continues to clash with initramfs tools it takes human resources away from working on things Lennart doesn't care about.

systemd is not the software which depends on /usr, so I do not think that blaming Lennart is fair. I have no idea why this myth is still alive.

Reply on news.ycombinator.com