1. 12

  2. 4

    It’s posts like this where I’m reminded that it’s only a matter of time before something goes wrong on my computer and I’m too dumb or burnt out to try and fix it.

    1. 1

      Or you could run a system like Void Linux and operate without any of the *kits.

      1. 1

        Does running Void Linux make audio easier? How is it controlled on Void?

        1. 1

          It makes it easier to know every facet of your audio install, at least the names of the components. After all, you probably installed most of the user tools yourself.

          1. 1

            But are there different tools or does it still require mucking about with PulseAudio and Jack and …?

            1. 2

              Me, I use alsa and sndio. Life was great even just using alsa.

    2. 1

      Yeah changing the permission bits on /dev inodes depending on who’s logged in is a little weird. I guess it has lower overhead than proxying access to those devices.

      Now I’m wondering what happens when multiple accounts log in at the same time. Do they all have access to the audio devices?

      I bet if you leave a process running when you log out which has an open file handle for the sound device, nothing will revoke that access so long as the process continues to live.

      1. 6

        Yeah changing the permission bits on /dev inodes depending on who’s logged in is a little weird.

        It’s not that weird; Unix has been doing it for a long time, at least since the early 80’s when Unix became a workstation operating system. Back when the only way to talk to the machine was via some sort of terminal (a serial terminal or an X terminal), your connection to the machine was hidden behind that one device and if you owned any devices directly at all it was just your single terminal device (e.g. /dev/ttyS0 or whatever).

        (It’s been way too long for me to remember if login(1) “always” changed ownership of your login device for you or if that was a BSD-or-later innovation but I seem to recall the intricacies of mesg n requiring terminal device ownership since time immemorial…)

        But then when you started logging in at the machine itself, you needed to have access to a lot of hardware (the framebuffer, the keyboard, the disk drive, etc).

        I know that login(1) on SunOS 4 (late 1980’s) used /etc/fbtab as a table of devices to change ownership/permission of upon login. I think that goes all the way back to to BSD-Lite releases but I can’t be sure. I know that modern {Net,Open,Free}BSD still use /etc/fbtab at least up until the last time I used them (which hasn’t been that long).

        The modern Freedesktop ConsoleKit way is just the latest step in a decades-long evolution of having a timesharing operating system designed for remote serial terminals running on a local workstation. :)

        1. 2

          The last time I logged onto any Unix system with other users also logged in was in the mid-90s and that was in a university setting. Even companies I’ve worked for (and currently work for) that use Unix almost never have more than one user logged in, and if they do, it’s usually a few developers or devops trying to diagnose a problem on a server, not using it in a time-sharing, general purpose way.

          1. 2

            Presumably only one account can meaningfully be actively using the keyboard/monitor/speakers at the same time.

            If there are multiple keyboard/monitor/speakers (I’ve heard this called a multi-head setup), then also presumably you’d have a single user at a single head at one time. Other usage patterns are possible, but I don’t think I’d generally want a remotely logged-in user playing audio while I’m at the terminal unless special permission is given.

            1. 1

              The Right Way™ to handle such a situation would be for the OS to ensure that /dev/audio points at the correct audio device for each head, /dev/mouse points at the correct moise, &c. There’s no inherent reason for the device filesystem to be global.

              Plan 9 was great at this kind of thing.

              1. 1

                I agree, but that doesn’t solve the problem of permissions on the linked-to device.