LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Closed Thread
 
Search this Thread
Old 06-03-2013, 08:19 AM   #346
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,614
Blog Entries: 2

Rep: Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070

Quote:
Originally Posted by elvis4526 View Post
I personally think it is a good idea since everything in Linux seems cheaply glued together.
This is an advantage, not a problem. If parts are loosely coupled I can exchange them with other parts that maybe fit my needs more. Is this possible with systemd? For example, can I replace udev in systemd with mdev or hotplug2?
 
1 members found this post helpful.
Old 06-03-2013, 10:57 AM   #347
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,225

Rep: Reputation: 175Reputation: 175
Quote:
Originally Posted by TobiSGD View Post
This is an advantage, not a problem. If parts are loosely coupled I can exchange them with other parts that maybe fit my needs more. Is this possible with systemd? For example, can I replace udev in systemd with mdev or hotplug2?
Yes.

Code:
systemctl disable udevd.service
 
Old 06-03-2013, 11:25 AM   #348
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,614
Blog Entries: 2

Rep: Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070
Quote:
Originally Posted by jens View Post
Yes.

Code:
systemctl disable udevd.service
And will the rest of systemd work coupled with mdev or hoptplug2? Or will the parts of systemd that are relying on a service like udev (if there are such, which I would expect, like the mount daemon) just refuse to start or, worse, start udev as a dependency?
I am really interested in that: can systemd be as flexible as the current system?
 
2 members found this post helpful.
Old 06-03-2013, 11:58 AM   #349
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,225

Rep: Reputation: 175Reputation: 175
...sorry...

Double post.

Last edited by jens; 06-03-2013 at 12:25 PM. Reason: Double post
 
Old 06-03-2013, 12:16 PM   #350
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,225

Rep: Reputation: 175Reputation: 175
Quote:
Originally Posted by TobiSGD View Post
And will the rest of systemd work coupled with mdev or hoptplug2? Or will the parts of systemd that are relying on a service like udev (if there are such, which I would expect, like the mount daemon) just refuse to start or, worse, start udev as a dependency?
I am really interested in that: can systemd be as flexible as the current system?
Sure.
You might not have all the advantages that come with systemd, but hey, you don't have those with plain sysv either ;-}

I've recently had to do something similar on a fedora system with both systemd and LXC (didn't work with sysd's udevd enabled).
Replace "disable" with "stop" if you want to do/try this on a running system without rebooting.

PS: ... again, at the end it's really just another (but imho better) init system.

Last edited by jens; 06-03-2013 at 01:12 PM.
 
Old 06-03-2013, 01:52 PM   #351
TracyTiger
Member
 
Registered: Apr 2011
Location: California, USA
Distribution: Slackware
Posts: 290

Rep: Reputation: 72
Politics & Religion

A mother addressing her family:

"We have guests coming over for dinner this evening. We want to have a pleasant conversation at the dinner table so remember, no discussing politics, religion, or systemd."
 
3 members found this post helpful.
Old 06-03-2013, 02:46 PM   #352
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 801

Rep: Reputation: 247Reputation: 247Reputation: 247
Quote:
Originally Posted by torimus View Post
@astrogeek, @Ser Olmy

