Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Why static /dev (old fashioned gentoo)?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
xanderal
Tux's lil' helper
Tux's lil' helper


Joined: 06 Mar 2019
Posts: 129
Location: Germany

PostPosted: Sat Oct 19, 2019 7:15 pm    Post subject: Why static /dev (old fashioned gentoo)? Reply with quote

Hej,
I'm wondering what the advantage of a static /dev is - so basically why would I want to use Old Fashioned Gentoo?
As of right now that is one of the last remaining differences between my current system and Old Fashioned Gentoo.
I googled a bit and also read forum7524448, forum7319236, forum1046536 and we also talked for a sec during elogind vs consolekit vs neither.
But right now I fail to see what my advantage would be over my current system with eudev. At the moment it looks like a fun exercise but not much more - so what did I miss? :lol:
Can't really imagine NeddySeagoon sticking to an experiment just for the heck of it since 2013...
Thanks in advance.
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 7497
Location: Saint Amant, Acadiana

PostPosted: Sat Oct 19, 2019 7:20 pm    Post subject: Reply with quote

Then you probably won't appreciate static IP address vs. DHCP and so on. Nowadays Linux systems are cluttered with all kind of "services" we didn't have before. Granted, our CPU-s are powerful enough to run all these and RAM is cheap. The only thing I see is the principle involved, why run all these "services" if we can do without? For instance, what good does avahi for you? Why it has to run all the time?
_________________
Please learn how to denote units correctly!


Last edited by Jaglover on Sat Oct 19, 2019 7:22 pm; edited 1 time in total
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 119

PostPosted: Sat Oct 19, 2019 7:22 pm    Post subject: Reply with quote

From what I understand, static dev is a way to avoid dealing with the issues that dynamic device node managers may present, be it configuration, dependencies, or perhaps a hostile community. Dynamic node managers hook into the same lower level kernel API in order to provide the nodes to begin with, so if you're already familiar with your hardware, why not cut down on another dependency? Especially since [e]udev depends on dbus at times (particularly if you also want Bluetooth support via net-wireless/bluez); some systems are able to divorce dbus, though it takes effort and nu Linux people have gotten creative with their dependency chain. (GTK+ requires accessibility support, which is what hooks into dbus, meaning you cannot have GTK+ applications without dbus)

If you're happy with eudev and don't want to learn how it provides your device nodes, then it'll be fine. If you're curious or want to work away from dbus, it might be worth learning. Like many choices in free software, it's up to you.

Edited to clarify that [e]udev doesn't require dbus directly, but *can* through bluez since it depends on dbus.


Last edited by spork_kitty on Mon Oct 21, 2019 12:47 am; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44907
Location: 56N 3W

PostPosted: Sat Oct 19, 2019 8:09 pm    Post subject: Reply with quote

xanderal,

First of all, I'm an old fart with a long memory.
At school, I was a bit of an oddball, being the only pupil in a school of about 1100 to claim computer programming as a hobby. :)
Static /dev was all there was for some time after I started Linux.

I went back to a static /dev as a way to avoid systemd, in case there should be no other way to go except BSD.
That was before this infamous email.
I remembered a lot and was surprised to find how much still just worked after correct manual configuration.
It was quite a nostalgia trip too.

That email spawned eudev, which in turn has curbed some of the worst excesses of systemd. However, when the promise in that email is made good one day, I wonder how long eudev can maintain functional equivalence with udev.
After all, Red Hat can bring more resource to udev inside systemd than Gentoo can ever hope to to keep eudev current.

I've stuck with it since that time. Hopefully, I'll be installing static /dev on new hardware early in the new year.
My 2009 Phenom II is getting a bit long in the tooth.

Another reason is just because I can.
Its fun too.

Lastly, there have been a few questionable design decisions in the last 20 years in Linux.
Static /dev has allowed me to ignore most or all of them. e.g. Separate /usr is broken ... really?



