Michał Zegan <webczat_200@xxxxxxxxxxxxxx> writes: > As for logind and other things, note that pipewire/pulseaudio are now > managed by the systemd-user. I mean it works exactly same as the systemd > system instance just in user context, and you can make it start on boot, > so you get similar reliability as in case of normal system services in a > systemd system. Pulseaudio nor pipewire are not started just by the > first client that tries to use them, and I even believe the only thing > that still does that is speech-dispatcher, unless it changed. > Logind causes changes on device acls and mediates access to some other > devices, but does not by itself spawn anything, and when it spawns > systemd-user it spawns it via systemd, like starts a service, so > reliability guarantees of an init system are not broken per my > understanding. Well, not everyone uses systemd. And by reliable, I mean always up and ready to do its particular job. Any good init system with service supervision can do that, and systemd is one such init system. Re: logind messing with device ACLs, this is where the always-up reliability gets broken. Let me put it a different way. Would a sighted person be happy if their monitor stopped working just because they logged out? I believe not. They expect the same always-up reliability from their screens as I expect from my audio system; it is my primary method of output. Of course that's also a good argument for hardware synths and braille displays, and maybe if Linux audio becomes unreliable, I'll be forced back to a hardware synth out of necessity. > As for your suggestions, actually interesting idea it is. The problem > happens when the only local computer you have is windows, do you have > any way to do it in that case? Or for example some kind of phone. I've never tried. I haven't ran Windows since late 2000 or so. I have no idea about phones, but I could possibly rig something up on Android if I really had to. Before that, though, I think I'd try using something like the Raspberry Pi. I have not tried using it as a GUI thin client yet, though I'm planning on it. For console use it works well as a thin client. For instance, right now I'm typing this out on a Pi, in my living room. I run emacs on a shared family server in the back room and forward emacspeak's speech server protocol over a TLS tunnel. So the machine running emacspeak isn't the same one as the machine with the keyboard and audio I/O devices. I could just as easily have my emacs + emacspeak running on some VM in a data center somewhere. Essentially I've got a terminal in my living room. > Yes. the thing is how much I or others want to play with it. Like not > everyone is sufficiently advanced to do it, and sufficiently motivated. Well there are two conflicting visions of computing here: personal computing and appliance computing. The latter is what's being sold with Windows, Mac OS X et al and by some Linux vendors too. It tries to be one-size-fits-all. The former is a different world. It's the world that gave us Linux to begin with. And usually there's some configuration / customization required, if you expect to get what you want out of it. > Yes, network transparency. However systemd multiseat works by attaching > something like a set of devices over usb, like you don't need a full > thin client, and you should get everything including audio. I would say > it's also a nice way to do it, at least technically. Except that thin clients give you some isolation for free. -- Chris -- Chris Brannon Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/). Personal website: (https://the-brannons.com/) Chat: IRC: teiresias on freenode, XMPP: chris@xxxxxxxxxxxxxxxxx
