I provided a fix for the application “Software” allowing to install packages in a few clicks in a template, but it didn’t get in.
A nice GUI intro when you first boot Qubes OS, explaining how to do XYZ in a few slides would be really cool… From my perspective, install software in Qubes OS could be really easy, no need for some store because it already exists.
What you want is a store for salt formulas, it’s much more complicated to implement, and I highly doubt it get approved by the developers anyway.
From my experience (not a qubesos dev here), once qusal/shaker salt stores are tested/stable enough, the discussion could open for integration in contrib repo and opt-in. As of now, there are too many discrepancies/bugs to be considered for inclusion. Ideal endgoal here would be post-install, network enabled salt deployments with shaker installer equivalent being installed by default, but there is no consensus here on how to arrive there as of now, unfortunately.
For example, cacher, both included in qusal/shaker contains bugs that prevent cacher to be useable without issues with Fedora (cksum) errors. Shaker doesn’t consider sys-whonix and misses sys-tor still today un repo, where qusal uses shaker upstream and tries to generalize not being bound to some specific use case shaker does.
Tbh qusal is amazing, and needs more testing to become mature enough, where shaker providing an installer (didn’t follow if fixed to work on q4.2 still), by providing rpms which clearly shows entry points for salt recipes in rpm spec files for both install/uninstall. That means installing qubesos customizations means installing an rpm and reverting to uninstall such rpm. Can it get more simpler then that? Yes, if the qubesos installer was proposing such customizations. But I’m getting ahead of ourselves here.
If those two projects upside/downsides were merged with more testing, I’m pretty sure the spec files/rpms could be considered for inclusion (afterall qubesos contribution guidelines are clear on packaging requirements) under contrib repo.
@solene I missed your PR for quick fixes on native distro installers? I Remeber vaguely @deeplow having suggested something similar in the past, maybe tagging him in your PR would get reviews and make this go farther? If software already in trusted repos, having them visually presented would be an improvement for sure.
that’s awesome. I would have been glad to have it the first time I used Qubes OS, I needed to be productive immediately after installation, I struggled too much to understand how to copy / paste and reinstalled a regular Linux
I never checked again if it fixed it because I realized that the default templates had switched to -xfce… (Which in my eyes as a blow for usability and asthetics). This meant that default templates no longer a modern-looking graphical software store.
So making it work out of the box to me now seems that it would be a nice niche feature. I was even working on a video tutorial (many actually) on installing software. I had it all already recorded. But the issue is that I had been using 4.2-rc1 and so I never realized until pretty late in the game that in rc2 the default templates changed and most of my recordings assumed gnome templates.
That was not the only reason for why I didn’t make more video tutorials, though. I am a perfectionist, which further delays things and I had a few other setbacks like my Qubes video editing setup not working on 4.2, etc. But it’s still something I want to do. And this was kind of the follow up to the integrated tutorials (a more sustainable approach).
So it would have been really nice to have had Gnome Software fully working and the devs do care (they shipped that patch into 4.2 even as it was in RC mode!). However I don’t think that matters much because default templates don’t ship it anymore . So there is currently no GUI path for installing software without ever using the terminal.
I would say yes because you need to use a terminal. So for someone who’s never used one it’s not a very good first experience. Require a harder to use tool to use a simpler to use tool is not ideal. Furthermore, before it was even on the template menu by default, which meant it could be discovered by the user out of the box.
Yes, but other than having a pre-historic user interface, synaptic has poor software discoverability. One has to know already the exact name of the software they are looking for. It’s better than nothing, but much worse than gnome software.
Reading all of the above (and I’m sorry for interrupting this thread from reading only e-mail subject and jumped to replying instead of having read the whole thread), this is kinda going where my ideal always was.
So if I recap, the default templates are now closer to minimal, that required a switch to xfce. That’s good for size of iso, and to fit base deployment to reduce size of sys-* runtime memory footprint, which was the goal initially of xfce template. The gnome-installer fix is now there, but required packages to deploy it by default are not present in the installer to be installed (no gnome in xfce templates) without network connectivity nor packages offered to be installed at install.
Maybe a bit of plumbing would be necessary?
If we get back to basics, the typical qubes user (there is no such thing, but still), lets call him “qubes beginner” to reflect persona, would want to be able to install trusted software from trusted distro repos GRAPHICALLY. And that misses a graphical INSTALLER that can talk through update proxy. They want near other Linux distro experience, but inside of qubes. Graphical experience, not shell based (feeeear) and that’s ok. This should be ok. Why is it neglected? Because other technical considerations want over. But it could and should not be a blocker.
Let’s take a top down approach then bottom up for integration path?
Top-down:
On qubesos installer, have the installer propose and activate “gnome Gui and Gui installer” ticked by default, whatever that name would be. The default!
in the installer, have those base package and associated salt recipes available for activation, without the packages being inside of the templates but made external so not deduplicated across templates (a la “cacher” approach ), so that all minimal templates can deploy them at install without those being inside of the templates (biiiig win on sizes, win for sys-* service qube, lower memory need generally). Fits all, no NEED to be in all templates.
Bottom-up
figure a way from the installer to have deb+rpm local repositories or similar somehow so installer can deploy additional software (without network connectivity) or enable on-demand additional salt repositories usage with network connectivity requirement
have installer propose those additional customizations which will be able to download other templates and deploy software install on second stage reboot of qubesos
The important point here is that templates choices to land in installer can and will change and just did change, where the defaults might have had size consideration over usability, even though I read complains on github as well on the result of usability of that choice. Setting default is always hard, but not permitting customization is the issue here. I’m pretty sure that if size constraints were respected with customizations at install being possible, then we would get what we want (lower iso footprint, lower sys-* service qube footprint, high usability by default for new comers, opt out for advanced users). AND NO NEED TO REDO ALL DOCUMENTATION.
Therefore I think the issue is the limitations of the installer to permit to deploy user selectable installation options to fit the “persona” problem once and for all. Not what the templates deploy by default and maybe the debate should be around how to push needed packages to be used across templates or other solution, and or salt recipe inclusion/network access in the installer?
I would vote for better usability by default with users opting out if really desired, but yet again without getting too ahead of ourselves, it’s a technical challenge to do this right, while I think the real challenge might be around having packages and salt recipes for templates customization at install to fit different goals, different persona. And if that grows too big, consider network install option while packages available and qubes install, if not in templates and duplicated increasing size of templates, could resolve all the needs of everybody without trying to tailor one size fits all templates that needs to fit in the ISO.
To image this, consider having minimal templates only, and externalizing packages needed to turn minimal templates in their xfce/gnome counterpart. The packages would be there once and available after template deployment at install, and salt recipes present to do this the right thing each time, since clean templates freshly installed. The packages footprint would be minimal, and the packages needed for customization present once instead of in all the templates. The final gain here would be to have one whonix template, not two, saving most of the place needed here for iso size constraints. And the minimal templates could be cloned by installer prior of creating xfce/gnome counterpart, where gnome counterpart would probably be deployed for new users and or not advanced users or lower end perf computer users, if not all because not consuming more ram in service qubes as the end goal of template choices.
Thoughts?
I dream of a day where qubes video companion, qubes screenshot and other needed customizations are in and ticked by default or through UX careful design decisions. The delays between needs and feature made available to users is the main problem I see here. The new user should be able to install softwares available through fedora/debian channels, visually, to get more people on QubesOS. And that is not happening because of technical constraints. We need to fix that. And in my opinion, we need to leave the one size fits all approach, and learn from side projects like qusal/shaker and somewhat bring back what was learned from those PoC projects in slow integration steps upstream. But well, and without jeopardizing usability through regressions. Let’s learn from this and define the needs properly, and choose best strategies to meet them.
From my experience, OEM now create custom ISOs to deploy their packages. This shouldn’t be that way. The ISO could wrap around a loop back disk layer that contains packages and salt recipes which would deduplicate sizes of templates and what creates those customized templates be available externally. This is a strategy not a need. But if we focus on the needs, we might get lucky.
Annnnd. Not need to redo our screenshots/videos all the time to explain to users how to address their needs. But that is the final goal of this thread. Not how to get there.
@deeplow I follow securedrop github repo and see a lot of your involvement there. I’m not sure how to suggest those approaches in a way that fits both qubesos and securedrop, but any insights you have to address the needs and then the strategies to go there would be really helpful for all, and not constantly redoing the docs and videos which are the outcome of both threads now spliited out.
I’m now working on SecureDrop, that’s probably why . I don’t have a specific answer for your question, unfortunately and I don’t think the SecureDrop team is focusing on software installation at this moment. But I might have misunderstood your question. Please let me know if that was the case.
Actually I don’t agree that the issue is with customization. A new Qubes user won’t know what to customize and may feel overwhelmed by the options. Furthermore having more default customization also complicates the documentation efforts. Think for example of all the various parts “if you’re on Debian do X if fedora, do Y”. Now we could have the matrix of options for [fedora,debian]*[gnome,xfce], which is not sustainable.
I don’t fully agree with the XFCE default templates but I understand the reasoning. Now we just have to deal with the consequences, documentation-wise.
Tik Tok Money accelerates the when, the point in time, when a usable, more polished Qubes is available.
I see some ideas put forward, that are like the perfect solution.
I was going to suggest to a more simplistic, way forward.
Then I wanted to experiment with the versions from downloading entire Qubes. As I do not have at home internet, and my public library was not open. So the impracticality of my what I thought was a good solution. Well.
Still. It is possible to create Qubes that might be directly installed, no salt. Salt may be a better solution, but it does not feel like it will take less time as testing and such.
As the first thing a person who needs a secure connection needs is a VPN.
First Qubes for the VPN’s ( which are not complained about as being , owned by someone who might be exploiting them, and/or, . . . .
As work flow, I imagine one having a disp Qube that is open to the internet, and
Such as a Template and a disp App for Mullvad. Or other browsers. Claws Mail.
then the information should be moved to an offline Qube , for viewing, preparing reply, deciding what to keep.
So a Template that is offline, with most of the standard types of tools, office, calculator already installed. this list could be from someone more knowledgeable than myself.
A Template that is prepared to allow installation of Snap Packages, Flatpak, Gnome, gee would that include Synaptic. So the user could clone up this Qube, and install what he desires with less study, looking back and forth to documentation.
Notes somewhere on how to move things between Qubes.
I feel unman has created Qubes already that cover some of the other needs.
Qube for use with a secure chat, and there are several options, I feel, just one of the reviewed software ones,
If we can find a Video chat that is not from an authoritarian country with adequate encryption protocols. Put that in a Qube by itself.
I had read that Ubuntu had an, “I talk, it types.” if it works, and it is free, then create a qube for that, that is always offline. but I have not found that applications (I talk it types)
This seems to cover a lot of, what the newcomer might need. If the user will stick to the flow of work, receive information in one set of disp Temporary Qube, transfer to a Qube for actual viewing and such.
If just one more Qube, is to be created, then it would be the tempate which already has all the connections to allow software to be installed without a lot of terminal work. Like has Flatpak installed. Snap Installed, the installers needed for the other software. and it will leave a clickable tab to be shown, for any Software installed.
I wonder how this impacts the project, but since I joined the community, I feel like developers are working on a secure operating system, while the majority of users seems to be chasing a privacy oriented operating system?
If this is really the case, Qubes OS won’t provide a good user experience, and will never do.
Are there any data about the community? Like a survey to understand what people need, what people lack etc…? This could be interesting to help the development team IMO.
@deeplow my bad.
What I meant is there is a tendency for duplication right now where the objectives could hide the implementation details
minimal templates could be the default deployed ones
packages needed to turn them into xfce/gnome clones could be externalized to be picked up at installation for sys-* (xfce) or standard qubes (gnome)
the normal end user wants to have better UX as far as I understood per referred results.
end user would want gnome based sys-usb, xfce based sys-firewall/sys-net
devel implemented differently because size constraints which defaulted to xfce default install and quick fix needed afaik.
all the doc needs refresh consequently (downstream as well).
What I’m trying to deal with here is mix of bottom up and top down approach cause I feel we are not that far of an understanding of what could be done to meet both size limitation requirements of iso, minima ram usage of sys-qubes without compromising UX experience.
Advanced users/constrained perf systems owners will tick “advanced options” and be willing to choose between more options.
Unfortunately, if we don’t want to go that path, an app store is needed again. And the dream of having qubes having one whonix template not two, and removing duplicated packages across all those templates present in the ISO, nor clean deployments easy to recreate will I think never really be attained.
Customizable deployments is needed by OEM/organizarions/end users. The story repeats itself everywhere in different forms. Qusal and shaker are just strategies, while hard to implement in an OS installer if not network connection. That’s what I wanted to tackle into investing time, maybe dodging the need to redo all those documentation and videos that would otherwise be still valid. Would be nice if we stopped changing UX and work behind the scene to meet back end requirements and fit those requirements thinking out of the box without the need to redo everything all the time. That is my opinion.
By saving that space (whonix workststion is more then 60% duplicated space from whonix gateway), having packages related to xfce and gnome as packages, I think it’s possible to imagine minimal and whonix templates being generalized so that packages dependencies to differenciate them into their gnome/xfce/whonix workstation counterparts not having to be deduplicated and the installer running the required salt calls to use packages and customize to match expected better gnome UX without having to impact service qubes which don’t need it, unless the user tick “advanced installation” options and enjoy the additional options, with that screenshot alone having to evolve in the docs, not all qubesos/securedrop workstation user guides screenshots, nitrokey/purism/novacustom etc docs screenshots and videos out there.
. So there is currently no GUI path for installing software without ever using the terminal.
. I don’t have a specific answer for your question, unfortunately and I don’t think the SecureDrop team is focusing on software installation at this moment. But I might have misunderstood your question. Please let me know if that was the case.