There was a simple solution that I asked about many months back
when it was announced that udev-171-r10 (IIRC) would be removed from portage.
I asked why it couldn't just stay there as it worked and it should be left until it broke
because of dependencies. That suggestion was summarily dismissed. Why? Because
it was promised that udev would continue to work. So now we have an announcement
that people need to change their systems because, "boo hoo hoo, now upstream
makes it too hard". Precisely what I and others predicted would happen.

Why do you bring up udev-171 again? First and foremost, the ebuild was never lost, anyone can fetch it from the attic even today. However, one would also have to deal with several blockers to squeeze it into the system. And how would that be any better than using a perfectly well working udev today, except maybe a few kB less download size? And, well, there still is eudev.

I know about the attic BUT the ebuild is only part of the picture.
Can the udev tar file and any patches still be found.
I actually ran into to this when I was pulling an old ebuild,
the tar file was nowhere to be found in the gentoo repository
fortunately I did find a copy of the file on a russian site.
But it's not guaranteed to find old stuff.

I'm still running an old version of udev, so what blockers are you talking about?

As far as why bringing up udev 171, it was last or almost last of the udevs, that
was a separate tarball vs pulling it out of a systemd tarball. I still don't see what
it would have hurt keeping it around._________________Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)

And they're upset that they are having to play, what will make it work this time and for how long.

That is not the problem here, the news clearly documents that in advance. Furthermore, an exceptional setup that we cannot guarantee to support should be an educated choice; and thus someone whom picks that choice should follow matters like this, as that person would know the setup that the person is running is fragile.

Anon-E-moose wrote:

But many might try listening more

We are listening, but I have not heard about anything actionable within reasonable boundaries; if you have something you deem that way then you can propose it on the gentoo-dev or gentoo-project ML (please pick the appropirate one) and after discussion perhaps bring it up to the Gentoo Council, which are both much more formal steps than hidden away in a thread on the forums which a lot of Gentoo Developers don't visit daily.

Anon-E-moose wrote:

Defending less

Most of us are not defending, we can merely do what we can; I see no indication that we stand behind all upstream choices or force their ways upon users, it's sometimes the opposite.

Please also note that dropping support is not equal to forcing you to use something else; it's rather a signal, that we cannot support it so we are not going to uphold fake promises...

Last edited by TomWij on Sun Oct 06, 2013 1:40 pm; edited 1 time in total

ulenrich,
There is a workaround for the GPL. Make the code so complex no single individual can understand it, therefore no single individual can fix it and supply patches.
This is where the concept of 'vertical integration' is headed.

What the normal user sees as a dark cloud of 'vertical integration' might well be modularized at source code level in the eyes of a developer:
This obviously is the case for Systemd. Otherwise it couldn't be swiftly adopted by new contributers like David Herrmann, who just implements his VT ideas. Also Canonical wouldn't be able to utilize logind for their unity desktop. The cause of Gentoo developers giving up on this was not Gdm but the further Systemd-user integration into Gnome-session by upstream Gnome. Do you want to blame Systemd for giving Gnome the opportunity when providing such framework as Systemd-user?

This modularized and vertical integrated framework gives developers the solid grounds they can develop further. It is transparent for them. Thus Gpl can work on all what is going on in that respect.

Quote:

Having seen a number of 'vertically integrated' projects grow in complexity to the point where they had to be abandoned because nobody could make them work, I am not a fan of the philosophy behind systemd. udev is tainted with that philosophy too.

One of that upstream packages left dead behind because of "bad vertical integration" actually is kde-base/kdm. Kde-5 will abandon Kdm in favor of sddm. I wonder if sddm developers will take advantage of a finer grained systemd-user modularization for starting up Kde without "sleep 30" seconds ..._________________fun2gen2

There was a simple solution that I asked about many months back
when it was announced that udev-171-r10 (IIRC) would be removed from portage.
I asked why it couldn't just stay there as it worked and it should be left until it broke
because of dependencies. That suggestion was summarily dismissed. Why? Because
it was promised that udev would continue to work. So now we have an announcement
that people need to change their systems because, "boo hoo hoo, now upstream
makes it too hard". Precisely what I and others predicted would happen.

Yes, I realize that many could have moved the old ebuild to their local directory
but they trusted the word of the devs and now it seems that that word
is useless. It's hardly the end users fault for trusting the devs to keep their word.

I also tried to caution a dev about promising things over which he had no control,
as it would cause problems. Now we got 2 devs on here playing CYA. All this could
have been avoided. Either by not guaranteeing things over which one has no control
or simply being quiet during these bitchfests, instead of thinking that one has to
control the thinking of the crowd.

Tom, I'm glad that your system is working, for others it's play catch-up since
they aren't on the cutting edge as devs are likely to be. And they're upset that
they are having to play, what will make it work this time and for how long.

Personally I think the devs, and that includes all, do a good job.
But many might try listening more and defending less.
Anyway just some thoughts on this.

Pax

You are seriously confusing two entirely different issues. Let me rephrase: sys-fs/udev doesn't have anything to do with the separate /usr issue or the news item about it.
It doesn't make ANY difference at all if you use 171, 204 or 208 with separate /usr now and later.

Gentoo has decided to remove flexibility. I've maintained my own overlay and have no problem doing so.

How so? What is that overlay for?

How long, now that a separate /usr will be unsupported, will devs simply break what already works out of convenience? I mean, that's the whole argument of the devs, to reduce overall flexibility to increase their convenience.

And my overlay is a set of packages that I use that aren't in portage, have been dropped by portage, etc. Not sure that anything there would pertain to anyone but me.

Quote:

saellaven wrote:

But if Gentoo buys into the Poettering line, as they appear to be doing, it is no longer worth my time to stay with Gentoo,

I don't see how Gentoo is buying it; as far as I see, there is only one optional dependency on GNOME 3, nothing more.

Today... the firewalls that keep the freedesktop craziness from spreading are being removed.

Quote:

saellaven wrote:

just as you argue that maintaining a large patchset makes life too hard on the Gentoo devs.

Exactly, doing large patchsets in multiple places while mantaining 18.000+ packages is overkill; be aware that we have a little more to do than a single package here and there.

And how many of those packages are early boot related? Let's not pretend that all 18,000 packages affect loading /usr early.

Quote:

Quote:

but the politics of Gentoo has always kept me away.

Which politics in particular?

When I first came to Gentoo, the total carelessness of the council in particular, having let the foundation expire and all of that. Then it was a matter of devs not listening to the users at all (Gentoo went through a stage where all that mattered was what the devs wanted, basically stating that Gentoo was by and for the devs and the users didn't really matter much) and frankly, with the /usr decision, I believe we are reliving that to some extent. Generally speaking, I find that there's too much bureaucracy in Gentoo and a handful of devs that want it their way and only their way, even if it actively harms other parts of the project. I get enough of the politics elsewhere, I just want my systems to work.

Quote:

saellaven wrote:

Then you haven't read the mailing lists and bugs over the last year or so where people have complained about lvm being updated in portage but the initramfs not being rebuilt, which in turn made their system non-bootable or other people complaining that initramfs simply wouldn't let their computer boot all the way.

So initramfs hasn't broken for you... yet. But it most likely will at some point (maybe less likely since you're on the kernel team and presumably update your initramfs frequently).

Well, it was about predictable network names, unless I have misunderstood; anyhow, I don't run an initramfs at all, so I indeed don't know what that is all about. Sounds like either users not following news and/or post installation messages or maybe the absence of such messages; or people running ~arch (which isn't covered by such messages until it hits people).

and it utterly fails at that job, as has been documented extensively here on the forum...

and Gentoo isn't a binary package distro, so when RH updates something like lvm that breaks boot with a previous initramfs, that initramfs automatically gets updated with it. In Gentoo, it doesn't. I think the chance of suddenly, quietly breaking a ton of systems by forcing them into an initramfs is far more detrimental than someone that chooses hardware and doesn't account for its special needs, like a bluetooth keyboard.

Quote:

saellaven wrote:

That's just it... we'll be dismissed, just as you've literally just done, so it doesn't matter what I or any of the other people who have spoken out against deprecating a separate /usr, the /usr merge, systemd, etc. The day that my Gentoo system no longer boots or forces me to use systemd, I leave and I'm sure a handful of others will as well. In the process, the Gentoo community shrinks a little bit more as you, the devs, continue to complain about a lack of manpower. But hey, your system wasn't affected, yet, so it doesn't really matter.

Yeah, because support for it has to come from somewhere; if nobody is in for it, nobody's going to benefit from it. You can speak out FUD all you want, your words alone are not going to make up a difference...

Poettering's /usr blathering is the FUD... systems worked just fine for years, decades, and he's out to change things on a whim to fit his vision even though just about everything he's ever done has been ill-conceived and scrapped along the way. Remember all the pain Gentoo users went through with hal, only to have to scrapped after, what, one stable release of xorg? How much effort did the Gentoo devs (and users) waste on that?

The /usr merge is being driven by a lot of upstream projects. udev was just the messenger.

That's not true, imo: it was driven by Poettering and Sievers, under the auspices of the freedesktop.org project.

And it was a crappy reason given, and afaic the only reason Linux developers don't like the discipline of keeping /usr separate, is because of gmake's dumbass default linking of libs in native root (or rather rewriting of libnames before the linker even sees them), which makes cross-compile a lot harder, especially if you're used to portable POSIX make, and do not know about gmake's behaviour (which not many Linux developers are even aware of) and try to take advantage of its extensions. Basically it's a misfeature no-one uses, and everyone now works around with macros instead, although it's clearly intended to be used with $+. So if you approach gmake as a developer, using it in the way it appears to be intended from the documentation, you'll never get tight linkage; and most people on Linux gave up on such a concept in the early days.

Quote:

The udev team decided to stop doing retries of commands that failed because /usr was not yet mounted.
I suspect it was getting harder and harder to paper over the cracks.

Well it was never a very good solution: really udev should start after localmount for most people, in particular the 99% of Gentoo users who build in their filesystem modules during install, just so that they can do the rest of it, and don't have a bluetooth keyboard that must be started before they can boot. And if you have a more esoteric setup, or want encrypted root, use an initramfs: exactly like before.

Nothing's really changed on a technical level: only the propaganda has, and the new "consensus" of idiots who break everything every couple of years only to give you a worse "solution."

If you have split /usr on LVM, then root is typically very small, as you've normally split /var, /home and /tmp as well, and doesn't need to be on lvm itself: it is exactly the same as an initramfs, only there is never any issue about keeping it in sync.

And that is the biggest disgrace about the attitude of so many Gentoo "devs": we should all have been collaborating from over 2 years ago, both the people that need (or want) an initramfs, and those who don't; since the problems are exactly the same. Instead they prefer bitching at us to fork, and then bitching at us (or maligning the project and its developers) when we do.

Quote:

There are two ways forward. Mount /usr in an initrd or start udev later, after /usr is mounted in the normal course of events.
Both ways work.

This is very true; for the same reasons as this:

Quote:

There is no problem when using an initramfs as the initramfs mounts both root and /usr and thats all, so that the init script sees a unified / and /usr, even though the reality is that they are still separate.

When udev is eventually started, it looks around the system to see what it should have done if it were running, much as if it was restarted.
This means that permissions on the content of /dev are not correct until udev starts but since everything is being run as root at that time, it does not matter

Gentoo has decided to remove flexibility. I've maintained my own overlay and have no problem doing so.

How so? What is that overlay for?

How long, now that a separate /usr will be unsupported, will devs simply break what already works out of convenience? I mean, that's the whole argument of the devs, to reduce overall flexibility to increase their convenience.

It is not 100% unsupported, because you can use it with an initramfs; if upstream doesn't provide flexibility, neither can we, this has nothing to do with convenience because this is the only option we see given this situation.

saellaven wrote:

And my overlay is a set of packages that I use that aren't in portage, have been dropped by portage, etc. Not sure that anything there would pertain to anyone but me.

Well, I wanted to know its relevance to this discussion; this way it sounds irrelevant.

saellaven wrote:

Quote:

saellaven wrote:

But if Gentoo buys into the Poettering line, as they appear to be doing, it is no longer worth my time to stay with Gentoo,

I don't see how Gentoo is buying it; as far as I see, there is only one optional dependency on GNOME 3, nothing more.

Today... the firewalls that keep the freedesktop craziness from spreading are being removed.

Which firewalls are you talking about? How can they be removed if they haven't been there in the first place?

saellaven wrote:

Quote:

saellaven wrote:

just as you argue that maintaining a large patchset makes life too hard on the Gentoo devs.

Exactly, doing large patchsets in multiple places while mantaining 18.000+ packages is overkill; be aware that we have a little more to do than a single package here and there.

And how many of those packages are early boot related? Let's not pretend that all 18,000 packages affect loading /usr early.

Why make an exception here?

saellaven wrote:

Quote:

Quote:

but the politics of Gentoo has always kept me away.

Which politics in particular?

When I first came to Gentoo, the total carelessness of the council in particular, having let the foundation expire and all of that. Then it was a matter of devs not listening to the users at all (Gentoo went through a stage where all that mattered was what the devs wanted, basically stating that Gentoo was by and for the devs and the users didn't really matter much) and frankly, with the /usr decision, I believe we are reliving that to some extent. Generally speaking, I find that there's too much bureaucracy in Gentoo and a handful of devs that want it their way and only their way, even if it actively harms other parts of the project. I get enough of the politics elsewhere, I just want my systems to work.

Well, systemd isn't forced and a separate /usr works with an initramfs; I don't see the problem here, you're stating that we are not listening or careless and then state a problem that's not actually there; we can't listen or care about something that is not currently happening...

saellaven wrote:

Quote:

saellaven wrote:

Then you haven't read the mailing lists and bugs over the last year or so where people have complained about lvm being updated in portage but the initramfs not being rebuilt, which in turn made their system non-bootable or other people complaining that initramfs simply wouldn't let their computer boot all the way.

So initramfs hasn't broken for you... yet. But it most likely will at some point (maybe less likely since you're on the kernel team and presumably update your initramfs frequently).

Well, it was about predictable network names, unless I have misunderstood; anyhow, I don't run an initramfs at all, so I indeed don't know what that is all about. Sounds like either users not following news and/or post installation messages or maybe the absence of such messages; or people running ~arch (which isn't covered by such messages until it hits people).

and it utterly fails at that job, as has been documented extensively here on the forum...

Support or documentation doesn't mean it fails to do its job, there is much more of that about the previous network names on the internet.

saellaven wrote:

and Gentoo isn't a binary package distro, so when RH updates something like lvm that breaks boot with a previous initramfs, that initramfs automatically gets updated with it. In Gentoo, it doesn't. I think the chance of suddenly, quietly breaking a ton of systems by forcing them into an initramfs is far more detrimental than someone that chooses hardware and doesn't account for its special needs, like a bluetooth keyboard.

It isn't quiet as you are notified to update it; unless you choose to ignore post install output, news messages and more...

saellaven wrote:

Quote:

saellaven wrote:

That's just it... we'll be dismissed, just as you've literally just done, so it doesn't matter what I or any of the other people who have spoken out against deprecating a separate /usr, the /usr merge, systemd, etc. The day that my Gentoo system no longer boots or forces me to use systemd, I leave and I'm sure a handful of others will as well. In the process, the Gentoo community shrinks a little bit more as you, the devs, continue to complain about a lack of manpower. But hey, your system wasn't affected, yet, so it doesn't really matter.

Yeah, because support for it has to come from somewhere; if nobody is in for it, nobody's going to benefit from it. You can speak out FUD all you want, your words alone are not going to make up a difference...

Poettering's /usr blathering is the FUD... systems worked just fine for years, decades, and he's out to change things on a whim to fit his vision even though just about everything he's ever done has been ill-conceived and scrapped along the way. Remember all the pain Gentoo users went through with hal, only to have to scrapped after, what, one stable release of xorg? How much effort did the Gentoo devs (and users) waste on that

You perceive it as the main thing, not me; it's just an alternative from a Gentoo perspective.

Yes, let us not waste time on fake promises and false attempts to bring false hope; if we can't support it, we really can't...

Last edited by TomWij on Sun Oct 06, 2013 4:34 pm; edited 3 times in total

It is a myth that the initramfs should not have udev! This only is the crippled genkernel way of generating an initramfs. In the Linux world the other 99% of users do have a fully enabled initramfs including udev:
Ubuntu, Debian, openSUSE and users of dracut._________________fun2gen2

It is a myth that the initramfs should not have udev! This only is the crippled genkernel way of generating an initramfs. In the Linux world the other 99% of users do have a fully enabled initramfs including udev:
Ubuntu, Debian, openSUSE and users of dracut.

Well, it's kind of true. Anything later than 2.02.97 of LVM2 needs udev in the initramfs for proper functionality. Otherwise I can't think of an any other mandatory reason.

It is a myth that the initramfs should not have udev! This only is the crippled genkernel way of generating an initramfs. In the Linux world the other 99% of users do have a fully enabled initramfs including udev:
Ubuntu, Debian, openSUSE and users of dracut.

Well, it's kind of true. Anything later than 2.02.97 of LVM2 needs udev in the initramfs for proper functionality. Otherwise I can't think of an any other mandatory reason.

- 5 years ago Debian wasn't able to set the system clock without an initrd
- binary deployment has a wider use case of an initramfs: net mounts
- emergency console if a device failed
- asian people would like to use their keys instead of plain english
...
I never got the whole thing about it, because I never needed it. But I just proved openSUSEs:
lsinitrd shows even files included about printer setup there! Though I know they have a "culture" of never touch until totally broken _________________fun2gen2

When I first came to Gentoo, the total carelessness of the council in particular, having let the foundation expire and all of that.

There is no formal relationship between the Gentoo council and the Gentoo Foundation. The Foundation represents Gentoo legally. Its a business entity.
The council is Gentoo top technical body. If anything, the Foundation is responsible for the Council, since if the council were to make a decision that was held be be illegal, the Foundation would receive the writ.

This lack of a formal relationship between the Gentoo council and the Gentoo Foundation makes me nervous as I have been a board member of the Foundation since 2008._________________Regards,

NeddySeagoon

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

With only one exception each of those is depended upon by multiple packages.

Anon-E-moose wrote:

As far as why bringing up udev 171, it was last or almost last of the udevs, that
was a separate tarball vs pulling it out of a systemd tarball. I still don't see what
it would have hurt keeping it around.

With current versions working perfectly fine, I don't see why it should have been kept around? Would you be happy if someone pulled out the udev bits and provided them in a separate tarball for e.g. udev-208? Why not use eudev then?_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

When udev is eventually started, it looks around the system to see what it should have done if it were running, much as if it was restarted.

So it is the kernel which buffers all these events? Otherwise udev could hardly be able to find out "what it should have done if it were running". Or is udev at start using only some heuristics to guess which events the kernel presumably has already sent and which were lost?

Third: Quote: "Oracle Solaris has implemented the /usr merge in parts 15 years ago, and completed it in Solaris 11." - So "Was driven by Poettering and Sievers" becomes to sound ridiculous. Solaris 11 was released in 2011. Alsa was working fine with a not pre-mounted separate /usr partition on my system in 2011.

Let's face it. There is absolutely no reason for a separate /usr partition at all, unless you a) need to mount /usr over LAN, or b) need a special encryption (for what? Protect your man pages or what?) that makes it necessary. If neither applies to you, in which cases you'd most probably have an initrd anyway, then you don't need a seaprate /usr partition. Admit it, the only reason you have and want it is, because you are used to it.
Like me.
I was scandalized and thought: "No way, I won't use an initrd! I never had and don't see why to change that!"
And further I wanted to have /usr on a separated partition so badly, because, because ... dammit ... because it was always like this.
Yes. That was the only reason. Because, without any real advantage or the slightest benefit (never ever), I was simply used to put /usr on a separate partition.
I moved /usr back into / over a year ago and the only thing I miss (not really) is the dread to end up with an initrd. Which never came._________________systemd - The biggest fallacies

...
There is a workaround for the GPL. Make the code so complex no single individual can understand it, therefore no single individual can fix it and supply patches.
This is where the concept of 'vertical integration' is headed.
...

An idea just popped into my head, despite my tinfoil helmet. No idea what triggered it, I ought to keep taking my tablets.

If I were interested in putting a backdoor into linux I'd want a complex piece of code to hide the backdoor. It would need to be part of startup so as to be in place before any protection systems could stop it. It would need to have kernel rights so it could be a backdoor into everything. It would need to take over some kernel function, and have rights over firmware, so it could muck about with hardware to enable hidden functions without anyone seeing. It would need to be a prerequisite of all sorts of stuff, particularly desktops, so ensure everyone has to install it. It would need to be developed and shipped by a single vendor, so it could be controlled, and later taken closed source and then shipped as object code to stop pesky people reading the source...

It's a good job no-one in their right mind would consider developing something like that. And anyway, who would want a backdoor into all the linux desktops?_________________Greybeard

Although this is a good base for a thriller to write, the idea to make it closed source would stop it eventually. Everything that went "closed" (be it licensing or the source itself) was forked the very moment. (OpenOffice -> LibreOffice, MySQL -> MariaDB) And if that happens, the hidden backdoor would be found rather quickly._________________systemd - The biggest fallacies

Yes, and
@Goverp, it is much simpler for capable institutions than you suggest:

There is the most simple and the most difficult problem at the same time, which is unsolved ever since the first computation: random-seed

Most of it goes wrong by badly configuring the system. Having to admin a not "vertical integrated" system with hundreds of man pages to read and ever changing and upgrading tools, it is likely to happen._________________fun2gen2

Gentoo has decided to remove flexibility. I've maintained my own overlay and have no problem doing so.

How so? What is that overlay for?

How long, now that a separate /usr will be unsupported, will devs simply break what already works out of convenience? I mean, that's the whole argument of the devs, to reduce overall flexibility to increase their convenience.

It is not 100% unsupported, because you can use it with an initramfs; if upstream doesn't provide flexibility, neither can we, this has nothing to do with convenience because this is the only option we see given this situation.

So, getting to the root of what I posted in this thread and which you again echo at the bottom of your message. The Gentoo devs shouldn't be making open promises they know they can't keep, particularly when the upstream which they have chosen to follow has an established tendency of breaking things.

And that is my point. YOU and most of the Gentoo devs may have faith in upstream, but I don't and I'm not going to compromise the stability of my systems for an upstream that has a history of hostility along with NIH syndrome and little foresight.

Quote:

saellaven wrote:

Quote:

saellaven wrote:

But if Gentoo buys into the Poettering line, as they appear to be doing, it is no longer worth my time to stay with Gentoo,

I don't see how Gentoo is buying it; as far as I see, there is only one optional dependency on GNOME 3, nothing more.

Today... the firewalls that keep the freedesktop craziness from spreading are being removed.

Which firewalls are you talking about? How can they be removed if they haven't been there in the first place?

today, it's that we can't have a separate /usr. How long until we get the /usr merge too? How long until upstream stops providing init scripts for some frequently used demon and only support systemd instead? Are the Gentoo devs going to maintain init patchsets for every package? How long until openrc is too much work to keep up on?

Quote:

saellaven wrote:

Quote:

saellaven wrote:

just as you argue that maintaining a large patchset makes life too hard on the Gentoo devs.

Exactly, doing large patchsets in multiple places while mantaining 18.000+ packages is overkill; be aware that we have a little more to do than a single package here and there.

And how many of those packages are early boot related? Let's not pretend that all 18,000 packages affect loading /usr early.

Why make an exception here?

Why exclude, say, libreoffice in a discussion of what packages are potentially relevant at boot? It's not like 18,000 packages need to worry about boot time, so to try to claim all 18,000 packages swamp the devs with worry over whether /usr is mounted is a false argument.

Quote:

Quote:

Well, it was about predictable network names, unless I have misunderstood; anyhow, I don't run an initramfs at all, so I indeed don't know what that is all about. Sounds like either users not following news and/or post installation messages or maybe the absence of such messages; or people running ~arch (which isn't covered by such messages until it hits people).

and it utterly fails at that job, as has been documented extensively here on the forum...

Support or documentation doesn't mean it fails to do its job, there is much more of that about the previous network names on the internet.[/quote]

Several people here have utterly destroyed the entire argument behind it and have shown how it falls flat on its face at its intended purpose... but again, let's follow upstream even when they walk off a cliff and intentionally break systems in unpredictable ways (because adding a peripheral card or changing my USB port should totally change my network device's name) because being a lemming and following upstream is less work.

Quote:

saellaven wrote:

and Gentoo isn't a binary package distro, so when RH updates something like lvm that breaks boot with a previous initramfs, that initramfs automatically gets updated with it. In Gentoo, it doesn't. I think the chance of suddenly, quietly breaking a ton of systems by forcing them into an initramfs is far more detrimental than someone that chooses hardware and doesn't account for its special needs, like a bluetooth keyboard.

It isn't quiet as you are notified to update it; unless you choose to ignore post install output, news messages and more...

So when lvm got updated and it didn't tell you that it would break your existing initramfs unless it's rebuilt, it's the fault of the user... how often until we're rebuilding the initramfs once or twice a week because every package that could potentially be in it throws a warning by default?

Quote:

Yes, let us not waste time on fake promises and false attempts to bring false hope; if we can't support it, we really can't...

and that's my point.

Just because your system is working today doesn't mean it will work tomorrow because Gentoo has decided to follow upstream even if it means going off a cliff. And those that do strive to achieve the previous behaviors will be marked with outright hostility and derision, as ssuominen has routinely done to eudev and now despite breaking his implied promise that a separate /usr would stay when he stabilized >udev-200ish (while further deriding eudev in the same message).

The /usr merge is being driven by a lot of upstream projects. udev was just the messenger.

That's not true, imo: it was driven by Poettering and Sievers, under the auspices of the freedesktop.org project.

Sorry, but enough is enough.

Save the drama, will you? So what if "someone on the internet is wrong"?

Quote:

Third: Quote: "Oracle Solaris has implemented the /usr merge in parts 15 years ago, and completed it in Solaris 11." - So "Was driven by Poettering and Sievers" becomes to sound ridiculous. Solaris 11 was released in 2011. Alsa was working fine with a not pre-mounted separate /usr partition on my system in 2011.

No, you're wrong, since you misinterpret my comments; I am talking about the push to merge /usr with rootfs in Linux.

That has very much been driven by the aforementioned team.

And really it's just a cop-out. Just because Solaris copped out, doesn't mean we need to. If you follow that logic, we might as well start emulating Windows. Oh wait.

As for ALSA, that's simply an indicator of why you need localmount (or its equivalent) before udev; many of us had the same issue with alsa and /var til it was patched.

Quote:

Let's face it. There is absolutely no reason for a separate /usr partition at all, unless you a) need to mount /usr over LAN, or b) need a special encryption (for what? Protect your man pages or what?) that makes it necessary. If neither applies to you, in which cases you'd most probably have an initrd anyway, then you don't need a seaprate /usr partition. Admit it, the only reason you have and want it is, because you are used to it.

Put it this way: I'm fed up to my back-teeth of having to justify my usage to anyone. Read my linked post about udev and initramfs if you want to see my responses to it.

Basically anyone who wants to tell me how to setup my machine, or to ignore my experience can STFU. I ain't interested one iota.

Nor am I interested in your road-to-Damascus conversion to the Kool-Aid. Use your machine however you damn well like, and good luck to you.

Gentoo has decided to remove flexibility. I've maintained my own overlay and have no problem doing so.

How so? What is that overlay for?

How long, now that a separate /usr will be unsupported, will devs simply break what already works out of convenience? I mean, that's the whole argument of the devs, to reduce overall flexibility to increase their convenience.

It is not 100% unsupported, because you can use it with an initramfs; if upstream doesn't provide flexibility, neither can we, this has nothing to do with convenience because this is the only option we see given this situation.

So, getting to the root of what I posted in this thread and which you again echo at the bottom of your message. The Gentoo devs shouldn't be making open promises they know they can't keep, particularly when the upstream which they have chosen to follow has an established tendency of breaking things.

And that is my point. YOU and most of the Gentoo devs may have faith in upstream, but I don't and I'm not going to compromise the stability of my systems for an upstream that has a history of hostility along with NIH syndrome and little foresight.

Exactly, as we can't promise it; we clearly state right away that we can't, because some of those things are broken upstream. That's why we opt for a stable subset instead.

If you don't want to follow that stability; then you are on your own, and that is much more compromising than following a system that is widely supported and everyone runs without much problems.

saellaven wrote:

Quote:

saellaven wrote:

Quote:

saellaven wrote:

But if Gentoo buys into the Poettering line, as they appear to be doing, it is no longer worth my time to stay with Gentoo,

I don't see how Gentoo is buying it; as far as I see, there is only one optional dependency on GNOME 3, nothing more.

Today... the firewalls that keep the freedesktop craziness from spreading are being removed.

Which firewalls are you talking about? How can they be removed if they haven't been there in the first place?

today, it's that we can't have a separate /usr. How long until we get the /usr merge too? How long until upstream stops providing init scripts for some frequently used demon and only support systemd instead? Are the Gentoo devs going to maintain init patchsets for every package? How long until openrc is too much work to keep up on?

Please read the news message again, you can have a separate /usr using an initramfs; and why does that merge even matter?

We do add local init files because they are a small addition (and not a patchset); so, if lots of upstream drop them I don't think it is going to be a problem.

As for openrc, the future will tell; it all depends on the people pushing it forward.

saellaven wrote:

Quote:

saellaven wrote:

Quote:

saellaven wrote:

just as you argue that maintaining a large patchset makes life too hard on the Gentoo devs.

Exactly, doing large patchsets in multiple places while mantaining 18.000+ packages is overkill; be aware that we have a little more to do than a single package here and there.

And how many of those packages are early boot related? Let's not pretend that all 18,000 packages affect loading /usr early.

Why make an exception here?

Why exclude, say, libreoffice in a discussion of what packages are potentially relevant at boot? It's not like 18,000 packages need to worry about boot time, so to try to claim all 18,000 packages swamp the devs with worry over whether /usr is mounted is a false argument.

Because the boot is just a small picture of the full picture, please don't ignore the rest; also, there is much more to worry about (stability, security, proper testing, quality assurance, prefix, dependency tree, ...).

saellaven wrote:

Quote:

Quote:

Quote:

Well, it was about predictable network names, unless I have misunderstood; anyhow, I don't run an initramfs at all, so I indeed don't know what that is all about. Sounds like either users not following news and/or post installation messages or maybe the absence of such messages; or people running ~arch (which isn't covered by such messages until it hits people).

and it utterly fails at that job, as has been documented extensively here on the forum...

Support or documentation doesn't mean it fails to do its job, there is much more of that about the previous network names on the internet.

Several people here have utterly destroyed the entire argument behind it and have shown how it falls flat on its face at its intended purpose... but again, let's follow upstream even when they walk off a cliff and intentionally break systems in unpredictable ways (because adding a peripheral card or changing my USB port should totally change my network device's name) because being a lemming and following upstream is less work.

Not sure which network names you are talking about, so I'll assume the previous network names; if you then still break your system by changing hardware, you haven't prepared and configured it properly.

Gentoo Linux is exactly not the distribution where you can just insert or change a device or card and expect everything to magically just work; it has never been this way, why expect it to be different for network cards?

But that's not entirely true as predictable network names do a good job at keeping it working if you keep the card in its place.

saellaven wrote:

Quote:

saellaven wrote:

and Gentoo isn't a binary package distro, so when RH updates something like lvm that breaks boot with a previous initramfs, that initramfs automatically gets updated with it. In Gentoo, it doesn't. I think the chance of suddenly, quietly breaking a ton of systems by forcing them into an initramfs is far more detrimental than someone that chooses hardware and doesn't account for its special needs, like a bluetooth keyboard.

It isn't quiet as you are notified to update it; unless you choose to ignore post install output, news messages and more...

So when lvm got updated and it didn't tell you that it would break your existing initramfs unless it's rebuilt, it's the fault of the user... how often until we're rebuilding the initramfs once or twice a week because every package that could potentially be in it throws a warning by default?

If it didn't, please report that; because it is always the intention to do as such. Rebuilding it once or twice a week is normal on a rolling release distribution.

saellaven wrote:

Quote:

Yes, let us not waste time on fake promises and false attempts to bring false hope; if we can't support it, we really can't...

and that's my point.

Just because your system is working today doesn't mean it will work tomorrow because Gentoo has decided to follow upstream even if it means going off a cliff. And those that do strive to achieve the previous behaviors will be marked with outright hostility and derision, as ssuominen has routinely done to eudev and now despite breaking his implied promise that a separate /usr would stay when he stabilized >udev-200ish (while further deriding eudev in the same message).

The stone age where we wrote on the walls is over; please consider to upgrade your system properly, instead of praying that running a upgrade command on your exotic configuration will not break things on reboot.

My system works, because I do as such; there isn't anything hard about that. Please realize that we live in a world that changes; what you run today is incompatible with what was available when you were born.

Separate /usr is still here (with initramfs), I don't see the problem. Promises that single developers make about single packages, do not necessarily reflect Gentoo; also note that individual support hasn't been disallowed...

Exactly, as we can't promise it; we clearly state right away that we can't, because some of those things are broken upstream. That's why we opt for a stable subset instead.

Then you might want to tell your fellow devs to stop making promises as such...

Quote:

If you don't want to follow that stability; then you are on your own, and that is much more compromising than following a system that is widely supported and everyone runs without much problems.

And when systems go unstable because following upstream was easier than doing the right thing, you and the users will get to deal with the headaches caused by it.

Quote:

Please read the news message again, you can have a separate /usr using an initramfs; and why does that merge even matter?

I've stated my reasons why. Those reasons don't apply to you, so you don't care. I could spend the next week arguing with you and it won't matter. Others could spend the next week arguing with you and it won't matter. The devs have spoken via the council and that's all that matters.

Quote:

We do add local init files because they are a small addition (and not a patchset); so, if lots of upstream drop them I don't think it is going to be a problem.

So, on one hand, you claim you can't maintain all 18,000 packages and then turn around and say you can handle all 18,000 packages without a problem. How about a little consistency?

Quote:

Because the boot is just a small picture of the full picture, please don't ignore the rest; also, there is much more to worry about (stability, security, proper testing, quality assurance, prefix, dependency tree, ...).

and when we get to the point where "well, every other distro uses systemd, so we're going to deprecate using openrc, sysvinit, etc because everyone else has abandoned it and we can't test it alone..." ?

Quote:

saellaven wrote:

Quote:

Quote:

Quote:

Well, it was about predictable network names, unless I have misunderstood; anyhow, I don't run an initramfs at all, so I indeed don't know what that is all about. Sounds like either users not following news and/or post installation messages or maybe the absence of such messages; or people running ~arch (which isn't covered by such messages until it hits people).

and it utterly fails at that job, as has been documented extensively here on the forum...

Support or documentation doesn't mean it fails to do its job, there is much more of that about the previous network names on the internet.

Several people here have utterly destroyed the entire argument behind it and have shown how it falls flat on its face at its intended purpose... but again, let's follow upstream even when they walk off a cliff and intentionally break systems in unpredictable ways (because adding a peripheral card or changing my USB port should totally change my network device's name) because being a lemming and following upstream is less work.

Not sure which network names you are talking about, so I'll assume the previous network names; if you then still break your system by changing hardware, you haven't prepared and configured it properly.

Gentoo Linux is exactly not the distribution where you can just insert or change a device or card and expect everything to magically just work; it has never been this way, why expect it to be different for network cards?

But that's not entirely true as predictable network names do a good job at keeping it working if you keep the card in its place.

No... and that's where you're wrong. The NEW network naming is neither predictable NOR persistent. Change one card in your system and it can reorder your pci bus, surprisingly changing your network device name. Likewise, if you're using a USB wifi adapter and plug it into a different port, you will, again, get a different name.

We could have defaulted to naming by MAC address (which is supposed to be a unique key), but instead it was chosen to name things by device slots. I install a new network card, I know I'm going to have to change my network configuration. I add a new device to my system, I'm not necessarily expecting my networking to break.

and that's the type of shortsightedness Poettering and friends give us and that's a big part of why I don't want them anywhere near my system. Yet, Gentoo is going down the path of selling out to them. The initramfs "solution" is just as prone to unexpected breakage as the "new and improved" network naming is.

Quote:

So when lvm got updated and it didn't tell you that it would break your existing initramfs unless it's rebuilt, it's the fault of the user... how often until we're rebuilding the initramfs once or twice a week because every package that could potentially be in it throws a warning by default?

If it didn't, please report that; because it is always the intention to do as such. Rebuilding it once or twice a week is normal on a rolling release distribution.[/quote]

You know when the last time I had my system break because I didn't rebuild my initramfs? Never... as I'm sure is the case for the majority of Gentoo users. So, you, up front, admit that forcing users onto an initramfs is a headache that will potentially unexpected break their systems, but continue defending it as a good thing. I'd call a useless, new point of failure a bad thing, but that's just me.

Quote:

The stone age where we wrote on the walls is over; please consider to upgrade your system properly, instead of praying that running a upgrade command on your exotic configuration will not break things on reboot.

My system works, because I do as such; there isn't anything hard about that. Please realize that we live in a world that changes; what you run today is incompatible with what was available when you were born.

Separate /usr is still here (with initramfs), I don't see the problem. Promises that single developers make about single packages, do not necessarily reflect Gentoo; also note that individual support hasn't been disallowed...

and again, the dismissive arrogance... and you wonder why some people don't want to be Gentoo devs. How long before Gentoo goes the way of GNOME and removes anything that people might find useful because it's just too complex to leave things that have worked working?

That's quite the opposite what would help for embedded; what would help is completed /usr merge so bin, sbin, lib, lib32, lib64, and other package-manager only-maintained directories would all be in the same partition for easy read-only mounting, like for embedded and sdcard.
As in, all this is to *help* embedded, not to take anything away from it.