Please, do not feed the troll. Thank you.
This brings to mind a certain Vincent Price movie (yes I'm that old) wherein a gourmand is force fed a banquet including his own pet poodles until he expires. The analogy fits systemd quite well. I would much rather have simpler more robust fare in portions suited to my needs.

I am a C/C++ programmer and also program in assembly language. Scripting languages exist because not all problems can be best solved using compiled programming languages. Scripting languages are designed to balance simplicity with flexibility and provide complex text parsing capabilities. Compiled programs are not always faster than scripting languages. A lot of that depends on the capabilities of the language and the programmer. I can say from experience that I am not expert at every kind of text parsing problem and that is what scripting languages do best. Were I to try and write something in C that I can easily write in a shell script the result might have horrible performance. I view writing scripts as writing programs using a different language. Scripting languages offer great benefits for testing and debugging. Making a change and testing the change requires much less time than recompiling a program and then running the program. Also, one can test individual scripts rather than the entire initialization system (program).

If even GRUB can make use of well established scripting language elements, why does systemd need its own, different way of defining behavior? If systemd needs to re-invent scripting and configuration languages, why does it not support changing all the behavior in the scripting languages? The answer seems obvious. Those working on systemd are not focused on making life easier for the people using systemd. They are making systemd easier for the programmers developing systemd. Those programmers are most familiar with C. This is a classic pitfall many inexperienced programmers encounter. One does not design the user interface and features around the software. One designs the software, user interface and features for the application. I am a firm believer in using established standards and precedents. If I'm designing an application and there is a well established way of doing things then I try to stay close to that. I try to add new functionality in a way that extends rather than replaces the established way of doing things.

How modular is systemd? How easy is it to test the initialization of one subsystem? How confident can one be that a test of one subsystem will catch problems when the entire system is initialized? Having "perfection" is not helpful if the process to achieve that "perfection" is laborious and unpredictable. A system administrator's job is to keep the system running and introduce necessary changes with as little down time as possible. It is much better to know that the system will successfully boot in 1 minute than to know that it might boot (or not) in 10 seconds.

In the words of my colleague, "Whats your hurry?". He was rather sarcastically putting things into perspective when asked to drastically redesign some software to only modestly reduce the execution time. Sometimes, the faster you go, the longer the trip takes. Because there are already good ways to initialize a Linux system, it will be necessary for systemd to prove itself. That means not only must systemd be faster, but more importantly it must be more reliable, more flexible, easier to use and better documented.

As a programmer who has worked for some large companies, I have seen the attitudes that programmers can develop in that environment. Many start to believe that users have no choice but to accept what the programmers choose to do. Some begin to believe that everything they do must be right because they are insulated from the end user's problems. The rude awakening comes when suddenly there aren't enough users to justify the programmer's job. Or, a programmer may do something on their own and discover that nobody is particularly enthralled with their work. The most difficult part of programming often isn't writing the software. It is understanding what the users want and need, then deciding how to best give them those things. Sometimes what the programmer wants to do, or what is easy to do, is not what the users really want and need.

Last edited by Erik_FL; 06-03-2013 at 02:50 PM.
 
8 members found this post helpful.
Old 06-03-2013, 03:05 PM   #353
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,225

Rep: Reputation: 175Reputation: 175
Quote:
Originally Posted by Erik_FL View Post

As a programmer who has worked for some large companies, I have seen the attitudes that programmers can develop in that environment. Many start to believe that users have no choice but to accept what the programmers choose to do. Some begin to believe that everything they do must be right because they are insulated from the end user's problems. The rude awakening comes when suddenly there aren't enough users to justify the programmer's job. Or, a programmer may do something on their own and discover that nobody is particularly enthralled with their work. The most difficult part of programming often isn't writing the software. It is understanding what the users want and need, then deciding how to best give them those things. Sometimes what the programmer wants to do, or what is easy to do, is not what the users really want and need.
True.
However ... I'm not that young either and I'm more annoyed with other programmers who simply refuse to accept anything new, just because that old stuff just happened to work for them.

Reality: Most users don't care about these things as long as it works for them.

Not saying systemd is perfect, but it did introduce some good things.
Even if you don't like it, do you really like sysv?

Last edited by jens; 06-03-2013 at 03:06 PM.
 
Old 06-03-2013, 04:15 PM   #354
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,614
Blog Entries: 2

Rep: Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070Reputation: 4070
Quote:
Originally Posted by jens View Post
Reality: Most users don't care about these things as long as it works for them.
The problem here is that we at this point do not know if these things work for them. This test will begin when RHEL 7 is deployed with systemd and all the admins in charge of RHEL or CentOS systems will be confronted with it. For now we have it only on desktop systems, AFAIK, and desktop users are far easier to convince with fast boot times and such stuff.
It may work out well for systemd, but we have not seen it working in professional environments yet.
 
1 members found this post helpful.
Old 06-03-2013, 07:08 PM   #355
ryanpcmcquen
Member
 
Registered: Apr 2013
Distribution: Slackware
Posts: 63

Rep: Reputation: Disabled
A musical analogy for systemd:

Systemd is the double-bass-drum pedal of the GNU/Linux world.

Sure, it's faster.

Sure, some great players use it.

But is it really better?

The kick drum is just one part of a band (an important integral part), but there is a lot more going on than just the kick drum. And if you are only concerned with being faster, are you really going to make "better" music? Will the band really benefit from you making more noise?

Sometimes, when you limit yourself, or use something that is more understandable and "simpler", you push yourself to realize things, and do things, you never would have. By limiting your tools, you can expand your perspective.
 
Old 06-03-2013, 07:40 PM   #356
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware
Posts: 218
Blog Entries: 13

Rep: Reputation: 151Reputation: 151
My new employers run a redhat shop, so I'll be getting to work with systemd first-hand. Half looking forward to the educational experience, half dreading the horror.
 
Old 06-03-2013, 08:04 PM   #357
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 2,019

Rep: Reputation: 785Reputation: 785Reputation: 785Reputation: 785Reputation: 785Reputation: 785Reputation: 785
Quote:
Originally Posted by ttk View Post
My new employers run a redhat shop, so I'll be getting to work with systemd first-hand. Half looking forward to the educational experience, half dreading the horror.
I'd be really interested in your first impressions and early experience, as I am sure others will be. Please post your comments as you think them useful to us Slackware Neanderthals!
 
Old 06-03-2013, 09:35 PM   #358
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,646
Blog Entries: 15

Rep: Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111
Quote:
Originally Posted by Erik_FL View Post
This brings to mind a certain Vincent Price movie (yes I'm that old) wherein a gourmand is force fed a banquet including his own pet poodles until he expires. The analogy fits systemd quite well. I would much rather have simpler more robust fare in portions suited to my needs.

I am a C/C++ programmer and also program in assembly language. Scripting languages exist because not all problems can be best solved using compiled programming languages. Scripting languages are designed to balance simplicity with flexibility and provide complex text parsing capabilities. Compiled programs are not always faster than scripting languages. A lot of that depends on the capabilities of the language and the programmer. I can say from experience that I am not expert at every kind of text parsing problem and that is what scripting languages do best. Were I to try and write something in C that I can easily write in a shell script the result might have horrible performance. I view writing scripts as writing programs using a different language. Scripting languages offer great benefits for testing and debugging. Making a change and testing the change requires much less time than recompiling a program and then running the program. Also, one can test individual scripts rather than the entire initialization system (program).

If even GRUB can make use of well established scripting language elements, why does systemd need its own, different way of defining behavior? If systemd needs to re-invent scripting and configuration languages, why does it not support changing all the behavior in the scripting languages? The answer seems obvious. Those working on systemd are not focused on making life easier for the people using systemd. They are making systemd easier for the programmers developing systemd. Those programmers are most familiar with C. This is a classic pitfall many inexperienced programmers encounter. One does not design the user interface and features around the software. One designs the software, user interface and features for the application. I am a firm believer in using established standards and precedents. If I'm designing an application and there is a well established way of doing things then I try to stay close to that. I try to add new functionality in a way that extends rather than replaces the established way of doing things.

How modular is systemd? How easy is it to test the initialization of one subsystem? How confident can one be that a test of one subsystem will catch problems when the entire system is initialized? Having "perfection" is not helpful if the process to achieve that "perfection" is laborious and unpredictable. A system administrator's job is to keep the system running and introduce necessary changes with as little down time as possible. It is much better to know that the system will successfully boot in 1 minute than to know that it might boot (or not) in 10 seconds.

In the words of my colleague, "Whats your hurry?". He was rather sarcastically putting things into perspective when asked to drastically redesign some software to only modestly reduce the execution time. Sometimes, the faster you go, the longer the trip takes. Because there are already good ways to initialize a Linux system, it will be necessary for systemd to prove itself. That means not only must systemd be faster, but more importantly it must be more reliable, more flexible, easier to use and better documented.

As a programmer who has worked for some large companies, I have seen the attitudes that programmers can develop in that environment. Many start to believe that users have no choice but to accept what the programmers choose to do. Some begin to believe that everything they do must be right because they are insulated from the end user's problems. The rude awakening comes when suddenly there aren't enough users to justify the programmer's job. Or, a programmer may do something on their own and discover that nobody is particularly enthralled with their work. The most difficult part of programming often isn't writing the software. It is understanding what the users want and need, then deciding how to best give them those things. Sometimes what the programmer wants to do, or what is easy to do, is not what the users really want and need.
Erik, you said a lifetime's worth.

I couldn't have said it any better or any more sanely.

My points highlighted in bold above as to why I feel that we admins are getting the shaft.

Truth be told, I'm glad I'm learning FreeBSD right now, as well as PC-BSD. It's a sad day when the Linux user wants to make things more difficult for the Linux admin, and even worse when a troll who has everything against not only the UNIX Philosophy, but also the Slackware mentality come in and try to say "GNU/Linux needs to be more like Windows". I only use Windows because I have to at work and at home for games, but the majority of the systems I administer are BSD or Linux based machines. If GNU/Linux becomes another Windows, then screw Linux.

No offense to Patrick for trying to keep some sanity within his own distribution, and more power to him if he ever can find a way to keep Slackware devoid of this trashware, but if needed, I will flush GNU/Linux straight down the toilet without prejudice, even if Slackware has to be flushed. Though it will at least be flushed with some honour.

Last edited by ReaperX7; 06-03-2013 at 09:38 PM.
 
Old 06-03-2013, 10:10 PM   #359
perbh
Member
 
Registered: May 2008
Location: Republic of Texas
Posts: 259

Rep: Reputation: 39
@Erik Fl,
Our backgrounds seems to be almost identical - however, your eloquence is far superior to mine.
I could not have said it any better no matter how hard I try - I bow to thee - well put!!!!
 
Old 06-04-2013, 12:16 AM   #360
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,646
Blog Entries: 15

Rep: Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111Reputation: 1111
In the world of the system and network administrator the term "faster booting" is meaningless when it comes to getting a system up and running. Real system and network administrators do have time limits to deal with, yes, but at the same time, we also have system and network stability and reliability to worry about. In short we have to work with a nearly failsafe system, and systemd is far from being failsafe.

This isn't a RonCo product where you can "set it and forget it". System and Networks require attention to detail and giving the maximum control to an administrator means sacrificing things like systemd in favor of administrator friendly init systems that rely on plaintext scripts that can be easily edited and quickly deployed for a service to be restarted by.

Let me make that clear...

User Friendly and Administrator Friendly are two entirely different terms.

In short the easier it is to edit and get working again, the faster your services come back online.

For us, Init systems like SysVInit, OpenRC, and BSDInit have been extremely reliable, because for the most part, they all use the same scripts in plaintext. I hate working with programming languages and the more complex you make a system, the longer it takes to get that system back online and working again. Having to generate a configuration file, then find out it was wrong, and now you have to re-generate it time and time again until you get it right... is ludicrous.

If at all on sysvinit and compatible systems, you can open a file in a text editor like nano, change a setting, save the work, and relaunch the service with a simple (for example as you would in Slackware) "/etc/rc.d/rc.samba restart" command in superuser mode, you've saved a hell of a lot of time, and eliminated a lot of overhead and problems from testing configuration files again and again to make sure it is right before you restart the service.

We system and network administrators could care less about how fast your system boots. This isn't a damn race, and we do not have time to play and jack around with C language code none of us understand nor are willing to understand. We aren't hackers with thumbs up our arses, nor do we care to be.

Systemd has no place in the enterprise IT world, and chances are, it never will unless the language shifts from using C programming language generated configuration files to simplistic plaintext scripts, and that isn't likely to happen.

Last edited by ReaperX7; 06-04-2013 at 12:18 AM.
 
3 members found this post helpful.
  


Closed Thread

Tags
cgroups


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: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 05:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 12:07 PM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 05:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 12:40 PM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 10:02 AM


All times are GMT -5. The time now is 03:25 AM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration