I tried to install it, ran into a few issues and gave up after a few hours because I didn’t see any benefit to battery life.
Little performance benefit: There is faster startup of core Qubes, presumably due to not starting X, but battery life seems the same, and I believe disposables take the same amount of time to start.
Less secure: It uses a bunch of buggy bash scripts to set it up and has received much less scrutiny than Qubes itself.
Goes too far: Small things like attempting (and failing) to resize the new core VMs for no reason. Switching to updates via TOR by default. To reduce maintenance, it should do as little as possible to achieve the desired goals.
I agree that we shouldn’t run X servers in service Qubes, but the workaround here of having a Xorg Qube seems like a security risk. Multiple VMs connect to the same Xorg Qube, so an exploit in one Qube now requires a vulnerability in X (very common) instead of a much rarer hypervisor vulnerability. Unless I misunderstood how this works?
If you feel parts of Liteqube really are an improvement, I’d encourage you to try to distill them down to simple components and submit a PR to Qubes. That way it would be useful to a much wider audience and you’d benefit from proper maintenance and auditing.
But I appreciate you stepping up and taking over this project. And you are no doubt more familiar with the internals than me, so perhaps I’m off the mark with some of the above comments, but in any case I think it would be much better (and safer for security) to try to merge the best parts.
The memory footprint difference is significant, and there are fewer moving parts (and I am going to reduce that further)
No it is not. Indeed scripts are buggy, but it is just the installation phase (and the point here is to fix it). If you get it working, there is no reason to call it “less secure”. It is more secure. The rpc part is VERY minimalistic and hardly poses any significant security risk.
core-xorg is unprivileged, and is not used at all during normal operation, it is needed for occasional administration tasks. I am thinking about getting rid of x11 libs on headless qubes completely, implementing some kind of remore shell instead, and making a separate template for tasks where x11 clients are needed.
The whole idea - should live on… and prosper. I’m suprepresly there os so little involvement, to me this seems to be MUST. I never saw point running sys-net, sys-firewall… or sys-usb on full blown fedora template.
I haven’t really spent much time on it, but yeah. Wasn’t able to get it all up and running at once. I was the resizing issue. Did we manage to fix and commit that?
I agree. Why have Keepass on your sys-net qube? Or OpenOffice? (But note I found a pitfall which I’ll discuss below).
There are “minimal” templates that can be used for making the sys-* qubes from. I don’t know much about liteqube but I imagine it’s even more minimal than the -minimal templates.
Be aware that minimal templates do not contain the software needed to create a functioning sys-net, sys-firewall, sys-usb, etc but there are docs that list software you will need to install on (what I hope is) a clone of debian-12-minimal or fedora-versionNumberOfTheWeek-minimal.
Pitfall that I mentioned earlier: You may want to insider installing a browser on sys-net, even though you shouldn’t need one. I found out that you DO need one when I attempted to use a hotel’s “free” wifi; unfortunately a lot of hotels insist on making you go through some stupid marketing-puke’s idea of a webpage to get to the internet and that won’t work without a browser. And of course I couldn’t install the browser without first getting to the internet. I got around this by simply using debian-12-xfce as the template for sys-net while I was at the hotel. I never did install the browser on sys-net’s template (I really don’t want a browser unless I absolutely have to have one); but I now know what to do when I need one.
In this case, you do. You can’t establish the wifi connection without the browser present to enter the wifi password; the hotel won’t connect you until you click through their webpage.
Having the browser on some other qube connected to sys.net doesn’t work. I know this from experience.
However, once you jump through the hotel hoops, your normal browser qube will work.
I’ll most defiantly give a try. I would of probably been able to fix it myself - but sometimes we choose the easy path - the full-blown bloated template which is unnecessarily at all due lack of time…
liteqube was actually very first thing, that attracted my attention once i got into qube os, this was while back before it got forked it.
I would happy contribute financially, if needed - i seen there was similar offer from someone else on some other thread.
It would be extra useful addition to qube utilities if this gets properly maintained and we have some contributors joined.