The Politics of systemd Part 3

[axl]

People need to be comfortable with just /bin/sh as init. and go from there. build everything ground up.

Sorry, but that is too extreme. My first thought was the bs word, but I restrained myself.

What would you do when you had to face an empty sh and had to start everything from there?
Right, you would start to write an init script.
Then you want to replace something and run into dependency problems. What'd you do?
Right, teach your script to start things in the correct order.

... and after a decade or so, you have a service manager. Maybe like runit, maybe like openrc, or anything else.
What good did that decade do to you? Nothing. Nothing but pain and a lot of wasted hours.

And now you know why LFS is rarely used and DIY is dead.

Besides, it's just a stupid simple layer. Doesn't help at all with "services". I call em daemons. It's what they were originally called and I still think it's fitting. People still dont know how to control em. rely on "service manager". poor delusional people.

You know, most people want to work with their computers and not permanently on them. We are Gentooers, we already have enough of the latter. Thanks.

OK. had a few beers that night. What I meant is that people who _WANT_ to call themselves sysadmins and roots, should be capable if the situation requires, to start the system from scratch.

I didn't say it's comfortable. I didn't say you should do it at every boot. All I badly said is that: "people need to get comfortable". it's an admission of the fact that is not comfortable.

I'll tell you a story. I have an AR parrot 2.0. It's a small arm board with linux. It's neither openrc or systemd. it has a single init file and a minimal linux. it doesn't have ssh, only telnet; and wifi is setup to work as ap without password. Anyone who has this drone can lookup what I'm saying.

Now you get this drone and you want to change things. there's no community you can bully into making changes upstream for you. WTF do you do? you get comfortable with just /bin/sh as your init. which was my original point.

[axl]

I got here in 99 because I was tired to compile cyrus-imapd and postfix and amavis and php manually in slackware. it was horrible work with terrible inconsistency in libraries even in short periods of time like 6 months.

I still remember now, my mom was doing the christmas tree and I was compiling gentoo right next to it. that was my 99 x-mas gift. gentoo.

Lies.
Krinn asked you flat out whether you even use Gentoo, and what a surprise, you evaded the question.

Sticking "I LOVE GENTOO" in your signature does not prove anything.
In fact it sticks out like a sore thumb.

And if you want to work in the field, you need to be comfortable with both.

Oh please.
Stop lying.

Besides, it's just a stupid simple layer. Doesn't help at all with "services". I call em daemons. It's what they were originally called and I still think it's fitting. People still dont know how to control em. rely on "service manager". poor delusional people.

You really are delusional if you think any of us believe a word of what you write.

Lay off the kool-aid; it's making you talk stream-of-consciousness nonsense which only makes you and other systemdbust fanbois look even more clueless than already thought.

if krinn asked me any question and I didn't answer it, I'm sorry. I don't think he asked me that. I don't remember reading that question. And regardless if it was asked and answered I often say this: exclusively gentoo, sometimes debian, mostly because of raspberry pi. and sometimes I go a little further to explain. but weather you guys like it or not, it was a blissful 20 years. Without much help.

And yes Khey... i know release date 2000. I just know it was around x-mas. Am I allowed to forget stuff?

Anyway, I will keep my signature. Last month, I did my best to help some people with some stuff. Sometimes it worked, sometimes it didn't. I had 2 guys with nouveau, one with a nvme, one with an efi setup, one with openvpn and one with distcc.

If people want to tell me to "walk off" from gentoo chat... fine. ima prolly do that. but if you want me to completely erase myself just because at the core I'm a "systemd fanboi"... then u're gonna have to fight me every single thread that is not in gentoo chat. Go on those threads give better advice. then i'll be gone.

censorship is pretty bad. fact that posts can become ghosts from 30 july to 3rd august is again regrettable. but that's just as far as I can go.


PS and again... no insults. no "you" there. count them. count yours. want to convince me I'm stupid and should not be here? can't. even stupid should be here to learn. ofc they can't learn from arrogant people but that's another topic isn't it?

