And at least with an email client, you don't have to worry about the UI changing every 5 minutes.

HEADSLAP

No, I did not know, but you are of course correct. It's right there. Building the man pages failed for a different reason related to the transform. I'll figure it out.

Thanks for correcting my derp.

UPDATE: It's a known issue: https://github.com/gentoo/eudev/issues/70 but nailing it down is odd. xsltproc fails to fetch the remote document http://docbook.sourceforge.net/relea...es/docbook.xsl even though (1) I remove --nonet from xsltproc's arguments, and (2) wget fetches docbook.xsl just fine.

Re-running the transform specifying a local copy of docbook.xsl fails because docbook.xsl contains several relative links. I could resolve all of those manually, but would rather figure out why xsltproc is failing to http-get docbook.xsl in the first place. It might simply be a matter of sourceforge filtering on user-agent or something (telling xsltproc to fetch from http://localhost/ttk/docbook.xsl works, so it's not that xsltproc is incapable of http-get). Will keep digging.

Someone did start working on a libudev replacement to be able to get rid of udev/systemd altogether: http://lutz.donnerhacke.de/Blog/Das-udev-Drama

3 members found this post helpful.

Did anyone try busybox' mdev?

If that can be used inside an embedded system built with buildroot, maybe that could be included in Slackware

See here and there.

1 members found this post helpful.

Gentoo and LFS(CrossLFS) both have mdev deployment guides, and I think there is a Busybox package included with Slackware.

There is a busybox in the installer. But it uses udev, not mdev. Strictly speaking, a busysbox package wouldn't make much sense. But all what is needed to build (and modify, of so inclined) the installer's busybox is provided in /source/installer.

I did find this rather easily.

https://wiki.gentoo.org/wiki/Mdev

Not sure how well that would translate for Slackware usage, but have it as best you can.

Well, don't take my words in post #139 too seriously

I'm pretty confident that Pat is aware of all the alternatives anyway and will make a sound choice when that will become necessary.

*sarcasm* How did we ever get GNU/Linux working before udev came along... Oh well we could always go back to devfs and relearn manual device mount point mapping. Oh but wait... Nevermind.

Sorry for coming in late, and respond to questions from weeks ago. But, I was searching for something else, when I came across this interesting thread. Judging from many responses on this this thread, there are many Slackware people (but not all) who are concerned that udev will become so intertwined with system that they can not be disentangled.

I would describe myself to be pro-options rather than pro-systemd or anti-systemd. My greatest allegiance is to Linux in general, although I have found Gentoo to be my distro of choice.

When it comes to the Linux Kernel, or the entire GNU/Linux system as a whole, there has always been the issue of herding cats. Some developers choose follow a path other than the one followed by the majority. One of the theses behind Eric S. Raymond's "The Cathedral and the Bazaar" is that a divergence of solutions makes the GNU/Linux system as a whole stronger. This divergence prevents a sort of lock-in. That is to say, because there is one-way we have been doing things, there is only one-way forward. A problem can arise if a path reaches a dead-end where development reaches a place where it would be impractical to continue the paradigm. The beauty of the no-one-single-way approach is that if one path reaches a dead-end, developers could switch to the path less taken.

That is the reason, I am always pro-option. However, when taken to extremes the many-paths method can become self defeating. If there are too many paths, no path has enough developers to continue development, fix bugs and add necessary features. Sometimes, it helps if two parties join forces to developer a single system that is flexible enough to accommodate the needs of all involved. In a sense this is what it takes to be a successful cat herder.

My suggestion for those Slackware users/developers who are worried that udev may not suite the needs of some Slackware systems eudev may be the solution that is already at your feet. Eudev is currently uses by Gentoo users who use the OpenRC init system. However the started goals for eudev is that it not be dependent on Gentoo or OpenRC. The mission statement for eudev can be found HERE. Because eudev is system agnostic when it comes to both init systems and distributions, I think that if could be a win-win for Slackware developers and Gentoo developers to join forces in the development of eudev.

eudev project

1 members found this post helpful.

I agree but then again, we have had mdev through BusyBox for quite some time for Embedded Linux. It's system agnostic as well, but I don't think it has some capabilities udev has, but I've heard it can supplement those missing features in other ways.

I doubt Linux ever truly get rid of udev to be honest with you. A few drivers in X11 like evdev depend on udev in some way, though I have found evdev to be a lackluster/useless driver for my system.

Woooww! Long time no see Slackware community... Years. I am reading all the funny comments and just really laughing at it out loud (LOL).

So here is my intake on my experience using SystemD. Its pretty much ideal target for Server use. But I do see the advantages of init and editing with shell scripts in creating greater flexibility with more simplicity. In other words you don't have to learn a whole new init system to use it. Most of the heavy lifting is through shell scripts. And that is pretty much what makes it so special.

So if you know scripting + Desktop. The old system is better. If you don't know it and are new at linux then systemd has some good advantages. In the end ofcourse systemd is here to stay and Slackware will have to adopt due to everyone writing code towards systemd.

Systemd is pretty complicated compared to the old init even though it is feature rich and faster. To me its not that important change as it is to some of you "the sky is falling down" types that get a kick out of FUD.

There is some great guys in Slackware community but some of you all really mess it up. It makes Slackware Community look dumb because a lot of dumb comments from a few zealots.

So what is Slackware's best option in this. Well keep going on... Stick to the same philosophy. KISS but some things you gotta live with like systemd.

Ironically I am thinking of returning back to slackware... Because I gained a lot more experience in linux land and developing and as you mature you begin to understand the significant parts of Slackware that have always been there from the beginning.

Let me introduce you to this humorous Keynote of FreeBSD developer Poul-Henning-Kamp:

http://ftp.belnet.be/FOSDEM/2014/Jan...us_Report.webm

It contains a part ("PsyOps For Nerds") about community derailing in the interest of pushing the agenda of major commercial players. I can clearly see the patterns here, so PHK is right. Don't take it too seriously, though.
If the environment gets too hostile, it's time to leave it behind. There is always a choice.

Great share jtsn, I'm glad you posted this thanks

My Eyes are opened. But to be honest I always had this in the back of my head. I see your justification for Systemd with this video. But what about the Linux Kernel and all the other many components? They are all susceptible to it. Unless you go ahead and write your own OS and own protocols to communicate with. U r screwed no matter what!

A lot of sidework is being done to see if systemd can be avoided, and even remove udev in favor or other init and system device handlers. I've been working on importing Runit into Slackware as of recent, and others have been looking into things like OpenRC, mdev or eudev, and various other things too off the radar and outside of the Slackware inner-circle.

Bartgymnast has been working hard to get a working import of a completely minimized and mostly non-invasive systemd port for Slackware made, just in case. The works really good too, and we're all hoping for the best in any aspects.