LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-02-2019, 08:56 PM   #16
Timothy Miller
Moderator
 
Registered: Feb 2003
Location: Arizona, USA
Distribution: Debian, KDE Neon, Arch, Fedora
Posts: 3,076

Rep: Reputation: 933Reputation: 933Reputation: 933Reputation: 933Reputation: 933Reputation: 933Reputation: 933Reputation: 933

I think I've actually watched a recording of that symposium.
 
Old 08-02-2019, 09:06 PM   #17
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,363

Rep: Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720Reputation: 1720
https://skarnet.org/software/systemd.html
 
Old 08-02-2019, 09:59 PM   #18
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,113

Rep: Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798Reputation: 3798
We've danced these songs before on the forum. Nothing that I write will be anything new that hasn't already been said in one of the many systemd threads in the Slackware subforum. In fact, much of my post will be a quote from my previous post back in 2015. In fact, that post was in reference to a question from enorbet asking what systemd can offer in a SOHO environment.

And just for those that are interested in typing the name of systemd properly, it is systemd. Their website goes into more detail:

Quote:
Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple.
As I and many others have said, speeding up the booting process was never the intention of systemd. It was due to changes they made in the init system that led to speedups (like parallelization).

Quote:
This is all gathered via a google search (not all are unique to systemd, but none are currently a part of Slackware's init system). I have not had any actual experience with systemd and I don't plan to unless it's included in Slackware in the future. This is to the best of *my* understanding. If I misunderstood something, please let me know.
  • Logging - Say what you will about binary logs, if they do function properly, you get immediate logging as soon as the init RAM disk is started all the way to the final shutdown of the system. (How many times have you tried to glean information from the boot process only to have it go by too quickly?) It can also store non-text, like memory dumps, which can be used later in further debugging. The old syslog can be used in place without the extra benefits of binary logs and without the possibility of corruption. Do the benefits of binary logging outweigh the possibility of corrupted logs? To me, no.
  • Unit files - Easy to make config files using declarative language used to start up system daemons. This replaces the various rc.* files. They are simplistic to make and seem to have little to no downsides (other than ReaperX7 stating that it could lead to people not learning proper scripting techniques). It still supports running shell scripts if needed (although, I believe it would require a basic unit file). Benefits outweigh the costs? To me, yes.
  • Dependencies - Services are able to be started once a certain set of dependencies are met. This is different than rc.* when startup is based on location in the script. The dependencies can be more than just a program/service starting, it can be based on udev, dbus, sockets, etc. One example of this is to mount the network harddrives after the network comes up, but mounting any physical discs before. The possible benefits from this are there, but I have no idea how well it works in practice. It could cause dependency circles when two things are waiting for each other to start. I don't know the likelihood of this, so do the benefits outweigh the costs? To me, unknown.
  • Parallelization - Allows the startup sequence to occur in parallel. This allows two or more services to start at the same time. Because of unit files and the dependencies specified, this should prevent programs from starting too early. This does usually equate to a boot speed increase and I am not aware of downsides of parallelization (short of the downsides listed in dependencies). Benefits outweigh the costs? To me, probably.
  • Cgroups - Cgroups containerizes a process and all child processes. This allows systemd to keep track of child processes even when the parent exits and shut them down if needed. This, in theory, is much better than using a PID, since we've all ran into the issue when a process won't start because an old PID is left in /run. It seems you are also able to limit resources to certain containers, meaning that you can limit how much RAM or CPU usage. I could see this adding complexity to the system, but the tradeoffs may be worth it. Benefits outweigh the costs? To me, undecided.
  • Additional Core Components - Replaces startup shell scripts, pm-utils, inetd, acpid, syslog, watchdog, cron, and atd with systemd components. This makes it easier for maintainers to provide the features those programs do, since they will all be included and won't need to be gathered separately and require verification they all work together. They also fall under a unified release schedule and come in the same tarball. Some replaced abandoned software, like logind replacing consolekit. However, all of this also causes feature creep and creates a larger amount of code to debug. This is probably one of my biggest complaints about systemd. The combination of many programs that don't need to be combined. It creates the possibility for more problems and works to prevent you from using alternatives if desired. You can see what it has taken over when you look at its ancillary components: consoled, journald, logind, networkd, timedated, udevd, and libudev. Adding more services to systemd seems very reminiscent of Windows and its svchost.exe file. Bug reports are sometimes ignored. Benefits outweigh the costs? To me, no.
@Timothy Miller, you can either disable journald and use syslog in place or you can have both and have journald forward messages to syslog.

Now, I do like to point out that I'm no systemd fanboy. I am very happy with Slackware's init system and hope Pat and team are able to continue to use it. But I have to also admit that systemd has benefits that Slackware doesn't offer... even if those benefits aren't even close to being enough to sway my preference from Slackware's to something else. Unfortunately, the objectiveness and awareness of the people can sometimes be overshadowed by the worry that systemd is ruining Linux by doing things very un-UNIX like. I have this same worry as well, but I do like to try and be informed on both the good and bad of situations. I think systemd brings more bad than good, but that is only my opinion, and it's obvious that many OS developers have felt it brings more good than bad.
 
8 members found this post helpful.
Old 08-02-2019, 10:38 PM   #19
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 2,240

Rep: Reputation: 564Reputation: 564Reputation: 564Reputation: 564Reputation: 564Reputation: 564
Quote:
Originally Posted by bassmadrigal View Post
As I and many others have said, speeding up the booting process was never the intention of systemd.
Maybe. But that's precisely how it was sold initially.
Quote:
(How many times have you tried to glean information from the boot process only to have it go by too quickly?)
Try this:

$man dmesg
 
2 members found this post helpful.
Old 08-02-2019, 10:49 PM   #20
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,531

Rep: Reputation: 1155Reputation: 1155Reputation: 1155Reputation: 1155Reputation: 1155Reputation: 1155Reputation: 1155Reputation: 1155Reputation: 1155
Quote:
Originally Posted by Timothy Miller View Post
Generally, I'm a systemd user. Do I like it? NO. But, all my favorite distro's moved to it, so I use it. It works* (*mostly, for the most part). Honestly the BIGGEST thing I dislike about it is binary logs. If journald saved everything as a straight text file, I'd probably like systemd. But I definitely agree with everyone who says they don't trust it...it's been a security NIGHTMARE since coming out. If it were easier to use my preferred distro's without it, I would. As it's difficult, if not impossible, to do so, I use it and I'll continue using it.
The binary logs are extremely frustrating. Hey, you know all those great Unix utilities you have for finding, parsing, redirecting, and otherwise using content in text files? Guess what, you can't use any of them for your logs now. You have to use our crappy limited journald system instead. It's the worst. And all for the sake of what, saving a few megabytes on your hard disk?

Last edited by montagdude; 08-02-2019 at 10:51 PM.
 
3 members found this post helpful.
Old 08-02-2019, 11:40 PM   #21
glorsplitz
Member
 
Registered: Dec 2002
Distribution: slackware!
Posts: 747

Rep: Reputation: 160Reputation: 160
Discussing this in the LQ Slackware forum is like some thread discussing the benefits of Windows on LQ.
 
Old 08-03-2019, 03:00 AM   #22
ferrari
Senior Member
 
Registered: Sep 2003
Location: Auckland, NZ
Distribution: openSUSE Leap
Posts: 3,765

Rep: Reputation: 653Reputation: 653Reputation: 653Reputation: 653Reputation: 653Reputation: 653
Quote:
The binary logs are extremely frustrating. Hey, you know all those great Unix utilities you have for finding, parsing, redirecting, and otherwise using content in text files? Guess what, you can't use any of them for your logs now. You have to use our crappy limited journald system instead. It's the worst. And all for the sake of what, saving a few megabytes on your hard disk?
You're free to configure systemd journalling as you like (as already mentioned in bassmadrigal's post) so this is a non-issue.
 
