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

[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.

[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.

[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.

[pal666]

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

did you try to read slides or watch video?

[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]

It is, but I guess its time to explicitly split that into "companion projects" or so. Explicitly hinting e.g. distro packagers these could and should be e.g. separate, optional packages.

why readme isn't enough for distro packagers? they don't read docs before packaging? switch distro then

[oiaohm]

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.

The plugins did not in fact solve the issues. They in fact added more quirks.

But slowly Pulse began to be requested as dependency by many packages without a specific reason (like Firefox).

Really it would pay to go read the firefox ALSA code. Firefox alsa was designed in the time frame of all those different ALSA plugins. There is over 8000 different quirk detection. Making the alsa section of firefox a total disaster to maintain. Wine project alsa got a lot cleaner after pulseaudio got to work as more quirk stuff for different sound servers and sound drivers could be dropped because stuff started working right.

Yes firefox dropped their Alsa code and tested with apulse for a while this was more modern ALSA code that provided a pulseaudio interface without pulseaudio server.

Applications developers looked at pulseaudio interface is way of getting out of having to maintain all the different stacks. They support pulseaudio interface and they could use apulse when pulseaudio was not provided.

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.

Not a false issue. There is a issue and the number of hours of labor to fix it. Firefox and other applications going pulseaudio and using apulse for non pulseaudio was a lower labor cost option.

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.

Making products out of Linux started 1998. So we have had 20 years of it. You had the wrong idea. Companies allowed more R&D work in areas because Linux in those areas companies did not class as productive. This does not mean corporations were allowing their employees to play around with GNU and Linux doing what they liked. Bosses were still giving those staff list of features they wanted.

Debian is funded heavily by companies selling support most of Debian funding comes because its a product.

Yes it annoys people but people are not working out how fund developers to work the way they want.

Developer like most humans having to choose between
1) food on his table and altering his principles
2) staving with principles
Is going to choose like 1 almost every single time.

By the way the Linux foundation started in the year 2000 to fund Linus because whole stack of companies at that time looked at Linus as a product and lot of those companies feared Linus being in the competitions hands. This did not come up sooner because Linus was employed by company that end up kind of crushed before that point. If Linus had not been employed by that company this would have blown up in 1996-1998.

Like it or not we are 20 years in with Linux as a product. We are now seeing more projects with the goal of complete the functionality. You think it something that happened in the last 10 years.

The change in the last 10 years is that companies are swapping Linux from R&D mode where near enough quality was good enough(crashing... was fine here) to we want to make profit from our investment with fully working product. Please note systemd starts just before the R&D side of companies start swapping over to final product mode. Systemd is most likely the last major wild R&D project we see without major management oversite from the company funded developers.

[Danielsan]

Debian is funded heavily by companies selling support most of Debian funding comes because its a product.

You are adding a lot of stuff that I can't verify... Even ALSA vs PULSE is a bit out of topic, but back to the time I could remove from Debian any *pulse* package I was able to use mic, speakers, flash, Firefox, Skype etc... with just a simple configuration file, using dmix, stored in my home with 1% of overhead against the 30% of pulse just in idle...

Debian it is not a product is a distro made by volunteers, Ubuntu (which is basically a worst version of Debian) is a product made by a corporation. So far I know just Debian LTS is actually funded by corporations toward single developers or maintainers but it is something pretty recent indeed.

https://wiki.debian.org/LTS/Funding

https://www.freexian.com/services/debian-lts.html

[oiaohm]

You are adding a lot of stuff that I can't verify... Even ALSA vs PULSE is a bit out of topic, but back to the time I could remove from Debian any *pulse* package I was able to use mic, speakers, flash, Firefox, Skype etc... with just a simple configuration file, using dmix, stored in my home with 1% of overhead against the 30% of pulse just in idle...

That was possible because application use to maintain there own alsa layers with quirks code.

https://github.com/i-rinat/apulse

Apulse acts as a generic ALSA client. It tries to open audio device, and sometimes fails. At its core, apulse does neither audio mixing nor resampling. Instead, it relies on plug, dmix, and dsnoop ALSA plugins, which are usually enabled by default. These plugins handle multiple audio sources, performing resampling and mixing transparently. For years now ALSA comes with those plugins enabled. Audio just works without configuring anything. But not everybody use default settings.

On custom configurations apulse may fail to output and/or capture audio. There could be no sound at all, or just a single audio stream playing at a time. It's also possible that adapters with hardware mixers, which capable of playing multiple streams, may still be unable to handle multiple capture streams. Depending on hardware, you may still need either dmix or dsnoop plugins. Or both.

In other words, for apulse to work, your setup should be capable of playing and capturing multiple streams simultaneously.

Notice this note with apulse turns out that o so simple configuration file is a "works for me" solution that apulse has to include this warning about requirements so it can work. Key bit "Depending on hardware, you may still need either dmix or dsnoop plugins. Or both" So depending on your hardware effects if dmix in fact works correctly so if you attempt to use a generic alsa configuration everywhere it will break so the solution you had was without question a "works for me" not a "works for everyone" due to requiring differences based on the hardware the person has.

Application developers want if possible works for everyone and if not that it breaks in some other part we can point the bug to and not deal with it ourselves. apulse gives we can blame apulse so not have to deal with the low level alsa problems in our own alsa wrapper when users don't want to run pulseaudio for application developers.

Once applications stopped direct alsa support they also started also being able to sandbox application access to kernel as well as current issue with firefox and apulse turns up.

Do note apulse can be installed system wide to make pulse-audio applications work without the pulse-audio server other than the security issues that have to be tweeked on some applications.

There is advantage to the pulseaudio/apulse route it gives you reduced number of error codes to know when alsa level is stuffed up.

Apulse implementation has not got funding to be completely compatible with pulseaudio. This is a true funding problem. Yes application developers were also wasting a lot of man hours working on their alsa wrappers before Pulseaudio. As I said you do need to look at the firefox alsa code then work out .

If apulse had been complete those not wanting to use pulseaudio would remove pulseaudio install apulse have alsa configured and everything would be as bad as alsa always was. Please note bad as in being a "works for me" configuration solution.

Debian it is not a product is a distro made by volunteers, Ubuntu (which is basically a worst version of Debian) is a product made by a corporation. .

Distribution by volunteers sounds nice but white washing over reality.

So far I know just Debian LTS is actually funded by corporations toward single developers or maintainers but it is something pretty recent indeed..

This is wrong. Funded developers is a long term debian one. LTS is just those deciding to go longer.

https://www.debian.org/partners/

The main project of debian is kept supplied with servers and a good percentage of the maintainers come from the companies in the partner program. This is a stack of corporations who have volunteered to take care of particular things because its in their best interest and their interests do directly effect debian..

Then there are the paid consultants

https://www.debian.org/consultants/

Yes these are people you can pay money to work on getting items fixed in debian.

Partners and Consultant side to Debian appeared in 1998. So we are 20 years in to debian being a multi company cooperation.

Debian to be correct is a distribution mostly made by personal force-ably volunteered by their bosses to work on Debian because Debian product is in the companies best interest to work. Yes those force-able volunteered are paid a wage todo what they do in debian world. There is a really small percentage of true volunteers who are not their for a wage at the end of the day.

[Danielsan]

You seem to have a really depth knowledge of this peculiar topic so I won't argue anymore and I thank you for the time you dedicated to me. My last quick comment is just about Debian that by my side I had more, direct and indirect, contacts with people that orbit around academics institutions rather than corporations.