If you have a problem with Poettering&co forcing everybody to do it their way, no matter how stupid, this thread is pure gold for you:
http://marc.info/?l=linux-kernel&m=134918302507859&w=2_________________Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

What a clusterfuck. Are any of the people involved in systemd/udev actual engineers or computer scientists? It seems like watching a 10 year old with a chemistry set. "Let's mix the red, yellow, and blue stuff and see what happens!"

they constantly forced their crap down the throat of the rest of the userspace. Now they tried it with the kernel... I hope they continue.. udev will be castrated faster than you can say 'Kay loves Lennart'.

Quote:

Stop this crazy. FIX UDEV ALREADY, DAMMIT.

Who maintains udev these days? Is it Lennart/Kai, as part of systemd?

Lennart/Kai, fix the udev regression already. Lennart was the one who
brought up kernel ABI regressions at some conference, and if you now
you have the *gall* to break udev in an incompatible manner that
requires basically impossible kernel changes for the kernel to "fix"
the udev interface, I don't know what to say.

"Two-faced lying weasel" would be the most polite thing I could say.
But it almost certainly will involve a lot of cursing.

I wish I could make this my sig._________________Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

they constantly forced their crap down the throat of the rest of the userspace. Now they tried it with the kernel... I hope they continue.. udev will be castrated faster than you can say 'Kay loves Lennart'.

Linus wrote:

The "I wish things were otherwise than they are" mindset is wishful
thinking. Reality is that probing - and firmware loading - happens
from the module init routines quite often, and it clearly used to
work. So udev broke. Fix it, don't argue that you wish things were
otherwise

I sent an email once to that Kay person, when I was trying to write a udev rule to handle the SCSI Zip disks once common in Macintoshes, and something arcane I needed didn't seem to be working as advertised. She never responded.

Trying to drive a change like this from the userspace end is a useful exercise in exploring user requirements, but it's now time to write those down in generalized form and take up the engineering process from the kernel outward. But what do I know; I'm just one of those useless pointy-haired "manager" assholes.

Gotta be gay. No self-respecting man would go through life being known as "Kay".

no, Kay means Kempe - fighter. It is not his fault that americans love to give their daughters male names. Maybe because they wished to have a son. Or some kind suppressed gayness.... so when they screw their daughters they can pretend to fuck a boy._________________Study finds stunning lack of racial, gender, and economic diversity among middle-class white males

Gotta be gay. No self-respecting man would go through life being known as "Kay". :P

no, Kay means Kempe - fighter. It is not his fault that americans love to give their daughters male names. Maybe because they wished to have a son. Or some kind suppressed gayness.... so when they screw their daughters they can pretend to fuck a boy.

It's been a long time since I was shocked by something I read on the internet. Thanks for reminding me what that feels like._________________Your argument is invalid.

Stop this idiocy.
..
The fact that you continually try to make this a "kernel issue" is just disgusting. Talking about the kernel solving it "properly" is pretty dishonest, when the kernel wasn't the problem in the first place. The kernel not only does things right, but this all used to work fine.

This is a common pattern with sievers and poettering: dishonest assertions make it into the accepted discourse, unless and until someone with more kudos calls them on it. (Try substituting the word "unix" for "kernel" or "the kernel" above and you pretty much have how I feel about it.)

A similar sort of dishonesty can be seen in the description for the new AUDIT_LOGINUID_IMMUTABLE kernel config setting:

Code:

config AUDIT_LOGINUID_IMMUTABLE
bool "Make audit loginuid immutable"
depends on AUDIT
help
The config option toggles if a task setting its loginuid requires
CAP_SYS_AUDITCONTROL or if that task should require no special permissions
but should instead only allow setting its loginuid if it was never
previously set. On systems which use systemd or a similar central
process to restart login services this should be set to true. On older
systems in which an admin would typically have to directly stop and
start processes this should be set to false. Setting this to true allows
one to drop potentially dangerous capabilites from the login tasks,
but may not be backwards compatible with older init systems.

When I read what it actually does, I could not understand why there is anything about the init system: init has always run getty, which runs login, and all of them have always run as root. So the capability itself can be seen as useful, if you want to enable a non-root program to handle logins, but it does not affect "older" init systems in any way. If anything, the capability is only needed by new init systems.

Instead, we have the clear inference, that older init systems are "potentially dangerous" in comparison to systemd. Which is laughable when you consider that the first thing the login program is going to do is setuid to the user's login, dropping root privileges.

So we have inaccurate, and irrelevant, marketing propaganda inserted into the kernel config help-files, lending authority to that nonsense, designed to make people think that only systemd is going to provide a secure login.

And if you understand security, you know that the Unix principles of keeping a program simple, and only performing one task, leads to a smaller attack vector and less code to audit. That is the antithesis of sievers and poettering's approach, yet they have the arrogance to claim better security, with false information.

When you look at their software, instead of making things easy to work with, it makes it hard, and then the blame is pushed on to everyone else around. The whole point of udev was to make device management simple: that means accommodating users with or without an initramfs, and handling the traditional methods, both in the kernel and in user-space. Instead we get more and more workarounds, or changes in fundamental policy and system-handling, as everyone else has to change to meet their expectation of how things should be done. (Which changes from month to month.)_________________

Kay, you are so full of sh*t that it's not funny. You're refusing to
acknowledge your bugs, you refuse to fix them even when a patch is
sent to you, and then you make excuses for the fact that we have to
work around *your* bugs, and say that we should have done so from the
very beginning.

Few decisions ever turned out so sweet as masking >=udev-180 _________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

The simple point is udev used to work, prior to trying to make it part of systemd. Revert or make systemd w/udev irrelevant._________________Asus m5a99fx, FX 8320 - amd64-multilib, 4.11.3-zen, glibc-2.21, gcc-4.9.4, eudev
xorg-server-1.19.2 w/mesa-17.1.0, openbox, nouveau and radeon, oss4(2017)