On Fri, Jun 17, 2016 at 10:56:28AM -0400, Owen Taylor wrote: > > How would non-GUI applications be installed in this picture? > I'm not entirely sure what you have in mind for a non-GUI applications, > but options available include. For _services_, running in a docker container seems like a good solution. I'm more talking about compilers, text editors, and other various utilities. I use the `calc` command-line calculator all the time, for example, and taskwarrior for keeping my todo list. > * Run in a container > This is the obvious path for network services - if you want to run > Mailman or Wordpress on your workstation. It's also may be the > an interesting route for development tools - the container > provides the "SDK" you are developing against. That's an interesting approach. How could we make that easy and obvious? Possibly we could install desktop icons and tools that start up a given "SDK" environment -- and let you customize it to your liking (so _we_ aren't deciding "emacs or vi?" for people). Maybe even the default terminal app drops you into a utility container rather than the base system. > * Use a layered RPM > rpm-ostree now has support for locally installing RPMs on top of an > OSTree. We don't want to use it as our primary installation > mechaniss, because it causes problems for the idea that applications > are upgraded independently from the OS. But it can be the perfect > escape hatch if you need 'tracepath' or whatever and it isn't > otherwise available. maybe this is the way, but unless we put a lot of development into alternatives, I think it's going to be very common in our target audiences, so it'd need to be more than a rarely-used "escape hatch". > * Package in a flatpak > There's nothing inherent about Flatpak that prevents it from working > for many TUI and command line tools; the export system would have to > be extended to export a wrapper script to turn 'nano' into > 'flatpak run org.nano-editor.Nano'. Turning on sandboxing is harder. Yeah, this seems possibly useful for some tools, but the sandboxing seems _really_ hard. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
