LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
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-01-2013, 08:36 AM   #136
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,335

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594

Quote:
Originally Posted by jtsn View Post
While most software is created to make things work, other software specifically is created to break things that work. The latter is called malware.
hear, hear!!

Quote:
If someone is trying to copy the services concept from Windows, he should copy it correctly. Windows services are able to work reliable even with parallel startup. The reason for this: MS actually had some smart people available for their OS design, while Red Hat clearly has not.
Not significantly - the major difference is in how a process is started. Linux uses a fork, followed by an exec. Windows uses the VMS approach which does both in one system call. It also makes it easier for the "parent" to know how far along the child process has gotten, and for more information than a simple exit code to be returned.

Quote:
So Fedora is broken. And a lot of Linux distributors copy them.
IMO, yes. It is definitely broken. The latest failure was that MariaDB wouldn't start properly when being started by systemd at boot (it just exited), yet it would start properly when manually started later. Did they fix systemd? Nope. butchered (my opinion) MariaDB. Likely the same "xxx wait-online" problem. (reference:
http://forums.fedoraforum.org/showthread.php?t=295518)

This just papers over the problem, it doesn't fix inherent design flaw.

Last edited by jpollard; 12-01-2013 at 08:41 AM. Reason: forgot the reference...
 
1 members found this post helpful.
Old 12-01-2013, 09:32 AM   #137
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,651
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
Quote:
Originally Posted by 55020 View Post
I guess we should remember that this is the constructive, positive systemd thread ... even if I agree with the points being made and admire the people making them...
Indeed, let's get back on topic. Systemd has its flaws, but let us discuss those in a different thread.
 
1 members found this post helpful.
Old 12-02-2013, 03:02 AM   #138
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 272

Original Poster
Rep: Reputation: 93
This thread is ment for the persons who would like to test/play with systemd on slackware.
But instead of saying systemd sucks etc. we as slackware community are able to make sure that the problems that systemd has gets solved upstream.

Dont get me wrong, there are thing I like and dislike about systemd.
The facts are as follows:

- Red Hat is behind systemd and will use it in their RHEL versions.
- systemd is 1 of the most active open-source project at the moment.
- most software is written with redhat or ubuntu/debian systems compatibility

With the above facts in mind, its almost certain to say that systemd is here to stay.
If and when pat decides to switch to systemd, it would be good that the we have already systemd working.

- It makes it easier for PAT & CO, for transition
- We might have found/reported bugs to solve issue related with slackware & systemd.
 
1 members found this post helpful.
Old 12-02-2013, 05:17 AM   #139
genss
Member
 
Registered: Nov 2013
Posts: 361

Rep: Reputation: Disabled
debian is the most popular server distro by far
ubuntu the most popular desktop distro
funny enough according to linux counter on desktops fedora has 7.33% while slackware holds 6.37%
http://w3techs.com/technologies/deta...-linux/all/all
http://linuxcounter.net/distributions.html

and ofc it is so active since it has much to do to integrate itself into everything and everything into itself

also; afaik RHEL wont have systemD in the next release and RHEL people stated they have not much to do with fedora people



i like what you are doing and might change my mind on systemd some day in the distant future
just dont be like other systemd fanboys and tell facts that dont really matter (or in many cases are plain wrong, not in yours thou as far as i can tell)
(like on-demand daemon starting; when you look at it objectively it is useless)
personally i dont like its design (a layer instead of fixing things) and want to punch its creator for being a lying ass
but that is my personal opinion

about the thread:
good work bart
i learned some about systemd here that i wouldnt elsewhere
keep up the good job

Last edited by genss; 12-02-2013 at 05:33 AM.
 
Old 12-02-2013, 05:57 AM   #140
GazL
Senior Member
 
Registered: May 2008
Posts: 3,502

Rep: Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024
Please, lets keep this thread "How to..." and leave advocacy, opposition, and prophecy for elsewhere.
 
5 members found this post helpful.
Old 12-02-2013, 06:09 AM   #141
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,335

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
Quote:
Originally Posted by bartgymnast View Post
This thread is ment for the persons who would like to test/play with systemd on slackware.
But instead of saying systemd sucks etc. we as slackware community are able to make sure that the problems that systemd has gets solved upstream.
Considering that the developers are ignoring significant failures even on the system it is used for, they are unlikely to accept any fixes from anyone else.
Quote:
Dont get me wrong, there are thing I like and dislike about systemd.
The facts are as follows:

