Announcement

Collapse
No announcement yet.

Systemd 199 Has Its Own D-Bus Client Library

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

  • Originally posted by Teho View Post
    Correct me if I'm wrong but to my understanding PulseAudio uses alsa-lib to interact with the kernel. However ALSA doesn't do mixing in the kernel so in any case you need to add additional mixer on top of it (you also need one for networked audio, audio processing and such that PulseAudio also does). Peope who refer to "plain ALSA" probably mean the mixer shipped with alsa-plugins called dmix.
    Strictly speaking, the ALSA related modules from libpulse use a tiny part of alsalib (the daemon itself doesn't), but that's only because alsa-lib is the way to do basic stuff like device enumeration and querying the kernel about the (sound) hardware capabilities, and because PA knows it's not alone in the world (and won't be for some time). It doesn't use the heavyweight stuff from alsalib (e.g. the whole plugin system).

    Anyway, from a typical app developer's perspective it was wrong from the beginning to write against alsa-lib. It's no surprise that people kept doing it though, considering how the whole Linux ecosystem works. It wasn't their fault that there was no better standard way. Just as it's not Lennart's fault that all the other sound servers failed at becoming standard. Because a general purpose operating system really needs such a mechanism. I think users should be happy about the fact that PulseAudio seems to be a good enough design (bugs aside) to become the standard for doing sound on Linux

    Comment


    • Originally posted by frign View Post
      There is more to Jack than the Daemon (jackd), smartass. It is part of the Kernel, because there is active support for its user-space-implementation. It is as if you were stating udev wasn't part of the Kernel only because it is just the user-space tool to manage the /dev-FS (which is explicitly right, but implicitly wrong).
      This stands in sharp contrast to PulseAudio, which is not endorsed by the Kernel; that makes me feel warm inside .
      First off, presumptuous *asshole* -> i wasn't being a smartass ~ just stating a fact. Jack is a user-space application.
      Sure, some changes were made to ALSA to improve support (which is no surprise since it's alsa's job to handle sound on the linux platform @ the lower levels), but that still does not change the fact that Jack is a user-space application.

      EDIT: You can come back and claim it is in the kernel - when i have to compile a jack kernel module, k? - until then, you are wrong, plain and simple.
      Last edited by ninez; 03-29-2013, 01:11 PM.

      Comment


      • Originally posted by ceage View Post
        Q: What's your view on systemd? [...]

        Linus Torvalds: I actually like a lot of what systemd does. My personal biggest issue with systemd is: the people involved seem to think that change is good for it's own sake. I've seen Lennart Poettering, for example, talking about how something is bad because it's something that has been done for thirty years, and old is by definition bad. Which makes no sense at all to me because I'm saying if it's been working for thirty years, it's clearly doing something right. This is my standpoint while some of the systemd people have the exact opposite, which is saying ``If it's been working that way for thirty years, it's about time we changed it.'' That mentality makes me very nervous. They seem to sometimes make changes for the sake of changes and worry less about what people are used to. That's probably why systemd has generated so much negative feedback, because it takes people out of their comfort zones and doesn't feel bad about that at all. At the same time I think, a lot of what it does is interesting. So I'm a bit nervous about the development model and willingness to break things, which I think is a huge mistake, but I do think that it's showing a lot of promise.

        http://bambuser.com/v/3084584
        Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

        There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.

        Comment


        • LP has already said that was his primary focus. What did he call it? I think he called it "Vertical Integration"

          Comment


          • Originally posted by cjcox View Post
            Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

            There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.
            But it worked out fine in the end, did it not?

            Also, no, I don't follow. What do closed-source solutions have to do with all that?

            Comment


            • Originally posted by cjcox View Post
              But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for.
              What exactly are you referring to?

              Originally posted by cjcox View Post
              Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.
              What things were ignored? What promises were made? What things can't be done well with systemd? What worse hacks are you referring to? What is wrong with the sysvinit script compatibility mode?

              Originally posted by cjcox View Post
              There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though.
              What kind of stability problems is systemd having? What large companies are you referring to?

              Originally posted by cjcox View Post
              It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.
              What do you mean? What closed solutions? What closed source software? How is systemd responssible for them?

              Try to give some examples. Your posts is so vague that it doesn't really tell anything to anybody.

              Comment


              • Originally posted by cjcox View Post
                Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

                There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.
                Oh, yes, I'm SURE RH isn't looking at systemd for use in enterprise settings
                For instance, I'm sure they haven't been doing this for sometime.

                Comment


                • Originally posted by cjcox View Post
                  Yes... again, let me reiterrate. I don't think people necessarily have a problem with the idea of a superior init. Nor do I think people have anything against making things smarter, more uniform, etc. But if you've followed systemd, then you know that this project started out without a lot of understanding of what all people were using init for. Now... we can disagree about how people use init... but things were ignored, and promises were made... and it has lead to a lot of scope creep and even so, there are things that can't be done well with systemd which will lead to even worse hacks (using the not well supported compatibility mode) via shell scripts.

                  There are certain large companies with large knives that are itching for systemd to stabilize... then they will plunge it straight into the heart of Red Hat. I'm not sure if anyone understands that though. It's not that I hate developers of closed source software, just want everyone to know that one of the outcomes of systemd is a lot of closed solutions.
                  Huh? What Teho said. Systemd started because launchd wasn't under a GPL-compatible license (Apple relicensed it a few months later from the Apple license to the MIT or Apache license) and the only reason launchd was being looked at was because Lennart believed it was wrong to push the hard tasks, such as dependency resolution and parallelization to the clients (services) in init.

                  What promises were made?

                  "Scope creep" in comparison to its original goal of "a new, better, init." Sure. But the systemd devs were very clear and open about the fact that they moved from an "init system" as their goal, to more of a suite of tools to cover the groundwork of a linux distro.

                  Large companies with knives waiting for systemd to stabilzie? Huh? I dont follow you on that at all o.O

                  What closed solutions are you talking about as well...? Systemd is under the LGPL or GPL

                  Comment


                  • Originally posted by Ericg View Post
                    Systemd started because launchd wasn't under a GPL-compatible license (Apple relicensed it a few months later from the Apple license to the MIT or Apache license)...
                    I think you are confusing systemd and Upstart.

                    The Ubuntu Linux distribution considered using launchd in 2006. However, launchd was rejected as an option because it was released under the Apple Public Source License which at the time was described as an "inescapable licence problem".[5] Ubuntu instead developed and switched to Upstart, its own service management tool.
                    In August 2006, Apple relicensed launchd under the Apache License, Version 2.0 in an effort to make adoption by other open source developers easier.[6] However, most common open source operating systems use systemd or continue with init instead.
                    -Wikipedia
                    Last edited by Teho; 03-29-2013, 07:02 PM.

                    Comment


                    • Originally posted by Teho View Post
                      I think you are confusing systemd and Upstart.



                      -Wikipedia
                      Whoops, thanks for the correction Teho. I was thinking of: http://0pointer.de/blog/projects/systemd.html where LP talked about being inspired by launchd, not using it.

                      Comment


                      • Originally posted by GreatEmerald View Post
                        Interesting. What OS and version are you using? Which version of the kernel and PulseAudio? Did you change any PulseAudio defaults? What are your hardware specifications?
                        Originally posted by Ericg View Post
                        Speaking of which... TAXI, sorry we like completly ignored you. I do want to help you though. What distro are you? What version of Pulseaudio? By "SB LIVE!" I'm assuming youre using a SoundBlaster card?
                        Thanks for your replies.

                        I'm running Gentoo (64 bit, always up2date), kernel is 3.8.4 (directly from kernel.org) but it was the same with older kernels, too. In fact this is since I installed PA. I tried various PA settings with the hope to fix this (which didn't work), so I'm not sure if they are default now:
                        default.pa
                        system.pa
                        client.conf
                        daemon.conf

                        What are the specifications you need? This is a SoundBlaster Live! 5.1 (emu10k1, driver build into the kernel) :
                        04:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)

                        CPU is a AMD Athlon(tm) II X3 455 Processor, 8 GB RAM. My GPU acts as a soundcard, too:
                        03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cayman/Antilles HDMI Audio [Radeon HD 6900 Series]
                        but it's disabled in pavucontrol (and I have no HDMI monitor).

                        In case this matters:
                        Code:
                        $ emerge -pv pulseaudio
                        
                        These are the packages that would be merged, in order:
                        
                        Calculating dependencies... done!
                        [ebuild   R    ] media-sound/pulseaudio-2.1-r1  USE="X alsa asyncns bluetooth caps dbus gdbm glib gtk ipv6 libsamplerate orc realtime ssl tcpd udev webrtc-aec (-abiwrapper) -avahi -doc -equalizer -gnome -jack -lirc (-oss) (-system-wide) (-systemd) {-test} -xen" MULTILIB_ABI="amd64 x86" 0 kB
                        
                        Total: 1 package (1 reinstall), Size of downloads: 0 kB
                        $ cat /etc/portage/make.conf | grep CFLAGS
                        CFLAGS="-march=native -O2 -pipe -fno-ident -flto"
                        CXXFLAGS="${CFLAGS}"
                        LDFLAGS="-Wl,-O1 -Wl,--as-needed ${CFLAGS}"

                        Comment

                        Working...
                        X