I made a test with apt-pinning and it just installed only the raspi3-firmware package from buster and the rest from stretch. Going to do some more tests, though. We could maybe also just enable the apt-pinning for the rpi-gateway so it won’t get used for the other builds.
How would that technically work? Shipping file /etc/apt/sources.list.d/rpi.list as well as /etc/apt/preferences.d/ in some package?
deb http://http.debian.net/debian stretch-backports main contrib non-free
deb tor+http://vwakviie2ienjx6t.onion/debian stretch-backports main contrib non-free
(Plus comments.)
And then include instructions to remove that file before release upgrade of Whonix when upgrading to Debian 10 / buster in Whonix release upgrade instructions?
imo, the reason for this was that each package got upgraded. Not just the desired one.
Disadvantages for building from source are: currently does not work due to being an architecture specific package, while the rest of the packages is not. Lots of lintian errors which I think are also due to being architecture specific.
Currently it is implemented via copying the build_sources_testing.list and preferences file to the build folder during the create-local-temp-apt-repo step. They can also be removed later on.
The firmware package currently depends only on dosfstools, though no specific version. Therefore, currently only raspi3-firmware is installed from buster and nothing else. Since the sources.list in the final version also does not contain anything from buster I would not expect any breakage from updates. The package should be more or less fixed at that version until Whonix gets updated to buster. To admit, the last part is more or less theory.
apt-pinning done properly is safe enough. I’ve been running my host with it enabled before upgrading to Stretch without any problems and never had to remove packages before the upgrade. Everything updated seamlessly enough.
It would benefit it us in other cases besides RPi builds too.
The most important thing is to find and apply accurate and updated documentation about pinning priority so things don’t unexpectedly start pulling in more deps and wreaking havoc. I think the important thing is to advise users to keep their hands off and not add more programs if they don’t know what they are doing and not doing so voids our “support”.
That was quick
Currently the network and date still has to be set manually. You likely also need to use a serial console. At least I could not yet get it working with HDMI. Either the reason is my hardware or something else during early boot like firmware or kernel. I’m going to make a test with a newer kernel and see if it helps. I’ll maybe also remove the wifi packages and make them Recommends instead of Depends. I think also a network config package specific to the cli versions would be required which sets eth0 to dhcp and the MAC to e.g. the one used for the gateway on Virtualbox.
Do you think you could add, and maintain --whonix-workstation-cli? The command line switch is already implemented but the meta package non-qubes-whonix-workstation-cli does not exist yet.
Yeah, I already saw them when my old build commands broke^^
The build script, however, reminded me of the new flavors
I’d carefully say yes. The question is what the usecase would be, how this should look like and which applications should be in there. If we would remove everything gui specific it would be mostly Debian + a bit of Whonix specific network config/hardening
Due to KDE resource hunger and upcoming spectre/meltdown defenses security penalty, I am also considering to developing/introducing XFCE flavors.
I’d carefully say yes.
Yay!
The question is what the usecase would be,
I am not sure. (What an answer.) It’s an experiment. A shoot into the blue. Just like there was no way to know there would be interest in Whonix generally.
Some people recently claimed in some benchmarking thread on the linux reddit that KDE now consumes less resources. Afaik even less than XFCE. Same happened back then on github qubes-issues when qubes introduced XFCE. So it would be maybe a good idea to do some benchmarking first, in particular for stuff from buster which is not that far away and would be the likeliest target for a new desktop environment.
Some people recently claimed in some benchmarking thread on the linux reddit that KDE now consumes less resources. Afaik even less than XFCE. Same happened back then on github qubes-issues when qubes introduced XFCE. So it would be maybe a good idea to do some benchmarking first, in particular for stuff from buster which is not that far away and would be the likeliest target for a new desktop environment.
I haven’t found any mentions of this. Please provide.
What I did read though was that XFCE works better in low RAM
environments. KDE might be even faster than that but requires more RAM
for that. Since RAM is limited in Whonix, this would still point at
XFCE. Also KDE might have better rendering speed on real hardware, but
that again wouldn’t effect Whonix in VMs much.
It was horrible to change from Whonix-Gateway from 512 MB RAM → 768 MB
RAM; and Whonix-Workstation from 768 MB RAM to 1024 MB RAM.