systemd is still a threat to users wanting to have their systems their own way. Not because it exists, or its there for you to choose. Its the declared aim of using systemd to make all Linux installs just Red Hat with a skin. (Yes I'm paraphrasing there)
If I wanted Red Hat I can install it. I choose not to and today, I still have that choice. As long as Old Fashioned Gentoo continues to work, that choice remains, whatever systemd does.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
xanderal
Tux's lil' helper
Tux's lil' helper


Joined: 06 Mar 2019
Posts: 129
Location: Germany

PostPosted: Sat Oct 19, 2019 9:36 pm    Post subject: Reply with quote

Thanks NeddySeagoon, I was counting on your response ;)
NeddySeagoon wrote:
That email spawned eudev, which in turn has curbed some of the worst excesses of systemd. However, when the promise in that email is made good one day, I wonder how long eudev can maintain functional equivalence with udev.
After all, Red Hat can bring more resource to udev inside systemd than Gentoo can ever hope to to keep eudev current.
That sounds to me like you worry about eudev not keeping up with future (not yet existing) features of udev? What would be the problem of eudev just staying where it is and just providing security/stability updates when needed?
NeddySeagoon wrote:
I've stuck with it since that time. Hopefully, I'll be installing static /dev on new hardware early in the new year.
My 2009 Phenom II is getting a bit long in the tooth.

Another reason is just because I can.
Its fun too.
That's kind of what I thought, it sounds like fun - just not sure if that justifies a reinstall for me.
NeddySeagoon wrote:
Lastly, there have been a few questionable design decisions in the last 20 years in Linux.
Static /dev has allowed me to ignore most or all of them. e.g. Separate /usr is broken ... really?
Could you elaborate on that? Compared to you I'm fairly new to linux apparently (~2012, understanding stuff since ~2018 at the earliest probably) and might take some things as a given that changed recently.
NeddySeagoon wrote:
As long as Old Fashioned Gentoo continues to work, that choice remains, whatever systemd does.
Since you're not just a user but a dev - do you have any say in the question of keeping (or starting) support of Old Fasioned Gentoo?
EDIT: Concerning the email:
NeddySeagoon wrote:
That email spawned eudev, which in turn has curbed some of the worst excesses of systemd. However, when the promise in that email is made good one day
Considering that he wrote that five years ago - is it still likely that that is going to happen? Or better: When do you expect it to happen? What has stopped RH/LP from doing that?

Last edited by xanderal on Sat Oct 19, 2019 9:49 pm; edited 1 time in total
Back to top
View user's profile Send private message
xanderal
Tux's lil' helper
Tux's lil' helper


Joined: 06 Mar 2019
Posts: 129
Location: Germany

PostPosted: Sat Oct 19, 2019 9:45 pm    Post subject: Reply with quote

Jaglover wrote:
Then you probably won't appreciate static IP address vs. DHCP and so on. Nowadays Linux systems are cluttered with all kind of "services" we didn't have before. Granted, our CPU-s are powerful enough to run all these and RAM is cheap. The only thing I see is the principle involved, why run all these "services" if we can do without? For instance, what good does avahi for you? Why it has to run all the time?
Right now I use dhcp but I have been thinking about static ip - just again not have seen the need for/advantage of it yet.
I do enjoy edging towards a system that's more bare bones, so recently I threw out the *kits, never had avahi installed but masked it for good measure after reading poettering wrote it and now thinking about removing (e)udev as well - hence the thread ;)
spork_kitty wrote:
From what I understand, static dev is a way to avoid dealing with the issues that dynamic device node managers may present, be it configuration, dependencies, or perhaps a hostile community.
What do you mean by configuration issues?
spork_kitty wrote:
Dynamic node managers hook into the same lower level kernel API in order to provide the nodes to begin with, so if you're already familiar with your hardware, why not cut down on another dependency? Especially since [e]udev depends on dbus for its messaging; some systems are able to divorce dbus, though it takes effort and they've gotten creative with their dependency chain. (GTK+ requires accessibility support, which is what hooks into dbus, meaning you cannot have GTK+ applications without dbus)
Is there another reason to leave dbus behind other than just because you can?
spork_kitty wrote:
If you're happy with eudev (and thus dbus) and don't want to learn how it provides your device nodes, then it'll be fine. If you're curious or want to work away from dbus, it might be worth learning.
Neither lazyness nor a lack of curiosity are a problem here ;) I definitely want to know more about the inner workings of my system, just not sure whether static dev is the way to go about doing that...
edited
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4398
Location: Dallas area

