Either we include it as part of the installation process as some sort of additional packages (which I’m not sure is possible) or we provide it as part of a “First time assistance”.
I obviously want to see Qubes evolve in a direction that will benefit myself as someone who use it as a daily driver, but I would also like it to be helpful and approachable to the “less techy”. Dev’s don’t have unlimited time and have to choose.
So what I proposed is beneficial to experienced users (help save time) and makes Qubes more approachable to new users (makes dealing with AppVMs less complicated). Anyone who will think “this is dumb” is more then welcome to click “skip” and move on.
As someone here wrote before - you don’t TRY Qubes-OS, either you commit or you don’t. In general, I believe users who made the decision to use Qubes are more open minded and committed, and will appreciate this option. Anyone who want to “just use my computer” could have bought a computer pre-installed with any of the more popular OS’s 
It’s possible. It would increase the size of the installer ISO, though. But it’s possible…
Plus, I have a feeling that a Qubes OS net-install ISO might turn some people off (or maybe I’m wrong?).
I guess… But we don’t really want to scare anyone away without a valid reason, either…
I mostly agree, and so suggested that this will be an optional “First time assistance” that will help add various AppVM’s. It would have “skip” botton, and will be accessible from the menu for anyone who wants to make use of it later. And since it runs after full install, it is essentially a few scripts that download and configure templates - nothing complicated to code.
However, I would still very much want Qubes to come out-of-the-box with NET/FW/USB minimal templates instead of the full ones they get now.
Although I certainly understand the complaint (one of the first things I wondered is why EVERY qube had keypass on it, rather than just the vault qube–and of course it’s because all of the default qubes use the same template, so that template needs to have everything on it), the problem really is space.
A full template is something like 5GB on disk. Minimals are 1.5 GB or so.
Just to handle my networking, I need four distinct qubes, with in essence four templates (one per each) if I go the minimal route. (I have separated my wifi from my ethernet.) Each of these is slightly different from the others (OK, without checking it’s possible the two firewall templates are essentially alike). So unless you want the install script to separately set up these templates, you’ve got to bundle them all together in the ISO.
Similarly, a Vault template, if it were to be the only one that has keepass on it, would add a lot to the ISO…or Setup would have to clone a no-keepass-installed VM and install keepass on it. And Setup already takes a long time [it doesn’t help that the side-to-side motion in the progress indicator slows down and freezes, making you think perhaps it “hung” during install]. Cloning is a lengthy operation, and renaming is just as bad (because it’s really a clone-and-delete-the-original).
In an ideal world the default templates would only contain what makes sense in their domains, but they had to go with just having the one template and having the AppVMs configured a bit differently. Actually, to the geekish, that’s a demonstration of the flexibility of the paradigm.
I don’t know which hardware you use, but on my SSD template cloning takes seconds.
I believe that providing the minimal templates on ISO is the way to go in order to have minimal template for NET/FW/USB from the start.
As for having templates tailor-made for specific tasks
a. that’s for the user to choose if they’re willing to spend the time and wait. (I think it’s worth it)
b. assuming there’s already a minimal template on the OS, it’s just a matter of getting the relevant packages from the repository. it takes time and bandwidth but instead of doing it from the command-line, if the user will have a nice “menu” to choose from (with the menu item running “sudo dnf install keepass” for them) then it makes it much more approachable for the less techy. I agree that it’ll take time depending on the hardware and bandwidth, but people are waiting much much longer to download/install a computer game. if they think it’s worth their time - they’ll wait for it.
If we must, why not having that “one template” a minimal, and have scripts install whatever packages are needed based on “what makes sense in their domain”?
The packages will have to be stored on the installer image and slipstreamed
in to the (cloned) template(s).
Don’t know if this is possible, but include kernel-latest in the ISO so users have option to install with kernel-latest on newer hardware. And if installer cannot start, try again starting with kernel-latest.
I’m not sure if you mean that this is a problem or just the way to achieve that goal, but considering size, isn’t the size of the minimal template + packages the same as the full template which includes the same packages?
I’d go one further and have an option to sync with the Qubes repo at install, and download any extra packages you may require. This would allow you to choose your templates and extra packages, if you wanted to.
No, I don’t think anyone in the “fugitive” category would be doing a net-install, but it sounds like there would be enough people who would consider this useful…
And go one step further and allow the whole thing to be automated, like the Debian installer. Great for enterprise adoption.
There is no sys-net and firewall at this point, so you will expose your vulnerable dom0 to the Internet. Are you sure you want this?
You’d be booted off the ISO, so you wouldn’t actually have a dom0 at this point
I said it wouldn’t be for everyone, but I can definitely see uses for it.
In all seriousness, it would be no different than qubes-dom0-update, and there would be a way to configure the installer ISO in a similar way.
It might not be worth the time and effort, but I still think there’s a pretty decent use case.
Or even declare which templates and extra packages you want at the time of install, and then once your sys-net, syps-usb, sys-gui, sys-firewall, sys-audio, sys-nas-backup, sys-whonix, and sys-gui-decoy-for-so-called-plausible-deniability were all set up, Qubes OS could automatically perform the necessary steps in the background (or foreground, depending on preference). That’s also an option.
It’s just a statement of fact.
If you only want to ship a minimal template (which?), then you cant get
online.
So you have to provide at a minimum packages that will allow
networking and provide drivers, and more likely all the packages that
you think should be installed in your target(s).
If you offer a choice of distros you will have to provide packages for
all of them.
The size of the minimal template + packages will be less than the
size of the template which includes the same packages.
When I comment in the Forum or in the mailing lists I speak for myself.
This is why the proposal is unworkable in current form.
But no reason why the installer could not provide something like tasksel
to be run on first boot, after networking has been configured.
The only way to provide an automated install would be to provide flavors
of Qubes - it’s been discussed many times.
When I comment in the Forum or in the mailing lists I speak for myself.
Not even a config file or a salt script?
I mean things like configuring the hostname, standard qube VM names and pciback assignments, pre-configuring packages to install and set up once your networking is ready to go after first boot. Things like that.
Something like plugging in two USB sticks at boot. Booting off the ISO and storing the config on the other one (or on a network drive if you’re doing an enterprise install).
(I’m trying to imagine the easiest and efficient way one would batch install a pre-configured Qubes OS on 100+ machines, ready to give employees)
Cloning can take anywhere from ten to thirty seconds on my system, and a rename basically takes time closer to the end of that range. It is only “seconds” but it feels like an eternity.
I don’t dislike this idea (of minimal template plus enclosed packages) and of course have been playing with minimal templates almost since the day I started using Qubes (going way out over my skis as far as (not) being an advanced user). I have yet to experiment with the even-more-minimal “core” templates someone worked out. I find it verging on crazy that it takes a gigabyte to run a sys-net machine, yet that’s a “minimal” template build of such a thing.
interesting. I never knew that.
obviously both Debian and Fedora. especially when taking into consideration your tidbit about template+packages are smaller in size than a full template.
I’m trying to imagine an organization with 100+ machines that chose Qubes as its OS for all of the employees. Don’t get me wrong, the thought truly fill my heart with joy, but is it a current request from someone or just a cool feature that should get a very low priority for now while the Devs are putting that time on other things?
As my wife say “you can’t argue with feelings”, so I can’t argue with that 
This is my daily driver and I’m more hesitant to play with anything, so I’d love to see an officially-supported minimal VMs for those three that really need to be minimal.
I think that an integrated HCL report as part of the installer as an opt-in option would really give us more information on compatibility. Perhaps it is clear to the devs what should work and what shouldn’t but as a community member it seems to be like it’d be good to get a lot of diverse HCL reports from people who might not stick around long enough to come and contribute manually.
It’s funny that we are talking about a wishlist to the installer and the developers have a problem adding more colors xd It’s looooong wait wishlist
VM colors is an off-topic in this thread. Also, did you read the comments in the corresponding issue?
Labeled this issue “Help Wanted,” because none of the core Qubes OS team are likely to be able to prioritize this anytime soon, abreast critical project priorities.