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

Reply
 
Search this Thread
Old 05-09-2014, 08:02 AM   #16
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,170

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534

Quote:
Originally Posted by GazL View Post
Anyway, lets cross this bridge when we get to it.
Exactly. We have an excellent development team that is charting our course. Life is too short to fixate on what might be.
 
Old 05-09-2014, 08:12 AM   #17
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,494

Rep: Reputation: 437Reputation: 437Reputation: 437Reputation: 437Reputation: 437
Quote:
Originally Posted by genss View Post
why do people believe that making something like an init system or udev or whatever is hard ?
Because it's a difficult problem to correctly and consistently handle asynchronous events in a multi-threaded/multi-core system.

If your system's configuration never changes after you start it, then, yeah, you find the order of initialization of "stuff" that works for that system and you're good until something changes (replace the drives with faster ones so the timing of events change and so on).

The upstart documentation talks about the pros and cons for various init systems.
 
1 members found this post helpful.
Old 05-09-2014, 08:20 AM   #18
genss
Member
 
Registered: Nov 2013
Posts: 190

Rep: Reputation: Disabled
Quote:
Originally Posted by Richard Cranium View Post
Because it's a difficult problem to correctly and consistently handle asynchronous events in a multi-threaded/multi-core system.

The upstart documentation talks about the pros and cons for various init systems.
i'm guessing you are talking about an init
i'l also guess you are thinking about dependencies between services

it's not that hard, you just make a dependency tree like bout systemd and upstart do
you can even get events from the kernel to track processes
and even go so far as to pre-load whatever is coming up (that none do)
it should not be that hard
 
1 members found this post helpful.
Old 05-09-2014, 10:05 AM   #19
dunric
Member
 
Registered: Jul 2004
Distribution: Slackware
Posts: 450

Rep: Reputation: 56
I'd welcome some blend of Slackware with OpenBSD as best representatives of both worlds. I see no reason to count in only eudev, upstart & similar not-yet-mature alternatives to systemd. Find BSD init system still enough for current demands, even Slackware's way of SysV-init with BSD-like init scripts. Even CGroups won't require systemd to initialize. One of the most common logical delusions - limited options aka "false dilemma".

Last edited by dunric; 05-09-2014 at 10:06 AM.
 
1 members found this post helpful.
Old 05-09-2014, 10:36 AM   #20
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 2,557
Blog Entries: 3

Rep: Reputation: 215Reputation: 215Reputation: 215
Quote:
SystemD status on next/future Slackware
Have you ever Google Patrick work on the init. Have you ever taken time to see his accomplishments And his contributions to the rc.sysvinit.
Look Pat has been maintaining the init for a long time. It is not about the init it is about if software developers like Gnome are going
to make it a dependency because they are to lazy to maintain there own work.

Linus Travolds has made it clear systemd is not about the kernel and leaves it up to the O/S developers and maintainers to do there own thing.
Pat has been very clear on this matter. His last words are I do not see happening to Slackware.

there are many programs that can use pulse audio and make it a dependency but do you see that in Slackware no.

In all truth if systemd would do what they would like it to do or their wish list or mission statement it would be nice.

Just remember the world is not flat. and it is not perfectly round. And far less stable then Slackware. So join the church and get your slack back.
 
2 members found this post helpful.
Old 05-09-2014, 10:48 AM   #21
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,494

Rep: Reputation: 437Reputation: 437Reputation: 437Reputation: 437Reputation: 437
Quote:
Originally Posted by genss View Post
i'm guessing you are talking about an init
i'l also guess you are thinking about dependencies between services

it's not that hard, you just make a dependency tree like bout systemd and upstart do
you can even get events from the kernel to track processes
and even go so far as to pre-load whatever is coming up (that none do)
it should not be that hard
I'm guessing that you didn't bother to read the link.
 
Old 05-09-2014, 11:19 AM   #22
genss
Member
 
Registered: Nov 2013
Posts: 190

Rep: Reputation: Disabled
Quote:
Originally Posted by Richard Cranium View Post
I'm guessing that you didn't bother to read the link.
i did...
first, "If your system's configuration never changes after you start it, then, yeah, you find the order of initialization of "stuff" that works for that system and you're good until something changes (replace the drives with faster ones so the timing of events change and so on)."

so you pointed for me to read
"However, consider how such a system would approach the problem of dealing with a user who plugs in an external monitor. Maybe we'd like our system to display some sort of configuration dialogue so the user can choose how they want to use their new monitor in combination with their existing laptop display. This can only be "hacked" with a dependency-based init system since you do not know when the new screen will be plugged."

that i already covered partially with
"you can even get events from the kernel to track processes"
s/processes/events/

