LinuxQuestions.org
Visit the LQ Articles and Editorials section
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 12-02-2013, 07:31 PM   #151
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 387
Blog Entries: 4

Rep: Reputation: 367Reputation: 367Reputation: 367Reputation: 367

Quote:
Originally Posted by ReaperX7 View Post
The issue we're asking is now that we know the obvious problems, where do we go from here?
We don't all have to go anywhere together. We can watch bartgymnast going somewhere alone, so long as we don't piss him off with negativity.

We should bear in mind this famous sentence: "Slackware is well known for its simplicity and the fact that we try to bring software to you in the condition that the authors intended." If that condition is broken-by-design, then it should be broken-by-design in Slackware. Plenty of software is broken-by-design. Observing the world outside Slackware, most people seem to prefer their software that way, or maybe they just have low standards. *shrug*
 
3 members found this post helpful.
Old 12-02-2013, 08:12 PM   #152
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0
Posts: 3,388
Blog Entries: 15

Rep: Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945
Broken-by-design should have no place in a working stable system like Slackware that has one of it's prides as stability, especially if it's a system critical service daemon.

I think for now, we know how it works, how well it will work, and what else is going to have to be done to achieve a working system using this software.

Sadly, yes low-standards are what fuels the world today, and software sadly is not immune to this trend. It's the fact that distributions like Slackware, LFS, and others strive for higher standards, they get singled out and ridiculed for doing so. However, as we all do see, when higher standards continue onward, people see those as a point of interest and try out the higher standard stuff, and they find it is better.
 
1 members found this post helpful.
Old 12-02-2013, 09:21 PM   #153
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by ReaperX7 View Post
Broken-by-design should have no place in a working stable system like Slackware that has one of it's prides as stability, especially if it's a system critical service daemon.
Correct. That is why systemd hasn't replaced SysV init in Slackware yet. But this thread is about the effort of a third party, trying to implement systemd in Slackware. If you think that this effort shouldn't be done then just stop contributing. If you want to try to port a different init system to Slackware then go ahead, start a new thread about that and just do it.
 
2 members found this post helpful.
Old 12-02-2013, 09:59 PM   #154
larrybpsu
LQ Newbie
 
Registered: Oct 2005
Location: Uniontown PA, USA
Distribution: Slackware
Posts: 25

Rep: Reputation: 7
Quote:
Originally Posted by 55020 View Post
Plenty of software is broken-by-design. Observing the world outside Slackware, most people seem to prefer their software that way, or maybe they just have low standards. *shrug*
Inspiring. There's a Mark Minasi book about 'bad software.' "The Software Conspiracy" A very good read. Google it. It's downloadable.

Most folks DON'T have the ability to make things different and just go with the flow. That could also be interpreted as 'low standards.'

Us Slack folk most likely do NOT fit into that category.
 
2 members found this post helpful.
Old 12-03-2013, 02:24 AM   #155
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 621

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by jpollard View Post
... but with all the required changes to Slackware it won't be Slackware anymore. It might look like Fedora. And be about as stable.
At least, Fedora (at whatever said version) is able to self build without supplementary changing/patching of its sources. Slackware is not capable to self build, out of box, like I believe you known...
 
Old 12-03-2013, 02:26 AM   #156
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 621

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by 55020 View Post
We don't all have to go anywhere together. We can watch bartgymnast going somewhere alone, so long as we don't piss him off with negativity.
That's the point! The guy on horse who try to catch the bull is him, we... we only watch the show with a beer in hand.

Last edited by Darth Vader; 12-03-2013 at 02:34 AM.
 
Old 12-03-2013, 02:31 AM   #157
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 621

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by ReaperX7 View Post
Broken-by-design should have no place in a working stable system like Slackware that has one of it's prides as stability, especially if it's a system critical service daemon.
Being older than the dirt, I remember the hungry speeches against adoption of UDEV, right there, in this forum. And how it limit your ability to configure your devices. And even I remember that someone invoked that popping up devices can be considered a security threat wich can NOT be tolerated in the so stable and secure Slackware.

Still, yet, right now, Slackware use UDEV by default...

Last edited by Darth Vader; 12-03-2013 at 02:40 AM.
 
Old 12-03-2013, 02:33 AM   #158
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 621

Rep: Reputation: 114Reputation: 114
Finally, to be on topic, ... finally!

I work at a patch to make SystemD to work directly with the shadow thing.

Not being a die-hard SystemD lover, but trying to sustain the Bart's wonderful work.

And yes, I have now a Slackware with SystemD init (without PAM) which work like a charm. And boot faster.

Last edited by Darth Vader; 12-03-2013 at 02:44 AM.
 
Old 12-03-2013, 04:50 AM   #159
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,234

Rep: Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577
Quote:
Originally Posted by Darth Vader View Post
Being older than the dirt, I remember the hungry speeches against adoption of UDEV, right there, in this forum. And how it limit your ability to configure your devices. And even I remember that someone invoked that popping up devices can be considered a security threat wich can NOT be tolerated in the so stable and secure Slackware.

Still, yet, right now, Slackware use UDEV by default...
And it isn't mandatory to use it either. If it aborts, the system continues functioning...

