https://old.reddit.com/r/linux/comments/91cxbt/kde_is_the_fastest_desktop_in_1804/
Though you might want to look in the comments because some say the measurements were flawed.
3 Likes
What’s next?
Should Whonix for arm64 / Raspberry Pi ( RPi ) be documented, announced as Whonix news, call for testers or something?
1 Like
I’m fairly sure I submitted documentation for building and the general setup to the wiki. iirc to the physical isolation page but I can’t find it. Is there maybe some log with submitted content?
1 Like
1 Like
Are those the real changes or also the submissions? Afaik my changes still had to be approved by one of the wiki mods.
All changes are there. Approved or not. Even non-approved changes stay in the log unless explicitly deleted (didn’t happen).
I see, so I guess I have to add it again. I can’t access Permission error - Whonix due to lacking permissions.
1 Like
Thanks for submitting the documentation!
Build Documentation: Physical Isolation
When using ( ) in titles it makes the resulting link look ugly (part .28RPI3.29).
Should we update Build Documentation: Physical Isolation?
Should we update Download Whonix ™ (FREE) - (https://www.whonix.org/wiki/Template:Supported_Platforms_Table)?
2 Likes
I can test the images from time to time. If it will be added to official downloads list I’d still add the “Advanced” and “Experimental” tag.
Also there would be easier ways for physical isolation on other system than the rpi i.e. by using the raw images and just burning those to disk as already described somewhere in this forum instead of going through a default debian installation + build from source.
I don’t know if it would be feasible to upload compressed raw images? They should work on most systems, however, there could be issues with ethernet or graphics drivers and uefi.
2 Likes
Yes. I saw Netrunner for Odroid C1+ coming with a script to automatically resize the disk image at first boot.
Most likely yes.
We already have code to compress qcow2. https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/prepare_release#L34
Perhaps same/similar code would also work to compress raw images.
Added.
Open to more changes throughout the website.
imho it would also be a good idea to reduce the default image sizes to maybe 8-16 GB or to make dedicated raw images for physical isolation of this size. Otherwise you will always have to burn a 100GB image which takes a while. Also physical isolation is an edge case and I’m not sure if anyone ever reaches the 100GB limit even on a virtual gateway. With a smaller size it can fit on the average USB or SSD, you can always resize the disk image if you need more space. I can try to add a script for such an image to the build steps.
2 Likes
Not for VirtualBox builds please because there it’s quite handy. VMs won’t use that much space but can grow until that amount of space. (Sparse images.)
For --target raw (we already have that), other defaults less than 100 GB are fine. (--target raw isn’t really used by anyone yet afaik.)
For --target root, other defaults less than 100 GB are fine as well.
Was merged.
Do we still require our grml-debootstrap fork?
1 Like
I’d like to get rid of our grml-debootstrap fork (or at very least close the delta with upstream) since they recently merged to enhancements.
https://github.com/Whonix/Whonix/pull/424
How is this different from zerofree?
https://github.com/Whonix/Whonix/blob/master/build-steps.d/2350_zerofree-raw
Do we need both?
Can or should both steps be merged?
Can 2550_shrink_raw use the same method to mount the raw image like 2350_zerofree-raw?
Is truncate --size=3500M "$binary_image_raw" required or does --vmsize 4G do the same? (Perhaps even vmsize 3500M already works?)
Could you please move the raw image compression to prepare_release? Reason:
Those who create the raw image for themselves only, don’t require compression?
Those who wish to redistribute images should prepare_release.
Could you make the raw compression code please similar to https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/prepare_release#L70 so it will be deterministic?
Zerofree overwrites free parts with zeros for better compression later on.
The 2550_shrink_raw script, however, shrinks the whole disk including the partition.
They could maybe be merged but then you have to create a raw backup image. The 2550_shrink_raw script currently does that though it is not strictly required. After merge you need to shrink and truncate the one of the images while converting the other image to qcow2 and vdi. Otherwise you would get a default disk size of ~ 4GB for the gateway VM.
2550_shrink_raw does not mount the disk.
If you would do a completely separate build of the images for physical isolation then this would certainly be an alternative. Result should be the same. I’m going to give it a try. With the 2550_shrink_raw script + the --phys switch you could build the images for physical isolation + the VM images in one step.
Yes.
Yes.
1 Like
Another non-perfection not easy to perfect.
non-qubes-whonix-(gateway|workstation)-(cli|kde|xfce) is neither by name a VM specific or VM unspecific package. Due to majority Whonix use case it defaults to VM specific.
Not easy to perfect without a lot code duplication / more package maintenance.
For now non-qubes-vm-enhancements-cli gets installed by default even for physically isolated (RPi) builds since it’s a dependency of non-qubes-whonix-gateway-cli.
Maybe non-qubes-vm-enhancements-cli should become a weak recommended package? Similar to how build-steps.d/1700_install-packages handles virtualbox-guest-x11 / spice-vdagent? To keep it installed for users who already have it whonix-legacy/debian/whonix-legacy.preinst could use
apt-mark auto non-qubes-vm-enhancements-cli || trueThank you for still having “dual build” (or how would we coin it) i.e. KVM and VirtualBox images at the same time in mind. This was always hacky having spice-vdaagent in VirtualBox. The above described weak recommended package is hacky.
In future, KVM builds will be created, signed an uploaded by HulaHoop. No more dual builds by me. (Due to increases build workload - Qubes-Whonix, Whonix CLI, Whonix XFCE, hardened debian, custom workstation, what not.) Therefore we might no longer need the dual build support since that wasn’t a clean way to start with. (Otherwise using dual builds these raw images would have both, VirtualBox guest addition as well as spice-vdagent, even though neither is needed there - could cause issues in some point in future.)
Would you like to build, sign and upload these raw images?
1 Like