- Red Hat is behind systemd and will use it in their RHEL versions.
Only if it works.
Quote:
- systemd is 1 of the most active open-source project at the moment.
arguable - but it is active only because it doesn't fundamentally work
Quote:
- most software is written with redhat or ubuntu/debian systems compatibility
false.
Most software is written for AIX, BSD, Windows, and the UNIX systems. The fact that it also runs on Linux has been because of the compatibility with the UNIX systems.
Quote:

With the above facts in mind, its almost certain to say that systemd is here to stay.
Some form of it MAY be around - but its current configuration is very buggy, unreliable, and not easily fixed - and any actual fixes defeat the purpose of systemd.
Quote:
If and when pat decides to switch to systemd, it would be good that the we have already systemd working.

- It makes it easier for PAT & CO, for transition
- We might have found/reported bugs to solve issue related with slackware & systemd.
So far, the developers have been ignoring whether it works for any system, security issues have been ignored, suggested workarounds have been ignored, and most get dismissed as "not our problem". IF it worked, it would be easy to substitute. Unfortunately, it is so intrusive into all aspects of the system that it isn't easy to use even on the system it is "designed for".

I do think it is an interesting experiment, the parallel startup would be very useful. Unfortunately the network of dependencies this particular implementation uses makes it unworkable. A number of people using it have resorted to even putting filesystem mounts into rc.local just to be able force the proper ordering of startup processes. Which mostly works... the remaining problem is that it seems rc.local gets run before the system seems to be completely ready for it, so even then some people have been putting sleeps in it to get things working.

It does seem to work in relatively simple startup environments (such as a desktop with only one network, and a single filesystem mount). It starts having trouble when things get more complex. The latest round of "fixes" has even removed swap from being mounted from the fstab file after mounting root - mounting swap got moved into the initrd. (I've wondered why, unless the processes mounting it didn't get run soon enough).