The version now in systemd doesn't. Because of the interdependencies it is just as likely to crash the system if it aborts. It does crash the system if dbus aborts...

I would have a LOT less heartburn over systemd if it stayed away from the core init functions of getting the system started. Some of the features are quite nice and would be very useful - the process monitoring is interesting though I don't care for the specific implementation (too error prone - this is what forces all the changes into all the services and causes some of the startup/shutdown problems). The interference with logging I can do without (that was done because it lost log events, I also don't like binary logs - impossible to read during recovery unless you have a nearly full installation from a different boot device).
 
Old 12-03-2013, 06:40 AM   #160
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 621

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by jpollard View Post
I would have a LOT less heartburn over systemd if it stayed away from the core init functions of getting the system started.
I feel like being someone that tell the truth about Santa Claus...

Well, SystemD is just a INIT system. Of course that it replace the orthodox init functions. Because that is his nature. The reason to exist. You want the turkey cooked and be still alive?

On topic:

Bart, how is the now the level of working of Network Manager under your SystemD? I want to test that thing, and to known possible problems...
 
1 members found this post helpful.
Old 12-03-2013, 07:47 AM   #161
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 261

Original Poster
Rep: Reputation: 87
you can read the logs with a live CD (the live CD needs to have systemd tho)

Here is a video explaining some things. (yes lennart is speaking)

https://access.redhat.com/site/videos/403833

This video is explaining things you might not know.

@Darth-Vader: on the wiki you can see how to build systemd without pam (and yes this does require shadow at least to be build)
Network-Manager is working fine, you just need to make sure inet1.service is disabled.

I am abit busy at the office this week, so hopefully I can continue this weekend.

Last edited by bartgymnast; 12-03-2013 at 07:48 AM.
 
1 members found this post helpful.
Old 12-03-2013, 08:26 AM   #162
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,234

Rep: Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577
Quote:
Originally Posted by Darth Vader View Post
I feel like being someone that tell the truth about Santa Claus...

Well, SystemD is just a INIT system. Of course that it replace the orthodox init functions. Because that is his nature. The reason to exist. You want the turkey cooked and be still alive?
That is the problem. It isn't just an init system. It also attempts to be a dependency web sorting solver. And a process monitoring solution. And a network monitoring solution. And a system log solution.

Had these additional functions been implemented separately from init (quite possible) and from each other, there wouldn't be a problem - the parts that don't work could be easily replaced or substituted. Instead, it takes a NP hard problem (web dependency sorting) and mashes it into process/network monitoring and logging... Making the entire thing a mess. Any part fails and the system crashes. Or hangs (I think it causes a livelock, but can't get the system to respond when it happens).

As for boot speed, I have two VMs, one running Fedora 19, one running Slakware. The slackware VM boots faster.
 
Old 12-03-2013, 10:46 AM   #163
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by jpollard View Post
That is the problem. It isn't just an init system. It also attempts to be a dependency web sorting solver. And a process monitoring solution. And a network monitoring solution. And a system log solution.

Had these additional functions been implemented separately from init (quite possible) and from each other, there wouldn't be a problem - the parts that don't work could be easily replaced or substituted. Instead, it takes a NP hard problem (web dependency sorting) and mashes it into process/network monitoring and logging... Making the entire thing a mess. Any part fails and the system crashes. Or hangs (I think it causes a livelock, but can't get the system to respond when it happens).

As for boot speed, I have two VMs, one running Fedora 19, one running Slakware. The slackware VM boots faster.
Again, this thread is NOT about problems that you see in systemd in general, this thread is about porting systemd to Slackware. Please keep this thread on topic.
 
2 members found this post helpful.
Old 12-03-2013, 03:22 PM   #164
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 621

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by bartgymnast View Post
@Darth-Vader: on the wiki you can see how to build systemd without pam (and yes this does require shadow at least to be build)
Network-Manager is working fine, you just need to make sure inet1.service is disabled.

I am abit busy at the office this week, so hopefully I can continue this weekend.
I have right now a machine with your SystemD (built without PAM support). And it works fine.

But, I do not, yet, make support per SystemD for NetworkManager. That was the question. If I should expect eventually problems after activating the support for SystemD into NetworkManager...
 
Old 12-03-2013, 03:23 PM   #165
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0
Posts: 3,388
Blog Entries: 15

Rep: Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945Reputation: 945
Quote:
Originally Posted by TobiSGD View Post
Again, this thread is NOT about problems that you see in systemd in general, this thread is about porting systemd to Slackware. Please keep this thread on topic.
With a new never-before attempted port there are going to be issues that are unresolved or problematic. Best we put our cards on the table now before we ante up.

Quote:
Originally Posted by Darth Vader View Post
At least, Fedora (at whatever said version) is able to self build without supplementary changing/patching of its sources. Slackware is not capable to self build, out of box, like I believe you known...
Actually someone recently did audit the code of Slackware with it's current code and patch set and with only a few minor fixes, Slackware was able to rebuild against itself. Fedora has just about as many if not more patches than Slackware does.

Last edited by ReaperX7; 12-03-2013 at 03:29 PM.
 
  


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



All times are GMT -5. The time now is 10:34 PM.

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