W dniu 20.02.2021 o 17:46, Chris Brannon via orca-list pisze: > 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. It doesn't. First it cannot revoke control over these devices if they are already opened, second if you add the thing to audio group it still has access. It's just for managing device ownership for local sessions. It would never affect system services or services having unconditional access to the device, it does not and cannot force-release a device with exception of graphic devices it seems. No one made that impossible. > > 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. I get it, although actually graphic cards are governed by a stronger mechanism that force-switches control between x servers/compositors, so sighted people are more affected than we are, in theory. Although, if I switch user sessions and am sighted, I get my configuration of monitor/etc applied, so ... it's all the same, all the same. X servers are currently also per session, same as wayland compositors. Of course requirements are different, but mechanisms themselves do apply here. > >> 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. Yeah, and here it appears. You need linux to accessibly connect to linux gui. And you are not always in a situation where you have any choices. > > 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. Well, but it is not either this or that. You should be able to customize things, but necessarily be forced to do it because othervise something doesn't work. Especially if sighted people don't have some problems and we do just because our requirements. > >> 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. Everything has pros and cons. I believe for example you get better performance when using usb devices compared to thin clients, especially when it goes to things like sound, as in, if you have to connect over tcp or forwarded unix socket, not sure you can use shared memory. All sound servers like pa/jack probably?/pipewire use shared memory for data transfer, mediated over unix sockets, and I doupt that works over tcp where you cannot even send file descriptors. And not sure what happens if over ssh when you tunnel unix sockets, for example. > > -- Chris >
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