[Ant P.]

axl ... you're past the point of being an annoyance with your constant trolling, speculative prognosis, and circular reasoning. Are we supposed to know what "caught a daemon" possibly means, or what might qualify the absolute condition of "at it's fullest"? You act as though you have insight when your entire argument turns on pronouncement, and arbitrary association.

Am I? I'm sorry.

What I meant by "caught a daemon" is the fact that even though some daemons have been there since forever, there is still no service manager in gentoo.

sysvinit has a built in service manager. No major distro ever used it properly; if they had then systemd may have not been built at all.

[axl]

axl ... you're past the point of being an annoyance with your constant trolling, speculative prognosis, and circular reasoning. Are we supposed to know what "caught a daemon" possibly means, or what might qualify the absolute condition of "at it's fullest"? You act as though you have insight when your entire argument turns on pronouncement, and arbitrary association.

Am I? I'm sorry.

What I meant by "caught a daemon" is the fact that even though some daemons have been there since forever, there is still no service manager in gentoo.

sysvinit has a built in service manager. No major distro ever used it properly; if they had then systemd may have not been built at all.

Whatever thing you are talking about, it's not there. It's not there in the default systemd gentoo distro. It's not there in the openrc implementation.

In fact what are you talking about?

I'm just curious. what was the implementation in sysvinit u're talking about?

EDIT: shouldn't a "service manager" know when a service is newly installed and start it? shouldn't a service manager be aware when a service has been upgraded/modified and know how and when to restart it? shouldn't a service know how to use it's own ssl certificates? I could go on. The simple story is forget "service manager". U are the service manager. the human in front of the keyboard. Other distros try to fake that, and they do terrible disservice to linux at large. That's what I think. It's not ok to be lazy.

[khayyam]

axl ... you're past the point of being an annoyance with your constant trolling, speculative prognosis, and circular reasoning. Are we supposed to know what "caught a daemon" possibly means, or what might qualify the absolute condition of "at it's fullest"? You act as though you have insight when your entire argument turns on pronouncement, and arbitrary association.

Am I? I'm sorry.

axl ... yes, you are. Over the past month or so we've seen you proclaim that we need to "get over it", "get in this century", how "systemd is actually [our] friend", etc, etc ... all with little more than pronouncement, or arbitrary association, as argument. That has all the hallmarks of trolling, and it doesn't seem like you're likely to desist, as after saying "sorry" you pile error on error and continue on that path (see bellow).

What I meant by "caught a daemon" is the fact that even though some daemons have been there since forever, there is still no service manager in gentoo.

All you're doing here is holding up your idea of what a service manager is, and then proclaiming such a thing doesn't exist ... this is a classic strawman argument. It's patently false because if I were to reboot then something is attempting to bring my system into a desired state, according to pre-defined requirements ... and it will do this consistently. That "something" we can call management ... regardless of it meeting your criteria.

You might want to call files in /etc/init.d or files in /lib/systemd/system as service files or whatever. But most of the time they don't work. That is ... if they exist at all. For instance, find cyrus-imapd systemd service file. Or they just don't work. Because there is no fancy layer of stupid proof.

There is so much wrong with that statement I don't know where to start. So I call them initscripts, or service files, your point is? As for them not working "most of the time", right, contrary to everyone's experience of them working "most of the time"? Oh, and here comes the "because" ... which should contain an argument supporting the premise but unfortunately only contains another, unrelated, proclamation.

