Announcement

Collapse
No announcement yet.

Lennart Poettering On The Open-Source Community: A Sick Place To Be In

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

  • Originally posted by gens View Post
    one system is enough thou, since they have the same sound card chip
    correction, i misunderstood that bout your laptop and desktop have a VIA envy
    oh well..

    your laptop playing a sound that has a sample rate different then the default output would be the worst case scenario (unless they changed the default software resampler, then its just bad)
    desktop with VIA envy would be the best case scenario

    well... VIA envy on raw alsa output would be the best case scenario, thus a baseline
    Last edited by gens; 09 October 2014, 05:40 PM.

    Comment


    • Originally posted by gens View Post
      nice
      i am in fact interested in the result, since, due to the VIA envy chip, your configuration is the best possible for PA
      i would also like to know if there is a difference in cpu usage when playing a 44.1kHz sound compared to a 48kHz sound, as that would show if PA treats your card properly

      basically with resampling moved to the sound card, this is mostly a benchmark of the overhead of PA's timing implementation and copy-ing
      it is not that precise thou since dealing with alsa adds to the cpu usage of PA
      I will try that when I get the chance. For your information about the onboard sound chip from both laptop:
      Intel [HDA Intel], device 0: ALC262 Analog [ALC262 Analog]
      Subdevices: 0/1
      Subdevice #0: subdevice #0

      and desktop:
      VIA1708S 8 -Channel High Definition Audio CODEC
      DTS Surround Sensation UltraPC
      - Supports Jack-Detection, Multi-Streaming, and Front Panel Jack-Retasking
      - Optical S/PDIF Out ports at back I/O
      - ASUS Noise Filtering

      I don't own a dedicated sound card. Starting another topic will be great.

      Comment


      • Originally posted by JS987 View Post
        Your post don't contain any relevant information.
        Coming from you, that's practically priceless.

        SystemD has bad impact on security and stability of Linux because of executable running as PID 1 with size over 1300 kB written in dangerous language like C by lax developers has big attack surface.
        I'm curious, what language did you think /sbin/init was written in? Hmmm... let's go check on the most secure open source operating system around, OpenBSD.

        Oops. It's written in C. The compiled executable is over 300 kilobytes. Holy. Shit. Somebody ought to run and tell Theo that he's doing it wrong. I nominate you.

        Crash of PID 1 will crash whole system.
        Duh. Yet SystemD has never crashed for me. Not even once. Hmmmmm... Perhaps you are just doing something wrong, eh?

        If you make post, post something relevant.
        If you make post, post something true.

        Comment


        • Originally posted by jaylittle View Post
          I'm curious, what language did you think /sbin/init was written in? Hmmm... let's go check on the most secure open source operating system around, OpenBSD.
          Oops. It's written in C. The compiled executable is over 300 kilobytes. Holy. Shit. Somebody ought to run and tell Theo that he's doing it wrong. I nominate you.
          sysvinit PID1 has only about 40 kB, which means systemd PID1 has over 30 times bigger attack surface.

          Duh. Yet SystemD has never crashed for me. Not even once. Hmmmmm... Perhaps you are just doing something wrong, eh?
          If it didn't crash, doesn't mean it can't. Probability will increase with complexity.

          Comment


          • Originally posted by JS987 View Post
            sysvinit PID1 has only about 40 kB, which means systemd PID1 has over 30 times bigger attack surface.
            No, attack surfaces doesn't work like that. You can't just count the size of the executable. A small executable that allows someone pretty much unlimited access to do whatever they want has a larger attack surface than a big executable that only exposes specific interfaces in limited ways and that keeps close tabs on what is going on.


            Originally posted by JS987 View Post
            Probability will increase with complexity.
            All other things being equal. But of course they aren't in this case, far from it. Probability will also increase with the flexibility you give the user, since it makes it more likely to hit untested code paths.

            Comment


            • So the entirety of your "technical argument" now revolves around the size of the executable? Based on that argument you are screwed. OpenBSD is clearly too insecure for you. Once Gentoo dumps OpenRC in favor of SystemD what will you switch to then? Windows? MUHAHAHAHAHAHA. Good luck with that.

              EDIT: TheBlackCat of course nails it. Size of the executable has absolutely nothing to do with the size of the attack area.

              Comment


              • Originally posted by TheBlackCat View Post
                No, attack surfaces doesn't work like that. You can't just count the size of the executable. A small executable that allows someone pretty much unlimited access to do whatever they want has a larger attack surface than a big executable that only exposes specific interfaces in limited ways and that keeps close tabs on what is going on.
                SystemD has more features like D-Bus activation, socket activation which means it has bigger attack surface.

                Comment


                • Originally posted by JS987 View Post
                  SystemD has more features like D-Bus activation, socket activation which means it has bigger attack surface.
                  This is not really relevant per se.

                  The important thing is, first, determining the the level of exploits are made accessible by attacking pid 1. Then, the second step is, what is the total attack surface of the system that may result in this level of exploit. That's the surfaces you have to compare, not just a single component. You cannot compare a single link of a whole chain when determining the chain's strength.

                  If your exploit is crashing the system, or getting root access, or evading a container, the surfaces involved are muuuch bigger than 10 or 300kb anyway, and it's not even quite clear that they are bigger with systemd.

                  Comment


                  • Originally posted by JS987 View Post
                    SystemD has more features like D-Bus activation, socket activation which means it has bigger attack surface.
                    No, it doesn't. Again, restricting people to a small, defined set of tightly-controlled interfaces reduces the attack surface relative to basically letting people do whatever they want.

                    As systemd opponents keep saying, it is possible to write scripts to make sysv do just about anything. That makes the attack surface nearly infinite.

                    Comment


                    • Originally posted by JS987 View Post
                      SystemD has more features like D-Bus activation, socket activation which means it has bigger attack surface.
                      systemd employs powerful kernel security features like "kernel capabilities" and namespaces (and cgroup) that can protect all daemons on the system. So eg. a daemon can have "NoNewPrivileges" and "Protectedsystem" etc turned on which prevent any privilege escalation from taking places, or prevents the hacker from ever accessing the /usr or /boot and similar, even if he gets access to a process with root privileges.

                      Here is further info:
                      http://0pointer.de/blog/projects/security.html

                      Just the fact that systemd separates code from config-files makes it more secure than script based init systems that mixes code and daemon parameters in executable files.

                      Comment

                      Working...
                      X