PostPosted: Sat Oct 19, 2019 10:22 pm    Post subject: Reply with quote

Note: There is a patch to keep accessibility bridge out of gtk+3 which drops the need for dbus, just because you're running gtk.

As far as dbus run it if you want, don't if you don't want to.
I avoid it for the same reason I avoid all things that LP and company have a hand in, I don't trust them.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44907
Location: 56N 3W

PostPosted: Sat Oct 19, 2019 10:42 pm    Post subject: Reply with quote

xanderal,

Started playing with computers when I was a 10 years old. That's late for children these days but that was around 1963.
It was on one of these
That means I've been playing with computers for over 50 years.
I started with Linux in 1999 and Gentoo in mid 2002. I came to the forums when I needed to expand my SETI@home farm into a second subnet.

I'm what used to be called a staffer, I'm not an ebuild dev. That means when your Gentoo breaks, it wasn't me as I cannot commit to ::gentoo.
As far as I know, I'm the only dev interested in Old Fashioned Gentoo and it was me that started it.
It not an official Gentoo project. I do not expect other devs to support the USE=olde-gentoo flag required to get some things to build.
After all, its not a configuration they can test. Its very much a minority use case.

I support it, here in Unsupported Software, so I guess I have a say.

eudev must remain functionally compatible with udev. If not, it can't be considered a udev replacement.
Programs that depend on new udev functions need to work if either udev or eudev is installed. Staying where it is is not an option.
I suspect it has to be bug compatible too. Think back to when Via, Cyrix and AMD began to produce Intel compatible CPUs.
Intel didn't help. All these would be competitors had to go on were publicly available documents and Intel CPUs that they bought.
In the early days, there were problems because Intel CPUs had bugs that the Via, Cyrix and AMD compatibles were missing.
They did what the databook said, not what the Intel part actually did. eudev needs to be that close to udev. That will be hard and Red Hat can deliberately make it more difficult.
I don't worry about udev, or eudev as I don't use either.
When I started Old Fashioned Gentoo, eudev did not exist.

Questionable design decisions.
Breaking separate /usr.
Introducing /run as a hack to satisfy the need for write space while root was still read only.
The /usr merge into /. That makes a read only shared over NFS /usr difficult.
Making the initrd the new root.
Persistent network device names that only changed one group of corner cases for another group of corner cases.
The nofail mount option, we have to live with that.
That's all that come to mind right now that are still with us.

Then there was hal, thats come and gone. XML configuration files now mostly gone.
None of these are of any concern to binary distro users as they are all invisible to users.
Gentoo 'users' are distro designers and not just users, so this sort of thing matters.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
GDH-gentoo
Apprentice
Apprentice


Joined: 20 Jul 2019
Posts: 206
Location: South America

PostPosted: Sun Oct 20, 2019 2:16 am    Post subject: Reply with quote

spork_kitty wrote:
Especially since [e]udev depends on dbus for its messaging;

It does not. Other parts of systemd use D-Bus, but not the udev parts. And neither does eudev.

xanderal wrote:
EDIT: Concerning the email:
NeddySeagoon wrote:
That email spawned eudev, which in turn has curbed some of the worst excesses of systemd. However, when the promise in that email is made good one day
Considering that he wrote that five years ago - is it still likely that that is going to happen? Or better: When do you expect it to happen? What has stopped RH/LP from doing that?

The kdbus proposal not meeting the kernel developers' quality standards and going nowhere as a result stopped that.

EDIT to add:
NeddySeagoon wrote:

Introducing /run as a hack to satisfy the need for write space while root was still read only.

What do you find questionable about that?
Back to top
View user's profile Send private message
axl
l33t
l33t


Joined: 11 Oct 2002
Posts: 910
Location: Romania

PostPosted: Sun Oct 20, 2019 4:02 am    Post subject: Reply with quote

Takes a special kinda fellow to keep up with 20 years old kernel 2.2 technology. M$ has it's nuts with XP, why can't linux has it's own.

You guys scare me. terry davis vibes.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44907
Location: 56N 3W

PostPosted: Sun Oct 20, 2019 10:01 am    Post subject: Reply with quote

GDH-gentoo,

