Well Didier, I can't speak for people who have vast farms of servers each of which have dozens of interfaces, because, strangely, I have never met anyone like that.

BUT

For every real person I have ever met, 75-persistent-net-generator.rules and all its consequences is a bloody pain in the arse.

I have a hard disk in my favourite lappy. The lappy has one (1) ethernet port (duh). The lappy dies. I move the hdd to the other lappy. The other lappy has one (1) ethernet port. And we all know what happens next....... eth1. Brilliant. Fantastic.

I have a hard disk in a server at a radio station. The server has two (2) ethernet ports. The server dies. I want to move the hdd to an emergency backup server to get us back on the air, then in the morning I can find out whether it was the PSU or mobo or whatever. This is a big win for Linux, because it's not tied to the original hardware because licences and Ballmer's deodorant costs. But yay, swap the hdd and now we have eth2 and eth3. Brilliant. Fantastic. *DERP*

Every time I move an image from one machine to another, I **CURSE** 75-persistent-net-generator.rules, but at least I know the rules of the game.

It seems bloody obvious to me that another iteration of disruptive change will not solve a damn thing. That applies equally to both udev and Slackware. It's awful, but for gods sake leave it alone.

3 members found this post helpful.

rm /etc/udev/rules.d/70-persistent-net.rules

bios naming is actually not that bad, for servers especially
but for home computers the naming scheme is a bit too crazy


i think i can write a script that would remove the names when the disk changes computers, if anyone's interested

1 members found this post helpful.

LibRaw 0.16.1 is out. The only entry in the changelog relative to 0.16 (which is in -current and SBo) is "Fixed dcraw vulnerability in ljpeg_start()" which seems to relate to this: http://www.securityfocus.com/archive/1/535513 (although there's also another quite minor bug fix included.)

I don't think the world is being taken over by .CR2 wielding maniacs -- not yet, anyway -- so to keep SBo and -current in step, I won't update SBo unless/until 0.16.1 lands in -current.

Shot in the dark question, but what about looking into OpenRC getting into Slackware?

Saw this project and it looks interesting: http://www.walecha.web.id/blog/2015/...-dengan-openrc

Original language was Indonesian but Google Translate seems to work well.

Author has a SlackBuild here: https://github.com/w41l/wlsbuild/tree/master/openrc

Indeed. Long list of changes here

FYI Aaditya has written an HowTo on SlackDocs. But frankly, don't hold your breath. If you think it's worthwhile you could submit a SlackBuild @ http://slackbuilds.org as a first step. I have asked a few questions to Aaditya, but that's just out of curiosity, in short "why?"

I did intend to submit the SlackBuilds to SBo, but only after a certain amount of testing

4 members found this post helpful.

Thanks for posting about this.

I've been playing around with OpenRC in Funtoo, and honestly, it's a nice little add-on to good ol' sysvinit. It's a grey area package between "extremely nice add-on" versus "system will benefit". I actually can't find anything negative, which is a solid plus. It's either Slackware gains, or Slackware gains.

It's not hard to use either, and is very KISS principled. Activating daemons isn't hard, nor do you ever have to edit files like rc.local or rc.M to get a service added (this would be good for admins not having to touch critical scripts). Everything fairly much runs just like bsdinit or sysvinit, except the scripts use dependency tree checks which can be enforced as an option if you use parallel startup mode.

Why? OpenRC honestly uses a very KISS principled approach to init, doesn't stray from the core implementation too far except using add-ons in scripts and some script parsing tools, it promotes good security practices by keeping scripts untouched (though scripts can be edited at any time by an admin), uses runlevels similar to the Slackware rc design but with approach using directories rather than files, and others that are going to take too long to write up. Just go use it for yourself.

Well, I could try it when a Slackbuild will be available, out of curiosity. I am a bit cautious about parallelism of an init system for the reasons stated in The Problem With Threads from Edward A Lee, but as long as it's optional...

Sorry for the digression.

Parallel works when you have proper dependency resolution set up. It's really about knowing what your required services are that need to be started first before others, and what services rely upon it.

The good part is the traditional start, stop, restart, and status functions aren't impeded upon, which was an issue I had with Runit in which init functions had to be duplicated through a shim package, and scripts had to be heavily modified. At least with OpenRC the only things replaced truly are the scripts. Runit unfortunately replaced much much more.

unlike threads, programs don't share data

starting tings in parallel is completely fine if all the dependencies are declared
and if the daemons that other programs depend upon are properly written
(another thing is starting hardware and such, but from what i see openrc does that before starting programs)

not that a parallel init would make slackware booting much faster,
as most of the starting time of a program is spent reading from the (one) disk

slackware already starts a couple things in parallel, like fc-cache

link looks good, il have a read of it later


PS i finally had a bit of a better look at openrc,
fwiw it has my blessing even though i think there is nothing wrong with slackwares init now (except maybe tracking processes)

1 members found this post helpful.

OpenRC wouldn't technically replace the init system, just add a few tools and dependency resolving bootscripts. Sysvinit would still be part of the equation and honestly, the OpenRC methodology is very close to the BSD style and Slackware style.

I think all it would replace is the sysvinit scripts package, and add the actual OpenRC package, the rest would remain the same.

From an aesthetic viewpoint, I don't like those ugly green [OK]s I saw when using Gentoo years ago (OpenRC). Very un-BSD-like. Is it possible to suppress them?

1 members found this post helpful.

In the scripts maybe. We do have one script still using it. rc.cups still has a tag. To be honest, the status tagging does have some benefits. At least you can see if something takes a fart.

Maybe we could take the OpenRC talk to this thread.

Yes, I suppose it is possible to disable the colors. From /etc/rc.conf:

1 members found this post helpful.