Old 08-03-2019, 04:14 AM   #23
bifferos
Member
 
Registered: Jul 2009
Posts: 152

Rep: Reputation: 53
Quote:
Originally Posted by average_user View Post
You said you want to configure your system with shell scripts and you can still do that within the framework provided by systemd.
No, not in the same way. Can I ask a question: have you actually tried to replace bits of init using both systems, if so how did you get along?

Quote:
Originally Posted by average_user View Post
It's different, that's way you find it hard to learn. You've worked on your scripts for years and know them well. It's just like people saying that Linux is hard because it doesn't look like Windows.
My experience of systems that call you is that it's inherently more complicated than systems where you control the top level. Your position is that I just don't remember, but I respectfully disagree.

Quote:
Originally Posted by average_user View Post
4MB is really very little these days. The trend I see is different - get more expensive hardware and cut development time using JavaScript instead of C, Linux instead of RTOS etc. I think that systemd was not written with such small devices in mind. It's mostly geared for desktops and servers.
They are still today producing 1MB devices that can run Linux, and they are still cheaper than the 4MB devices. If you run a business shipping thousands of units it can make a difference.
PS: I'm very interested to know how javascript cuts development time, there could be another thread devoted to that one .

Last edited by bifferos; 08-03-2019 at 04:25 AM.
 