The whole boot process on a PC is a mess. Its the way the PC has evolved.
Originally, it was the BIOS loaded the first block from a floppy and that loaded a program from the floppy that had to be smaller than 64kB.
It was usually command.com but could be anything.
That was it. command.com then said A:\ and it was all yours.
That was in effect, the operating system.

The concept of directories, partitions, hard drives, network cards and so on, in PCs did not exist.

For some years the boot process has been layers of circular dependencies that need to be broken to get a system that cannot read a hard drive to load an operating system from the hard drive.
/run is a result of adding to this house of cards without doing proper system design first. Its yet another answer to breaking another round of circular dependencies that were not required in the first place.

UEFI tried to address this but came with its own problems. e.g. the dependence on vfat, which does not support permissions nor symlinks.
Perhaps I should not tar UEFI with the Trusted Platform concept but its difficult to separate them since they were introduced about the same time.
The Trusted Platform idea is to hand over the keys to the private key owners. The equipment owner is not trusted.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44907
Location: 56N 3W

PostPosted: Sun Oct 20, 2019 10:06 am    Post subject: Reply with quote

axl,

You don't understand.
The 5.2 kernel works fine. Just turn off DEVTMPFS so that the kernel does not mount and populate /dev.
Don't install [emu]dev so device node creation and /dev node permissions management is under user control.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3540
Location: Illinois, USA

PostPosted: Sun Oct 20, 2019 4:40 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Started playing with computers when I was a 10 years old. That's late for children these days but that was around 1963.

Wow! the same year as me, but I was 18, an entering freshman at I.I.T. (Illinois Institute of Technology). Hollerith cards and all.

So I'm eight years older than you. see, youare a spring chicken. :wink:
Back to top
View user's profile Send private message
GDH-gentoo
Apprentice
Apprentice


Joined: 20 Jul 2019
Posts: 206
Location: South America

PostPosted: Sun Oct 20, 2019 6:42 pm    Post subject: Reply with quote

NeddySeagoon wrote:
The whole boot process on a PC is a mess. Its the way the PC has evolved.

OK, but what makes mounting a tmpfs to guarantee the availability of a read-write filesystem so egregious that it made it to a list that contains 'jewels' like broken separate /usr and usr-merge (if that's what you meant)?

NeddySeagoon wrote:
For some years the boot process has been layers of circular dependencies that need to be broken to get a system that cannot read a hard drive to load an operating system from the hard drive.

Hmm, I don't see circularity, I see the process more as a sequence of components taking control in order, each of which is a little smarter that the previous one.
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 119

PostPosted: Sun Oct 20, 2019 9:28 pm    Post subject: Reply with quote

xanderal wrote:
spork_kitty wrote:
From what I understand, static dev is a way to avoid dealing with the issues that dynamic device node managers may present, be it configuration, dependencies, or perhaps a hostile community.
What do you mean by configuration issues?


"Predictable" Network Interface Names, to start. Otherwise, [e]udev may change behavior in settings in later versions, and someone who's quite happy with their devtree may not want to add more dynamism to it. Granted, setting `net.ifnames=0` in the kernel line (and creating /etc/udev/rules.d/80-net-name-slot.rules) isn't difficult, but that's only *one* change that creates two new tasks for the administrator. I still use eudev, but I can fully understand why someone would want to avoid such circus antics.

xanderal wrote:
spork_kitty wrote:
Dynamic node managers hook into the same lower level kernel API in order to provide the nodes to begin with, so if you're already familiar with your hardware, why not cut down on another dependency? Especially since [e]udev depends on dbus for its messaging; some systems are able to divorce dbus, though it takes effort and they've gotten creative with their dependency chain. (GTK+ requires accessibility support, which is what hooks into dbus, meaning you cannot have GTK+ applications without dbus)
Is there another reason to leave dbus behind other than just because you can?


Personally, I have read through the design spec for dbus and I don't see why one needs RPC as IPC. The reverse TLD notation for the stream identification is reminiscent of Java, which is IMO busted. I don't see a reason to use dbus over text streams, sockets, or other, simpler IPC mechanisms. Socially speaking, D-Bus is peddled by FreeDesktop, which aims to coalesce all Linux desktop software to use the same "standards" and is close to IBM/Red Hat, who I hold responsible for many of these backwards "innovations" that've struck Linux land for the past decade plus. Some more reading about other turds by FDO. Frankly, it's enterprise-level complexity that has no place on a desktop machine.

xanderal wrote:
spork_kitty wrote:
If you're happy with eudev (and thus dbus) and don't want to learn how it provides your device nodes, then it'll be fine. If you're curious or want to work away from dbus, it might be worth learning.
Neither lazyness nor a lack of curiosity are a problem here ;) I definitely want to know more about the inner workings of my system, just not sure whether static dev is the way to go about doing that...


Sorry, I meant that as a general perspective rather than anything to you personally. I tried to come up with simple and/or practical reasons both for and against using static dev.

GDH-gentoo wrote:
spork_kitty wrote:
Especially since [e]udev depends on dbus for its messaging;
It does not. Other parts of systemd use D-Bus, but not the udev parts. And neither does eudev.


Check `equery g sys-fs/eudev --depth=5`. dbus appears under net-wireless/bluez. So, if you use bluetooth devices then udev will be forced to use dbus to communicate with the bluetooth daemon. Not required in all cases, but easy to pull into the deptree, all according to keikaku. To my knowledge there is no way to use bluetooth devices on Linux without bluez. Its dbus dependency was a tactical choice.

I'll amend my prior comment to mention bluetooth so the origin of the problem is better explained.

Anon-E-moose wrote:
Note: There is a patch to keep accessibility bridge out of gtk+3 which drops the need for dbus, just because you're running gtk.


Awesome! Do you have a link? GTK is one of the last hold-outs of dbus on my machine and I intend to either zap it or patch it.

NeddySeagoon wrote:
Gentoo 'users' are distro designers and not just users, so this sort of thing matters.


Well said! I hadn't thought of us as distro designers but that's what the nuts and bolts work really is.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44907
Location: 56N 3W

PostPosted: Sun Oct 20, 2019 10:04 pm    Post subject: Reply with quote

You plug a USB stick into a freedesktop system and it mounts and lets random users execute nasty things from it. Shudder.
It creates a dynamic device node when the device is plugged in.

Plug in a random USB storage device into my my system and nothing happens.
It either needs to be a known device, in which case, its listed in /etc/fstab with the users and noexec option, or you need to be able to use mount as root. Not that I'm paranoid or anything.
Of course, you may also need to create a few /dev nodes too.

A long time ago I got rid of auto mounting. That was in the days when it was possible to use a DVD+RW like a 4.7G floppy.
However, each mount cost a write to the superblock and the media is only good for about 1000 writes, so auto mounting killed DVD+RWs.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
axl
l33t
l33t


Joined: 11 Oct 2002
Posts: 910
Location: Romania

PostPosted: Sun Oct 20, 2019 10:16 pm    Post subject: Reply with quote

NeddySeagoon wrote:
axl,

You don't understand.
The 5.2 kernel works fine. Just turn off DEVTMPFS so that the kernel does not mount and populate /dev.
Don't install [emu]dev so device node creation and /dev node permissions management is under user control.


No, I get it, and I do know the difference. At least the technical part of it. It's just that it's not something I expected people to use. Or cherish the freedom to do this.

What I meant about kernel 2.2 is that dynamic dev was created in 2.3. Thus 2.2 was a time when people thought it's good enough. After that they changed their mind and thought to go the dynamic way and have been doing that ever since.

Which raises the issue we collectively have, yet again. I may get it technically but I don't get it philosophically. And I don't think I'm supposed to get it. It's a matter of personal preference and those are not matter to criticism.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4398
Location: Dallas area

PostPosted: Sun Oct 20, 2019 10:46 pm    Post subject: Reply with quote

spork_kitty wrote:

Anon-E-moose wrote:
Note: There is a patch to keep accessibility bridge out of gtk+3 which drops the need for dbus, just because you're running gtk.


Awesome! Do you have a link? GTK is one of the last hold-outs of dbus on my machine and I intend to either zap it or patch it.


I don't know where I originally posted it but here's a current download http://dpaste.com/028P0T5 (haven't tested it since gtk+-3.24.8 ) but it should work.
I put it in /etc/portage/patches/x11-libs/gtk+:3
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
GDH-gentoo
Apprentice
Apprentice


Joined: 20 Jul 2019
Posts: 206
Location: South America

PostPosted: Sun Oct 20, 2019 11:00 pm    Post subject: Reply with quote

spork_kitty wrote:
Check `equery g sys-fs/eudev --depth=5`. dbus appears under net-wireless/bluez. So, if you use bluetooth devices then udev will be forced to use dbus to communicate with the bluetooth daemon.

No, that is an incorrect interpretation of equery's output. Bluez appears in the dependency graph because it can be pulled by Python if the bluetooth USE flag is set. Python is an optional dependency of util-linux, which is a dependency of eudev. And it is an optional dependency of an optional dependency of util-linux, libcap-ng. That's all.

According to the ebuild, Python pulls bluez because apparently it needs some bluez headers to build. So it isn't a runtime dependency.

spork_kitty wrote:
To my knowledge there is no way to use bluetooth devices on Linux without bluez. Its dbus dependency was a tactical choice.

D-Bus would be a bluez 'problem' (if you object to D-Bus), not an eudev problem.
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 119

PostPosted: Mon Oct 21, 2019 1:05 am    Post subject: Reply with quote

GDH-gentoo wrote:
spork_kitty wrote:
Check `equery g sys-fs/eudev --depth=5`. dbus appears under net-wireless/bluez. So, if you use bluetooth devices then udev will be forced to use dbus to communicate with the bluetooth daemon.

No, that is an incorrect interpretation of equery's output. Bluez appears in the dependency graph because it can be pulled by Python if the bluetooth USE flag is set. Python is an optional dependency of util-linux, which is a dependency of eudev. And it is an optional dependency of an optional dependency of util-linux, libcap-ng. That's all.

According to the ebuild, Python pulls bluez because apparently it needs some bluez headers to build. So it isn't a runtime dependency.

spork_kitty wrote:
To my knowledge there is no way to use bluetooth devices on Linux without bluez. Its dbus dependency was a tactical choice.

D-Bus would be a bluez 'problem' (if you object to D-Bus), not an eudev problem.


How is that any different from "if you use udev with bluetooth, you will run into dbus"? Regardless of why, it's still in the dependency tree.
Back to top
View user's profile Send private message
fpemud
Apprentice
Apprentice


Joined: 15 Feb 2012
Posts: 289

PostPosted: Mon Oct 21, 2019 1:22 am    Post subject: Reply with quote

Quote:
However, each mount cost a write to the superblock and the media is only good for about 1000 writes, so auto mounting killed DVD+RWs.


NeddySeagoon, can you elaborate more on this? what filesystem did you use?
Back to top
View user's profile Send private message
xanderal
Tux's lil' helper
Tux's lil' helper


Joined: 06 Mar 2019
Posts: 129
Location: Germany

PostPosted: Mon Oct 21, 2019 2:32 am    Post subject: Reply with quote

Anon-E-moose wrote:
As far as dbus run it if you want, don't if you don't want to.
I avoid it for the same reason I avoid all things that LP and company have a hand in, I don't trust them.
Yes, that is kind of the approach I have taken, too and one of the main reasons for all the cleanup on my system. I was just wondering if there is another concrete reason to specifically avoid dbus and not just LP/RH stuff in general.
spork_kitty wrote:
"Predictable" Network Interface Names
[...]
the design spec for dbus
[...]
Some more reading about other turds by FDO.
Thanks for that. I'll start reading now I suppose :lol:
spork_kitty wrote:
Sorry, I meant that as a general perspective rather than anything to you personally. I tried to come up with simple and/or practical reasons both for and against using static dev.
Don't worry, I don't feel attacked, just wanted to make sure you don't hold back ;)
Back to top
View user's profile Send private message
xanderal
Tux's lil' helper
Tux's lil' helper


Joined: 06 Mar 2019
Posts: 129
Location: Germany

PostPosted: Mon Oct 21, 2019 2:50 am    Post subject: Reply with quote

NeddySeagoon wrote:
I'm what used to be called a staffer, I'm not an ebuild dev. That means when your Gentoo breaks, it wasn't me as I cannot commit to ::gentoo.
As far as I know, I'm the only dev interested in Old Fashioned Gentoo and it was me that started it.
It not an official Gentoo project. I do not expect other devs to support the USE=olde-gentoo flag required to get some things to build.
After all, its not a configuration they can test. Its very much a minority use case.
Do the other devs (especially ebuild devs) have some contingencies in place for when LP/RH make it really difficult for non-systemd? Or are we just screwed then?
What do you mean by that USE flag? I haven't found that - or are you proposing that as a future possibility in case other devs would start to get interested in static /dev again?
GDH-gentoo wrote:
The kdbus proposal not meeting the kernel developers' quality standards and going nowhere as a result stopped that.
Ok, but that still means that they can come back with it and try again, right? I mean it's not dead for good...
NeddySeagoon wrote:
I support it, here in Unsupported Software, so I guess I have a say.
Good to know :)
But what about sys-fs/static-dev? How certain is it that it keeps getting maintained/in tree?
NeddySeagoon wrote:
eudev must remain functionally compatible with udev. If not, it can't be considered a udev replacement.
[...]
Ah, ok, I hadn't thought of that but of course, that makes sense.
NeddySeagoon wrote:
Questionable design decisions.
Breaking separate /usr.
[...]
Making the initrd the new root.
Hmm, never before heard of separate /usr, probably should read up on that...
What is the issue with initrd?
NeddySeagoon wrote:
You plug a USB stick into a freedesktop system and it mounts and lets random users execute nasty things from it. Shudder.
It creates a dynamic device node when the device is plugged in.

Plug in a random USB storage device into my my system and nothing happens.
But that is just missing udisks/automounting stuff, right? Because I think that's the same for me, too...
NeddySeagoon wrote:
It either needs to be a known device, in which case, its listed in /etc/fstab with the users and noexec option, or you need to be able to use mount as root. Not that I'm paranoid or anything.
Of course, you may also need to create a few /dev nodes too.
What other mount options would you recommend then?
How does one create /dev nodes? Actually what really does that mean? Could you point me to some good reading material on that topic?

@axl: Thank you for the clarification. But I was more interested in discussing the advantages of static /dev rather than getting into an argument over whether it is better/worse/whatever than (emu)dev or not or whether it was a good decision to move towards them or not.
Back to top
View user's profile Send private message
axl
l33t
l33t


Joined: 11 Oct 2002
Posts: 910
Location: Romania

PostPosted: Mon Oct 21, 2019 3:04 am    Post subject: Reply with quote

xanderal wrote:
@axl: Thank you for the clarification. But I was more interested in discussing the advantages of static /dev rather than getting into an argument over whether it is better/worse/whatever than (emu)dev or not or whether it was a good decision to move towards them or not.


It's one of those things. I doubt anyone would try or even consider this if things weren't like this at one point. Someone remembers, therefor someone tries. And it becomes a thing. I call it a personal preference, because it's hard to imagine someone in 50 years doing this.

Its much simpler to just turn off autorun, than to force current linux to run by 90's/2000's rules. literally. turning off autorun 1 minute. a system against systemd... hours of work and research and testing and stuff.

Not that it can't be done. It's that it's not worth wasting time with 90's linux. You know, just because you lack a certain block file in /dev it doesn't mean you can't make another one with mknod. or bring one in a tar with wget. And your whole sense of security is just wrong... There. takes a few seconds to bring down hours of work that you guys invest in NOT having a dynamic dev. that's just fine. but block files don't need to be in /dev and also can be moved around with tar. :) ooops.

But by all means. Practice makes perfect. I have nothing against that. But it is exactly that. Practice. A retrospective into how things used to be. Much harder for no reason. Go ahead and practice. :)
Back to top
View user's profile Send private message
xanderal
Tux's lil' helper
Tux's lil' helper


Joined: 06 Mar 2019
Posts: 129
Location: Germany

PostPosted: Mon Oct 21, 2019 4:17 am    Post subject: Reply with quote

Well, I think when it comes to this you're talking to deaf ears. I think most if not everyone else reading/commenting on this thread (but definitely me) is an irredeemable opponent of LP/RH and other things you've been advocating for :twisted: . So, thanks again for your contribution but please let's get back to topic and discuss reasons for a static /dev and maybe how to make sure that option stays viable for the foreseeable future.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum