Distributors ponder a systemd change.....not Slackware ;)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It was a sad day for me last year when I realized Debian no longer provided an environment I like to work in. I feel like if I ever go back to work for a large company I will be utterly lost due systemd. I wonder if the CompTIA Linux+ certification requires systemd knowledge...
Perhaps I misunderstood the other article, but it appeared that what has changed is the default behavior. Distributions were able to turn this ability on to make it their default, but some subset of distributions chose not to do so. I have no idea on the size of that subset.
It also does not appear to me that when this wonderful feature was introduced that there was a concurrent warning that it would become the default in a certain specific future release.
from the change log:
Code:
* systemd-logind will now by default terminate user processes that are
part of the user session scope unit (session-XX.scope) when the user
logs out. This behavior is controlled by the KillUserProcesses=
setting in logind.conf, and the previous default of "no" is now
changed to "yes". This means that user sessions will be properly
cleaned up after, but additional steps are necessary to allow
intentionally long-running processes to survive logout.
While the user is logged in at least once, user@.service is running,
and any service that should survive the end of any individual login
session can be started at a user service or scope using systemd-run.
systemd-run(1) man page has been extended with an example which shows
how to run screen in a scope unit underneath user@.service. The same
command works for tmux.
After the user logs out of all sessions, user@.service will be
terminated too, by default, unless the user has "lingering" enabled.
To effectively allow users to run long-term tasks even if they are
logged out, lingering must be enabled for them. See loginctl(1) for
details. The default polkit policy was modified to allow users to
set lingering for themselves without authentication.
Previous defaults can be restored at compile time by the
--without-kill-user-processes option to "configure".
I think you can not make it more clear, if this is not enough, what do some packagers need, a messagebox in the build script?
This topic systemd is just hysteric, no matter what happens, there will some people freak out, some media will write about that, some more people will freak out.
You can think about systemd what you want, but technical, as a developer, how they develop and document and bring in stuff is impressing, also that some things become a topic of discussion. You might not like it, with a reason or just because, but you still have options, and the topics have a point and are interesting.
Unfortunately the default reaction of some hard core anti systemd people and Pottering haters is embarrassing for the whole Linux community. That's why I still react on this topic and try to put things into the right perspective, even if I am aware that for some people that is senseless since their hate has a religious magnitude, and no technical reasons at all.
This topic systemd is just hysteric, no matter what happens, there will some people freak out, some media will write about that, some more people will freak out.
You can think about systemd what you want, but technical, as a developer, how they develop and document and bring in stuff is impressing, also that some things become a topic of discussion. You might not like it, with a reason or just because, but you still have options, and the topics have a point and are interesting.
Unfortunately the default reaction of some hard core anti systemd people and Pottering haters is embarrassing for the whole Linux community. That's why I still react on this topic and try to put things into the right perspective, even if I am aware that for some people that is senseless since their hate has a religious magnitude, and no technical reasons at all.
In other words, 29 years of GNU Screen is wrong, and 5 years of systemd is right.
Thanks for the clarification. We'd still be living benighted lives were it not for the more enlightened among us. People like you and your idol Poettering.
In other words, 29 years of GNU Screen is wrong, and 5 years of systemd is right.
Thanks for the clarification. We'd still be living benighted lives were it not for the more enlightened among us. People like you and your idol Poettering.
systemd changes nothing on screen, the distributions or administrators can do that or not, just like they want.
Thanks for proving that you A) did not get the simplest technical basic of this topic and B) that you come with one phrase ala Poettering Fanboy, you could not have given a better sample for the typical stereotype pattern. But if this far from reality simplification helps you to keep your view of the world simple enough and make you feel better, feel free to do so
Additional threads created for the sole purpose of arguing over systemd will result in closures and/or bans. If you have any questions or comments on this, feel free to contact me directly.
--jeremy
If you just can't let this topic drop then please save the bar stools and take it "outside". (not in this Slackware Forum).
Last edited by TracyTiger; 07-07-2016 at 02:11 PM.
Reason: Another Appeal to End This
* systemd-logind will now by default terminate user processes that are
part of the user session scope unit (session-XX.scope) when the user
logs out. This behavior is controlled by the KillUserProcesses=
setting in logind.conf, and the previous default of "no" is now
changed to "yes". This means that user sessions will be properly
cleaned up after, but additional steps are necessary to allow
intentionally long-running processes to survive logout.
While the user is logged in at least once, user@.service is running,
and any service that should survive the end of any individual login
session can be started at a user service or scope using systemd-run.
systemd-run(1) man page has been extended with an example which shows
how to run screen in a scope unit underneath user@.service. The same
command works for tmux.
After the user logs out of all sessions, user@.service will be
terminated too, by default, unless the user has "lingering" enabled.
To effectively allow users to run long-term tasks even if they are
logged out, lingering must be enabled for them. See loginctl(1) for
details. The default polkit policy was modified to allow users to
set lingering for themselves without authentication.
Previous defaults can be restored at compile time by the
--without-kill-user-processes option to "configure".
I think you can not make it more clear, if this is not enough, what do some packagers need, a messagebox in the build script?
No, the way to socialize this sort of change is to state quite clearly when you introduced the feature that it is now defaulting to "no" and that the default will be changed to "yes" in some clearly identifiable future release.
Introducing a feature that defaults to "things work like they used to" followed by "things now won't work like they used to" without prior warning of when that transition was going to happen is a dick move.
If you show me the change log entry of that warning or some other public official communication from the systemd team that telegraphed the change so that people could prepare themselves for it prior to it happening, then I'll agree that this is much ado about nothing. Telling people that the change is part of the release with no prior indication that was going to happen is not a good thing.
One way is rude, the other way isn't. Not surprisingly, you don't appear to have a problem with the rude approach.
I should hope that any systemd consuming distribution will no longer assume that the default for any such flags will remain thusly and set them to what they want as soon as they are introduced.
For the other people reading the thread, I'll point out that Linux Is Not UniX and that Mr Poettering appears to believe that will all his heart. Quoting unix fundamentals about his work is somewhat pointless; it certainly won't effect his decision making.
No, the way to socialize this sort of change is to state quite clearly when you introduced the feature that it is now defaulting to "no" and that the default will be changed to "yes" in some clearly identifiable future release.
Introducing a feature that defaults to "things work like they used to" followed by "things now won't work like they used to" without prior warning of when that transition was going to happen is a dick move.
If you show me the change log entry of that warning or some other public official communication from the systemd team that telegraphed the change so that people could prepare themselves for it prior to it happening, then I'll agree that this is much ado about nothing. Telling people that the change is part of the release with no prior indication that was going to happen is not a good thing.
One way is rude, the other way isn't. Not surprisingly, you don't appear to have a problem with the rude approach.
says a user of a distribution in the hands of a bdfl, thanks for sharing you double standards. whats next, polls for each patch Linux applies if they fit into your worldview ?
It was a sad day for me last year when I realized Debian no longer provided an environment I like to work in. I feel like if I ever go back to work for a large company I will be utterly lost due systemd. I wonder if the CompTIA Linux+ certification requires systemd knowledge...
@mralk3:
as far as I know the CompTIA Linux certification paths are based on and identical to the LPIC paths.
You can browse the LPIC-1, LPIC-2 and LPIC-3 exam objectives under the Certification menu at the LPI website.
says a user of a distribution in the hands of a bdfl, thanks for sharing you double standards. whats next, polls for each patch Linux applies if they fit into your worldview ?
I say again my last
Quote:
Not surprisingly, you don't appear to have a problem with the rude approach.
*I* am not one of those complaining about the change in systemd behavior; I don't use it and am thus unaffected.
You, OTOH, don't appear to understand that changing a public interface without prior notice really annoys users of that interface. I'm inclined to believe that you've never had to create and support such a beast and thus have no idea about the human issues involved.
I'm not making a technical argument about systemd and what it is doing.
There appears to a large set of people who *do* use systemd and were unpleasantly surprised by the change. There are rather simple ways to reduce the level of surprise which did not appear to be used. I can speculate *why* they weren't used and Occam's Razor would lead me to a simple conclusion about how RedHat and RedHat engineers view their position in the Linux ecosystem.
Then again, people screw up. It's what people do.
By all means, continue to be pointlessly rude to me in this thread. I'll eventually react and get another PM in my inbox.
Distribution: Slackware/Salix while testing others
Posts: 1,718
Original Poster
Rep:
Lets not close the thread, its a good discussion on the continuing developments of a major (regardless of viewpoint) Linux application(s). I found it interesting that once the distros/maintainers were getting use to using it, they are now having another major change thrown at them.
Regarding the LP supporter, if the unresolved processes was such a problem, why has it not caused any major trouble in 25 years? When did this cause a security hole or hackfest on Linux or Unix?
*I* am not one of those complaining about the change in systemd behavior; I don't use it and am thus unaffected.
You, OTOH, don't appear to understand that changing a public interface without prior notice really annoys users of that interface. I'm inclined to believe that you've never had to create and support such a beast and thus have no idea about the human issues involved.
I'm not making a technical argument about systemd and what it is doing.
There appears to a large set of people who *do* use systemd and were unpleasantly surprised by the change. There are rather simple ways to reduce the level of surprise which did not appear to be used. I can speculate *why* they weren't used and Occam's Razor would lead me to a simple conclusion about how RedHat and RedHat engineers view their position in the Linux ecosystem.
Then again, people screw up. It's what people do.
yes, my point of view is in this case it is in the hand of distributions to break user interfaces. because that what it is, and if some packages are over strained with reading the changelogs for the software they want to maintain,
Is the problem the software? I do not think so, as long as you have options and documentation and you need to adopt the build script anyway
This could be indeed an interesting discussion, not senseless bashing of software or people
Quote:
Originally Posted by Richard Cranium
By all means, continue to be pointlessly rude to me in this thread. I'll eventually react and get another PM in my inbox.
what do you mean with rude, asking things like if you have you been asked about Slackwares change to pulse audio or not and what's the different to the changelog in systemd? if you find questions like that rude, ... ok,
I have been updating my own sphere to 14.2 since almost the moment of release, and all smiles!
Other than some necessary adjustment for pulseaudio, I have had no upsets nor disruptions!
The well established and secure methods I have used and tweaked for my own environment continue to be useful and adaptable in a nice, stable, predictable way! It is a fully updated continuation of what has gone before, not some new departure into someone else's vision of what the future should be.
It respects my existing uses and methods and knowledge and thus, facilitates my own growth without pruning it to fit into someone else's landscape. It respects and enables my individual FREEDOM instead of restricting it by someone else's rules du jour.
Seeing the continual disruption, turmoil and uncertainty of other distros does indeed remind me how happy I am to be a Slackware user! But to the extent that their disruptions drain like effluent into the common ecosystem, I know that they will inevitably force changes on Slackware over time. This makes me all the more appreciative of Slackware's BDFL development model, and our BDFL himself, Patrick Volkerding! He respects his passengers and crew and steers a straight and safe course through troubled waters!
Continuity. Stability. Respect. Slackware. Patrick Volkerding.
Distribution: Slackware/Salix while testing others
Posts: 1,718
Original Poster
Rep:
Quote:
Originally Posted by astrogeek
Indeed!
I have been updating my own sphere to 14.2 since almost the moment of release, and all smiles!
Other than some necessary adjustment for pulseaudio, I have had no upsets nor disruptions!
The well established and secure methods I have used and tweaked for my own environment continue to be useful and adaptable in a nice, stable, predictable way! It is a fully updated continuation of what has gone before, not some new departure into someone else's vision of what the future should be.
It respects my existing uses and methods and knowledge and thus, facilitates my own growth without pruning it to fit into someone else's landscape. It respects and enables my individual FREEDOM instead of restricting it by someone else's rules du jour.
Seeing the continual disruption, turmoil and uncertainty of other distros does indeed remind me how happy I am to be a Slackware user! But to the extent that their disruptions drain like effluent into the common ecosystem, I know that they will inevitably force changes on Slackware over time. This makes me all the more appreciative of Slackware's BDFL development model, and our BDFL himself, Patrick Volkerding! He respects his passengers and crew and steers a straight and safe course through troubled waters!
Continuity. Stability. Respect. Slackware. Patrick Volkerding.
This is a Slackware forum and Slackware doesn't use systemd.
I will just say this, and then hold my tongue: bit by bit the systemd cabal are burdening distro teams and upstream developers with extra work that, to my mind, confers no advantage whatsoever over existing implementations. I have yet to see a single compelling case for systemd that demonstrates its superiority over these already existing implementations.
Just today in this post Eric Hameleers referred to the extra burden systemd is placing on him. I don't see this situation improving in the future. Quite the opposite: I expect the burden to become intolerable as systemd infests every single nook and cranny of Linux. Now you might feel that that does not have very much to do with Slackware, but it still pisses me off, moreso when loudmouths around here (not you) tell me I don't understand the technical merits of systemd and shouldn't therefore offer my opinion. I understand systemd well enough to know there is nothing whatsoever that it implements that is not already implemented in Linux, and to know that it is increasingly adding to the workload of thinly-spread teams like the Slackware team. All because the dictatorial and crusading zealots at places like Gnome and Red Hat know so much better than the rest of us how Linux should "proceed" into the future.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
whats next, polls for each patch Linux applies if they fit into your worldview ?
