> That fight was long long lost. We will never ever make things like video games open source.
I don't share your pessimism.
Yes, it is harder to exploit users with [FLO] software; so there is less profit to be made; and that will discourage some companies from making it. But I can easily imagine that with a modest income from donations, a project like [Black Mesa] would be happy to make their game open source. Also yes, most software projects today cannot make a living off of donations. But there's no inherent reason this has to be so. People have shown they are willing to pay money for software; in principle, it is ["just"] a matter of redirecting that money from proprietary software to FLO software. And yes, solving the free-rider problem is a very ambitious "just".
But addressing a collective action problem like this requires a coordination mechanism, and the [existing crowdfunding platforms] don't have that. So, I am actively working on one that does — [Snowdrift.coop] — and am not yet ready to throw in the towel.
> But we can sandbox them. Even open source tools could do with being sandboxed.
I agree, but I don't think the operating system is the right level of abstraction to do this. Sandboxing is complex. Implementing it in the OS pushes that complexity on every program, which makes tinkering much harder. I absolutely do not want to have to deal with sandboxing and permission prompts in my .bashrc aliases and shell scripts. I write shell scripts to make my life easier by automating common actions, and having to set flatpak/SELinux type permissions every time I do that would defeat the purpose, or at least substantially raise the bar for how much friction is required before I turn to a script. Writing a simple program on Android/Linux is soo much more work than writing one for GNU/Linux, and soo much less accessible.
Also, we already have an excellent application sandboxing platform for running untrusted and borderline malicious programs — the web. The result of that sandboxing is incredible complexity which makes it a herculean task to develop a web browser. That's a real shame; I'd love to see the "web of documents" split off from the "web of applications" (e.g. to a different protocol, like gopher). I don't want to see desktop environments go the same way. When I install and run a program natively, I am indicating that I trust it and want to leave the restrictions and complexity of the web sandbox behind.
I do see a case to be made for a sandboxing tool for graphical applications specifically. Because building a GUI is already a lot of work compared to writing a CLI, so the relative effort to handle permissions, etc is not as large. But this should be built into and enforced by the packaging tool (e.g. flatpak permissions), not the operating system. And, to bring this discussion back on topic, not by the display manager.
Here's a concrete example: I use Mumble for voice chat. I use push-to-talk. [PTT on Wayland] doesn't work, because the display server only sends keyboard events to the client that has focus. You can look at the linked issue and see all the complexity that results. So for now I am still running X. Yes, there are workarounds. No, I don't want to have to deal with them. Not having to deal with them is the kind of nice thing we can't have if we accept sandboxing by default, rather than sandboxing only the few programs that we cannot trust to run directly on our machines.
I don't share your pessimism.
Yes, it is harder to exploit users with [FLO] software; so there is less profit to be made; and that will discourage some companies from making it. But I can easily imagine that with a modest income from donations, a project like [Black Mesa] would be happy to make their game open source. Also yes, most software projects today cannot make a living off of donations. But there's no inherent reason this has to be so. People have shown they are willing to pay money for software; in principle, it is ["just"] a matter of redirecting that money from proprietary software to FLO software. And yes, solving the free-rider problem is a very ambitious "just".
But addressing a collective action problem like this requires a coordination mechanism, and the [existing crowdfunding platforms] don't have that. So, I am actively working on one that does — [Snowdrift.coop] — and am not yet ready to throw in the towel.
> But we can sandbox them. Even open source tools could do with being sandboxed.
I agree, but I don't think the operating system is the right level of abstraction to do this. Sandboxing is complex. Implementing it in the OS pushes that complexity on every program, which makes tinkering much harder. I absolutely do not want to have to deal with sandboxing and permission prompts in my .bashrc aliases and shell scripts. I write shell scripts to make my life easier by automating common actions, and having to set flatpak/SELinux type permissions every time I do that would defeat the purpose, or at least substantially raise the bar for how much friction is required before I turn to a script. Writing a simple program on Android/Linux is soo much more work than writing one for GNU/Linux, and soo much less accessible.
Also, we already have an excellent application sandboxing platform for running untrusted and borderline malicious programs — the web. The result of that sandboxing is incredible complexity which makes it a herculean task to develop a web browser. That's a real shame; I'd love to see the "web of documents" split off from the "web of applications" (e.g. to a different protocol, like gopher). I don't want to see desktop environments go the same way. When I install and run a program natively, I am indicating that I trust it and want to leave the restrictions and complexity of the web sandbox behind.
I do see a case to be made for a sandboxing tool for graphical applications specifically. Because building a GUI is already a lot of work compared to writing a CLI, so the relative effort to handle permissions, etc is not as large. But this should be built into and enforced by the packaging tool (e.g. flatpak permissions), not the operating system. And, to bring this discussion back on topic, not by the display manager.
Here's a concrete example: I use Mumble for voice chat. I use push-to-talk. [PTT on Wayland] doesn't work, because the display server only sends keyboard events to the client that has focus. You can look at the linked issue and see all the complexity that results. So for now I am still running X. Yes, there are workarounds. No, I don't want to have to deal with them. Not having to deal with them is the kind of nice thing we can't have if we accept sandboxing by default, rather than sandboxing only the few programs that we cannot trust to run directly on our machines.
---------------------------
[FLO]: https://wiki.snowdrift.coop/about/free-libre-open#flo
[Black Mesa]: https://store.steampowered.com/app/362890/Black_Mesa/
["just"]: https://blog.snowdrift.coop/crazy-ambition/
[existing crowdfunding platforms]: https://wiki.snowdrift.coop/market-research/other-crowdfundi...
[Snowdrift.coop] besides the main site, our wiki has more/better information: https://wiki.snowdrift.coop/
[PTT on Wayland]: https://github.com/mumble-voip/mumble/issues/3243