Peter Jackson wants to make a trilogy based on it, as a follow-up to the Hobbit. Another spectacular epic.

It took me until that post until I realized what your name meant :) Bravo!

Reminds me of Roosterteeth's name... (they couldn't just name their company Cock Bite)

Member Response
 

Hi,
For the post you are querying about it is general posting to the thread. If I want to direct to another member directly then I would quote that post. When you enter a thread the posts should be posted via time & date stamp to keep things in order. LQ threads keep the posts in line via post time stamp.

Hope this helps.

I never said it was a bug in systemd, rather its a lack of sane defaults for things that depend on systemd.

Anyways, there are plenty of other issues discussed. As you can discern from my user agent, I use FreeBSD, more than I use Slackware or Void, and the reason is that I find the FreeBSD project is doing things in a way that has a future, for now. If Jordan Hubbard gets his way, though, we'll have launchd eventually, and if that happens, I'll tell him to shove it up his ass and fork FreeBSD with a large proportion of support from FreeBSD users - most of them aren't happy with the way the Apple section of the OS is pushing their agenda anyways - we have plenty of time though as it likely won't happen till after the 11.0 branch is released as a release version.

If a database daemon corrupts a database due to respawning I would consider that a bug, but anyways, that is the point I wanted to make: in the case you describe the defaults for this behavior are not set by the systemd team, the are set by the MySQL team, so there is no point in blaming systemd for it.
This is your right to do and though I am in favor of the systemd approach I would appreciate it, just because you actually would act like it , IMHO, should be in the open source world: you don't like something, you get the work done to change it.

So why aren't you in favor of the Slackware approach?

While you are correct that such a misconfiguration is not a bug in systemd, it is a problem that is likely to arise again in the future given systemd's basic design philosophy.

