Basically what we are getting for desktop Linux is exactly that Tobi. Think Factory Reset combined with Google Play. That gives too much power to distributions to say what can and can not run on their systems. Think if each system update had a factory reset trigger added in.

It also amounts to possibly reimplementing another travesty of software. Hearing "Verifiable Systems" makes me cringe and think of one nasty software package ripped directly out of the Microsoft Bible... System Registration.

I am reading "loss of freedom", from my point of view, written all over this.

And your question about having all the necessities to a Linux system within systemd... so what's so bad about all the individual projects from kernel.org and GNU being used to create a working system?

At least I'm working on an alternative to sysvinit that's sound alongside Stoat and Keith, and the Gentoo project is working on Eudev which is still viable.

As far as ConsoleKit. It was only forcefully deprecated by it's authors who abandoned it. All the project needs is someone to devote time to keeping it maintained. It doesn't have to have active development either. Hell, HAL's been maintained all this time and it's been a non-dev project for years.

Do you honestly know how much time I spend maintaining LFS-Runit's installation scripts and help file each week? Possibly less than a couple of hours tops. Keith and Stoat draft scripts when they can, but there's no rush or hurry to do so. Are you saying you can't devote maybe an hour a week to ConsoleKit's maintenance?

1 members found this post helpful.

Excellent news!
A long awaited feature that saves *lots* of headache while making embedded distros.

ssl779... What part of Slackware makes you assume Slackware is going to just magically become like ArchLinux?

Where did he mention Arch?

Speaking of not even bothering to read things, did you read the reddit thread I linked to earlier? Or how about I give you some more material: discussion on hn.

1 members found this post helpful.

Oh I'm reading it. But so far all the arguments against it's adoption are still quite valid regardless of what website you read it from. In fact 1/4 down the page, daemontools and Runit are quite well mentioned as alternatives to sysvinit, though there aspect that someone thinks Runit doesn't start services in parallel is misleading.

About halfway down the page, the UNIX Philosophy is called upon multiple times.

So far it's all a good read, but nothing significant as to say systemd should be adopted, but rather Linux needs a modern init system that isn't like systemd.

There was even talk of s6 being used.

1 members found this post helpful.

Well, my team works on building embedded systems, and back in 2012 my personal duty was to evaluate available init systems and pick one for our new project. Alas, in spite of talks about "many choices in Linux" there were only two viable alternatives - upstart and systemd. Anyway, I proposed them, and after extensive analysis we chose systemd as a technically surerior solution (a wise decision as it turned out - Canonical has abandoned upstart).
Please note that decision was made by five highly experienced embedded system developers,
and I also should note that the distro we build is for a mission-critical devices (must adhere to ISO-9001 and heaps of other standards, certifications and so).

You may wonder why I tell you all this cr*p?

Because from your statement that I am "not really qualified" I conclude that you are a highly knowledgeable in init systems, so I would really appreciate if you suggest a systemd alternative that satisfies the following requirements:

- socket activation;
- D-Bus activation and interop;
- process babysitting using cgroups;
- easy way to serialize and parallelize services startup;
- uniform logging (preferrably with remote access);
- boot time less than 15 seconds (not a strict requirement however);
- must remain maintainable by upstream for at least 5 years;


As you wish - tomorrow you will have sunshine and temperature +26C

And you since 2012 never researched other init implementations like Runit or s6 that have been around for several years now?

Just because upstream maintains something doesn't mean it's stable or bug free. I'm always learned to be careful of upstream because you can get sandbagged by them very easily.

Runit has been stable for a while now and hasn't required any updates. Skarnet's s6 is still actively developed and has been for some time now. My Runit LFS box boots in under 9 seconds to log in, but that's far from what Runit is useful for. It's a well tested daemon manager.

As far as the rest... fickle arguments really. There are other tested methods of performing each of those actions using non-systemd tools, and some aren't even required. Uniform logging is something systemd does not do. It's the only logging system that uses binary language logs, aka 0s and 1s, whereas just about every other logging system using plaintext which is uniform. Last I checked just about every OS can read uniform plaintext.

No, you're a developer who looked for the easy way out rather than learning the actual methods of implementation.

1 members found this post helpful.

Man, you have 2682 posts (only on this forum!).
In terms of amount of words, each of your post is roughly equivalent to 10 lines of C code (on average).
So you would be able to deliver a software project equivalent to 27000 lines of C code.
Twenty-seven thousands lines - it's quite a serious project, isn't it?!
And I guess you wouldn't do it all along, right?
You would public a repository, become a maintainer, and lots of developers would join you (according to amount of systemd-haters found only on this forum).

So, I ask you - where is this "modern init system that isn't systemd"?
?

Research init systems like Runit and s6. They're a step in the right direction of a proper init system for GNU/Linux, but as it stands there is no perfect init system for GNU/Linux yet.

And does my post count and words used post have any relevance to this topic other than you showboating?

1 members found this post helpful.

You may call both maintenance, but one is shell scripting and the other is C coding. Two tasks of different nature. Also, ConsoleKit and logind have different D-Bus interfaces and report different information, so each has to be explicitly supported by desktop developers, which might make the code harder to maintain and they could easily decide to not support ConsoleKit. If you wish to keep a systemd-less system, I believe it would be wiser to support the OpenBSD GSOC project (mentioned many times on this thread already) to provide systemd-{logind,hostnamed,timedated,localed} compatible alternatives instead of insisting on ConsoleKit, it would make life easier for desktop developers if they only had to work with one set of interfaces.

Can you also backup your "HAL is maintained" statement with a source? I believe HAL might be maintained for the BSDs but not for Linux. HAL functionality on Linux was split up between other packages (I might be wrong on this, but I think they were udev, upower and udisks, perhaps some others as well).

BSDs are the only known maintainers of HAL, but oddly HAL can still, with patching, be built and used on Linux. I know of only a handful of projects that still have HAL code as well. However, you can still use it. I know first hand the VMware free drivers optionally reference HAL for their interfaces, and Flash still uses it for DRM. Other than that, I think Xfce, KDE, MATE, and other DEs have legacy HAL support on BSDs and Linux but on Linux its mostly unused and functionality put through ConsoleKit. However, if you probably built around HAL, it could still be used.

1 members found this post helpful.

"stateless" and "factory reset"
some companies will love it,
no one sells software so good as the systemd guys, that's a fact
http://0pointer.de/blog/projects/stateless.html

bla bla bla
"Most importantly: the majority of Linux packages are simply incomptible with this scheme the way they are currently set up. "
bla bla bla
:-)

but how cares, they sell it so good that they have success.
and RHEL7 comes with systemd, so systemd is a reality for a long long time.

ps: personally I still have no opinion about the systemd stuff
but I have somehow the feeling that it becomes so big that sooner or later there will be a 'certified systemd engeneer' with courses and exams for some money, yep, companies will love it :-)

1 members found this post helpful.

Good. I was just waiting for the move that would make me stop using that c*appy app. Maybe this is it.

Now who's being an ass?

You proudly proclaim in your profile that you switched to Arch in 2012. Arch is a systemd distribution, so I would have thought that the obvious answer would be for you to just use Arch and stop wasting your time trolling Slackware forums?

1 members found this post helpful.