1 members found this post helpful.
Old 08-03-2019, 05:24 AM   #24
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 17,994

Rep: Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870Reputation: 2870
Quote:
Originally Posted by glorsplitz View Post
Discussing this in the LQ Slackware forum is like some thread discussing the benefits of Windows on LQ.
Agreed - I long ago gave up hoping to have a sensible dispassionate systemd discussion here. Reminds me of the Amish - the world just passes by what was once considered "honourable".

Likely to be get a more balanced perspective elsewhere. Or maybe not given the protagonists ... :shrug:
 
Old 08-03-2019, 06:27 AM   #25
average_user
Member
 
Registered: Dec 2010
Location: Warsaw, Poland
Distribution: Slackware
Posts: 411

Rep: Reputation: 161Reputation: 161
Quote:
Originally Posted by bifferos View Post
No, not in the same way. Can I ask a question: have you actually tried to replace bits of init using both systems, if so how did you get along?
I haven't. I have never had a need to touch most of Slackware startup scripts neither apart from modifying several switches here and there.
Quote:
Originally Posted by bifferos View Post
PS: I'm very interested to know how javascript cuts development time, there could be another thread devoted to that one .
For starters, it's easier to find Javascript developers because this language is much more popular than C. There is no need to compile Javascript code. It's easier to avoid memory leaks thanks to built-in garbage collector. It's portable across various platforms, for example you can use React framework to create mobile apps https://facebook.github.io/react-native. But perhaps the most important advantage is that you can create web apps that run in the web browser that always executes remote code and by doing that you are able to upgrade your app in one place without deploying it on millions of your devices.
 
Old 08-03-2019, 06:59 AM   #26
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Brú na Bóinne, IE
Distribution: Slackware, NetBSD
Posts: 1,570

Rep: Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053
First: if they don't know themselves where they're going with it, how are we supposed to make an intelligent assessment of it?

Second: if nobody can point to a feature of systemd that we didn't already have, why exactly did they cause so much disruption by imposing it? And yes, they did impose it, because they made the burden of maintenance so much harder for developers offering alternatives.

systemd was the brainchild of the bully boys in the Linux world, people in various projects who like to think it's their way or the highway. No intelligent assessment is possible with people like these. They don't listen.

I've been using openSUSE for my LPIC course. I am yet to find a single feature of systemd that was not already available in Linux, nearly always from a more intelligent and respectful developer.
 
4 members found this post helpful.
Old 08-03-2019, 07:13 AM   #27
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 460

Rep: Reputation: 259Reputation: 259Reputation: 259
Quote:
Originally Posted by Gerard Lally View Post
I am yet to find a single feature of systemd that was not already available in Linux, nearly always from a more intelligent and respectful developer.
For example: Slackware (with its ConsoleKit) supports the true Multi-Seat?

I seen that Multi-Seat in action at the school where learns my younger kid: imagine two kids having their own set of keyboard, mouse, headphones and LCD monitors, every one doing his independent job on their independent desktops, but having just a single computer between them.

The teacher told me that from their own experiences any of their average computers can drive decently up to 4 seats, but there appears the physical issues of how to organize the seats around computer, and that they are (already) quite happy with those double seats, which permits them to cut at half the number of computers.

RE: 20 (average) computers for 40 (happy) kids.

Could be that be done with Slackware instead of Ubuntu?

Last edited by LuckyCyborg; 08-03-2019 at 07:23 AM.
 
2 members found this post helpful.
Old 08-03-2019, 07:40 AM   #28
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys for decades while testing others to keep up
Posts: 2,315

Original Poster
Rep: Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332Reputation: 2332
I have to say I'm rather disappointed that it appears few have actually watched the video. The speaker is a BSD guy and he explains some deep level uses, uses that have parallels in MacOS and Windows, in fact he castigates Lennart somewhat for his apparent fascination with (and "taking pages" from) Apple. The point is that if a software developer for BSD, with the deep background he seems to have, sees some developmental value in such init systems (one area mentioned is containers and security, others I understand even less) it is at least worthy of honest discussion IMHO.

