Slackware 14.1 Goes Into Beta, Brings New Packages

[rvdboom]

since = <specific time>
for = <general time-frame>

Thanks, Stiixy. I know about that but wrote that message early in the morning and was probably not fully awaken. On the other hand, I must admit writing less often in english and thus doing more and more mistakes while writing. It's bit frustrating to see how quickly you loose practice in a foreign language....

Back to Slackware, requiring PAM is certainly one of the reasons systemd is still out of Slackware. PAM has been forbidden to enter Slackware long before I start using it for some reason. But Volkerding seems quite adamant about keeping it out.
I must admit I don't know much on systemd. It seems quite intrusive and I haven't found anything yet that shows it fixes anything worthwhile, though I must admit I didn't look hard. My systems obviously run quite well without it and I don't feel I miss any particularly important features. Any infos would be appreciated.

[Teho]

This is just a fake, so that they can tell people "Hey, just use that part" and once you do they make the part you use dependent on systemd.

Eh?

Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

[1] For example, systemd-detect-virt, systemd-tmpfiles, systemd-udevd are.

It never mentioned systemd-logind. Then how about the handy portability chart?

logind:
Covered by Interface Stability Promise: Yes
Fully documented: Yes
Reimplementable Independently: No
**systemd Implementation portable to other OSes or non-systemd distributions: No

So yeah...

See Gnome and logind, which suddenly has systemd as hard dependency (funnily in the same timeframe as Ubuntu started to use logind, what a coincidence).

Yeah, what a coincidence that at the same time there was a major cgroups changes in the kernel that require you to use single writer for the cgroup hierarchy (systemd in systemd systems) to take use of the modern cgroup functionality and therefore the cgroup handling of systemd-logind was moved to systemd PID1. I'm sure this was all just to piss off Ubuntu...

SIf Slackware is ever forced to use systemd they have demolished the oldest existing Linux distro.

It's hardly systemd developers fault that there seems to be little intrest in keeping the developement philosophy alive that you happen to like... or at least very few people to do any actual developement. It seems most of the time is wasted in spreading FUD about projects like systemd... with little success (who would have guessed?).

it tries to be a complete OS in itself

No it doesn't? It provides some core building blocks for an operating system but that's really, really far from trying to be a "complete OS".

It requires a lot of stuff I would not expect of init - PAM, libkmod, selinux, libaudit. It does seem like a lot of responsibility for the tool that kicks off run level changes.

Well one thing Vim_User was right about that systemd is not just an init system so why do you think it's just something that kicks of run level changes? It's a systemd and session manager, it's not called initd, it's systemd because it's a deamon that manages the system. Now the package includes quite a bit of other stuff like systemd-udev that you would probably have installed anyway that has its own depdencies, systemd-logind that replaces ConsoleKit that you would probably have installed otherwise, systemd-journald that can replace syslog that also has its dependencies among various other things. These are separate binaries and therefore separate processes. They however are not usually packaged separately and most of the can't be used independently (see the portability chart).

I wonder, does it's author have any ties to the American NSA?

Seriously, what the fuck? systemd has been completely open source from the start and it has a large developer community behind it. The author is also a long time open source developer and he works for the most prevalent open source company there is, Red Hat.

[hoohoo]