anyway this has not much with init, unless you make init an arbitrator too instead of just being an init
even better arbitrator would be a daemon, like udev, that gets those events and runs whatever (like udev)
it can even track processes like daemons without being pid 1 (low overhead with ptrace over netlink, can even be mmaped afaik)

control over a running system should be, if you ask me, separated from starting that system
(starting being configuring a state machine(the kernel) and running a couple processes)
yet people think it has to be one and the same
 
1 members found this post helpful.
Old 05-09-2014, 01:26 PM   #23
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0
Posts: 3,197
Blog Entries: 15

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
ConsoleKit and PolicyKit are still the default support on desktop environments and are the segregated stand-alones of their systemd counterparts. They were only deprecated by their maintainers who wanted to force the issue of systemd. That argument on their deprecation has never held water.

As far as BSDinit/SysVinit, yes there are some flaws, but to be honest, those flaws are POV only. Other than that sysvinit and bsdinit are foolproof except to people who are shell-scripting-challenged. Even Init systems like s6 and Runit use shell scripts with basic command structures equal to, similar, and derived from SysV and BSD init scripts. While the "hack" they mention to load daemons in parallel is crude, the fact of the matter is, it works, and if you script properly you can use dependency trees in parallel with linear loading per branch and have the same functionality. Runit, s6, and OpenRC do just that. That's technically not even a hack, but proper scripting methods that any knowledgable system administrator worth their salt learns in CompTIA Linux+ classes.
 
1 members found this post helpful.
Old 05-09-2014, 04:04 PM   #24
jprzybylski
Member
 
Registered: Apr 2011
Location: Canada
Distribution: Slackware
Posts: 98

Rep: Reputation: 23
I didn't feel like posting in another systemd thread, but I felt that something was warranted:

When I read about systemd, I feel that it has a particular target - Linux as an application. When I look at other new developments in its class, I see things like cgroups, btrfs, openstack support, xen and kvm, and a ton of other projects. When I look at them all together, they seem like they are heading towards massive virtualization, to the point that the operating system is, top to bottom, made to be run as an application. I'm not certain why traditional init would hamper that, exactly, but I can see why systemd and CoreOS would help.

This doesn't mean that we need to use software that insists on systemd. It doesn't make sense that software would depend on systemd at all, aside from some enterprise bits. Even if the entirety of the Linux community decided to jump on the CoreOS ship, the BSDs, Apple and Microsoft would still exist, and still hold market share.

I prefer the UNIX ways of small tools passing messages through pipes and scripts, so I prefer sysvinit. Then again, I don't regularly deploy thousands of Linux servers, so I've never dealt with the kind of problems I bet CoreOS is made to tackle. In any case, I trust Pat's judgement - it is far more experienced than mine.

Just my two cents.

PS. I just went to the CoreOS website, and the title of the page is "CoreOS is Linux for Massive Server Deployments". Boy, do I feel like a weenie now.
 
Old 05-09-2014, 08:32 PM   #25
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,494

Rep: Reputation: 437Reputation: 437Reputation: 437Reputation: 437Reputation: 437
Quote:
Originally Posted by ReaperX7 View Post
As far as BSDinit/SysVinit, yes there are some flaws, but to be honest, those flaws are POV only. Other than that sysvinit and bsdinit are foolproof except to people who are shell-scripting-challenged. Even Init systems like s6 and Runit use shell scripts with basic command structures equal to, similar, and derived from SysV and BSD init scripts. While the "hack" they mention to load daemons in parallel is crude, the fact of the matter is, it works, and if you script properly you can use dependency trees in parallel with linear loading per branch and have the same functionality. Runit, s6, and OpenRC do just that. That's technically not even a hack, but proper scripting methods that any knowledgable system administrator worth their salt learns in CompTIA Linux+ classes.
Did they learn how to easily have something "watchdog" their services in the same class? Why isn't that in the framework already if it *is* so easy?
 
Old 05-13-2014, 02:16 PM   #26
mattallmill
Member
 
Registered: Nov 2009
Location: Salina,Kansas
Distribution: Slackware64-current
Posts: 203

Rep: Reputation: 31
Here's another quote on /. in reply to your "dweeb":
Quote:

Systemd is not the only choice GNU/Linux has. Just because systemd is a Red Hat funded project, and is being adopted by the mainstream distributions, doesn't mean it's the only choice. Small, unfounded, and non-mainstream software also exists that is available but isn't widely used because any number of reasons.

Over at LinuxQuestions several guys have been experimenting with finally getting a full port of Gerrit Pape's Runit init and daemon manager ready for mainstream usage alongside Eudev which they completed work on a while ago, and was actually published in the LFS-Dev book.

