If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I do hope they'll optionally provide journald support. journald is pretty nifty.
Otherwise, this is a great idea and I wish them well. Hopefully this will put this baffling conflict to rest.
I'll second this - if there's an easy way to install it with journald support, I'll happily replace systemd with it. It's a great compromise for people who like the improvements systemd offers, but don't like the way it tries to assimilate everything under the sun.
It also looks extremely well suited to embedded systems, given that they're supporting alternative C libraries.
If they wanted to improve the current software, they could have contributed to Upstart or forked it if they didn't want to give their copyright to Canonical. For example, the feature of tracking child processes not only by their parent PID. That can also be added to Upstart. And you know, with Upstart you still get compatibility with System V scripts.
Instead, they had to do this virus and mimic Apple's Launchd, showing total lack of creativity.
I suppose is better to do their own system and pass it through our throat, like when Red Hat tried to standarize their shitty RPM package format with the LSB.
Last edited by Filiprino; 21 September 2014, 06:00 AM.
atlast somebody instead of whining & doing nothing, STARTED something..
let's see how the community will react, respond & contribute.
Agreed. I personally think it's unlikely to be a success, but at least they're doing something instead of just complaining.
Problem is, I think that by the time they're removed all the bits that they don't like, they'll be left with an empty directory. Reading through the project FAQ, everything about it seems fundamentally opposed to how systemd is designed and developed... and this is a one-man project. I'm pretty sure he'd do better by starting from scratch...
If they wanted to improve the current software, they could have contributed to Upstart or forked it if they didn't want to give their copyright to Canonical. For example, the feature of tracking child processes not only by their parent PID. That can also be added to Upstart. And you know, with Upstart you still get compatibility with System V scripts.
This is that they wanted to do at the start but after looking into it they found that the concept behind Upstart was broken. They even talk about this in their talks and explain why they think a event driven model for an init system is broken.
Also, systemd IS compatibility with Sys V scripts.
I'll second this - if there's an easy way to install it with journald support, I'll happily replace systemd with it.
That seems unlikely, given the FAQ suggests that the journal is one of the (many) things they dislike about systemd. The philosophy behind the project seems to be to rip out all non-essential elements, and to instead promote the ability for users to choose between alternatives for things like logging and udev and the likes. That sounds wonderful in theory, but it's insanely hard to actually make work in a way that doesn't just limit things to the lowest common denominator.
So the question would be - is it possible to adequately re-implement the journal on top of nothing but the classic syslog interface? Maybe, maybe not - but it certainly sounds like journald wouldn't be available unless someone were to put a bunch of effort into supporting it as a third-party project, since the uselessd developer wouldn't be including it in his source tree.
I like systemd but still see their effort as potentially useful.
If one thinks some solutions are wrong, s/he should roll up h/is/er sleeves and do something about it.
Which is what they are doing.
Even though systemd is not 100% on my "wavelength" I don't see this approach solving it for me.
They are just pruning it down of all the tools that could benefit from integration, not actually solving anything that is not done ( correctly) by systemd.
Comment