With Sysvinit, if one wishes to have a daemon, it is necessary to edit /etc/inittab and then sighup init (or reboot). While doing this is straightforward for a human administrator, if upstream wants this to occur automatically upon package installation, their post-install script would need to be able to parse inittab and figure out how to insert the appropriate code without interfering with the other things happening. Again, most competent system administrators could tell at a glance what needs to be done, however, writing a program that does this is not exactly trivially (at least one that doesn't stomp on the existing setup).

Over the years, there have been alternative inits -- or proposed patches to sysvinit -- that address this by having an /etc/inittab.d directory or somesuch into which an install script could place the necessary additions to inittab, in the same vein as xinetd supplements inetd or Slackware's sysvinit-scripts can supplement the stock BSD-style init scripts.

Such a variation from traditional Sysvinit does not seem particularly troublesome, though it does increase the complexity and readability of init's configuration. Nonetheless, the fact that over the last fifteen years such a simple change hasn't seen mainstream adoption suggests that there has not been much demand for such facility (perhaps some even being adverse to it). Likewise, dedicated tools such as monit or daemontools address the same problem but have seen a similar lack of uptake.

Now with Systemd, the only effort required to change the behavior of a process so that it respawns indefinitely is for someone (upstream, packager, sysadmin) to substitute a keyword or two into the service file. Again, not in and of itself such an odious concept, but it is also undoubtedly to be expected that under such a regimen there are going to be more instances arising where someone in the pipeline makes the change without a full appreciation of the potential ramifications.

I am in favor of any approach that puts their money (or work) where their mouth is. I think that should be clear by now when you have read my posts in this thread and others about similar topics.
I appreciate your work to get runit working on Slackware, because you do something about things you are in favor of. The same is true for bartgymnast's project of systemd running on Slackware.
I am in favor of skarnet's work when he asks s6 users to tell him which features they miss in his software that is delivered by other service supervisors, so that he can work on improving it.
I am in favor of the systembsd project and I am in favor of Consolekit2, because those people do what is necessary for them.

I actually don't know what Slackware's official approach is, it looks like it is "Let's wait and see what happens".
What I can see is the approach many (not all) Slackware users seem to choose: remain ignorant about systemd, do nothing to support the status quo, but complain about systemd wherever and whenever possible. I am clearly not in favor that approach.

And Heaven help you if a distribution creates a patch that fixes or changes something for a single distribution that enables or disables something triggered in the unit file.

I think Slackware has put its money where its mouth is. It's just not appreciated because it's not new enough.

@saulgoode: You are right, those issues can arise when some admins, developers or package maintainers don't know what they are doing. Nonetheless I don't see the point in blaming that on systemd, they merely offer that functionality. OpenRC offers the same functionality (I guess s6 and runit do also, I haven't studied them much), so it can be used in the wrong there also, but the duty to get this right lies entirely on the side of admins/developers/package maintainers.

Mind to provide a link to a case where such a patch is dismissed without good reason?

Get over yourself, but don't pat your own back too much, you'll dislocate a socket that way.

The atmospheric on this Slackware forum has been a bit more tense than usual.

I think you all need to relax a bit. Drink beer, wine or whatever, and don't take yourself too seriously.

Cheers!

I think the lack of visible development activity isn't helping. There hasn't been anything in slackwareland to talk about or engage with for a while. Back in the days of the sailing ships, I expect there were many more petty squabbles when they were becalmed for any length of time.

In the days of sailing ships, the officers had to keep busy the crew of a becalmed boat.

Maybe folks posting in this thread could instead occupy themselves contributing to SlackDocs?

Or other slackware related pet projects. Problem is, without the visibility of where slackware is going (and I'm talking in general, not specifically about init/systemd) no one is going to want to expend effort on something that might be invalidated by future changes. All my pet projects are on hold until we get to RC, or at the very earliest BETA.

But, you're certainly right: there are far more productive things to do than take part in this thread. :)

So I give you KDE 5 for Slackware-current today, something to sink your teeth into: http://alien.slackbook.org/blog/kde-...kware-current/

Eric

When one exists I'll make sure to send you the memo. That's not the point though. The point is trying to give a generalized startup proceedure to something that is meant to be controlled by the distribution rather than upstream is not the best approach. Who knows better how to handle the startup of the system? Upstream or the Distribution maintainer(s)?

This is why parallelization of startup doesn't always work and why it takes more efforts to maintain parallel startup and dependency chains in startups. Plus, not every distribution is going to need or have equivalent software betwixt and between to accomplish this.

Even I was forced to admit Runit wouldn't be the best approach. As much as the benefits of a new init system would help any distribution, including Slackware on some level, I was forced to admit that the task of getting services up and running using parallelization is a daunting task in and of itself.

S6's approach is no different or better and has many of the same problems. Laurent's init and service supervision suite is very powerful and you can do a lot with it, and even use execline to handle fifos and other things, the problem of s6 is staggering. There is no generalized init script set that just simply works with any distribution, meaning if Patrick ever imported it, or anyone for that matter, you'd have to write the stage scripts from the ground up to handle the tasks of booting the system, starting it up, shutting it down, and you'd need at least several tools from s6-portable-utils and s6-linux-utils to gain the most out of the system. Even then, you still need to work out the details of dependency trees within the run and finish scripts for the services, work out the logging, and figure out how to best approach the issue of runlevels which are non-existant in these types of service supervision suites.

It doesn't matter if it's systemd, s6, runit, monit, init-ng, god, sysvinit+perp, or any init system trying to approach the problems of sysvinit and startups. The problem of init isn't within upstream or the init system. It lays squarely on the distribution which is responsible for maintaining its init scripts, and there's no excuse for poorly written service scripts for any init system, nor the willingness to "pass the buck" off to a scapegoat such as upstream or the developers of packages. The only reason launchd works for Apple is not just because they created it, but they are the distribution as well. The same goes with Solaris and SMF.

Upstream is trying to solve the problems on their end, but the problem still resides with the distribution.

And as stated, until shutting down the system properly can be addressed on any system to where you have 100% successful shut downs where the root file system isn't left dangling with a service still in the execution phases, you're going to have problems and moreso in systemd because a corrupted log from an improper shutdown damages the journal causing further problems.

In a nutshell, service supervision is nice, but there are still far too many flaws to have the proper benefits of service supervision over the standard design frameworks.

Will service supervision ever bring enough promise to be of use to UNIX? I don't know. Until distributions are willing to invest the time and effort into init systems and write effective scripts for handling the system and services, no init system is ever going to be the red pill that suddenly wakes everything up and automagically when there is too much reliance on outside interests.

Alien_Bob, thanks for the packages for KDE 5.2
I will sink my teeth into it.

I see gstreamer1 and wayland as new deps, I will look into those closely.

for those that wonder systemd and gnome3.14 with systemd for Slackware development is at https://github.com/Dlackware
How is the support on python3 going within kde application ?

Nice, I appreciate it when claims are backed up by facts, waiting for that.I don't quite get where systemd does not allow distributions to customize system startup as they see fit.
If a distribution does not want or need to run systemd or wants to use it without having to use all of its components, then so be it. Nobody is forcing them to use systemd and nobody is forcing them to use the optional components if they don't want to. While I use systemd-networkd for setting up the network on my systems I am free to use any other software that is available to do the same job. If I can do it I am quite sure that distro developers can do so also.
The point is, though, software doesn't maintain itself. If a distribution decides to not use systemd or some of its components then the alternatives that are used have to be maintained. Some developers have realized that and have started to work on compatible alternatives (systembsd), make changes as they would like to have it (eudev) or mainatin the status quo and improve on it, when necessary and possible (Consolekit2), while other developers (and users) just fled into complaining.
This is what I criticize.Of course introducing a new init system to an existing distro is a task that doesn't come for free, work will always be required for implementation and testing. Nobody denies that. But in the long run it can save a lot of work, not only for distribution developers, but also for upstream developers. For example, with traditional init every daemon that wants to run as unprivileged user but needs at start root privileges (for example to open sockets) has to implement the part where it switches to the unprivileged user themselves. This ends in a lot of duplicated code with all the implications (like security problems, time that is needed to maintain that code that possibly is better spent elsewhere, ...), while systemd (and possibly other service supervisors) can handle this functionality at a central point, which not only decreases general time for development and maintenance, but also eases up security reviews.
There is a reason why so many distribution have switched to systemd or provide it as an option and that reason is not that they are bored and need something to work on, the reason is that the work they have to do in the short run will benefit them in the long run.

But we have discussed these points over and over again and time may indeed be better spend with testing Alien Bob's work on KDE instead.

I agree with everything TobiSGD just wrote,
if anyone wants to test systemd with Alien Bob's work on KDE, please do so, also systemd for Slackware needs improvement, and we want to make sure it can run also with Alien Bob's KDE.

https://github.com/Dlackware

ReaperX7, for your info I do like Slackware - but I will cease using it if Slackware adopts systemd. Just like I left Arch, Fedora, Debian, CentOS for the same reason. I have tried using systemd and I do not care for the way it functions, or its architecture. If a day comes where all of Linux uses systemd, well, I'll cease using it altogether.

I won't fork a Linux distro because I have no intent of contributing to GPL software. However, I have no problems forking FreeBSD if the time comes, as much of my infra depends on it now.

Dunno about a mass exodus or systemd; I think the sailing ship remark by Gazl [edit: sorry it was Didier] was spot on. Perhaps some hard work would be better than extra rum rations.

Having said that, I've been playing with Arch recently. It's a quite nice distro that certainly likes to keep things neat, though I sense the level of bonhomie on the Arch forum is not quite at the LQ level. Certainly more tense, to use the recent description, than the protypical Slacker attitude. Obviously never a handholding distribution will Arch be either, nor a place to run from systemd. But I like the latest software and running -current doesn't quite get that itchy spot I can't reach.

I say all this not to bore you all (that's merely a side effect), but because in my travels I noted the following sort of problem which has been discussed here previously and is unavoidable with a parallelizing init system. Basically, a race condition, see the last section of https://wiki.archlinux.org/index.php/NVIDIA under the title of "Xorg fails during boot, but otherwise starts fine"

A fix is provided, involving some mucking about with udev to make sure systemd doesn't start X before the Nvidia driver is started. Duh.

Is that a bug or a feature? You be the judge. Well, back to work.

Oh my. I've been poked by the soft cushion.

I tried to get over myself once. I laid down, but I was unable to achieve an out-of-body experience. I then realised I am trapped inside the twisted reality in my head.

Little debate goes into analyzing the pros/cons? This is, as I understand it, one of several long threads that have beat the topic to death. I've seen a number of reasonable points made regarding the pros. It appears you have not. There are also reasonable arguments on the con side.

I took some time (WAY more than I should have allotted) and read the entirety of this thread. There appears to be no reason to visit the previous ones based on the commentary that this thread rehashed the others.

I'm willing to accept change. Can't avoid it. Linux based operating systems have given me a job for a number of years, and I've enjoyed the opportunity. I owe a great deal to those that have put in the work to develop these systems, and greatly appreciate those efforts.

I work in the financial sector, in networking security. My workgroup also gets to work on developing/implementing the various systems we use for monitoring, logging, or whatever else we need. I really do love what I do. I couldn't ask for a better mix of challenges that I enjoy.

My feeling is that if systemd is something that can't be tolerated by a certain faction of the community, competing systems will evolve or perhaps be maintained. Our world is always changing. That's fine by me.

mmmnnnn...beer

This is the best answer systemd has turned into religion, the best answer is always to improvise, adapt, and overcome.

And I'm real sorry to hear that. Maltards and other mental floss I can deal with but soft cushions are way out of my league. I'll ask Jeremy to appoint a committee to determine the proper response. We're looking at probably twenty rules to combat this, depending on if it's the plain stuffy North-American Pillow or the much feared Eastern-Pacific Cushion. Of course if it's been recently cried upon, as I suspect, all bets are off...

I was always partial to "crucify the leaders!" :) even though your solution is my tagline at OCN XD

How about a mass exodus from this thread?

Unfortunately there is no way out of a black hole.

Let's just hope it doesn't absorb the whole Slackware forum :(

I never posted in this thread. ... o wait! Heeeelp!

Is no distro safe? I think I will be going the way of the BSD or stay with LFS where I have a say what happends on my hardware, if slack gets infected.

I have avoided the following software like the plague because of the authors policy or attitude towards people with altenitive ideas.

- pluseAudio (JACK2 + JACKNET2)
- avahi (mDNS) (yes I know you can't use mDNS between subnets, if I wanted to I would give the device a dhcp address!)
- systemd (SysVinit + rsyslog + dcron + dhcpd + iptables + eudev + lxc)
- udev (eudev)

The way I see it, if enough people boycott these, RedHat's imperistic ventures will be well on there way to being over. No company should have direct say on how Linux is formed, the license is GPL not RHELPL (sorry have to pull a Microsoft with there MSPL). Linux doesn't belong to RedHat so why are they pulling the strings for every distro? Let RedHat deploy systemd, they can keep wayland too as far as I am concerned pn their own distro, I see no reason why Suse, Arch, Debian, now Slackware NEED to use it... Linux has been about choice for a long time, well what happened to it?

Wayland isn't a problem - but Weston is because of udev dependency. I don't use udev, I use mdev currently on Slackware. It was a lot of work, and I can't run a full DE. Doesn't bother me one bit.

I've never been a huge fan of the GPL myself, so I'm at a perfect place to fully jump ship to BSD, but I'd rather not, because if I stop using Linux at home, I'm not going to use it at work. RedHat has its shareholders interest at heart, and so they're poised to take down Windows, and in the process they're turning to "the dark side" moreorless.

None of these distros need to use systemd. The distro developers just have chosen to use it (or set it as default, in Debian's case), which is totally up to them to do. Just as you have the choice to use distros that have chosen not to use systemd.

That you have the choice in Linux implicitly also gives distro developers the choice to decide how they develop their vision of how a Linux distro should look like. This includes all distros, those like Suse, Arch, ..., that have decided to opt for systemd, those distros that have decided against systemd, like CRUX or Slackware, and those distros that let the user decide which to use, like Gentoo, Void or Debian.
The problem is, at least for the distros that have not opted for systemd or to provide more than one option, that choice can only exist when there are actually more than one option. So to be able to make a choice the available options must be maintained, or new options must be developed, when not enough options are available.

Choice is not something that comes from nothing, choice must be worked for.

Hardly. They might be able to take some of Microsoft's market, but take them down? Not a chance.

Poised to attempt to take it down, is what I meant.

There is no indication in -current that Mr. Volkerding is moving Slackware to systemd.

Too many people confuse the "if" with "when".

I see it this way Alien_Bob

I am wondering "when" PV decides "if" systemd will be included in Slackware.
It would be nice to hear the following things from the devs.

* Just some random lines what I wrote here
1x a year (in Januari make a post, with some news on development)
- We did not decide if systemd will be included in Slackware
- We are looking into including Linux-PAM in one of the next releases.

etc. etc.

That would be my suggestions.

Historically, from my limited use of Slackware, it has been my experience that PV always keeps us informed of software changes in the changelog. I trust PV.

Seems to be too much worrying about an issue that may or may never happen. All one needs to do is go here slackware.com and read the second paragraph. That tells me Slackware will always remain Unix like so no real need to worry.

Maybe it is time for Miss Sweety Poo (improbable.com) :)

but if you want to have the real UEFI secure boot experience you will have to use systemd, otherwise you will not be able to have a chat with your bootloader which has to be gummiboot.

http://www.phoronix.com/scan.php?pag...ot-Boot-Loader

poettering's latest news........ (yes, more systemd)
 

If you want to know how poettering feels about systemd and what he compares it to, look at page 4 & 5 in this pdf here:
https://rhsummit.files.wordpress.com...g_systemd1.pdf
Pretty ballzy if you ask me.

I intentionally DO NOT capitalize his name.

poettering's latest news........ (yes, more systemd)
 

I know that I posted this in another thread, but it needs to be seen by as many people as possible to expose poettering and his mindset about Linux.

If you want to know how poettering feels about systemd and what he compares it to, look at page 4 & 5 in this pdf here:

https://rhsummit.files.wordpress.com...g_systemd1.pdf

The whole pdf is a good read and exposes how much more of Linux systemd is taking over.

Even if you don't want to be polite to him (do we really need that information?), you could spell his name correctly: Lennart Poettering.

[EDIT]Spelling fixed while I was typing, sorry.

You're new here, aren't you? :)

Can I just save some time and panic without having read the pdf?

Maybe that's just a bit of humour targeting the easily excitable?

Have some fun:

https://igurublog.wordpress.com/2014...ainst-systemd/
https://igurublog.wordpress.com/2012.../red-hat-flag/
http://sporkbox.us/misc/old_posts/95.html

tl;dr

Move to Slackware, Gentoo, CRUX... if it gets too bad, move to BSD.