Bye udev, nice knowing ya

[curaga]

http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI

Lennart Poettering has declared that the time is close to removing the ability to run udev without systemd.

[bmarkus]

Hopefully a clean udev fork will survive at least for a while.

[Juanito]

I saw a couple of distros had made a "systemd shim" to allow the timedate daemon to work without the rest of systemd - didn't manage to make it work on tc yet though...

[curaga]

That shim is not a sustainable path. The systemd-udev will keep requiring more and more of systemd as time passes.

[darry1966]

Slackware has developed eudev - so alternatives are out there.
http://www.blog.paranoidpenguin.net/2015/11/slackware-linux-is-moving-to-eudev/

[PDP-8]

erm, really old post but same topic I suppose ..

Speaking of slackware, I played around with PORTEUS, a slackware ram-based distro with what looks to be like "modules", which I suppose is somewhat in the same veign (but not exactly like) our on-demand.

Ver 4 supposedly any day now.  I suppose the lack of systemd, incorporating eudev, and the general slackware way of doing things, running in ram, this might be interesting to visit.  Got my first taste of vi on slackware back in '95.

Only 300mb.  I just need to cut out about 290mb, make busybox the init and login shell, and I'll be happy.   Interesting work.

[andyj]

I started using Slackware back in the early 90's on a screamin' 486-40. Almost a quarter century of slackin'. Slackware has a build system but no dependencies, TC has dependencies but no build system. Maybe that's why I like TC, too. It fills a void for me.

[PDP-8]

Funny you should say that - I get that same good feeling with TC / PiCore.  With Slackware, I had to *learn* stuff if I wanted something done my way.  Same with TC.

I didn't have a working cd-rom, but I had plenty of floppies and time as a young adult.  Downloaded it all by phone with mskermit on a shell account that I was totally lost in.

Even the Eudev thing kind of bugs me too.  Who knows where the Porteus guys may go.

 I don't know what's happening, but it seems the only way to *ensure* that we stay lean and mean is to use busybox as the main component.  And so far, that means Tinycore/picore/dcore.  Or as I'm using now testing midori, Slitaz (busybox init) rolling weekly 64-bit with the new kernel, but sad to see development seems to be in a slump other than rolling.

[hiro]

old thread but still relevant.

have there been any recent experiences by anybody on this topic?

i remember many years ago, the crux linux people were not using udev, they had something more barebones.

[PDP-8]

Well, 6 years after the original warning - one can simply choose what they like.  Crux, TC, Slackware, BSD's and all that are still around.  Looks like we still have a choice.

If I was a dev, and if looking for something new/different to hack on for TC with a toolset mindset, maybe S6?

I think looking beyond init systems, what concerns people now is that some applications or desktop environment contain init-specific hooks.  Waaah.

Use a different application, or build one of your own.  Stay flexible - that's what Unix is all about really - if you haven't built an invisible prison around you with all our free tools.

It's a bad analogy, but crying over application hooks would be like me getting totally upset when modern applications won't read my old Microsoft-Works files.  I shouldn't have put all my eggs in one basket.

Freedom of choice - run the init system you like - and if your beloved applications have hooks you can't abide by - well then that's the signal to look for new application / desktop pastures.

[gadget42]

Slackware 15.0 for those interested and/or curious

https://download.liveslak.org/

sharing is caring

[gadget42]

when i searched the forum for "Lennart Poettering" this thread was the most-recent-mention so i will post here instead of starting yet-another-new-thread...

Brave New Trusted Boot World - Lennart Poettering
https://0pointer.net/blog/brave-new-trusted-boot-world.html

from a recent post to:
https://planet.gnome.org/
rss feed:
https://planet.gnome.org/atom.xml

[hiro]

yeah, now that he changed to microsoft it all makes even more sense.
microsoft and intel are to control what operating systems you're allowed to run.

[gadget42]

https://0pointer.net/blog/linux-boot-partitions.html

[nick65go]

https://0pointer.net/blog/linux-boot-partitions.html

WTF? the article is about mostly systemd (aka cancer spreading) and UKI (unified kernel image).and XBOOTLDR partition.
- no match for searching "udev" word into the text; --> systemD useless for tinycore.
- UKI to incorporate "some configuration", --> making boot-loader / tc-config parameters useless? ; why? We can with a 164 KB grub-loader to boot from ESP into a ext2 partition containing kernel+core.gz.
- extra XBOOTLDR partition? hm.. we can have the same unique vFAT partition, seen as ESP (from GPT type disk) or boot-able FAT (from MBR type disk).

So, all the article is about perceived security (really?), because possible bugs in boot-loader and file-system drivers (linux) ; but hey, we then trust obscure bad-code programing in Firmware (BIOS / UEFI).