Another point about which I was mistaken and some here seem still mistaken, is that while some people touted faster boot times with systemd, that was never a design goal.

As for the spelling, bassmadrigal, I have read that too and frankly I don't give a hoot. In a title where it is common to capitalize, given that not one single person would misunderstand "SystemD" I care even less. I want to know more about what alternatives it offers of which, in my ignorance of deep OpSys development, I am interested solely in cost/benefit. Currently I don't see that as even a break-even-point, but the video made me more aware of what I don't know well at all.

I commonly test out other distros and naturally many of those use systemd. I have struggled with it some but mostly that was from the learning curve for newly named processes and conventions. It was no great benefit but wasn't that big of a deal. It was fairly transparent but I'm now thinking maybe I got no benefit exactly because of that learning curve and I'd like to know if that is true or not. Granted I could learn that best by submitting to the curve but my time is valuable and I think it is inefficient to chase goals that are not well defined. So this thread is so I can hear from anyone who was forced into that curve and accepted that curve and found some value of which I am unaware and I don't mean necessarily limited to systemd, but the entire concept behind why anyone would consider it a good idea.

Years have now passed since so many distributions chose (or caved depending on your POV) to switch to it. Surely the community knows more now than they did then.

I would greatly appreciate fewer comments by people who can't be bothered to spend 47 minutes to get a 2019 update from someone experienced in the field, especially someone something of an outsider whose only affiliation is software development and seems to be reasonably objective. If it is just a rehash of how you (or I) initially reacted, as many have already noted, that's been done to death and doesn't belong in this thread.
 
1 members found this post helpful.
Old 08-03-2019, 08:48 AM   #29
hitest
Guru
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware
Posts: 5,859

Rep: Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031Reputation: 2031
Quote:
Originally Posted by enorbet View Post
I commonly test out other distros and naturally many of those use systemd. I have struggled with it some but mostly that was from the learning curve for newly named processes and conventions. It was no great benefit but wasn't that big of a deal. It was fairly transparent but I'm now thinking maybe I got no benefit exactly because of that learning curve and I'd like to know if that is true or not. Granted I could learn that best by submitting to the curve but my time is valuable and I think it is inefficient to chase goals that are not well defined. So this thread is so I can hear from anyone who was forced into that curve and accepted that curve and found some value of which I am unaware and I don't mean necessarily limited to systemd, but the entire concept behind why anyone would consider it a good idea.
Recently I experimented with running Arch and Debian. Over time I became accustomed to systemd conventions like systemctl. I am very fond of Arch, it is outstanding. The only glitch I noticed with Debian was occasional lock-ups. As I initially stated in this thread I have mixed feelings about systemd. I am comfortable with using systemd distros, but, I don't feel the need to permanently adopt any of them. Slackware meets my computing needs.
I am taking a wait and see attitude on this issue. What will be, will be. Acceptance.
 
1 members found this post helpful.
Old 08-03-2019, 09:25 AM   #30
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Brú na Bóinne, IE
Distribution: Slackware, NetBSD
Posts: 1,570

Rep: Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053Reputation: 1053
Quote:
Originally Posted by enorbet View Post
I would greatly appreciate fewer comments by people who can't be bothered to spend 47 minutes to get a 2019 update from someone experienced in the field, especially someone something of an outsider whose only affiliation is software development and seems to be reasonably objective. If it is just a rehash of how you (or I) initially reacted, as many have already noted, that's been done to death and doesn't belong in this thread.
I was just answering the question in the thread title.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Q. Can your Linux PC run Crysis? OK, it can. But will it run natively? A. Soon, very soon LXer Syndicated Linux News 0 03-11-2014 11:01 PM
LXer: My Nerd Life: Too Loud, Too Funny, Too Smart, Too Fat LXer Syndicated Linux News 0 01-24-2014 05:21 AM
LXer: Abolishing patents: Too soon or too late? LXer Syndicated Linux News 0 01-09-2013 02:20 PM
Application Assessment for Linux Migration MSquared Linux - Software 1 02-02-2005 05:14 PM
Probed and Attacked - Battle Damage Assessment halifax Linux - Security 2 08-17-2003 08:06 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:11 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration