Is the way forward for Gentoo documented anywhere, with respect to udev, systemd, fork(s) of udev, sticking with OpenRC, etc.? Is there an official plan?_________________Deja Moo: the feeling that you've heard this bull before

Yes, I understand. Good plans often involve developing information, reducing uncertainty, and then making decisions.

So, does "untangle" mean obtaining an unambiguous commitment, from whoever governs the architecture of systemd and udev, to modularity, enabling distributions using init/rc systems other than systemd to make architecturally clean, unencumbered use of udev for the foreseeable future?

I get the sense, from one statement he made, that Mr. Poettering's vision is a world where everybody eventually migrates to systemd. After people raised some fuss, he has spent a lot of time making carefully-worded statements indicating udev remains effectively seperable and things will still work as is "for a long time". But, frankly, I don't see any commitment to a permanently seperable architecture. I'd rather know now than be lied to.

Does openly talking about this create problems?_________________Deja Moo: the feeling that you've heard this bull before

Yes. It is likely that you will get soon attacked by some Poettering fanboys. I realized this in many forums. This man is like a Guru with fanatic followers which throw buzzwords like "necessary unification", "old methods not appropriate for modern systems" etc., of course avoiding all actual technical facts, since otherwise they would be lost.
It became clearly visible when the two udev forks happened: The original arguments ("No one forces you to use Poetterings programs - you are always free to program and fork") was suddenly changed to "the intention of this fork is only to be hostile". It is really a pity to see how this guru and his technically unskilled but apparently socially well-trained followers are sytematically attempting to destroy the idea of FOSS.

I initially thought there would be one.
Some collection of strategic views / commitments from the Gentoo Counsil.
At least some development of some vision of the future shared by the most prominent Gentoo devs we get, I mean, but not exclusively, people such as Diego, Greg, well, you know, those who are used to and have the capabilities to tell what is wrong !

I tried to find out some sort of strategic plan on only a small part of your topic there https://bugs.gentoo.org/show_bug.cgi?id=447072, which, by the way, highlights (from the answers obtained) that Gentoo Devs are themselves working without any forseenable future...

As far as "we" are concerned, I would tend to think that we are in a "Chacun sa me***" situation. (I do not know how to translate this in English... something like each to his own... but there is one important concept lost in that translation... )_________________

people such as Diego, Greg, well, you know, those who are used to and have the capabilities to tell what is wrong!

I would not rely on such opinions, because in principle, they are just that - opinions.
However, at least Diego was quite optimistic in some blog entry that the coupling of udev and systemd will not become mandatory in the foreseeable future, since otherwise eudev would certainly take over.
Unfortunately, this does not exclude that Poettering might strategically wait until the fork dies (like the first already did due to lack of resources), and then take the advantages of the monopolist. Of course, this is also a reason why this fork is attacked so unusually strongly.

The last thing I want to do is start yet another ranting session. I'm sure that what Mr. Poettering is doing makes sense from his perspective, although it may be the desire of others that udev be cleanly separable. Without making any judgements, I for one do not believe it is his intent they remain cleanly separable indefinitely.

I think all discussions people are having about this will be more productive if they don't get too personal in a critical sense.

I don't even necessarily want to know what Gentoo's plan is; mostly I'd just like some reassurance that there is one. Beyond that, it might be nice to know what it is (but I can understand there may be reasons why it not to be public knowledge).

But, really, it's enough for me to know what NeddySeagon said, which is essentially that we're keeping our options open at this point, and I do not want to stir up even more discord._________________Deja Moo: the feeling that you've heard this bull before

I don't even necessarily want to know what Gentoo's plan is; mostly I'd just like some reassurance that there is one. Beyond that, it might be nice to know what it is (but I can understand there may be reasons why it not to be public knowledge).

I don't really see anything changed regarding sys-fs/udev. As in, 197-r3 is just another upgrade among others. If systemd guys keep udev sane as it is now, I don't see any reason why the default in virtual/udev would change.
If they do something really stupid, then we can re-evaluate the situation.

Doesn't really need a plan yet as things are as they have always been regarding udev (and it's stabilization).

I realize he probably felt he was addressing a limited audience with that message, and that he has made a number of conciliatory statements since then addressing concerns that have arisen, but I have seen nothing in these carefully-worded statements that contradicts what is in that message.

So, if "udev on non-systemd systems" is indeed "a dead end" -- if that's their real vision -- then we have two choices: either move to systemd or find an alternative to udev. The only reason I can see not to acknowledge this now is if there is a possibility that his/their mind(s) can be changed with regard to that. Hence, I was wondering if that (the possibility of changing minds) is what NeddySeagoon was referring to when he referred to "untangling" the two.

Additionally, Gentoo is not the only udev stakeholder with (apparently) no intent of using systemd. It might be useful if everyone in that position at least communicated about the possibility of pooling resources to achieve a common solution._________________Deja Moo: the feeling that you've heard this bull before

While udev can be used without systemd there is no need to plan to do anything. If we wake up one day and find that udev is no longer separable from systemd, they Gentoo needs to make a choice. Until then, its business as usual.

There are several choices now, depending on your needs
systemd (yes, it really is a choice)
eudev
mdev
static /dev
Anything else in the udev virtual.
There is also the short term, use the last useful version of udev. That buys us a month or two to plan.

Personally, I hope the good idea fairy pays the systemd devs another visit and they get to understand that 'vertical integration' is a terrible idea.
I've been there, done that and seen a project scrapped because with 'vertical integration' the code was unmaintainable. It couldn't even be debugged well enough to make a first delivery. On the basis of that experience I have systemd hard masked.

I hope that a choosing among udev alternatives will not be required any time soon, if ever, but like you, being prepared is always a good idea._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

im using systemd, only loss so far is apache... vsftpd unit file i drew up from scratch (and permit to cross over from gentoo-wiki to wiki.gentoo.org) works well. can a dev plz start a unit file hoard on the wiki for me to add to.....

as just a user I think systemd main fault is to be a binary controlling ALL. That remains the soles point of failure.

Latest systemd's/Potter 'propaganda' effort is his 'debunking 30 myths' on his blog and all.

True, each of those 30 points do solve something and are amazing solutions.

Yet, cramming ALL those pieces into a single binary doesn't seem to be a very wise idea.

The init scripts are pieces of script that manually bring up services, if a service screws up doesn't affect the rest. Looks like having scripts plus openrc (more manual) adds two steps to ensure things work. Whereas with systemd's unification zeal has the potential to do to many things for itself (which seems to be the road is taking). 'ooooh aahh systemd get's rid of a,b, c, d, f ... tasks into a single binary!!!'

Besides, do you really need a binary to this?

modprobe foo

lololol

In anycase it remains to bee seen how systemd fares, only time will tell.

The controversy lies in the difference of paradigm I think, binary versus scrips. On phoronix one commenter call's systemd m$$$ registry implementation on linux.

as just a user I think systemd main fault is to be a binary controlling ALL.

The binary is not the main issue, but there are several bad ideas related with the way systemd+*kit attacks things:

Having daemons permanently running - this is a needless waste of resources. Even if on machines nowadays it is not much, we have nothing to waste, especially not to waste permanently just to save 2 seconds for booting.

The idea to replace scripts by config-files means - well, it means to restrict the user's possibility for flexible setups. The *kit-guys have meanwhile realized that configure files will never be flexible enough and saw the need to introduce javascript.

Summarizing, what is effectively done? Yes, they have replaced a scripting language (shell) by another scripting language (java-script), but with confusing and error-prone intermediate daemon levels which need permanent resources, even so much that the main job the tool is supposed to do - booting - has even become impossible if not something else (ramdisk) does all the dirty work for it in advance by shell scripts. Great job!

Unfortunately my message text got "lost" and I can't retype everything at the moment, but briefly I wanted to comment that I was surprised by the recent decision to stabilize udev-197 and the abrupt proposal to migrate to the new systemd/udevd network interface naming scheme. The new network interface naming scheme was only proposed just the other day for Fedora 19 on the Fedora-dev list, and by no means seemed certain even there. And this is Gentoo.

What exactly was the problem with udev-17x that -197 solves? The new udev seems much buggier, while the older one was working fine even with the most recent kernels. Hmm.. Lots of executables now link to libsystemd-daemon.so.0 too.

Unfortunately my message text got "lost" and I can't retype everything at the moment, but briefly I wanted to comment that I was surprised by the recent decision to stabilize udev-197 and the abrupt proposal to migrate to the new systemd/udevd network interface naming scheme. The new network interface naming scheme was only proposed just the other day for Fedora 19 on the Fedora-dev list, and by no means seemed certain even there. And this is Gentoo.

What exactly was the problem with udev-17x that -197 solves? The new udev seems much buggier, while the older one was working fine even with the most recent kernels. Hmm.. Lots of executables now link to libsystemd-daemon.so.0 too.

More later...

The new networking scheme is not enabled by default for stable users, and not even ~arch users when upgrading; only for new ~arch udev users. This can easily be reverted if the new network naming scheme doesn't fly.

There are no problems with linking to libsystemd-daemon.so -- If you are just annoyed by the library name, then "oh, please, really complaining about cosmetics that has nothing to do with functionality?"

And in 171 you had to chose between broken path-by symlinks and broken rule_generator (and /dev/cdrom symlink). And that's the most visible problem it had out of dozens. The 171 is so buggy I'm actually somewhat embarressed it's still in Portage as giving impression it's still supported. It's really not and is about to be removed from tree.

Futhermore the new internal hwdb among other features is now used by sys-fs/udisks, both SLOTs, which involves any desktops automounting capabilities, 171 just didn't do the job anymore.

I don't even necessarily want to know what Gentoo's plan is; mostly I'd just like some reassurance that there is one. Beyond that, it might be nice to know what it is (but I can understand there may be reasons why it not to be public knowledge).

There is something you need to understand about Gentoo, which I didn't really understand for a long time. Gentoo is a loose collection of developers, without any appointed leadership (on a lower level we have project leads, which may or may not actually act as leaders). The Council is not our leadership either—they act more like a supreme court, and only decide on things that are referred to them, when developers cannot come to an agreement among themselves. We share some values, but most of them are not explicit either. As a result, there is no plan. We have no common, explicitly stated, goals or vision.

What happens is mostly that the people who do the work make the decisions and decide the way forward. They may or may not have a plan. As long as individual developers remain within the rules that QA and DevRel enforce, they can pretty much do what they want, until they do something so controversial that it is brought to DevRel or Council. We have the gentoo-dev mailing list where things are discussed as well, but individual developers may choose to ignore that. But in reality, people who are vocal on the dev mailinglist usually do have an influence on shaping policies and the direction that things are going.

So what happens is in effect a mixture of meritocracy and anarchy.

So, that said, as an answer to your original question: no, there is no official plan. For now it is up to the developers who maintain the involved packages. The status quo is OpenRC and standalone udev (through some ebuild hackery) are remaining the defaults in Gentoo. The plan, such as there is one, is keeping the status quo.

This may change as soon as systemd-udev upstream will make the maintenance costs of us producing and maintaining a standalone udev ebuild much higher than it is now, or when the maintainers change their mind about what they are willing to do. On the other hand, when eudev becomes more mature, it will become more interesting as a possible new default.

And it is much more likely we will switch udev implementation than init system. There is a lot of love for OpenRC, and a lot of resistance against systemd and the vertical integration they stand for. The idea of Gentoo switching its default to systemd would be very controversial, to say the least. If that would be pushed through, I think that would likely result in a break-up/fork of the distro._________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

Thank you for these valuable insights. That pretty much fills in the gaps for me.

Also, I don't mean to be critical of the lack of a "plan" per se. Loosely governed anarchy has its benefits along with its drawbacks (and I mean "anarchy" there without any of the usual negative connotations; I mean "highly decentralized governance).

Maybe I should monitor the dev mailing list if I'm interested in such things, rather than asking whiny questions in here and setting off more rants. Thank you both, and Neddy, for taking the time to answer._________________Deja Moo: the feeling that you've heard this bull before

That individual apparently needs to read more of what they have said. I think they've pretty clearly stated their intentions. It's possible that they've got so much grief about it they may feel pressured into maintaining explicit modularity, and maybe they need help to be able to do so, but from what I see, the intent is clear: use systemd or you're on your own as far as getting udev to function as a separate product.

That individual's "could have done that already" logic makes no sense and fails to recognize the evolutionary nature of the changes being made (which appear to me to be intended to gradually compel everyone to migrate to systemd). Now, maybe doing that would not be a bad thing necessarily, but people need to be honest about things.

How much tangible involvement in the eudev project has emerged from non-Gentoo folks?_________________Deja Moo: the feeling that you've heard this bull before

Reading ajax's take on choice, and those of his Red Hat compatriots in the follow-ups, it is clear that Red Hat and Gentoo have divergent goals/principles. Gentoo sees Linux as an ecosystem, Red Hat sees it as a platform for *their* OS._________________Personal overlay | Simple backup scheme

After reading yngwin's explanation of how Gentoo works, I still have one doubt. I can understand that developers can work freely on whatever they like and so on, however, someone has to make a decision on things such as default package choices or, for instance, the init system. Who decides this? The council? A meeting of developers? Is it done according to a plan or just on a case by case basis?

As described above, Gentoo Developers work on what interests them. A lot of those foundational choices are decided by members of the Gentoo Base System Project. Whenever a major change is proposed, there's lots of lively discussion on the gentoo-dev mailing list.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

And it is much more likely we will switch udev implementation than init system. There is a lot of love for OpenRC, and a lot of resistance against systemd and the vertical integration they stand for. The idea of Gentoo switching its default to systemd would be very controversial, to say the least. If that would be pushed through, I think that would likely result in a break-up/fork of the distro.

I think that most Gentoo users are vocal enough about their way of doing things that a fork would be created like you said, and it would tear the community apart being the worst thing for the community.

mv wrote:

BoneKracker wrote:

Does openly talking about this create problems?

Yes. It is likely that you will get soon attacked by some Poettering fanboys. I realized this in many forums. This man is like a Guru with fanatic followers which throw buzzwords like "necessary unification", "old methods not appropriate for modern systems" etc., of course avoiding all actual technical facts, since otherwise they would be lost.
It became clearly visible when the two udev forks happened: The original arguments ("No one forces you to use Poetterings programs - you are always free to program and fork") was suddenly changed to "the intention of this fork is only to be hostile". It is really a pity to see how this guru and his technically unskilled but apparently socially well-trained followers are sytematically attempting to destroy the idea of FOSS.

+1_________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming