Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #81
    Originally posted by oiaohm View Post

    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.
    Last edited by Danielsan; 09-24-2019, 10:14 PM.

    Comment


    • #82
      Originally posted by Danielsan View Post
      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.

      Originally posted by Danielsan View Post
      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.

      Originally posted by Danielsan View Post
      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.

      Comment


      • #83
        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.

        Comment


        • #84
          Originally posted by oiaohm View Post
          [...]
          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.

          Comment


          • #85
            Originally posted by timofonic View Post
            But I can't understand what interesting use cases can systemd-homed.
            did you try to read slides or watch video?

            Comment


            • #86
              Originally posted by SystemCrasher View Post
              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?

              Comment


              • #87
                Originally posted by SystemCrasher View Post
                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

                Comment


                • #88
                  Originally posted by Danielsan View Post
                  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.

                  Originally posted by Danielsan View Post
                  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.

                  Originally posted by Danielsan View Post
                  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.

                  Originally posted by Danielsan View Post
                  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.

                  Comment


                  • #89
                    Originally posted by oiaohm View Post
                    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
                    Last edited by Danielsan; 09-25-2019, 11:39 PM.

                    Comment


                    • #90
                      Originally posted by Danielsan View Post
                      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.

                      Originally posted by Danielsan View Post
                      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.

                      Originally posted by Danielsan View Post
                      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.

                      Comment

                      Working...
                      X