Nice! Im very happy about the debian base!
Great news. Should there be someday a community version with KDE, I will definitely give it a try. Anyway, I wish them success,
Some notes from my experience of trying to test this:
- There is no live-cd functionality, just the installer, so don’t expect to try before you install.
- The installer will tell you that it needs at least 28.1Gb of space. I tried installing to a 32Gb (virtual) drive which allowed the installer to proceed, but then the installation failed with a “No space left on device” error.
- After increasing the virtual drive to 50Gb the installer then failed with an error that it failed to run
grub-install
I didn’t get any further than this. I was attempting to install in a VirtualBox VM.
Regarding the failed install error, you need to make sure that VirtualBox is using UEFI - Legacy Boot isn’t currently supported at the moment.
Had the same issue while using Boxes, switching it to UEFI allowed the install to complete successfully!
Thanks, it gets a bit further, but this time fails with:
grub-install: warning: Cannot set EFI variable Boot0003. grub-install: warning: efivarfs_set_variable: writing to fd 6 failed: Read-only file system. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system. grub-install: error: failed to register the EFI boot entry: Read-only file system. panic: Failed to run grub-install: exit status 1Interesting, I’m not too sure what could be causing that, but if I had to take a guess VirtualBox’s UEFI implementation doesn’t allow for writes from the VM, at least by default. It’s been a long time since I’ve used VirtualBox (since before UEFI was even really a thing), I don’t suppose there’s any sort of setting that might resemble making it writable?
My version of VirtualBox is a few years old so I wouldn’t be surprised if it was lacking some features.
If you’re using UEFI in VB, definitely update to the latest version. UEFI support in older VB was pretty bad. Works a lot better now, though I haven’t had time to test this new version of Vanilla OS, so YMMV.
Fríggin’ finally. This distro is the one to watch, because unlike Silverblue or any other immutable OS, Vanilla doesn’t build it’s system image using some esoteric homebrewed standards. It uses OCI images to boot an immutable system.
Add
distroboxinto the mix and suddenly you’ve separated the system from the user environment. That way user applications and system applications never need to touch, like at all.Additionally if you can get one OCI image running on a bare metal system like a laptop or workstation, you could probably do it with others as well, meaning that as long as the system itself contained the tooling to rebase images, you could “distrohop” without having to delete any partitions or reinstall in any way.
You might need a process for that specifically, but it it possible - and being able to hotswap Linux distros, whereby going back is a reboot and selecting the previous image? Yes please.
There are several more immutable systems, like the afformentioned Silverblue (rpm-ostree), MicroOS (transactional-update) and NixOS (the programming language and environment that can spit out a system known as “nix”… which is what I’m using now). But it’s all very developer-centric - even if that is not the intention.
Vanilla is a desktop-oriented distribution, pure and true. The developers and community want an easy, safe experience for all which is what an immutable system can help with and will open a massive world to newcomers who don’t care what a distribution is, because they can use any distribution they want - from a single command… but also, in the future, a GUI!
So massive, massive shout out to the Vanilla devs and community. When it’s released as beta stable I might consider returning, but… nix… well… the power is just immense. Mmmmm. MMMMM!
Isn’t Fedora Silverblue builds moving to OCI-based as well?
Yup, we’ve even been able to engage (to some extent) with it for the last couple of months.
It does require some know-how to set up, at least if you’re unaware of uBlue; a community project that is set on offering said OCI images of Fedora Silverblue (batteries included) with different desktop environments (even those that aren’t offered by Fedora (yet)). Bazzite, that has received some significant traction and exposure since it’s very recent 1.0 image, is just one of the provided OCI images.
They even offer a very easy way for everyone to engage in building their own custom OCI image. I got mine spin up within two hours or so without knowing how git or containerfiles worked beforehand, it’s that simple.
Hey, I’ve seen the “batteries included” thing several times related to ublue, but I don’t understand what it means here. Could you explain?
I know what the idiom generally means - everything you need to get started - and even the origin of the expression. I just don’t know what the metaphorical “batteries” are here.
Due to legal reasons, Fedora is not able to distribute their distro with everything baked in to ensure (close to) maximum functionality out of the box. Notoriously, codecs required for (some of the) hardware acceleration and enabling the use of some multimedia file types are not delivered out of the box. Therefore, users are required to set those up themselves. Thankfully, RPM Fusion steps in to the rescue and makes it a lot easier for the end user to acquire these nonetheless.
But…, what if retroactively Fedora is forced to remove even more stuff and what if the solution is not directly available on RPM Fusion and thus requires (advanced) manual intervention in order to resolve the problem for the end user? Which actually happened just a few months ago with the mesa drivers*. Or what if a new Nvidia update causes troubles and you can’t boot into your system? Which actually happens once every often if you don’t pay attention and/or are unlucky. These are real problems that require real solutions; solutions which Fedora can’t offer in the most elegant way in fear of the court (rightfully so).
This is where the “batteries included”" expression comes in. The aforementioned two problems were nonexistent on images provided by uBlue. Because problematic images are hold back by default automatically, which cautions them to resolve it ASAP and within a day (so far) the workaround gets built-in to the image and the end-user just gets the solution without ever noticing that something was wrong in the first place. Why? Because the end user’s system never got the update without the workaround in the first place. An interaction unique as such within the Linux space is simply unheard of. I’m only aware of Vanillas OS that might be able to pull off something similar in the near future. Which is why I’m also very excited to see how it develops. Furthermore, as the end user you never had to go to the RPM fusion page in the first place to get/set up the earlier mentioned codecs as they were actually built-in to the image by default. That, is also part of the “batteries included” expression.
If you’re interested, please consider checking out their documentation. Furthermore, please feel to inquire, if you so desire 😉 !
@s20 @throwawayish whats the difference between idiom and boilerplate code
-– pardon my ignorance , haven’t read the article yetIn this case, I’m using idiom in its “I was a Creative Writing Major at College” sense; that is:
A speech form or an expression of a given language that is peculiar to itself grammatically or cannot be understood from the individual meanings of its elements, as in “keep tabs on”.
*credit to Wordnik.com
So my use of the word here just means “expression” or “figure of speech,” which is probably what I should have said in the first place; sorry for the confusion.
Edit: a grammatical correction no one but me would probably notice or care about.
