Systemd-homed: Systemd Now Working To Improve Home Directory Handling

[pal666]

Lol, Mr. Poettering how about to explore splitting some "systemd-*" projects out of systemd?

should all gnu projects be split out of gnu? what about all apache projects out of apache?

[pal666]

But I can't understand what interesting use cases can systemd-homed.

did you try to read slides or watch video?

[Danielsan]

[...]

I am mostly agreed with you, let me go briefly where I am not...

ALSA vs PULSE is an hold topic flame, my feeling was that, back to time, what was really missing was a gui interface to handle with the peripherals without dealing with an arcane and obscure config file, but (so far I remember) everything was treated like functionality missing in ALSA, but that was a false statement. Alsa had a plenty of plugins to solve this issue. But slowly Pulse began to be requested as dependency by many packages without a specific reason (like Firefox).

Today the pattern isn't changed at all. Someone creates a false issue with a false statement offering a replacement and others, with complicity or just for pressure, start to hard coding the replacement until you can't get rid of it anymore. Like systemd in Gnome.

There are plenty of example where some crucial component were made by individuals and grow up dealing with the community, starting from the same kernel, ten years ago the same corporations left their employees playing around GNU and LINUX with side projects, today are leading the development and everything is treated as a product, and this way of doing, which is not compatible with community distro like Debian, eventually annoys a lot of people, especially the end-users.

[linuxgeex]

I'm happy to see this. /var/user braindamage really pissed me off. None of that should be outside the user's home folder. Bringing the user /etc records into the home folder is a great idea. Soon we'll have AMD-SEV enforcing cryptographic isolation of mutually untrusting users and that will be infinitely better than POSIX permission isolation, and that will make it even more obvious why /var/user was a design mistake.

[oiaohm]

For example pulseaudio has been a crap for years before to be usable, when, with a very basic config setup, you could use alsa_dmix to mix audio sources and devices without caring anymore, .

Problem is what you just stated is you found a works for me. Of course you were not aware of that. Before pulseaudio you had people with wine needing to use either oss(from 4Front Technologies) or alsa. on Linux. Why because either the driver in oss worked or driver in alsa worked of course you could have application expecting quirk. Even before Pulseaudio was what people classed as usable Poettering work with Pulseaudio was help you to get decent alsa drivers with repeatable test cases.

Please note the wine project was and is very stubborn that alsa interface had to work on top of pulseaudio.

but we were forced to use it, however since the moment it is still another Poettering product today we have, finally, a replacement: pipewire.

Pipewire is also out of redhat. It would not be possible without the ground work to repair a lot of the lower level that Poettering did. Yes Poettering was the first to code up a test suite for alsa driver function.

It will happen the same for systemd. Anyway my point is: I don't want use the Linux Poettering Edition, but I see a lot of people that want (desperately) a change, whatever, I am not against changing but I am against to a "one-way changing", especially when these changing are not community driven but it are part of a strategy of a Company that, for sure, helps Gnu and Linux a lot but this is not for me neither for you, it is just a fortunate coincidence.

One way change is better than no change and being stuck with broken. The idea not community driven has to be taken with large grain of salt. Very little open source development is truly community driven. Less than 5 percent is community driven. More than 95 percent is company driven by some company interest this is detailed when you start looking at development histories of who did what and why.

My biggest problem here is a lot of people say they don't want to using Linux Poettering Edition those people don't seam to be able to assemble enough funding to make something decently competitive. Openrc is critically short on developers. This is not redhat fault.

This is the thing a lot of people complain about what the Poettering does but they are not funding competitive alternatives either. Yes with Pulseaudio have sat around and waited for Redhat to decide to fund something better than pulseaudio with pipewire. Remember redhat funded pulseaudio into existence as well. Pipewire is not a community backed idea either.

If you want true community development you really do have to work out how to fund the developers differently. Otherwise you have to either complain and change nothing or accept the reality of the current Foss business model for putting food on developers table.

[Danielsan]

Really would pay to look closer. Poettering is good for Linux as in the Linux kernel and most likely not good for freebsd or gnu long term. I will detail why.

Lets take pulseaudio. Lot of people don't remember or issue logs from before pulseaudio. People who say they use Alsa instead of pulseaudio today have a lot to thank pulseaudio for.[...]

I apology because I will not articulate like you... By the way the philosophy "that works for me" hence "must works for all because RH", is the same reason why I left Ubuntu many years ago... I Like Linux but I dislike the way Canonical/Shuttelworth does as well as I dislike the idea of Linux that Poettering has. For example pulseaudio has been a crap for years before to be usable, when, with a very basic config setup, you could use alsa_dmix to mix audio sources and devices without caring anymore, but we were forced to use it, however since the moment it is still another Poettering product today we have, finally, a replacement: pipewire. It will happen the same for systemd. Anyway my point is: I don't want use the Linux Poettering Edition, but I see a lot of people that want (desperately) a change, whatever, I am not against changing but I am against to a "one-way changing", especially when these changing are not community driven but it are part of a strategy of a Company that, for sure, helps Gnu and Linux a lot but this is not for me neither for you, it is just a fortunate coincidence.

[tildearrow]

In one picosecond you can only transmit data at a distance of 299792nm and that would be a very small scale AI :-)

Are you sure? Doesn't current slow down depending on the material?

[oiaohm]

I've never though that I would prefer be a homedless in my life...

However it is clear that no one of these changes introduced by Poettering serve to make GNU or Linux better, it is just the way how, since ever, Red Hat holds its dominance on GNU and Linux. The only thing is changed since before the introduction of Systemd is the fact that today there are more players on the scenario and thus Red Hat became more aggressive with its usual behavior...

Really would pay to look closer. Poettering is good for Linux as in the Linux kernel and most likely not good for freebsd or gnu long term. I will detail why.

Lets take pulseaudio. Lot of people don't remember or issue logs from before pulseaudio. People who say they use Alsa instead of pulseaudio today have a lot to thank pulseaudio for.

Before pulseaudio we had multi sound servers basically going down the route of a sound server per DE(desktop environment i am going to use this short a few times) . Just like we have people distro hopping because X feature does not work we use to have people DE hope because their audio did not work. We end up with fragmented solution and a lot of works for me DE outcomes. It was like 1 person tries DE 1 there audio is not working right they would switch to DE 2 maybe after multi DE switches then they would find a "Works for Me" now they would recommend DE 2 to person 2. Person 2 has the same kind of issue and after a lot of DE switching they would find a "Works for Me" on audio DE1 now think person 1 was a idiot not catching up they had just found another "Works for Me" solution.

The cause of this problem was found by pulseaudio. Pulseaudio resulting in fixing a lot of low level kernel sound drivers. Why pulseaudio documented that when X audio driver go X instructions it did X yes Y audio driver got X instructions it did Y when it should do X. This was a long list of what caused the "Works for Me" problem in the Audio stack. This was work done under Poettering lead.

Now lets look at systemd effects on lower down Linux kernel. Systemd is why we have cgroupv2 because once systemd started using cgroupv1 heavy again it demoed that it was a "works for me" if I am lucky solution by design. Kdbus a lot think as a failure if you look closer is not there were a lot of options people said for IPC that could give the performance that systemd developers were after for dbus that were also in a "works for me" if I am lucky state.

Then we have the big blow up over how the LInux command-line should be used over systemd. Techically systemd did nothing wrong as there was no rules so it was a "works for me" solution.

I could keep on going. Something Poettering is good at is finding a "works for me" solutions and providing pressure to that weak point to get a "works for everyone" solution in the Linux kernel. This homed would be another one to apply pressure all the faults homed has happened to everyone who attempts to run a business network with shared home directories on Linux if the machines are not all under a single central management. Heck how even if it is under a central management it can still go bell up.

Poettering is really like the real world bull in china shop for the Linux kernel. A real world bull can in fact walk though a china shop without breaking a single thing and that is the most common outcome Mythbusters and a few other parties have proven this. But looks as scary as hell of course so causes those who are not aware how a real world bull will behave to take extra protective measures. So Poettering being Poettering does the kernel a lot of good.

I am not going to say he is all good. For freebsd/"other operating systems", "other distributions" and gnu Poettering really does not give a rats about either. His wage is paid by Redhat like it or not he has to keep his employers happy. Redhat only support Linux kernel devices so Poettering cannot be expected to work on the other stuff. This means he has a Linux platform first policy. Some ways this is providing active pressure to those other solutions to have people from their camp to step up to counter Poettering.

[Danielsan]

I've never though that I would prefer be a homedless in my life...

However it is clear that no one of these changes introduced by Poettering serve to make GNU or Linux better, it is just the way how, since ever, Red Hat holds its dominance on GNU and Linux. The only thing is changed since before the introduction of Systemd is the fact that today there are more players on the scenario and thus Red Hat became more aggressive with its usual behavior...

[F.Ultra]

One picosecond is plenty of time for an AI at the scale of GLaDOS to forget why it's doing what it's doing.

Actually the larger scale of the AI the higher the latency since C is and will always be a constant. In one picosecond you can only transmit data at a distance of 299792nm and that would be a very small scale AI :-)