Supervision, PAM, a proper "ConsoleKit"(-like) application -- just splitting out things without thinking .. You know, basically everything that people from other distribution take for granted and should (or can) not be our challenge to implement correctly and securely..

You're confusing "Learning how to do things manually" with "everyone for himself, doing the same thing"... The first is a nice way to learn things... The second is a completely unsafe way even for learning...

---

Currently Slackware is a great desktop operating system for every-day old users and, depending on the language, developers... Otherwise, I'm sorry but, in my opinion, it's almost useless in a practical sense.. Unified logins (LDAP) -- hustle.. VMs --hustle .. anything more complicated than simple web or mail servers -- hustle..

Somehow it's still my "go to" operating system, but not having at least a bit of new (actually, already old) features that can actually make the operating system more in touch with reality ... well people will soon begin to alienate even if not right away (and I know this trend isn't new in the Slackware world -- but the gap between Slackware and other distros seems higher than ever)..

P.S. I didn't vote since I haven't yet tried even the systems that seem attractive.. But I can also see Slackware keeping it's current init system ... I'm not sure if the "Systemd alternative" should be another init system or simply a collection of packages that provide some lost functionality by not switching-- which will ultimately be required anyway if systemd gains even more popularity (altough, an init with supervision would be nice)

P.P.S It's one thing not to change something that already works with a new thing that provides no major improvements.. It's a whole other thing to not change because of stubbornness

2 members found this post helpful.

But part of the reason I use Slackware is that I don't need PAM or ConsoleKit and don't want to learn about them, in much the same way I don't care to learn about the ins and outs of Solaris specific infrastructure, at least unless someone pays me to need to know that. This seems a better place for the sorts of volunteers who create slackbuilds for various things not in the main distro, like drop gnome and so on. In fact, hasn't someone on here done PAM for Slackware and posted his scripts? As for ConsoleKit, I seem to remember turning that off. i.e. Slackware has it. Is the way it runs on Slackware deficient in some way?

3 members found this post helpful.

That's exactly the thing... The system will work the same with or without PAM if you don't need it.. The good part is that the extra functionality is there if you do need it... And all this in a secure, fairly tested way -- the way only a distro can build it.. not me... My build of PAM will be "touch and go", "trial and error"... I also need to do a fair amount of "trial and error" everytime the software which uses it (e.g. shadow) will update because that version might be very good on a non-PAM system, but may not run well with my build version of PAM... etc... This is all fun to do once, twice.. But depending on this or using it in a real world is not something doable.. So you see, some suffer for something that others don't care about but none have a convincing argument against... There are over 2000 packages in Slackware and most of the time we aren't familiar with 10.. even thought we will use a lot without ever knowing or really caring what they do .. Some might use Vim, some might not... The fact that some don't use it or care that it exists is not an argument against it.. It's simply use-case at most..

As for ConsolKit, yes Slackware has it.. But from what I've read it's kind of messy the way it works (mostly because of missing PAM or missing some other thing -- or am I wrong?)... Anyway, here I was hinting about the future need of a logind alternative (which is a good -- yes, good -- ConsoleKit replacement)

1 members found this post helpful.

i guess if systemd really becomes that necessary, Slackware will find a way to deal with it. As for other distros, let them have it.

Attached Thumbnails

 

No - if the current init system works - which it does - I can't see the rationale for changing anything. If the gnome project want to tie themselves into systemd, that's entirely up to them. Pat clearly made the right decision with regards to gnome a few years ago.

If users want systemd they can go and install one of any of the plethora of distributions which are now based on it, or they can build it from source and incorporate it into their Slackware systems themselves.

6 members found this post helpful.

The difference here is I probably wouldn't be able to do removepkg pam. For its presence not to bug me would require at least two things:

1. no bugs appear because of the added complexity PAM adds. i.e. I really can remain ignorant of PAM's presence. I found this not to be true when I used Debian. First I found I had to learn about PAM because a comment in their bash profile script caused me to believe the Debian way of setting umasks is to use a PAM module designed for that purpose (what the hell I say, but never mind). Then in trying out lshd for my ssh daemon I stumbled into a bug there where its packager and upstream weren't clear on what debian's PAM policy and requirements are, in a way that caused me to run with umask of 0 when sshed to the machine. What fun. So I'm skeptical. Then again Slackware's way of doing things avoids the combinatorial explosion problem of software package interaction testing (this idea of us walking together over the same ground maybe you're getting at), so perhaps I'd only run afoul of PAM in my own customizations. And perhaps P.V. would take PAM without the idea that a PAM module is a sensible way to set your umask.

2. Aside from normal browsing, etc., I use my home computer as a hobbiest, to learn more about programming and operating systems. This means I like sometimes to look into how my system works and is put together. So, as a starting point, the ideal system would be Unix 6th edition, minix or maybe plan 9. There's not a lot of point looking at how something works if what you encounter is large scale engineering. I'll (kind of) learn how to fix a bicycle. I won't learn how to fix a car, and definitely won't learn how to fix a 747 or the Space Shuttle. But practically I want my learning operating system to be the operating system I use (I won't work on a bike I don't need to get working to ride somewhere). So from minix, etc. I branched out and eventually landed here and at openbsd (but openbsd still needs better nvidia support so mostly here at the moment). This is kind of an OpenBSD thing to say, not a Linux thing to say, and probably shouldn't be said by an ordinary and fairly new user, but if you have different preferences, I'm asking myself why you don't just use one of the systems with the stuff you want.
(hmmm, so the "thing" for number two would be that PAM be simple (bicycle like) with documentation that's pleasant to read and with config files that are easy to understand, maybe even self-evident in their functioning, definitely not with an ad hoc turing-incomplete horrible quasi-programming language, or at least not with something looking that appears to maybe be like a goto statement, I dunno, I didn't have much patience to keep an open mind about PAM).

The site says
udev is now under systemd, and it will likely be needed by other parts of the OS. However, there is eudev. The switch would probably only happen if it is necessary. If you think it will never be necessary then it probably won't happen. I can't be sure, but I wouldn't wanna be caught off guard.

I was thinking more along the lines that there needs to be a viable competitor to systemd, otherwise there is no choice and this poll is mostly useless (except for voting for systemd).

1 members found this post helpful.

(In reference to dmd)
It's the init system for Guix GNU/Linux. In fact, I think that may be the only place it's currently used. So maybe the question should be, "has this even been ported to the HURD (yet)?" er, not ported maybe, it's all scheme so should be portable except in the sense of what daemons it should start and whether it could take advantage of Hurd features. But neither Debian GNU/Hurd nor Arch Hurd use it last I heard. There's someone I think working on Guix for Hurd, so I'd guess that's how dmd gets to the Hurd.

Exactly. Despite all its flaws, the reason why systemd is so prevalent is that it is featureful, and no other init system does as much.
The only way to avoid systemd taking over the whole GNU/Linux space is to have plausible alternatives, real competitors, and for now, there is none.
This is why I plan to turn s6 into such a competitor. It is not enough to oppose systemd - it is necessary to provide a suitable replacement and have a banner to rally to. Please stay tuned - I will definitely keep you informed when I'm done with the current stuff preventing me from working on it full-time.

8 members found this post helpful.

Nor do I. I'm firmly in the "It ain't broke" camp.

I think that ruario hit the nail on the head. There is nothing wrong with sysvinit and the eventual dependence of DE's on systemd is mostly about logind and the udev functions. So far, eudev has been able to abstract udev functionality, but eudev is not really an alternative to the newer udev -it's simply an isolated clone of systemd-udev. This means that it will need to follow future developments of systemd-udev -for good or bad.

If that is true then what is even the point of eudev ? Why not just use systemd-udev ? I'm not sure it will need to follow all future developments. Most of the API will need to adapt, but the rest can change.

You can have sysvinit with the bare minimum of scripting to operate and dump the rest off on perp, s6, runit, etc.

As far as what we REALLY lack, yes, Slackware ONLY lacks service supervision.

That and a document that tells you if you want to implement other specifications outside the baseline then you need to research things for yourself, and learn to implement them on your own.

If Patrick really wanted to be a sadist and tell people to learn proper UNIX-isms he could have left in hal-daemon, hotplug, and devfsd and thumbed his nose at udev entirely. We should be thankful we were spoiled so minimally with some automation.

Eudev is being done to avoid extras. It's more of a minimalistic port rather than a full udev implementation, but it works as a full implementation. The only thing it lacks, or will lack in future developments is kdbus, but that has yet to even be considered as Linus warned them specifically about breaking the userspace would bring severe consequences.

If I had another 6 months to work on it, I could "try" and port runit-for-lfs out into a project like runit-for-slackware, but honestly, I'm tired guys, and I'm taking a well deserved break from developing that script kit. If you guys want to port it, be my guest. The project is MIT licensed so you're free to work on it as you see fit with only citing a reference back to the runit-for-lfs project as the source of inspiration, and you don't have to contribute back... unless you REALLY want to.

With all due respect I think you are missing something here; to wit, that the reason for much of the opposition to systemd is precisely because being 'featureful' is NOT a good thing in an init system.

To the degree the features provided are good they can be implemented outside of the init system.

1 members found this post helpful.

I have struggled a little with the scope of this term. I see it used frequently and it seems to be one of those terms that everyone "just knows what it means"...

But in reading docs (runit for example) and searching for a concrete definition, I come up somewhat empty. Some uses seem to limit to the obvious function of monitoring and restarting daemons automatically, other d's imply or include much more.

The word "service" itself, correctly or not, I have tended to think of as both a Microsoft-ism and a RedHat-ism, a marketing term that blurs the historical uses of daemon, process, etc... Admittedly, that may be simply an artifact of my particular experience-path, but it seems pretty well founded.

So, please pardon my own ignorance if necessary, but if the term service supervision is to be a talking point in this discussion, could someone put an unambiguous scope and definition on it?

3 members found this post helpful.