Couple of months have passed since I tried to remove it from 13.1 install and failed.
Lack of alternatives have forced me to fdisk and look for proper sysvinit replacement elsewhere.
This is what I’ve found so far: busybox, openrc and upstart.
So I am now struggling to find a reason why openSUSE has enforced systemd and ignored everything else.
Especially because systemd comes from Red Hat who publicly stated they’ve no intention of supporting competitor products.
Is SUSE product, the downstream of openSUSE project, not a competitor of RHEL anymore?
Anyway, I don’t care about these corporate decisions as long as they don’t affect me, as openSUSE user.
However, I was previously told that, if I don’t like systemd, I should gtfo to another distro.
To put things into perspective, other distros have provided a choice, but openSUSE did not.
Debian has voted systemd as default, but still supports alternative init system regardless.
Arch forum thread on openrc+eudev implementation has 60k views.
Slackware has unofficial systemd build working, but it’s not anywhere near default.
Gentoo has always been about choice, needless to say, this is still the case.
In conclusion, I’m not really sure what to expect from this project anymore.
Maybe one of these days, GNOME will become the one and only openSUSE DE deprecating everything else.
Perhaps distros will become services in the future, enabling a “core” system to start/stop systemd-openSUSEd on demand.
Jokes aside, tinycore busybox boots my system in less than 4 seconds. Does this mean systemd is now deprecated?
If I decide it’s deprecated, does it mean it’s deprecated for everyone else automatically?
It would be interesting to know what you don’t like about systemd. Having said that, most distributions have now adopted it, and SysVinit’s days are numbered as an option, even with those that still offer it. Even Ubuntu has recently dropped Upstart for systemd, so being pragmatic about it, you’d better get used to it if you want to continue using Linux.
First, - I don’t have the technical skills to judge systemd. Another branch there is KDBUS and I was reading at Phoronix. The comments there are very enlightening.
As a non-technical person but at manage level I have a feeling that something is trying to sneak in. A fox in the henhouse?
As a private user of openSUSE it doesn’t probably mather. The developers and packaging team will have my dist working.
To be expected from complexity and over-engineering, which also tends to affect diagnosis of failure and “mean time to repair”, both adversely.
So I am now struggling to find a reason why openSUSE has enforced systemd and ignored everything else.
Especially because systemd comes from Red Hat who publicly stated they’ve no intention of supporting competitor products.
Is SUSE product, the downstream of openSUSE project, not a competitor of RHEL anymore?
No. openSUSE and Red Hat are competitors, but that’s a sort of red herring wrt this issue. It might be more relevant that openSUSE tends go where Fedora goes on new developments, and Fedora was the first adopter with systemd as default.
However, systemd is free and open-source software, not bound by competition. If you were seriously looking for why systemd was taken up so readily by openSUSE, then you would have to look for common ground or characteristics shared by the systemd engineers (Messrs Poettering and Sievers) and openSUSE.
Another clue might be found in the adoption of PulseAudio, not as controversial, also free and open-source, and also developed by Poettering. In my experience when PulseAudio fails it has a history of being difficult to diagnose and repair. In this case there is an alternative present in our distro of choice.
There are alternatives for now. Systemd is listed for each distro as a separate component on DistroWatch, e.g PCLinuxOS is listed with no systemd, and independent of ubuntu and debian. Oh, and SUSE Linux Enterprise doesn’t have it yet.
I have somewhat the same feeling. On the other hand that I have maybe the change is good. It is a very large change of Linux. Good? Bad? Time will tell:|.
While I love a good rant, like everyone, since it reminds me of the joke, “is this a private fight, or can anyone get into it?”, why would a typical user
care whether or not Linux uses the older Unix style Sysvinit, or this newer systemd? What subtleties am I missing here?
Being a “user” of Linux (as opposed to a “power user”), and not needing to tinker with various things in the system, I never noticed any difference when systemd was adopted. I don’t even know why it’s used now, or what the advantages are. It doesn’t bother me, everything still works. I did hate PulseAudio at first, it didn’t really work. But now it seems ok, though I never understood why we needed it.
With 13.1, there is now a systemd user process. It stays there when you logout. It messes up the session count, so that an “ecryptfs” private directory is not unmounted at logout.
The systemd user process seems to be involved with authentication (maybe with communication with policy kit). And it sometime seems that authentication stops working when there is a systemd update.
Maybe these problems will eventually be ironed out.
On a different front, I have ubuntu 14.04 in a separate partition. Startup and shutdown are a lot faster. Ubuntu is not using systemd. One of the early arguments for systemd was that it would give faster startup and shutdown.
In my mind to… Maybe. Calgary Stampede parade! With all the bells and wissles witch make Europeans so hard to understand it. A truckload of manure? Calgary flames, Not to many of locals there and Lazy programming. Red Hat? Systemd?
I’m seeing that (all those empty directories of systemd) with 13.1
You don’t sound very sure? How did you get a tmp.conf? My “/etc/tmpfiles.d” and “/etc/tmpdirs.d” are both empty. I upgraded from 12.3, so what are we missing?
I copied “tmp.conf” from “/usr/lib/tmpfiles.d”, then edited it. I have it set to empty “/tmp” at bootup.
I did the same for 12.3, but it did not clean up systemd-private directories. And it also filled “/var/tmp” with systemd-private directories. With 13.1, I am only seeing a single “systemd-private” directory in “/var/tmp”, and it is from the current boot. Similarly for “/tmp”, but my “tmp.conf” is supposed to clean up “/tmp” so I’m not sure what “systemd” would do without that cleanup.
On 2014-05-25 18:36, BSDuser wrote:
>
> While I love a good rant, like everyone, since it reminds me of the
> joke, “is this a private fight, or can anyone get into it?”, why would a
> typical user
> care whether or not Linux uses the older Unix style Sysvinit, or this
> newer systemd? What subtleties am I missing here?
well… for instance, you umount manually a partition, and systemd
decides that it should be mounted, and mounts it again. This is a change
in behaviour, and their devs argue that it is correct.
yet it breaks things…
This one got corrected in 13.1, I think.
So the answer for a typical user is that a user would not care, except
when things that worked stop working, and he has to work around to get
them working again.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-05-25 20:46, Fraser Bell wrote:
>
> No comment.
>
> Except:
>
> systemd -still- clogs the tmp directories with a manure-truckload of
> empty directories, refusing to clean up after itself.
Because they argue that “/tmp” must reside in RAM. If a distribution
doesn’t, it has problems. They apparently design it to work their way,
no variations allowed if they disagree with them.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On Sun, 25 May 2014 08:16:02 +0000, finders wrote:
> So I am now struggling to find a reason why openSUSE has enforced
> systemd and ignored everything else.
Because the maintainers decided that this was the way forward that met
their design goals and needs. You might review the discussions on the
developer mailing list archives at the time the decision was made.
> Especially because systemd comes from Red Hat who publicly stated
> they’ve no intention of supporting competitor products.
systemd is open source, so this really isn’t a relevant point.
> Is SUSE product, the downstream of openSUSE project, not a competitor of
> RHEL anymore?
Obviously SLES and RHEL are competing products. Asking these kinds of
hyperbolic questions isn’t likely to make anyone think you have a serious
question here, but rather that you just want to “stir the pot”.