The problem that causes is that the initrd must be rebuilt if you change your swap configuration (the system crashes if you don't - it turns out that the /etc/fstab file got copied into the initrd. Right now only root and swap are mandated, previously neither were required, with root specified on the grub kernel command line - where root was easy to handle). Of course this would impact how Slackware would get booted...

Can it be coerced into working? yes - but only by defeating the purpose of systemd.

One of the nicest things with systemd is the interface to enable/disable/start/stop services. Unfortunately, that damages the web of dependencies - adding a single service causes things to be reordered in startup (mostly due to the thundering herd scheduling), and that exposes more failures in the dependency web. And in any such web, removing a service also reorders things causing yet more failures.

If RH has any sense, they will test it, and refuse to use it in its present form, just as they refused to use Gnome 3 in its form (the developers are redoing a lot of work to present a "Classic" capability).

One thing that could improve the situation a lot is to do the same type of thing Pat did with the sysVinit - The current Slackware startup is more BSD than it is SysVinit, yet the SysVinit capability is completely present - with full ordering capability. The thing in systemd isn't (services started there still seem to get out of order somehow, though it may be with things outside of the SysVinit control).
 
1 members found this post helpful.
Old 12-02-2013, 06:40 AM   #142
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 434
Blog Entries: 4

Rep: Reputation: 438Reputation: 438Reputation: 438Reputation: 438Reputation: 438
Quote:
Originally Posted by jpollard View Post
Can it be coerced into working? yes - but only by defeating the purpose of systemd.
That would be the perfect outcome! So let's encourage bartgymnast to get on with it, shall we?

Last edited by 55020; 12-02-2013 at 06:42 AM. Reason: It's always good to find the right word -- even after pressing 'Post' ;-)
 
1 members found this post helpful.
Old 12-02-2013, 06:53 AM   #143
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by jpollard View Post
Considering that the developers are ignoring significant failures even on the system it is used for, they are unlikely to accept any fixes from anyone else.

Only if it works.

arguable - but it is active only because it doesn't fundamentally work

false.
Most software is written for AIX, BSD, Windows, and the UNIX systems. The fact that it also runs on Linux has been because of the compatibility with the UNIX systems.

Some form of it MAY be around - but its current configuration is very buggy, unreliable, and not easily fixed - and any actual fixes defeat the purpose of systemd.


So far, the developers have been ignoring whether it works for any system, security issues have been ignored, suggested workarounds have been ignored, and most get dismissed as "not our problem". IF it worked, it would be easy to substitute. Unfortunately, it is so intrusive into all aspects of the system that it isn't easy to use even on the system it is "designed for".

I do think it is an interesting experiment, the parallel startup would be very useful. Unfortunately the network of dependencies this particular implementation uses makes it unworkable. A number of people using it have resorted to even putting filesystem mounts into rc.local just to be able force the proper ordering of startup processes. Which mostly works... the remaining problem is that it seems rc.local gets run before the system seems to be completely ready for it, so even then some people have been putting sleeps in it to get things working.

It does seem to work in relatively simple startup environments (such as a desktop with only one network, and a single filesystem mount). It starts having trouble when things get more complex. The latest round of "fixes" has even removed swap from being mounted from the fstab file after mounting root - mounting swap got moved into the initrd. (I've wondered why, unless the processes mounting it didn't get run soon enough).

The problem that causes is that the initrd must be rebuilt if you change your swap configuration (the system crashes if you don't - it turns out that the /etc/fstab file got copied into the initrd. Right now only root and swap are mandated, previously neither were required, with root specified on the grub kernel command line - where root was easy to handle). Of course this would impact how Slackware would get booted...

Can it be coerced into working? yes - but only by defeating the purpose of systemd.

One of the nicest things with systemd is the interface to enable/disable/start/stop services. Unfortunately, that damages the web of dependencies - adding a single service causes things to be reordered in startup (mostly due to the thundering herd scheduling), and that exposes more failures in the dependency web. And in any such web, removing a service also reorders things causing yet more failures.

If RH has any sense, they will test it, and refuse to use it in its present form, just as they refused to use Gnome 3 in its form (the developers are redoing a lot of work to present a "Classic" capability).

One thing that could improve the situation a lot is to do the same type of thing Pat did with the sysVinit - The current Slackware startup is more BSD than it is SysVinit, yet the SysVinit capability is completely present - with full ordering capability. The thing in systemd isn't (services started there still seem to get out of order somehow, though it may be with things outside of the SysVinit control).
Being slow today, I can't understand how your glorious speech can help the OP top successfully port/build a functional SystemD under Slackware.

My bet is that you are missed the right room. There is the engineering room, but you are trying to find the lawyers room, which is next on right...
 
Old 12-02-2013, 07:50 AM   #144
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,335

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
Quote:
Originally Posted by Darth Vader View Post
Being slow today, I can't understand how your glorious speech can help the OP top successfully port/build a functional SystemD under Slackware.
The key word is "functional". It isn't even functional now.

Porting it is relatively trivial - but to make system actually work means you have defeat the design, which makes it nearly useless. To make it reliable requires every service file (most of them anyway) to be forced into a proper ordering. Of course, that defeats the purpose. It also becomes fragile because optional services become problematical - which can be worked around... but only by creating additional control points in the dependency network that isolate the service.
Quote:
My bet is that you are missed the right room. There is the engineering room, but you are trying to find the lawyers room, which is next on right...
Don't need the lawyers room - the problem is a technical nightmare.
 
Old 12-02-2013, 09:14 AM   #145
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 907

Rep: Reputation: 446Reputation: 446Reputation: 446Reputation: 446Reputation: 446
Quote:
Originally Posted by jpollard View Post
Not significantly - the major difference is in how a process is started. Linux uses a fork, followed by an exec. Windows uses the VMS approach which does both in one system call. It also makes it easier for the "parent" to know how far along the child process has gotten, and for more information than a simple exit code to be returned.
The Windows services framework does a little bit more than just a CreateProcessEx() and waiting the call to succeed. The first thing is that you can't have a regular executable be a "service". Services specifically have a ServiceMain() callback, which then registers another callback using RegisterServiceCtrlHandlerEx() and then calls StartServiceCtrlDispatcher(). It will then be steered by the Service Control Manager using a control connection. BTW: Windows drivers are services, too...

The main point is: Windows has a well-defined API and its services are designed specifically around it. The SCM always knows what a service is doing and how to change its state. Systemd now takes our traditional unix daemons, tries to emulate that and fails miserably, because the API isn't just there. And their "solution" to this mess is, of course, that every damn unix daemon of the last 30 years should to be redesigned for systemd, using D-Bus for "service control".
 
2 members found this post helpful.
Old 12-02-2013, 09:50 AM   #146
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by jtsn View Post
The main point is: Windows has a well-defined API and its services are designed specifically around it. The SCM always knows what a service is doing and how to change its state. Systemd now takes our traditional unix daemons, tries to emulate that and fails miserably, because the API isn't just there. And their "solution" to this mess is, of course, that every damn unix daemon of the last 30 years should to be redesigned for systemd, using D-Bus for "service control".
Yes, that's the point. Windows have a well-defined API, Linux not. Every Linux service will do it in its frakking personal way. But, if I remember right, there are talks about including D-Bus services even at kernel level, right for "service control".

We should expect a new wave of standardization on Linux World, and D-Bus will be its messenger.

Now, with all respect, I will implore my Slackware colleagues to do their frakking academic speech about how stupid is SystemD, in another thread, at their choice.



This thread is about SystemD's frakking Slackbuilds, not about academic speeches about how stupid is SystemD!


What part of this phrase you don't understand?

Last edited by Darth Vader; 12-02-2013 at 09:59 AM.
 
Old 12-02-2013, 12:13 PM   #147
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,335

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
Quote:
Originally Posted by Darth Vader View Post
Yes, that's the point. Windows have a well-defined API, Linux not. Every Linux service will do it in its frakking personal way. But, if I remember right, there are talks about including D-Bus services even at kernel level, right for "service control".
Linux has had a VERY well defined API. One defined for far longer than Windows has ever existed. It also works EXTREMELY well. Unlike Windows. And "its ... personal way" happens to be the same for all standard services. initialize reporting any problems. detach from controlling terminal (requires a fork). Parent process takes normal exit.

Last I hear about Dbus and the kernel was that it got dropped because of all the user mode destruction it causes. Trying to turn Linux into Windows is not the way to go.
Quote:

We should expect a new wave of standardization on Linux World, and D-Bus will be its messenger.

Now, with all respect, I will implore my Slackware colleagues to do their frakking academic speech about how stupid is SystemD, in another thread, at their choice.



This thread is about SystemD's frakking Slackbuilds, not about academic speeches about how stupid is SystemD!


What part of this phrase you don't understand?
It IS about what doesn't work. Sure systemd can be put on Slackware... but with all the required changes to Slackware it won't be Slackware anymore. It might look like Fedora. And be about as stable.
 
4 members found this post helpful.
Old 12-02-2013, 12:53 PM   #148
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,651
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
Quote:
Originally Posted by jpollard View Post
It IS about what doesn't work.
You are talking about what does not work with systemd in general. That is not the topic of this thread, the topic here is: How to make systemd available for Slackware.
Technical discussions about systemd in general and philosophical discussions if it would be Slackware when running on systemd should go into a different thread, not this one.
 
2 members found this post helpful.
Old 12-02-2013, 05:38 PM   #149
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,833
Blog Entries: 15

Rep: Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187
We've, at least for now, never once actually trashed and bashed directly on Lennart and systemd in this thread. We've been pointing out the more than obvious flaws that are the main issues that will affect it's implementation on any system, including Slackware, and why at the moment, there are other alternatives that could and/or should be considered at the moment until upstream issues can be resolved, if they ever will be resolved.

The issue we're asking is now that we know the obvious problems, where do we go from here?

Do we:

A) Keep working on the Slackbuild until upstream repairs the issues?

B) Abandon the SlackBuild and search for an alternative?

C) Implement maintenance mode while searching for a viable alternative?

D) Abandon it altogether and stick with doing nothing?

Last edited by ReaperX7; 12-02-2013 at 05:41 PM.
 
Old 12-02-2013, 08:22 PM   #150
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,575

Rep: Reputation: 466Reputation: 466Reputation: 466Reputation: 466Reputation: 466
E) Talk about it on another thread.
 
3 members found this post helpful.
  


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