If systemd would be just another init system no one would care and one could even think about to use it on Slackware (in fact, some users have already ported it and tried it, but the feedback wasn't that good). The problem is that systemd is not just an init system, it tries to be a complete OS in itself, something like "the kernel of the userland", which is against the Unix philosophy of "do one thing and do it good" and against the KISS principle.

Anyways, both AMD and Nvidia drivers work fine on Slackware.

Thanks Vim_User, for the explaination about systemd, and about the AMD.VN drivers.

I just looked at the deps for systemd on an OpenSuSE 12.2 box. It requires a lot of stuff I would not expect of init - PAM, libkmod, selinux, libaudit. It does seem like a lot of responsibility for the tool that kicks off run level changes.

I wonder, does it's author have any ties to the American NSA?

[Vim_User]

Why is systemd bad/unwise/what-have-you?

This question is not a dig, I simply don't know what the problem is.

If systemd would be just another init system no one would care and one could even think about to use it on Slackware (in fact, some users have already ported it and tried it, but the feedback wasn't that good). The problem is that systemd is not just an init system, it tries to be a complete OS in itself, something like "the kernel of the userland", which is against the Unix philosophy of "do one thing and do it good" and against the KISS principle.

Anyways, both AMD and Nvidia drivers work fine on Slackware.

[hoohoo]

That would explain why they haven't adopted systemd yet.

Why is systemd bad/unwise/what-have-you?

This question is not a dig, I simply don't know what the problem is.

[hoohoo]

I've always liked Slackware becuase it used less init file, /etc/sysconfig, /etc/defaults (and so on, and on, and on) voodoo than do Debian and RH derived distros. With Slackware man was a man and a config file was a config file.

That said, I've been living in OpenSuSE land for a while.

Does anyone know whether AMD or NV proprietary driver installers play nice on Slackware?

TIA!

[Vim_User]

According to the Systemd myth debunking page, it's supposed to be rather modular, so hopefully it's possible to use just what's needed by the dependencies without setting up the whole stuff.

This is just a fake, so that they can tell people "Hey, just use that part" and once you do they make the part you use dependent on systemd. See Gnome and logind, which suddenly has systemd as hard dependency (funnily in the same timeframe as Ubuntu started to use logind, what a coincidence).
If Slackware is ever forced to use systemd they have demolished the oldest existing Linux distro. In that case Linux is officially dead for me and I will switch to something with sane developers.

[stiiixy]

Happy English grammar helper tip of the day for our English-as-not-your-first-language friends;

since = <specific time>
for = <general time-frame>

I've been running Slackware since about 10 years
I've been running Slackware for about 10 years

I'm happily running slackware-current since a few months
I'm happily running slackware-current for a few months

Better yet;

I have been happily running slackware-current for a few months



I've noticed 'since' used quite a lot. Not sure why, just trying to help out a bit for those who would like to speak better generic English*


Eins, zwei, drei, PROST!

[rvdboom]

If they ever need to add systemd because of dependencies, I trust Pat Volkerding will add it in the saner possible way. According to the Systemd myth debunking page, it's supposed to be rather modular, so hopefully it's possible to use just what's needed by the dependencies without setting up the whole stuff.
It would nice, though, if user space software offered at least systemd dependencies as a compile time option and not making it mandatory. As indeed, seen from the Slackware POV, it's a bit difficult to see what's actually solved by systemd and what advantages it brings.

Anyway, I've been running Slackware since about 10 years, and that's really a nice, quite stable distro. The packages may not be bleeding edge, but they are recent enough, and for the adventurous, there are several repositories with newer packages to test. I personaly compile my own kernel and graphic stack (git libdrm, mesa and xf86-video-ati) and it works like a charm. And since the packages do not deal with dependencies, you can do that without hassle.

[Grogan]

That would explain why they haven't adopted systemd yet.

... and if they ever do, my next OS won't be Linux based (I could also use FreeBSD by now on this hardware but I still need Windows for games). The day I can't edit plain text boot scripts and grep logs (while booted with any damned media) is the day I might as well switch brands of dog food, if I have to eat someone else's. Most of the programs I use all have Windows ports now. I'm done caring about philosophy, and it's getting harder and harder to have things my way in a Linux environment anyway. (Slackware is still sane, so my whinging is premature, but there's going to come a point in time where they will have to conform because software that people want to use will require it.)

It's already a workaround to get some stuff to compile on Slackware. I have to do stupid things like put pus audio headers in place for some things (then remove them immediately after because I don't want any other builds seeing pulse)

I already take it as an ominous sign to see Grub 2 in the "a" category, of non optional packages. Of course it still is optional (can deliberately deselect it) and LILO is still a choice but for how much longer? I disliked Grub, but I can work with it (had to, on redhat based servers and stuff). Grub 2 just pisses me off, though really, it's more the distributors that are responsible for that. It still tastes like a shit sandwich to me though.