And other distros try harder. For instance debian variants don't just configure your service and start it for you when you install it (which gentoo doesn't do) but also restarts it for you when you upgrade it (which also gentoo doesn't do).

You're off on a tangent, those are tasks that the package manager are responsible for ... and in fact you could have it do so ... but I would say that installing, or upgrading, are not instances where services should be made to start, restart, or be added to a runlevel (though some in fact are).

With all the other insults, it's hard for me to discern where you stand on the issue. U barely say anything about it. I went on and said lots. Maybe too much. I'm afraid to go back because I might go circular again.

Those were not insults, they were observations based on your behaviour. I didn't provide anything like a counter-argument, because, as I said, you didn't have a discernible argument ... just proclamations, associations, etc.

I'll try to keep it donald_trump easy and non-circular. being fooled by (whatever) init into thinking it's doing services for you .... BAD. SAD.

learning to do your own service file in either init... GOOD.

Would you disagree with that?

It's a false argument, "being fooled" does not follow from the premise.

[...] also, the idea of "service manager" is stupid. and it's masking incompetence. I cannot go to an interview and say things like "service manager". if that daemon is crashing with that message what would you do? I would ask the service manager to ...

No, your argument (such as it is) "is stupid", "masking incompetence" doesn't follow from the premise, nor do any other statements in that paragraph. An argument follows the form: premise, justification, conclusion ... and true conclusions only come from true premises.

best ... khay

[Ant P.]

Whatever thing you are talking about, it's not there. It's not there in the default systemd gentoo distro. It's not there in the openrc implementation.

For starters, I was talking about neither of those things, so you're not going to find anything there.

In fact what are you talking about?

I'm just curious. what was the implementation in sysvinit u're talking about?

RTFM.

[saellaven]

And other distros try harder. For instance debian variants don't just configure your service and start it for you when you install it (which gentoo doesn't do) but also restarts it for you when you upgrade it (which also gentoo doesn't do).

You're off on a tangent, those are tasks that the package manager are responsible for ... and in fact you could have it do so ... but I would say that installing, or upgrading, are not instances where services should be made to start, restart, or be added to a runlevel (though some in fact are).

In fact, automatically starting or restarting a service can make you vulnerable to remote attacks, corrupt data, lose data, hang your system*, kick you offline without a way back in if you're doing remote administration, etc.

No service should be brought up or restarted until the admin is sure things are properly prepared for it to be started/restarted.

Ditto for automatically restarting a crashed service, or else you could possibly be subjecting yourself to further damage from the above list.


* let us not forget the systemd bug where a simple null string could hang systemd, causing all kinds of issues including preventing a clean reboot, because the programming geniuses behind it couldn't even bother to check for null, ignoring the basic rule to always validate input.

[khayyam]

And other distros try harder. For instance debian variants don't just configure your service and start it for you when you install it (which gentoo doesn't do) but also restarts it for you when you upgrade it (which also gentoo doesn't do).

You're off on a tangent, those are tasks that the package manager are responsible for ... and in fact you could have it do so ... but I would say that installing, or upgrading, are not instances where services should be made to start, restart, or be added to a runlevel (though some in fact are).

No service should be brought up or restarted until the admin is sure things are properly prepared for it to be started/restarted.

saellaven ... I agree, in fact I think any change to /etc/runlevel should be treated in the same manner as CONFIG_PROTECT, and that the PM shouldn't be adding/modifying runlevels, or indeed, doing anything in relation to the current env.

Ditto for automatically restarting a crashed service, or else you could possibly be subjecting yourself to further damage from the above list.

I agree, mostly, but there are instances in which supervision might be applicable.

best ... khay

[axl]

It's kind of circular thinking having a service manager that is not actually a service manager. To me it's clear that this is a fluid concept. Quite a number of implementations. And again, there are variations even when same init system is used (one example being that while gentoo and debian share systemd, one starts/restarts services as it installs/reinstalls packages and the other does not). I wasn't saying it's a smart idea. I was trying to explain that there is not ONE way to think of a service manager.

But, at least I get your guys point. init.d scripts are perfect.

Truth be told, I kinda agree on that. at least in gentoo, openrc had a lot more time to mature. Those openrc init scripts have been refined by 20 years of experience in gentoo alone, and were the product of the work not only in gentoo. And therefor are WAY better than the counterpart in systemd. Where again, I can attest with my own experience that it sucked in the first few years. Quite a few of daemons I am using didn't have service files at the beginning. Some of them still don't have them now. Again I offer cyrus-imapd as example. Missing documentation. Missing a lot of things. It wasn't easy. Especially at first.

PS also that "systemd is you friend" was in may. not this month. also, some of my activity concerning systemd was years back. it wasn't all this month. just sayin...

[Yamakuzure]

It's kind of circular thinking having a service manager that is not actually a service manager. To me it's clear that this is a fluid concept. Quite a number of implementations. And again, there are variations even when same init system is used (one example being that while gentoo and debian share systemd, one starts/restarts services as it installs/reinstalls packages and the other does not). I wasn't saying it's a smart idea. I was trying to explain that there is not ONE way to think of a service manager.

Please stop right there and don't move! First read this list:

1. You are talking about "package managers".
2. Please read no 1 again.
3. ...and again, please!

Neither Apt nor Portage are Service Managers, they are Package Managers. And that's the difference. No matter whether you utilize openrc, systemd, runit, plain sysvinit or something completely different.

And again: The "Starting and restarting when installing/upgrading" is solely the matter of the used Package Manager. This has nothing to do with any init or rc software used.

Edith had to add: By all means search for a different example! Cyrus-Imap is a very very very bad example. Even its founding institution, the Carnegie Mellon University, has ditched Cyrus-Imap last year. Having no automatic service configuration and setup for a hilariously complicated service like Cyrus-Imapd is not a proof of the package manager (again, you are not talking about service, but package managers) being bad at all.

[axl]

It's kind of circular thinking having a service manager that is not actually a service manager. To me it's clear that this is a fluid concept. Quite a number of implementations. And again, there are variations even when same init system is used (one example being that while gentoo and debian share systemd, one starts/restarts services as it installs/reinstalls packages and the other does not). I wasn't saying it's a smart idea. I was trying to explain that there is not ONE way to think of a service manager.

Please stop right there and don't move! First read this list:

1. You are talking about "package managers".
2. Please read no 1 again.
3. ...and again, please!

Neither Apt nor Portage are Service Managers, they are Package Managers. And that's the difference. No matter whether you utilize openrc, systemd, runit, plain sysvinit or something completely different.

And again: The "Starting and restarting when installing/upgrading" is solely the matter of the used Package Manager. This has nothing to do with any init or rc software used.

again. tons of debian users (not sure what happens in rpm based distros) but tons of users in debian are asked if they want they services automatically restarted. don't argue with me. argue with debian. i'm just stating a fact.

I'm not saying apt is a service manager. But i can say the package manager has hooks in the init system and that might be a thing, or not.

also funny enough debian used to be the most old school distro.

[Anon-E-moose]

axl please, do us all a favor and STFU.

Your continuing to argue when you don't know what you're talking about fills two niches.
1. It annoys everyone else (which makes you look like a troll)
2. It makes you look dumber than a box of rocks, because you conflate various things that have nothing to do with each other, ie init systems and services, package managers, etc.

Edit to add: I try to be nice and polite, but you really push the boundaries (which again makes you look like a troll)

[Anon-E-moose]

Just a little more.

I could add a question to the login script "Do you want to start/restart service x.y.z" so you would see it ever time you logged in
and guess what, it has nothing to do with init or any service "manager" or even the package manager.

The fact that debian asks if one wants to start/restart a service when a package is (re)installed has absolutely nothing to do with init and services,
it's a convenience that debian added, for their own reasons.

[khayyam]

It's kind of circular thinking having a service manager that is not actually a service manager. To me it's clear that this is a fluid concept. Quite a number of implementations. [...]

axl ... here you are again with your specious logic, remember, it was only a short while back [post=8247542]you were proclaiming[/post] that we shouldn't pretend that such a thing is even "possible", but now, it's "a fluid concept", with "quite a number of implementations" ... that is, if we only knew what sort of confused idea you have in mind.

[...] And again, there are variations even when same init system is used (one example being that while gentoo and debian share systemd, one starts/restarts services as it installs/reinstalls packages and the other does not). I wasn't saying it's a smart idea. I was trying to explain that there is not ONE way to think of a service manager.

As others have pointed out, the package manager and the service manager are entirely separate components ... and as I said, the fact that gentoo doesn't do such things is the safest option.

But, at least I get your guys point. init.d scripts are perfect.

No, you certainly don't ... but don't let that stop you having a good troll.

Truth be told, I kinda agree on that. at least in gentoo, openrc had a lot more time to mature. Those openrc init scripts have been refined by 20 years of experience in gentoo alone, and were the product of the work not only in gentoo. And therefor are WAY better than the counterpart in systemd. Where again, I can attest with my own experience that it sucked in the first few years. Quite a few of daemons I am using didn't have service files at the beginning. Some of them still don't have them now. Again I offer cyrus-imapd as example. Missing documentation. Missing a lot of things. It wasn't easy. Especially at first.

It was only a few post back you were proclaiming that [post=8248900]"most of the time they don't work"[/post], but now they seem to have "mature[d]". You can't even present a consistent argument. All I've seen so far is you failing to address any of the points put to you ... you simply wander off on some other tangent, and issue more proclamations about this-that-or-the-other ... that makes any discussion with you completely pointless.

best ... khay

[Fitzcarraldo]

As some of you have been discussing DCOP and DBus, I thought you might find the following 5 June 2009 post in the lxde.org blog interesting. I just now came across it by coincidence while searching for information on how to use DBus in LXDE. Seems the LXDE developers are not too fond of freedesktop.org either (I can't blame them!).

https://blog.lxde.org/2009/06/05/if-you ... ling-list/

I almost feel like quoting the entire post, but here are a few snippets:

Besides, another big issue here is, most of the specs/standards are advocated by Gnome or KDE developers, and they don’t even consider the needs of other desktop environments. The so-called cross-desktop standards are actually well-implemented in Gnome and KDE only. XFCE tried hard to follow all those standards, but never get everything work flawlessly. LXDE tried to follow those specs, too, but found that many of the specs are very complicated and inefficient, which can slow down our desktops and add bloatness.

Recent changes in freedesktop.org, like PolicyKit and ConsoleKit, are mainly developed and implemented by Gnome-related developers. Then the KDE guys are forced to follow them. They even drop their well-designed and high performance IPC mechanism, DCOP, and adopt dbus, which is mainly advocated by Gnome developers. Some people even suggested that KDE should replace their own VFS with GIO/GVFS developed by Gnome. Some new technologies are developed by Gnome first, and then they wrote freedesktop.org specs for them. Later, those things are copied to KDE and they soon have their KDE equivalence. Unfortunately, all other desktop environments are forced to follow those standards whether they really need it or not, to keep the compatability with those two major desktop environments.

Why should we always be forced to follow all those things we don’t like or don’t even need? If we don’t follow them, we lost compatibility with many existing Gnome/GTK+ and KDE programs. In addition, they modify the specs frequently, and always break backward compatibility. So our precious time are wasted on re-implement everything in their new specs and try to fix all broken compatibility left by them. It’s enough!

[Anon-E-moose]

Why should we always be forced to follow all those things we don’t like or don’t even need? If we don’t follow them, we lost compatibility with many existing Gnome/GTK+ and KDE programs.

Indeed, and when I look for programs I usually wind up ignoring both gnome and kde apps, for the simple reason that I can't just have the application,
I have to have this bloated framework even for simple things like a calendar, music/video player, etc.

It's not that they have to have those tie-ins but it seems that group think is alive and well, originally mainly in gnome, but kde is almost as bad nowadays.

[bghoons]

Why do I get the impression that behind SystemD is a grinning Bill Gates? Since Microsoft could not defeat Linux, they had to go the route "let's make Linux more hateful to use than Microsoft --they will come running and crying back to us!"

I have not had a problem using SystemD so it is not a big deal, but I am not a SysAdmin dealing with hundreds of servers. Other than the initial install, I notice no difference between SystemD and the old init system. Other than a few different commands to do some things, it is almost invisible.

[pjp]

Continued in [topic=1084948]systemd discussion: agree to disagree[/topic].