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.
Wired network works in 4.3, wireless still has issues. UPD: i need to say the current way how it handles Debian package dependencies is fargile AF, better go pure salt declarations.
Also, it might help to have a specification for the intended package set change in the debian template as a comment around the aptitude invocation code.
I realise it’s complicated, because it has both a positive (what to keep) and a negative (what to keep out) part, and both can change unexpectedly between Debian releases… But at least for now we’re on bookworm. And the added clarity might actually help progressing to further releases…
yeah will do. but the rabbit hole is deep. it seemed to work, but turns out there are new issues with mount-dirs script which was changed in 4.3 bookworm template (and those changes were not reflected in parent qubes-core-agent git or at least i could not see it there). to add insult to injury, i spent this morning trying to debug it with sh, just to realize later that now it uses bash-only redirection syntax.
the primary goal of salt migration would be to have proper state transitions via declarative descriptions, functional testing and clean rollback. it would be much easier to maintain and update afterwards.
Frankly, salt seems like an insufficiently principled solution as well, far behind the state of art – both on declarativity and reproducibility fronts.
It would be more upfront work, that’s for certain. But some of that work would be done by people anyway, as they do the full nixos-qubes enablement – so my guess is there’d be a potential for collaboration. Once that’s done, though, I would say Nix as a language is far superior substrate for this kind of affair than salt or similar.
More to the point of liteqube itself – another benefit would be the fact that on NixOS we can trim packages rather easily, by disabling unneeded functionality and therefore trimming the library dependencies – which would be impossible without introducing alternate builds for .deb/.rpm packages.