How about the big one: the socket activation API.

Software is changing and people are doing new things. systemd has many new things. Many of these new things provide functions that your alternatives do not - or they have been developed for specific reasons [networkd in the initrd/very early boot. The parallel boot is much better when you have an API for socket activation. Your syslog alternatives don't offer damn near anything that journald does (stuff that benefits from a binary format). systemd's cgroups API is much more convenient than "libcgroups with init". Give me a break.]

We get it. You don't like systemd. But your constant refusal to acknowledge systemd's features doesn't make them not exist or not matter or not beneficial to someone.

1 members found this post helpful.

Still, an educated opinion should be backed by verifiable reference information if you want to have a meaningful argument. Give us URLs to all these developer opinions and interviews.

Eric

1 members found this post helpful.

your right, but like everyone else I'm a bit lazy. it can get out of hand and very tedious if you set out to link to every point. I don't think I would even want to read such a thread. generally if its important or unknown you shoudl try to hunt down a link. but there are other things that become 'common knowledge'. at least among those who try to stay reasonably informed of current Linux news.

if you read a lot and have a good memory it can be quite hard to dig up published stories that you read two weeks ago given the fact that most news sites now go through a full page of news every day.

edit:

as a pointer for anyone who is looking for information, most Floss conferences now post there sessions online in video or at least slides. so even if you cannot attend you can catch up on all the latest work that is being done. but it does assume you understand how to program. most of these sessions are about code.

https://archive.fosdem.org/2014/news...-first-videos/

1 members found this post helpful.

Socket activation hasn't even been proven to be any better than using Dedicated pipes for service communication. That's not even worth switching out for. Go google search benchmarks for pipelining versus UNIX sockets. Have you ever used other parallel service activation inits other than systemd to prove dedicated pipes are any better than UNIX sockets? Even the bidirectional communication of sockets hasn't been proven to be completely better than single directional communication. The gains using sockets often when this was tested, were better but only fractionally, even minisculely, and even in some cases there were no gains, only loss. The reason, pipes don't used the shared memory needed by sockets. Granted in cases where you need bidirectional communication, like using TCP/IP and UDP protocols for data transmission, sockets will be faster, but when you don't have to use extra resources to push data through, why bother with something so trivial as milliseconds? Service work either way and milliseconds of performance versus adding on extra resource usage is paltry at best.

http://www.opendmx.net/index.php/Pip...et_Performance

Yes, syslog-ng, sysklogd, and rsyslog don't have what journald does. They don't corrupt the logs forcing the init system to slow to a damn crawl to rescan and try to fix the logs which is impossible, because the author is too narrowminded to fix it. People like you were specifically warned about binary logging and the potential for data corruption, but no, you just don't listen.

And yes software is changing, and not always for the better. That has unfortunately been proven by systemd because it isn't offering anything better. All it does is try to take everything done right, clump it together, get some of it wrong, and claim it is better.

1 members found this post helpful.

I'm done talking to this wall. I'll just wait until Pat decides on what's best.

I hope there is a mass exodus - maybe we'll see fewer garbage posts in this forum (including this one).

1 members found this post helpful.

Experience is useful, but it is also original research; i.e. it might be total crap.

I agree with it in principle, though. It's good to qualify what you're saying, if not you're just making assertions. As regards to readability, this isn't Twitter or Facebook; there's no reason people shouldn't be happy to elaborate and reference what they mean; many do.

I hope there is a mass exodus, especially of the pro-systemd crowd who do nothing but complain about paltry topics with no factual foundation. One point was all you could manage? And a weak point at that. Plus, you do know you can do do sockets can be created using traditional init systems at service launch. There's no evidence creating them at service launch is even any better than creating them at boot. All this evidence places systemd and it's hype dead center in being nothing but a strawman. Systemd assumes you're ignorant. It assumes that to be successful sysvinit, the existing GNU system, and every known has to have a flaw whether factual or opinionated. And in the end offers no factual betterment of the system while producing it's own set of flaws which are heavily downplayed.

And what will you do if Patrick doesn't pick systemd and sticks to his implementation of bsd-stylized sysvinit?

2 members found this post helpful.

I know what I will do. crack open a bottle of imported Osaka sake and giggle uncontrollably for 10 minutes.

3 members found this post helpful.

The writer of the next post: #1000, will win an autographed photo of Lennart Poettering! Enjoy!!!

1 members found this post helpful.

Just to elaborate on this: journald is not simply corrupting the logs for no reason. What you speak about is the behavior of journald when a corruption appears (and using rsyslog, syslog-ng, ... can not prevent corruption). It does not at all trying to fix anything in the logs. When the corruption is detected the current log-file is closed and a new one created, so that no further corruption in that file can happen. The only thing that journald is trying to fix when detecting a corrupt log is the output of the journalctl command (and this can be deactivated), but never the log itself.
If you want to complain about it at least get it right.

2 members found this post helpful.

Congratulations TobiSGD for post #1000, now can all of you just STFU and do something constructive for a change?.

Eric

6 members found this post helpful.

I hope Tobi's prize is not a bikini photo or nude shoot.

It's a thong! *reference from Shrek*

As a constructive project...

Everyone chip in $5 bucks so we can buy Eric a copy of Windows 10.

1 members found this post helpful.

Why do you want Eric to hate you?

All in good humor ol' boy.