These guys are just users and system admins who, from reading their work, are sick of the hype, lies, and misinformation surrounding the fanboyism and propaganda being promoted by the pro-systemd crowd, and honestly, who can blame them? But these guys are making a difference by actually trying something different.

It's sad only three people are even working on the Runit effort for LFS as a complete fully featured and functional alternative and successor to sysvinit. LFS software can be fully transported out into any Linux distribution. Maybe if they had more help, systemd would be just another alternative, but I guess people are willing to drink the koolaid no matter how much poison it contains.
I think that pretty much sums up the issue, and does so quite nicely. Nothing more needs to be said on the issue, IMHO.
 
1 members found this post helpful.
Old 05-13-2014, 04:25 PM   #27
briselec
Member
 
Registered: Jun 2013
Location: Ipswich, Australia
Distribution: Slackware
Posts: 32

Rep: Reputation: Disabled
Quote:
Originally Posted by genss View Post
why do people believe that making something like an init system or udev or whatever is hard ?
A nice example of how to write an init system
Demystifying the init system
 
2 members found this post helpful.
Old 05-13-2014, 04:32 PM   #28
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,245

Rep: Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044Reputation: 1044
Quote:
Originally Posted by genss View Post
why do people believe that making something like an init system or udev or whatever is hard ?
Because they actually did, or at least tried
 
2 members found this post helpful.
Old 05-13-2014, 05:23 PM   #29
genss
Member
 
Registered: Nov 2013
Posts: 190

Rep: Reputation: Disabled
Quote:
Originally Posted by Didier Spaier View Post
Because they actually did, or at least tried
biggest problem i had when writing a shell was learning ioctl (so backspace would work)
looking at rc.S/M, a basic shell is not far from a full init

setting environment variables is patching the environment variable (just a long string)

starting things is fork + exec + however you want to deal with the child (usually wait)
k first you have to tokenize the arguments you start it with (that is make argv and argc; environ pointer is also there somewhere, cant remember)

setting random seed is just write a file to /dev/urandom
storing it is reverse

/bin/mount is not even needed as there is mount() (unless you cba to parse fstab)
same for powering off and probably most other things

logic that glues it all is Boolean if-else
and so on

so its just basic parsing, playing with strings of text and some logic
parallel starting adds making a tree

you can even go the suckless init way and just spawn shell scripts to do the parsing for you http://git.suckless.org/sinit/tree/

could even be fun to do if it weren't that easy

PS idk about udev and not knowing makes it look a bit complicated, but i'm sure it's not something that needs a special kind of programmer

edit: forgot about modules; same thing, finit_module() or modprobe

Last edited by genss; 05-13-2014 at 07:37 PM.
 
Old 05-14-2014, 03:52 PM   #30
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,199

Rep: Reputation: 567Reputation: 567Reputation: 567Reputation: 567Reputation: 567Reputation: 567
What makes an init hard is getting things in the proper order.

With a shell script it is easy - the order is specified by the order of commands in the script.

With systemd, it is next to impossible. Systemd uses a random scheduling order, with a multi-level dependency network that has to be analyzed by systemd. If you miss some obscure dependency, the system may hang, or that particular service may not work (before, after, requires, ...).

The reason systemd has so much trouble is that it has to assume the service is ready when it starts it. This is NOT true. Before the service is ready it has to process its configuration file(s). In all other init systems (sysVinit, BSD, and slackware) the completion of this phase is when the service forks/becomes a daemon process, and the parent process exits. Systemd doesn't have that. To provide the equivalent each service must be modified to send systemd a message. In the case of networks, it becomes a two level thing - Systemd has to have NetworkManager send a message... but NetworkManager can't always know if the network is up either - specifically, in the case of DHCP. This can take up to around 30 seconds (depending on the dhcp server). Yet, NetworkManager has to assume it is ready when dhclient is started... Thus the message back to systemd indicating the network is ready is wrong.

This incorrect assumption allows other processes that may need the network to run... and fail.

The rest of the problem is assuming that one service can analyze all the dependencies. Here you get multiple dependencies - between services like apache, database servers, the network... To get those right requires each service to be modified to send back notifications to systemd...

And that makes the service incompatible with any other init because systemd just doesn't work well with other init systems, and is nonportable.

And worse, the developers don't care.

Last edited by jpollard; 05-14-2014 at 03:53 PM.
 
6 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


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Systemd Is The Future Of Debian LXer Syndicated Linux News 1 02-11-2014 03:09 PM
It seems that in future Linux kernel itself will force the use of systemd blancamolinos Slackware 25 11-07-2013 02:38 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 11:40 AM


All times are GMT -5. The time now is 07:12 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