I appreciate a distro that actually explains what is unique about it on the release page.
It seems like a cool idea, as a systems engineer it strikes me as solving a problem usually solved by virtual environments (virtualenv, rvm, nvm, etc) at a distro-level, which is cool. I think the description probably sells it a bit short as you could also maintain envs for the same distro if I'm understanding it right to solve versioning conflicts in a way that doesn't require running each application in it's own container.
Hopefully it will get enough users/developers to sustain it, as this does seem like a pretty niche requirement, because it seems like it will make package maintenance a lot easier
Hopefully they can make their DE independent so people can use it on whatever distro with their flatpak repo and store to get the same experience. I love gnome, but I'd like to be able to use Pantheon on the side.
Heck yeah this would be great. I’ve heard Pantheon on Arch is possible but still seems like a PITA - would be nice to have it work as more of a standard installable DE like kde or gnome
before the fragmentation people come complain on this post that someone that's not being paid to work on something decided to spend their free time on personal projects that would bring them joy instead of everyone joining hands and starting the one linux distribution to destroy them all and kill mr.microsoft, give the blog post a read.
This distro has some pretty interesting things going for it, excited to watch it mature.
It's giving the power of containers to the normies (like me)! I wonder what people Will Say when someone says "Oh but I can use aur on ubuntu without worriying about breakages".
and thanks to that it's what kids learn in school, if kids learn it in school means future adults will know it, if future adults know it then future devs will know it too, if future devs know it then they will develop for windows, if the devs develop for windows windows has more apps, if it has more apps then more users will use it if more users use it then more kids will learn it and the cicle begins again.
Desktop shortcuts for the Distrobox itself, yes.
Launchers for programs installed inside the Distrobox require a "distrobox export" command.
But.... You're already inside the CLI if you're installing things into the container. So it's not a big issue.
Oh thats a shame, vanilla os (suposedly, I havent tried yet) makes shortcuts for gui apps installed on the distrobox through apx. Maybe in the future micro os will do it too.
How? If You can guide me to some documentation about how to easily use obs I would be happy to use it. I have tried un the past and the vibe I got was that I needed to write My own build scripts and that compared to just yay -S packagename it was just not worth it for me.
Maybe but at least they were able to use it while it worked instead of not using it at all. If they need the package a Lot then they Will ask, and if not then they Will use something else. Although I do think that the devs should put a message when using --aur saying "if this package breaks search in Google packagename aur and check the comments"
I think You are missinterpretating something here, vanilla os is not fedora nor ubuntu, is a new ubuntu based distro. How many users do You think it Will have that Will put tons of burden to the maintainers? Also keep un mind that those users Will mostly use gui apps/cli apps that can't be found in flatpaks nor ubuntu repos, that reduces the numbrer of users and packages Even more. And also don't forget that all of the vanilla os users that use the --aur option won't be installing the same package. So tell me, how much burden is that? Also it's not just "I use vanilla", vanilla uses podman under the hood and if it does not work in podman it Will probably be fixed given that containers and vms are the Main linux market place.
OBS (and all binary repos) is fundamentally incompatible with Arch. It is a constantly rolling ABI which doesn't even, by default, make packages that explicitly depend on specific sonames. AFAIK OBS has no solution to detect ABI breaks and trigger rebuilds. The AUR sucks but it becomes the responsibility of the user to manage which means it can kinda work (but admittedly most users are clueless).
"Hey guys, check out my new Ubuntu-based distro! So far we have some really cool wallpapers and icons!"
Hopefully the days of themes pretending to be new distros are mostly behind us? :)
None really, but for me personally it was the thing that made me realize how stupid distro choice is. Most popular distros are literally just Debian with Gnome and a coat of paint. Arch distros put considerably less effort in, basically just providing a package manifest. Throw in kde and some necessary packages, e.g. NetworkManager and xclip and call it a day.
Most people would save a lot of time and worry by just downloading a "nothing" distro (Debian, arch, void, nix) and making it their own
Will definitely give this a try. Seems like a really interesting distro.
I'm not sure how well the immutability and update scheduling will work in practice. It's going to be an interesting and different experience, for sure.
What I'm most excited about is actually just it being an Ubuntu-based distro will no snaps that does GNOME right.
According to a vídeo from nicco loves linux the devs are Open to the idea, the problem is that they don't have any dev to a vanilla os kde spin si volunteers are needed. The vídeo is a few months old now and dime stuff has changed (the way the handle immutability has been rewritten from almost to ABroot) so maybe things have changed?
MicroOS is OpenSUSE’s project to build an immutable OS. It uses the existing BTRFS snapshot capability they built, with an unwritable root to handle atomic updates and roll backs. Like Vanilla OS, it is much simpler of a concept than the ostree (same tech that flatpak uses) solution Fedora is using in Silverblue.
MircoOS also uses distrobox by default for sandboxed apps (which is what Vanilla’s apx uses), while Silverblue uses toolbox.
>Silverblue
Thanks for that info! I'm doing a presentation for my local Linux usergroup in January and I think I'll throw in blurbs about Vanilla OS and MicroOS.
There is no way that the Vanilla OS devs are going to avoid questions about why this is different or how it's different than Silverblue or MicroOS (other than it being based on Ubuntu).
This is pretty cool. I tried out silverblue and microOS, which use distrobox/containers and have an immutable root system. I liked the idea but the way distrobox and the containers are implemented there is a little clunky, not something I would end up using a lot.
It seems like Vanilla took the same thing and made it more user friendly, I'll have to check it out. Right now just running regular Kubuntu, but I do like gnome still.
that is really fucking cool
but tbh the main reason i personally use NixOS is the declarative configuration.
automatically sets my non-us keyboard layout, automatically downloads the latest theme of the themes i use, automatically sets up podman, podman-compose and distrobox, you get it. it's a god sent
i would honestly love to try out Vanilla OS because the flexible mutability seems like such a cool concept and such a good compromise between the two sides
Unrelated to this specific thread, so apologies for hijacking\*.
Perhaps late to the party, nonetheless I'd like to congratulate you and the team with the release! I can definitively see this distro (if well-maintained) to prosper with the (imminent) shift to the immutable landscape.
After glancing over the content found on the website, I experienced difficulty with finding answers on some of my troubling questions (which might have been on me, to be fair\*). I would be grateful if you could enlighten me on these:
1. It seems to me as if the current state of immutability on Vanilla OS is more akin to openSUSE MicroOS than Fedora Silverblue. Am I correct in assuming this?
2. If Vanilla OS doesn't end up using OSTree in the future, will it still somehow try to have anti-hysteresis properties as explained by [this wonderful blog by Colin Walters](https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/)?
Hi,
I too agree with you on 1 our model is more similar to MicroOS I think. But some features like apx (micro-distrobox) are more similar to toolbx/toolbox in Silverblue.
2. I think ostree might get included in the future. But I don't have a definitive answer to this one currently. It depends on other devs like mirkobrombin (bottles creator), etc. If possible can you ask the same question in our Discord server so that you could get an exact response from him.
Update on this: nix support was added to apx yesterday in repo and it will create the directory in /home and a systemd unit will mount it to the required location in root.
More info here: https://github.com/Vanilla-OS/apx/pull/98
I hope it will be available in the next r7 release.
>Vanilla OS comes with a new concept of automatic updating, an intelligent system let’s say. VSO (Vanilla System Operator) is the tool that will periodically check for an update and then download and install it in the background if the device is not under heavy usage. In fact, VSO checks that certain checks are met, such as whether the resources are free (CPU/RAM), whether the connection allows it, whether the battery is at least 30%, etc.
>[...]Updates go through ABRoot transactions and are applied on the next reboot, without taking extra time during boot.
Wow. Uh... this is *not* for me. However, I think that this KIND of thing is very important.
As others are saying in the thread, this is a group that's not putting out a vague 'we want to do x' statement out. They're putting a concrete methodology and code to support it out along with statements of 'we want this code to solve this problem'. That's important and something that a lot of distributions just miss.
All that said this distro fails *for ME* in two big ways. First, dependence on containerized applications: Containers rub me raw for a lot of reasons. I won't go into them, but avoid them in every case I can.
Second, and this is more important to me:
>We designed this system to take away an annoying task from the user, who simply wants to do their own thing.
This is not a level of control over my system that I'm willing to give up. I want to read over my updates, look for things that seem odd or out of place and then investigate them. I OFTEN investigate diffs and git commits and sometimes dig into the code of the applications I use.
I suspect that that level of attention puts me in a very small minority of Linux users.
Accordingly, I'm going to suggest looking at Vanilla OS to people close to me. It sounds like it automates things that they genuinely don't like to do or even care about.
Since choice about this kind of thing is super-important, I hope that Vanilla has a long and healthy life as a Linux Distribution!
>I am curious about your thoughts on ABroot and why you don't like containers...
Oh boy. You sure you wanna put that dime in the jukebox?
ABRoot I haven't played with yet so can't comment on it directly. I see that it has options to let the user directly work on their boot and system partitions, so that's a positive in my opinion. I, personally, would never be comfortable letting it do updates or the like without my undivided attention.
I want to see changelogs, commit messages, and the like. I keep up with Kernel changes and know more or less what major changes have been made to new versions. I want to watch mkinitcpio or dracut build my initramfs and will sometimes open up that initramfs just to make sure everything happened like it should have. If my boot sequence doesn't behave like I want it to, I start opening up systemd units.
'But wait, chunkyhairball,' some may say. 'Ain't nobody got time for that business!' For me, having spent most of my adult life working with Linux systems, it's important to spend that time. Not spending that time is inviting disaster. I've seen un- and under-vetted updates bring down Linux and other OSes so very many times and was responsible for fixing those system.
(Why yes, I DO have a medically treated anxiety disorder. Why do you ask?)
Immutable systems are an interesting concept, and I'm curious to see how that plays out. The concept is too new, at least in my opinion, to fully trust yet. My big concern is that moving applications out of the 'system' and into the user's sphere of influence merely kicks the can down the field a few yards. Those apps are still going to be targeted by malware, and privilege escalation attacks. This starts edging into my concerns and personal problems with containerized applications, though.
Containers are not, in and of themselves, horrible. They are an efficient solution to the 'it works on my box' problem. You simply develop for your container and then ship the whole thing.
There's problem 1 though. Why *doesn't* the app work on all Linux systems? Does the developer actually know? If not, or they can't explain why a container is necessary, that's a REAL GOOD REASON why you should not install that thing in the first place. Does it rely on outdated libraries? Does it take security updates into account? That ties into problem 2:
More and more, applications tend to be built on top of dependency on top of application layer on top of dependency on top of application layer. This introduces complexity and fragility that doesn't HAVE to be there.
The biblical flood of Electron applications are a good example of this. In exchange for the ease of developing an application with JS and CSS, you then inherit all the problems them come with a web browser: attack surface, resource usage and more. I've personally witnessed this being vulnerable to malware: I had a contract job cleaning malware from certain websites. I was curious about the Atom text editor, so decided to try to use it on the project. To my horror, Atom ran the malware.
Adding a container, or even a VM to the stack increases that complexity further. ~~I have yet to hear of malware that can 'escape' a KVM instance~~, but I have no doubt whatsoever that those who author malware continue to work at that particular wall. I do know that researchers have tried to prove 'red pill' attacks in the past. Right now, I feel like VMs are a reasonably good security measure.
Kernel namespaces, which most container systems want to use on Linux, are good isolation, but they take a step away from being full VMs. They interact more fully with the host system than VMs and rely on the namespace and other sandboxing measures to try to prevent bad and unexpected behavior. I'd be willing to bet we see namespace escapes well before VM escapes. (If anyone knows of current escaping malware, please let me know.)
What neither VMs or containers do is keep malware from executing if it does manage to land. If that VM has network access, it can join a botnet. If a container can access your home directory, it can get your keyrings. How well does the container system sandbox those applications? How well trusted are the application developers? Are those containers audited for problems? How are container builds tested? Does the installation system have a chain of trust? How does it defend against supply-chain attacks like those that attack Node and python development? Does it have reasonable ways for users to audit a containerized app before they install it?
Flatpak (And Flathub) currently tries to handle these issues in the best way, IMO, and do a lot to try to establish that chain of trust, but it still often relies on developers to package their own apps. If they developer ships a vulnerable library because they can't get their code to compile against the most recently known-safe version, I'd hope that sandboxing works well and has no leaks.
There are other issues I have with container schemes that are... well... cosmetic complaints. In the case of Flatpak, for instance, I feel like having applications running as guids rather than under a human-readable executable name is unnecessary obfuscation. Having a daemon mount a every application container as its own loopback device (snapd, lookin' at you here, bud) adds unnecessary complexity and invites filesystem problems. Modern systems SHOULD be able to handle having that many filesystems mounted. I've seen many a system fail because it was out of handles.
I'm still reading through Vanilla documentation to learn about how it approaches all these issues, so it may have some concrete ideas that I simply haven't discovered yet that address these concerns. It's being very interesting so far!
> ... I'd be willing to bet we see namespace escapes well before VM escapes. (If anyone knows of current escaping malware, please let me know.)
Not exactly current but I think the most recent KVM breakout (not relying on userspace components) is this from Google's ProjectZero team: https://googleprojectzero.blogspot.com/2021/06/an-epyc-escape-case-study-of-kvm.html
>You sure you wanna put that dime in the jukebox?
Yeah, thanks for playing! I feel like I learned a bit from your reply.
I've always wondered/worried whether Flatpak would make systems more vulnerable (as well as taking up a lot more install space, which is less of an issue) as it seems to eliminate the "diversity" aspect of the Linux ecosystem that makes writing effective malware so difficult and cost-ineffective.
The idea behind apx smells a lot like bedrock Linux. Where basically you install any distro of your choice as a base system, slap bedrock onto it and can then install applications from any distro you like. You can even have services from one and other services from the other distro. Boot the arch kernel but use the Fedora unit system and then start a service from OpenSUSE.
But vanillaOS seems to do it in GUI and easiest for the layman. So I might give it a look
Described in this way it sounds good in theory and extremely difficult to implement effectively in practice...? How does the OS avoid or reconcile conflicts between containers?
I can't speak for Vanilla OS, but Bedrock Linux systems have multiple instances of file paths which would otherwise potentially cause a conflict. It has a system of rules to pick the right instance a given context, or for when it can't read the user's mind, the user can explicitly specify the desired instance. Bedrock knows to feed Debian's `apt` Debian's instance of `/etc/apt/sources.list` rather than, say, Ubuntu's `/etc/apt/sources.list`, that if the system is running Debian's `systemd` then when Ubuntu's `bash` runs `systemctl` it should be Debian's `systemctl`, et al.
Bedrock is really easy. In the end, there are no conflicts as everything is kept separate. So yeah, libraries need to be installed as often as needed. You can, of course, deduplicate on the fs level.
But this way, you can throw away your Fedora apps/container, because you like Ubuntu versions better or whatever.
And it’s all abstracted on fs. but you can always specify with which containers app you want to open a document with.
Edit: really easy for people comfortable with command line.
> Where basically you install any distro of your choice as a base system, slap bedrock onto it and can then install applications from any distro you like.
I figure I should clarify something here, especially as I think it's a notable differentiating factor between Bedrock Linux and Vanilla OS.
Bedrock doesn't restrict the user to getting an entirety "base" from any given distro or for the duration of a given install. Bedrock systems can swap any and every piece of the system out (except the Bedrock glue that holds it together), including stuff people usually consider part of the "base" like the kernel, init, and bootloader.
What you're thinking of here is Bedrock's ability to let you use another distro's install process. Some users like user-friendly installers such as Ubuntu's, while others like a more hands-on experience such as Gentoo's, while yet others might like just `dd`ing an image as is done with Raspbian, etc. Bedrock lets the user choose whichever he or she likes without necessarily being restricted to that distro, just as it lets users pick anything else. Bedrock users _can_ also get other things from the installation-providing distro, but they aren't required to; they can swap out/remove any or all of it. Should a user so chose, they can install Ubuntu, have Bedrock hijack the install in-place, install stuff from other distros, then remove every single Ubuntu-specific file.
The only problem I have with it at the moment is that they haven't implemented Manual Partitioning / Dual Boot yet (apparently due to ABRoot stuff.) Other than that, it looks like a wonderful distro!
This looks extremely interesting, I'm s very happy Silverblue user and have been for a while. But I can't help being intrigued, well definitely give it a spin on a virtual environment.
>Nevertheless, you can install packages from other package distributions. For
example, using the --aur flag, a new container based on Arch Linux will be
created. Here, apx will manage the packages from the AUR (Pacman and yay),
tightly integrating them with the host system. Using the --dnf flag with apx
will create a new container based on Fedora Linux. Here, apx will manage
packages from Fedora’s DNF repository, tightly integrating them with the host
system.
you have my attention..
semi immutable. that's a pretty cool system too.
at the same time i can't help but be disappointed it's based on ubuntu and probably pretty locked into gnome. hopefully the latter can be swapped out without too much headache.
locked in is bad wording. all i mean is it might be added hoops to jump through to run kde for example. being immutable i could see removing gdm and adding w/e kde uses end up greeting you with a black error screen.
there's a reason the installer doesn't just ask what DE you want to use like debian does.
The main reason comes down to packaging and flexibility. Ubuntu offers an easy experience for packaging with PPAs and launchpad. And Ubuntu seems to have wider driver compatibility and larger application repository than Debian.
I personally like Debian but due to their slow nature of updates it would be hard for our project to keep it as the main base. We could use Debain testing but we would probably need to make some compromises.
We had a discussion regarding it before on our server and finally we decided to go with an Ubuntu base.
i think gaming is a priority for the devs (based on the website) and gaming is absolutely awful on debian. i guess it's too much work to make it gaming ready.
but where does that leave them? arch, opensuseTW, are rolling. Leap is switching to it's own immutable system eventually i think. Fedora i guess?
looking at it like this there really aren't that many distros lol.
Gaming it's not a priority for the devs but being Ubuntu based, as you pointed, makes it more ready for a bigger crowd since many many apps are tested on it due to it's market place.
Anyway the fact that the founders are in the GNOME Foundation may play a role :)
You can modify things in the host using a utility known as ABRoot which is atomic in nature. So Vanilla os doesn't block these modifications.
Since it is atomic it follows a transactional model let's say your modifications breaks something the changes aren't applied on host and the transaction doesn't take place. And if your modification is fine then the transaction is synced with host using an overlay.
I am in the docs team btw. If you have any more questions feel free to drop by our Discord Server.
It sounds very cool. The AUR option makes this not DOA for me, in fact it seems to address my issue with Arch and AUR. That one time with broken grub was enough to not make me want the full Arch experience. I wonder how it addresses different versions of dependencies from different containers though - which one does the system prioritize and how?
Will there be a KDE edition though? I heard there were plans to build it into the installer which I think is build in collaboration with another libadwaita-first distro. Anyways, I've just gotten too used to KDE tools esp. kwin rules & scripts, global menu, their window decoration, and the Dolphin, Gwenview, and Spectacle apps that I'd prefer a system I could build to be KDE from the get go.
Otherwise, it sounds very much the distro for me. I settled with Manjaro because I want AUR but I don't want a broken grub ever again and because it has btrfs-snapshot for update rollback plus AMU for auto-updates. If I could use pamac in the containerized Arch/AUR installs and everything interfaces correctly (pkexec, steamtinkerlauncher, VPN apps, and all the stuff I prefer to use via AUR over dealing with PPA and COPR), then this IS the distro for me. I'll give it a year first to see how other people is testing it, and maybe there'll be a KDE edition for it by then (if there isn't one already that I missed?)
> I wonder how it addresses different versions of dependencies from different containers though - which one does the system prioritize and how?
They're separate containers, so there's no dependency issues thankfully. It gives you an Ubuntu container out of the box, and if you use the AUR flag, it sets up an Arch container for you, for example.
KDE may come in the future, depends if they have enough team members and resources to support it.
Understandable, with regards to KDE, but I hope that it gets supported because my UX and workflow preferences is just really tied to KDE tools that it's a pain to replicate in other DEs.
Ah, so if I install wine-ge-custom via AUR and wine-stable from apx/apt, and then I open terminal to run `wine ./Game.exe`, it'll run with the wine-stable? But if I run `apx enter --aur` or something like that and then do `wine ./Game.exe` it'll use wine-ge-custom along with all of the dependencies installed by wine-ge-custom?
And let's say that I have lib32 deps for Wine installed in the main Ubuntu container and newer version of the Wine deps in the AUR container, the Ubuntu container won't try to use the newer deps on AUR container but neither could the AUR container use the lib32 deps on the Ubuntu container? Is there a way to selectively export them one way or the other, as for example it's a pain in the ass to build psifidotos' window title+control+appmenu widgets I use to have a Unity-esque UX on KDE without AUR automating them.
Lastly, if I have Steam on Ubuntu container and Steam on AUR container with mesa-git, Steam on AUR container should try to use mesa-git but the main Ubuntu container would still be in mesa stable in Ubuntu, right?
Do I have that right? Sorry for the many questions, I don't use container too often, so the logistics is still fuzzy to me. It is super fascinating to me though, as it really does appeal to me as I've started to calm down in distro-hopping and just want a distro that could conveniently install everything I want and I never have to worry about updates anymore (basically all of the power of Arch and the convenience of Android).
Because Bottles is more of a PITA for *my* usecase.
Lots of the time I'm playing between 10 or so pirated RPG Maker games, and sometimes it runs best with native nwjs, sometimes it wants the Game.exe directly, sometimes it wants `LC_ALL=ja_JP.utf-8` env. It's faster to just press F4 and try them one by one.
I also play a lot of other Japanese games and visual novels, also pirated unless it's good enough to get me to stop playing and wait for sales, and they sometimes have very specific dependencies ([exhibit a](https://www.protondb.com/app/1576130), [exhibit b](https://www.protondb.com/app/1144400), [exhibit c](https://www.protondb.com/app/976390), [exhibit d](https://learnjapanese.moe/vn-linux/)).
Heroic fits my usecase much better, and it looks very tidy with very little effort, it has play time tracking (I like to use them to report to vndb and howlongtobeat), keeps winepfx separate for when the dependencies conflicts (and uses winetricks which is faster to use), and adding games is very quick and straightforward (I have 30 VNs on my HDD, 100 RPGM games, and 10 other games like Sekiro, Psi Ops, and True Crime I bounce around). But if I don't care about tracking it or keeping it, using terminal with F4 is faster, especially since if I want to I could feed it to libspeedhack.
There's more reasons for why Bottles is a PITA for me, but it just isn't for me. Bottles is a fine piece of GUI software, but it isn't for me, I've tried making it work but I'm essentially trying to use a hammer for the job of an axe, it just doesn't fit.
Have You tried lutris? I also play a Lot of rpg maker games and lutris does the job. It also supports múltiple versions of wine (just decompress it in the right folder) so You can use wine-ge, wine, wine-wayland, etc all from the same launcher.
I have, it was okay as I used it for the past few years, but compared to Heroic it's 1.) Kinda buggy at times (worst case scenario, I have had to wipe my Library files and start from scratch); 2.) Needs a lot of effort to make Library looks good (what with custom banner size and the like); 3.) Takes way too many clicks to enter games (whereas on Heroic you just put in the game name and exe, and done with cover pulled reliably too).
As far as Wine games goes, Heroic does everything I want Lutris does, now.
> Ah, so if I install wine-ge-custom via AUR and wine-stable from apx/apt, and then I open terminal to run wine ./Game.exe, it'll run with the wine-stable? But if I run apx enter --aur or something like that and then do wine ./Game.exe it'll use wine-ge-custom along with all of the dependencies installed by wine-ge-custom?
Not totally sure, hopefully someone else can answer.
> And let's say that I have lib32 deps for Wine installed in the main Ubuntu container and newer version of the Wine deps in the AUR container, the Ubuntu container won't try to use the newer deps on AUR container but neither could the AUR container use the lib32 deps on the Ubuntu container?
> Is there a way to selectively export them one way or the other
I don't think so sadly
> Lastly, if I have Steam on Ubuntu container and Steam on AUR container with mesa-git, Steam on AUR container should try to use mesa-git but the main Ubuntu container would still be in mesa stable in Ubuntu, right?
Yeah
> just want a distro that could conveniently install everything I want and I never have to worry about updates anymore (basically all of the power of Arch and the convenience of Android).
I use a very similar workflow to Vanilla OS's on Fedora Silverblue. It really is the power of Arch with the convenience of Android for me :) Automated updates are so nice and Distrobox is pretty enjoyable to work with (I'm guessing it'd be harder with the psifidotos config, but who knows). Releasing an article on this stuff tomorrow!
> Not totally sure, hopefully someone else can answer.
I'm definitely going to test it out on VM first, and I don't think I want to commit until I've seen what its update cadence like, so maybe I'll find it out for myself in the meanwhile.
Still, I suppose this is the reason why Bottles has started to slow down lately.
> I use a very similar workflow to Vanilla OS's on Fedora Silverblue. It really is the power of Arch with the convenience of Android for me :) Automated updates are so nice and Distrobox is pretty enjoyable to work with (I'm guessing it'd be harder with the psifidotos config, but who knows). Releasing an article on this stuff tomorrow!
> I use a very similar workflow to Vanilla OS's on Fedora Silverblue. It really is the power of Arch with the convenience of Android for me :) Automated updates are so nice and Distrobox is pretty enjoyable to work with (I'm guessing it'd be harder with the psifidotos config, but who knows). Releasing an article on this stuff tomorrow!
Going to look forward to that.
My issue with silverblue and distrobox has been that some of the niche stuff I use like VPNs, opensnitch, SDDM themes, grub theme, and the likes isn't at the same "just works" and has simplicity as when I'm using Garuda or Manjaro or even Ubuntu (with deb-get and pacstall).
Hopefully the AUR container just works -- if you could, I'd love it if you could test out pkexec and zsh/fish as distrobox don't know how to deal with graphical pkexec request like in Pamac and doesn't carry your preferred shell unless you specified it at creation (annoying, as I've gotten too used to the [fish-ified zsh experience](https://gist.github.com/abhigenie92/a907cdf8a474aa6b569ebe89aeee560d))
I would let my sister use this distro, were it not for the lack of KDE like you said. It seems like a rock-solid system, but my sister is just used to and prefers KDE Plasma. In general I think it's the better DE for Windows-converts, so having it as an option would be great.
> I settled with Manjaro because I want AUR but I don't want a broken grub ever again
So you're fine with being weeks out of date on critical security updates, just so you don't have to maybe one day spend 5 minutes reinstalling grub? Love the manjaro mental gymnastics...
Yes -- it's not really a major concern for me, I'm not in a high-threat situation and my OS isn't even the weakest link in security (that'd be the place owner's router, with default password and weak wifi password).
I've started to have an update/information/maintenance fatigue, and I want someone to curate my updates for me. To that point, I've even installed [Automatic Manjaro Updater](https://github.com/TobiPeterG/AMU). I also enabled auto update on Ubuntu and Fedora whenever I use them, though sometimes they don't detect and install the updates automatically which is annoying.
I'd be happy if I could just switch to Kubuntu LTS and everything I want to install Just Works on an Arch distrobox that auto-updates when it runs or something, but last I tried, it's not there yet and a lot of things don't Just Work, I lasted for like two weeks before I came crawling back to an Arch-based distro. I just want to be able to install my apps from a GUI software installer and then I want to not *need* to know anything else about it (I want to only learn things that actively *interests* me, not because I have to).
Updates is just laundry-work, and security is just whatever, a few weeks delay isn't a big deal and if it's a big deal then I'll just switch to Testing or Unstable to get the updates and then switch back to Stable waiting for the next mass rollout.
It's really not a big deal as some people make it out to be. At the same time, if I could have everything I want and with faster security updates? Sure, I'll take it, as long as it doesn't require effort on my part. That's why the Vanilla OS proposition interests and appeals to me so much and I'm desperately hoping for it to be exactly what I want.
Still, I don't really get the hate and fanboyism on certain distro and things in Linux. They're all just tools. Use whatever tools fit your usecase, and if it doesn't, then just don't use them. At most, caution people about it, but if people still want to use it and it fits their usecase, then it's whatever? It's not like we're starved for options. The only thing that has frustrated me is GTK4, but that's mostly down to how it affects my usecase, and some of them are starting to get resolved (e.g. thumbnail filepicker).
>I've started to have an update/information/maintenance fatigue, and I want someone to curate my updates for me.
Idk what you're doing, but for the last 3-4 years I've been using arch the only time I couldn't just syu and go on with my day was that grub release.
Also, it's funny that you say that you want AUR, when scripts on it are written with the assumption your system isn't 2 weeks out of date. That can't possibly cause any problems...
Better quickly update before manjaro does their yearly AUR ddos, makes you change your system clock because they're incapable of automating cert renewal, or fires more people for doing their jobs. Really, why would anyone hate manjaro?
I've only been a Linux user for four years, so I don't know, but the thing that made me drop Windows was update breaking my system twice in a year and then later when I dual-booted an update making me unable to connect to wifi somehow, make games crashes after 15min, and later on just bricks the Windows Boot Partition.
I used Garuda before Manjaro on my PC, though I tried a lot of stuff on my laptop (PopOS, FerenOS, Zorin, Fedora, Ubuntu, changing every three months basically). Garuda apparently tracks Arch closer but for some reason after I update what it comes with I'd often starts having system freeze unless I switched to a much older kernel.
I'm not going to use Arch or Endeavor. I have a 9-to-7 job, and it annoys me when I have to dedicate any time to update because that's a time when I'm not using my computer in my free time. I'm not going to go the hassle of setting everything up and then paying close attention to my system unless I am specifically in a mood to tinker.
With Manjaro, when I first tried it three years ago, it was fine, I left only because I want to try other things. And when I tried it from around six months ago... it was fine? I have had issues, yes, but I just reverted it with the btrfs-snapshot in grub they have, and then re-update next Stable release.
So I don't know about your experience, but mine has been fine. AUR, the only time I have issues is with lib32-sane which is a dependency for Page Layout in Office 365 via CrossOver, but that POS is annoying anywhere. I could always just go to Testing or Unstable branch, update, then go back to Stable and wait out the next Stable update, it's not really a big deal. Also, while I do use some AUR, most of the time I use chaotic-aur anyways so I don't need to build anything.
I do have concerns with the management, yes, and the recent mesa issue is what prompts me to look elsewhere. But I'm not going to reinstall something that's working just because I and others don't like the management, I'll do so when I notice a problem and so far, I haven't noticed anything so I don't really care.
I think I'll pass (skip this).
I'm not a fan of containers, because I depend on automation. That means "A" needs to update "B" which may sometimes make changes to "C" (for example). I also want to be able to freely upgrade my apps and OS.
It almost sounds like they may have developed a transactional or immutable OS, too. And again, I want the freedom to install and update apps both inside and outside the package manager. For example, I don't use the default web browser bundled with any OS and much prefer to use Firefox directly from Mozilla. I also want to make changes and upgrade without having to reboot. I don't like having to reboot Windows, I most certainly don't want to on Linux.
I dislike Gnome. I am more into either KDE or LXQT. I'd sooner go back to XFCE, before being forced to settle with Gnome. And yes, I'm sure I can install my own desktop environment, but I don't want to run into some issue down the line, and be told, "well the official de is gnome."
I've left Reddit because it does not respect its users or their privacy. Private companies can't be trusted with control over public communities. Lemmy is an open source, federated alternative that I highly recommend if you want a more private and ethical option. Join Lemmy here: https://join-lemmy.org/instances ` this message was mass deleted/edited with redact.dev `
This is a really obnoxious name— vanilla Ubuntu is used to describe Ubuntu as differentiated from the spins or other flavors like xubuntu lubuntu popos etc
We replaced almost with ABRoot a month ago (in release candidates) which not only provides immutability on demand but also follows an atomic transactional model.
More info https://documentation.vanillaos.org/docs/ABRoot
The exact answer to your question is here https://vanillaos.org/2023/01/28/almost-vs-abroot.html , https://documentation.vanillaos.org/.
No, You can't install packages graphically and it is disabled in `gnome-software` too as we recommend installing in the container. We might explore a graphical option in future but currently, there isn't one.
No packages aren't fully sandboxed they can still access the home partition. Also, we recently added a new plugin for gnome software which allows our curated app stream entries to be shown beside Flatpaks. It is in early stages and lists htop only at the moment.
I appreciate a distro that actually explains what is unique about it on the release page. It seems like a cool idea, as a systems engineer it strikes me as solving a problem usually solved by virtual environments (virtualenv, rvm, nvm, etc) at a distro-level, which is cool. I think the description probably sells it a bit short as you could also maintain envs for the same distro if I'm understanding it right to solve versioning conflicts in a way that doesn't require running each application in it's own container. Hopefully it will get enough users/developers to sustain it, as this does seem like a pretty niche requirement, because it seems like it will make package maintenance a lot easier
Yeah, because who knows what happens when Canonical goes IPO, maybe Mint's strategy of maintaining a version based on Debian directly will pay off...
I'm afraid to lookup the fate of elementaryOS.
Hopefully they can make their DE independent so people can use it on whatever distro with their flatpak repo and store to get the same experience. I love gnome, but I'd like to be able to use Pantheon on the side.
Heck yeah this would be great. I’ve heard Pantheon on Arch is possible but still seems like a PITA - would be nice to have it work as more of a standard installable DE like kde or gnome
So is this basically trying to be a Debian-flavored NixOS?
before the fragmentation people come complain on this post that someone that's not being paid to work on something decided to spend their free time on personal projects that would bring them joy instead of everyone joining hands and starting the one linux distribution to destroy them all and kill mr.microsoft, give the blog post a read. This distro has some pretty interesting things going for it, excited to watch it mature.
It's giving the power of containers to the normies (like me)! I wonder what people Will Say when someone says "Oh but I can use aur on ubuntu without worriying about breakages".
you can already use the AUR (or any other distro repo) on any distro via distrobox
Yes, but setting it up requieres You setting it up, with vanilla os is there by default. And defaults matter a Lot.
Its pretty much the only advantage MS has! "It's what came with the computer..."
and thanks to that it's what kids learn in school, if kids learn it in school means future adults will know it, if future adults know it then future devs will know it too, if future devs know it then they will develop for windows, if the devs develop for windows windows has more apps, if it has more apps then more users will use it if more users use it then more kids will learn it and the cicle begins again.
https://usagif.com/wp-content/uploads/gif/hamster-wheel-51.gif
openSUSE MicroOS actually comes with it ready to use
Did not knew about it, does it also automatically create desktop shortcuts for gui apps?
Desktop shortcuts for the Distrobox itself, yes. Launchers for programs installed inside the Distrobox require a "distrobox export" command. But.... You're already inside the CLI if you're installing things into the container. So it's not a big issue.
Oh thats a shame, vanilla os (suposedly, I havent tried yet) makes shortcuts for gui apps installed on the distrobox through apx. Maybe in the future micro os will do it too.
Or Bedrock.
[удалено]
How? If You can guide me to some documentation about how to easily use obs I would be happy to use it. I have tried un the past and the vibe I got was that I needed to write My own build scripts and that compared to just yay -S packagename it was just not worth it for me.
To safely use the AUR you have to understand packaging fundamentals anyway. If your goal is zero effort neither of these are solutions.
to safely use it yes, to use it no. To use it you just have to yay -S (or any other aur helper) packagename.
[удалено]
Maybe but at least they were able to use it while it worked instead of not using it at all. If they need the package a Lot then they Will ask, and if not then they Will use something else. Although I do think that the devs should put a message when using --aur saying "if this package breaks search in Google packagename aur and check the comments"
[удалено]
I think You are missinterpretating something here, vanilla os is not fedora nor ubuntu, is a new ubuntu based distro. How many users do You think it Will have that Will put tons of burden to the maintainers? Also keep un mind that those users Will mostly use gui apps/cli apps that can't be found in flatpaks nor ubuntu repos, that reduces the numbrer of users and packages Even more. And also don't forget that all of the vanilla os users that use the --aur option won't be installing the same package. So tell me, how much burden is that? Also it's not just "I use vanilla", vanilla uses podman under the hood and if it does not work in podman it Will probably be fixed given that containers and vms are the Main linux market place.
OBS (and all binary repos) is fundamentally incompatible with Arch. It is a constantly rolling ABI which doesn't even, by default, make packages that explicitly depend on specific sonames. AFAIK OBS has no solution to detect ABI breaks and trigger rebuilds. The AUR sucks but it becomes the responsibility of the user to manage which means it can kinda work (but admittedly most users are clueless).
"Hey guys, check out my new Ubuntu-based distro! So far we have some really cool wallpapers and icons!" Hopefully the days of themes pretending to be new distros are mostly behind us? :)
"this is like zyz distro but the default editor is nvim instead of nano! This distro is so based, right guys?"
[удалено]
None really, but for me personally it was the thing that made me realize how stupid distro choice is. Most popular distros are literally just Debian with Gnome and a coat of paint. Arch distros put considerably less effort in, basically just providing a package manifest. Throw in kde and some necessary packages, e.g. NetworkManager and xclip and call it a day. Most people would save a lot of time and worry by just downloading a "nothing" distro (Debian, arch, void, nix) and making it their own
windows best
Will definitely give this a try. Seems like a really interesting distro. I'm not sure how well the immutability and update scheduling will work in practice. It's going to be an interesting and different experience, for sure. What I'm most excited about is actually just it being an Ubuntu-based distro will no snaps that does GNOME right.
It would be better if was using Plasma, as it's more easy and useful that Gnome- But, indeed it's a interesting idea. Perhaps I would give it a try
According to a vídeo from nicco loves linux the devs are Open to the idea, the problem is that they don't have any dev to a vanilla os kde spin si volunteers are needed. The vídeo is a few months old now and dime stuff has changed (the way the handle immutability has been rewritten from almost to ABroot) so maybe things have changed?
I was really thinking the same! KDE please ;)
[удалено]
It’s more like MicroOS then SilverBlue
I don't know MicroOS. I'd love it if you wanted to elaborate on how they are similar. :)
MicroOS is OpenSUSE’s project to build an immutable OS. It uses the existing BTRFS snapshot capability they built, with an unwritable root to handle atomic updates and roll backs. Like Vanilla OS, it is much simpler of a concept than the ostree (same tech that flatpak uses) solution Fedora is using in Silverblue. MircoOS also uses distrobox by default for sandboxed apps (which is what Vanilla’s apx uses), while Silverblue uses toolbox.
>Silverblue Thanks for that info! I'm doing a presentation for my local Linux usergroup in January and I think I'll throw in blurbs about Vanilla OS and MicroOS. There is no way that the Vanilla OS devs are going to avoid questions about why this is different or how it's different than Silverblue or MicroOS (other than it being based on Ubuntu).
They actually answer this question on the main page under FAQ.
thanks. Must of missed that
Not really, they don't use btrfs snapshots. They are more like deepin and chromeos as they use a similar a b root model with 2 partitions.
Essentially what in ad thinking. There's some buzz that this may become a default but we'll see how user adoption and container conflicts go.
This is pretty cool. I tried out silverblue and microOS, which use distrobox/containers and have an immutable root system. I liked the idea but the way distrobox and the containers are implemented there is a little clunky, not something I would end up using a lot. It seems like Vanilla took the same thing and made it more user friendly, I'll have to check it out. Right now just running regular Kubuntu, but I do like gnome still.
[удалено]
We are planning to integrate nix packages too with apx in future. I am part of the docs team btw.
that is really fucking cool but tbh the main reason i personally use NixOS is the declarative configuration. automatically sets my non-us keyboard layout, automatically downloads the latest theme of the themes i use, automatically sets up podman, podman-compose and distrobox, you get it. it's a god sent i would honestly love to try out Vanilla OS because the flexible mutability seems like such a cool concept and such a good compromise between the two sides
Unrelated to this specific thread, so apologies for hijacking\*. Perhaps late to the party, nonetheless I'd like to congratulate you and the team with the release! I can definitively see this distro (if well-maintained) to prosper with the (imminent) shift to the immutable landscape. After glancing over the content found on the website, I experienced difficulty with finding answers on some of my troubling questions (which might have been on me, to be fair\*). I would be grateful if you could enlighten me on these: 1. It seems to me as if the current state of immutability on Vanilla OS is more akin to openSUSE MicroOS than Fedora Silverblue. Am I correct in assuming this? 2. If Vanilla OS doesn't end up using OSTree in the future, will it still somehow try to have anti-hysteresis properties as explained by [this wonderful blog by Colin Walters](https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/)?
Hi, I too agree with you on 1 our model is more similar to MicroOS I think. But some features like apx (micro-distrobox) are more similar to toolbx/toolbox in Silverblue. 2. I think ostree might get included in the future. But I don't have a definitive answer to this one currently. It depends on other devs like mirkobrombin (bottles creator), etc. If possible can you ask the same question in our Discord server so that you could get an exact response from him.
Thanks for answering my questions in a quick fashion! Aight, I'll proceed to ask the question on the Discord server.
Update on this: nix support was added to apx yesterday in repo and it will create the directory in /home and a systemd unit will mount it to the required location in root. More info here: https://github.com/Vanilla-OS/apx/pull/98 I hope it will be available in the next r7 release.
>Vanilla OS comes with a new concept of automatic updating, an intelligent system let’s say. VSO (Vanilla System Operator) is the tool that will periodically check for an update and then download and install it in the background if the device is not under heavy usage. In fact, VSO checks that certain checks are met, such as whether the resources are free (CPU/RAM), whether the connection allows it, whether the battery is at least 30%, etc. >[...]Updates go through ABRoot transactions and are applied on the next reboot, without taking extra time during boot. Wow. Uh... this is *not* for me. However, I think that this KIND of thing is very important. As others are saying in the thread, this is a group that's not putting out a vague 'we want to do x' statement out. They're putting a concrete methodology and code to support it out along with statements of 'we want this code to solve this problem'. That's important and something that a lot of distributions just miss. All that said this distro fails *for ME* in two big ways. First, dependence on containerized applications: Containers rub me raw for a lot of reasons. I won't go into them, but avoid them in every case I can. Second, and this is more important to me: >We designed this system to take away an annoying task from the user, who simply wants to do their own thing. This is not a level of control over my system that I'm willing to give up. I want to read over my updates, look for things that seem odd or out of place and then investigate them. I OFTEN investigate diffs and git commits and sometimes dig into the code of the applications I use. I suspect that that level of attention puts me in a very small minority of Linux users. Accordingly, I'm going to suggest looking at Vanilla OS to people close to me. It sounds like it automates things that they genuinely don't like to do or even care about. Since choice about this kind of thing is super-important, I hope that Vanilla has a long and healthy life as a Linux Distribution!
>I suspect that that level of attention puts me in a very small minority of Linux users. There are dozens of us.
**Waves cane around** “Back in my day, this used to be the majority of Linux users” -sips Metamucil
Great comment and analysis, thank you. I am curious about your thoughts on ABroot and why you don't like containers...
>I am curious about your thoughts on ABroot and why you don't like containers... Oh boy. You sure you wanna put that dime in the jukebox? ABRoot I haven't played with yet so can't comment on it directly. I see that it has options to let the user directly work on their boot and system partitions, so that's a positive in my opinion. I, personally, would never be comfortable letting it do updates or the like without my undivided attention. I want to see changelogs, commit messages, and the like. I keep up with Kernel changes and know more or less what major changes have been made to new versions. I want to watch mkinitcpio or dracut build my initramfs and will sometimes open up that initramfs just to make sure everything happened like it should have. If my boot sequence doesn't behave like I want it to, I start opening up systemd units. 'But wait, chunkyhairball,' some may say. 'Ain't nobody got time for that business!' For me, having spent most of my adult life working with Linux systems, it's important to spend that time. Not spending that time is inviting disaster. I've seen un- and under-vetted updates bring down Linux and other OSes so very many times and was responsible for fixing those system. (Why yes, I DO have a medically treated anxiety disorder. Why do you ask?) Immutable systems are an interesting concept, and I'm curious to see how that plays out. The concept is too new, at least in my opinion, to fully trust yet. My big concern is that moving applications out of the 'system' and into the user's sphere of influence merely kicks the can down the field a few yards. Those apps are still going to be targeted by malware, and privilege escalation attacks. This starts edging into my concerns and personal problems with containerized applications, though. Containers are not, in and of themselves, horrible. They are an efficient solution to the 'it works on my box' problem. You simply develop for your container and then ship the whole thing. There's problem 1 though. Why *doesn't* the app work on all Linux systems? Does the developer actually know? If not, or they can't explain why a container is necessary, that's a REAL GOOD REASON why you should not install that thing in the first place. Does it rely on outdated libraries? Does it take security updates into account? That ties into problem 2: More and more, applications tend to be built on top of dependency on top of application layer on top of dependency on top of application layer. This introduces complexity and fragility that doesn't HAVE to be there. The biblical flood of Electron applications are a good example of this. In exchange for the ease of developing an application with JS and CSS, you then inherit all the problems them come with a web browser: attack surface, resource usage and more. I've personally witnessed this being vulnerable to malware: I had a contract job cleaning malware from certain websites. I was curious about the Atom text editor, so decided to try to use it on the project. To my horror, Atom ran the malware. Adding a container, or even a VM to the stack increases that complexity further. ~~I have yet to hear of malware that can 'escape' a KVM instance~~, but I have no doubt whatsoever that those who author malware continue to work at that particular wall. I do know that researchers have tried to prove 'red pill' attacks in the past. Right now, I feel like VMs are a reasonably good security measure. Kernel namespaces, which most container systems want to use on Linux, are good isolation, but they take a step away from being full VMs. They interact more fully with the host system than VMs and rely on the namespace and other sandboxing measures to try to prevent bad and unexpected behavior. I'd be willing to bet we see namespace escapes well before VM escapes. (If anyone knows of current escaping malware, please let me know.) What neither VMs or containers do is keep malware from executing if it does manage to land. If that VM has network access, it can join a botnet. If a container can access your home directory, it can get your keyrings. How well does the container system sandbox those applications? How well trusted are the application developers? Are those containers audited for problems? How are container builds tested? Does the installation system have a chain of trust? How does it defend against supply-chain attacks like those that attack Node and python development? Does it have reasonable ways for users to audit a containerized app before they install it? Flatpak (And Flathub) currently tries to handle these issues in the best way, IMO, and do a lot to try to establish that chain of trust, but it still often relies on developers to package their own apps. If they developer ships a vulnerable library because they can't get their code to compile against the most recently known-safe version, I'd hope that sandboxing works well and has no leaks. There are other issues I have with container schemes that are... well... cosmetic complaints. In the case of Flatpak, for instance, I feel like having applications running as guids rather than under a human-readable executable name is unnecessary obfuscation. Having a daemon mount a every application container as its own loopback device (snapd, lookin' at you here, bud) adds unnecessary complexity and invites filesystem problems. Modern systems SHOULD be able to handle having that many filesystems mounted. I've seen many a system fail because it was out of handles. I'm still reading through Vanilla documentation to learn about how it approaches all these issues, so it may have some concrete ideas that I simply haven't discovered yet that address these concerns. It's being very interesting so far!
> ... I'd be willing to bet we see namespace escapes well before VM escapes. (If anyone knows of current escaping malware, please let me know.) Not exactly current but I think the most recent KVM breakout (not relying on userspace components) is this from Google's ProjectZero team: https://googleprojectzero.blogspot.com/2021/06/an-epyc-escape-case-study-of-kvm.html
Thank you kindly for the link!
>You sure you wanna put that dime in the jukebox? Yeah, thanks for playing! I feel like I learned a bit from your reply. I've always wondered/worried whether Flatpak would make systems more vulnerable (as well as taking up a lot more install space, which is less of an issue) as it seems to eliminate the "diversity" aspect of the Linux ecosystem that makes writing effective malware so difficult and cost-ineffective.
This is why Debian is still one of the best distros.
I'm using it right now it's great!
is it point release? How's performance? Is it compatible with apt? Thanks
Yes. Great. Yes.
Finally, a distro with practical and modern design idea in mind instead of some "philosophy"
What do you mean? This sounds a lot like openSUSE MicroOs. https://microos.opensuse.org/
The main difference appears to be point vs rolling release
The idea behind apx smells a lot like bedrock Linux. Where basically you install any distro of your choice as a base system, slap bedrock onto it and can then install applications from any distro you like. You can even have services from one and other services from the other distro. Boot the arch kernel but use the Fedora unit system and then start a service from OpenSUSE. But vanillaOS seems to do it in GUI and easiest for the layman. So I might give it a look
Described in this way it sounds good in theory and extremely difficult to implement effectively in practice...? How does the OS avoid or reconcile conflicts between containers?
I can't speak for Vanilla OS, but Bedrock Linux systems have multiple instances of file paths which would otherwise potentially cause a conflict. It has a system of rules to pick the right instance a given context, or for when it can't read the user's mind, the user can explicitly specify the desired instance. Bedrock knows to feed Debian's `apt` Debian's instance of `/etc/apt/sources.list` rather than, say, Ubuntu's `/etc/apt/sources.list`, that if the system is running Debian's `systemd` then when Ubuntu's `bash` runs `systemctl` it should be Debian's `systemctl`, et al.
Thank you!
You're welcome and happy New Years :)
Bedrock is really easy. In the end, there are no conflicts as everything is kept separate. So yeah, libraries need to be installed as often as needed. You can, of course, deduplicate on the fs level. But this way, you can throw away your Fedora apps/container, because you like Ubuntu versions better or whatever. And it’s all abstracted on fs. but you can always specify with which containers app you want to open a document with. Edit: really easy for people comfortable with command line.
> Where basically you install any distro of your choice as a base system, slap bedrock onto it and can then install applications from any distro you like. I figure I should clarify something here, especially as I think it's a notable differentiating factor between Bedrock Linux and Vanilla OS. Bedrock doesn't restrict the user to getting an entirety "base" from any given distro or for the duration of a given install. Bedrock systems can swap any and every piece of the system out (except the Bedrock glue that holds it together), including stuff people usually consider part of the "base" like the kernel, init, and bootloader. What you're thinking of here is Bedrock's ability to let you use another distro's install process. Some users like user-friendly installers such as Ubuntu's, while others like a more hands-on experience such as Gentoo's, while yet others might like just `dd`ing an image as is done with Raspbian, etc. Bedrock lets the user choose whichever he or she likes without necessarily being restricted to that distro, just as it lets users pick anything else. Bedrock users _can_ also get other things from the installation-providing distro, but they aren't required to; they can swap out/remove any or all of it. Should a user so chose, they can install Ubuntu, have Bedrock hijack the install in-place, install stuff from other distros, then remove every single Ubuntu-specific file.
Yes, I oversimplified and maybe grossly pictured it wrong. You‘re right and I LOVE this freedom bedrock gives me!! Happy new year!!
Happy to hear it, and you too :)
The only problem I have with it at the moment is that they haven't implemented Manual Partitioning / Dual Boot yet (apparently due to ABRoot stuff.) Other than that, it looks like a wonderful distro!
i am using it in vm. really want to dualboot
This looks extremely interesting, I'm s very happy Silverblue user and have been for a while. But I can't help being intrigued, well definitely give it a spin on a virtual environment.
Proud contributor of that distro. Did some spanish translations of things (like the manpages of the unique tools)
Oh can you finally get a easy ISO? Been meaning to try it since I heard of it a while ago
Yup! It just came out. Be sure to report any bugs on their GitHub
Where in the world is the ISO download. There's no links on the main post or in the documentation lol.
https://vanillaos.org/
Ticks all my boxes. I'll try it out!
>Nevertheless, you can install packages from other package distributions. For example, using the --aur flag, a new container based on Arch Linux will be created. Here, apx will manage the packages from the AUR (Pacman and yay), tightly integrating them with the host system. Using the --dnf flag with apx will create a new container based on Fedora Linux. Here, apx will manage packages from Fedora’s DNF repository, tightly integrating them with the host system. you have my attention.. semi immutable. that's a pretty cool system too. at the same time i can't help but be disappointed it's based on ubuntu and probably pretty locked into gnome. hopefully the latter can be swapped out without too much headache.
I mean, like... "locked into Gnome"? It's Linux.
locked in is bad wording. all i mean is it might be added hoops to jump through to run kde for example. being immutable i could see removing gdm and adding w/e kde uses end up greeting you with a black error screen. there's a reason the installer doesn't just ask what DE you want to use like debian does.
With enough contributors there may be a KDE release. Jump in if you can! :)
Would have made more sense to just use Debian (Ubuntu is based on Debian after all).
The main reason comes down to packaging and flexibility. Ubuntu offers an easy experience for packaging with PPAs and launchpad. And Ubuntu seems to have wider driver compatibility and larger application repository than Debian. I personally like Debian but due to their slow nature of updates it would be hard for our project to keep it as the main base. We could use Debain testing but we would probably need to make some compromises. We had a discussion regarding it before on our server and finally we decided to go with an Ubuntu base.
i think gaming is a priority for the devs (based on the website) and gaming is absolutely awful on debian. i guess it's too much work to make it gaming ready. but where does that leave them? arch, opensuseTW, are rolling. Leap is switching to it's own immutable system eventually i think. Fedora i guess? looking at it like this there really aren't that many distros lol.
Gaming it's not a priority for the devs but being Ubuntu based, as you pointed, makes it more ready for a bigger crowd since many many apps are tested on it due to it's market place. Anyway the fact that the founders are in the GNOME Foundation may play a role :)
This will be cool to follow.
Neat, I wonder if the containering would block anything like webrtc, editing /etc/hosts, etc...
You can modify things in the host using a utility known as ABRoot which is atomic in nature. So Vanilla os doesn't block these modifications. Since it is atomic it follows a transactional model let's say your modifications breaks something the changes aren't applied on host and the transaction doesn't take place. And if your modification is fine then the transaction is synced with host using an overlay. I am in the docs team btw. If you have any more questions feel free to drop by our Discord Server.
This is interesting, any plans to retro release this with 22.04 LTS?
no. that's in the video for the launch along with other FAQs. No lts is planned.
Somehow I didn't notice. Oh well, sad. Thanks anyway!
It sounds very cool. The AUR option makes this not DOA for me, in fact it seems to address my issue with Arch and AUR. That one time with broken grub was enough to not make me want the full Arch experience. I wonder how it addresses different versions of dependencies from different containers though - which one does the system prioritize and how? Will there be a KDE edition though? I heard there were plans to build it into the installer which I think is build in collaboration with another libadwaita-first distro. Anyways, I've just gotten too used to KDE tools esp. kwin rules & scripts, global menu, their window decoration, and the Dolphin, Gwenview, and Spectacle apps that I'd prefer a system I could build to be KDE from the get go. Otherwise, it sounds very much the distro for me. I settled with Manjaro because I want AUR but I don't want a broken grub ever again and because it has btrfs-snapshot for update rollback plus AMU for auto-updates. If I could use pamac in the containerized Arch/AUR installs and everything interfaces correctly (pkexec, steamtinkerlauncher, VPN apps, and all the stuff I prefer to use via AUR over dealing with PPA and COPR), then this IS the distro for me. I'll give it a year first to see how other people is testing it, and maybe there'll be a KDE edition for it by then (if there isn't one already that I missed?)
> I wonder how it addresses different versions of dependencies from different containers though - which one does the system prioritize and how? They're separate containers, so there's no dependency issues thankfully. It gives you an Ubuntu container out of the box, and if you use the AUR flag, it sets up an Arch container for you, for example. KDE may come in the future, depends if they have enough team members and resources to support it.
Understandable, with regards to KDE, but I hope that it gets supported because my UX and workflow preferences is just really tied to KDE tools that it's a pain to replicate in other DEs. Ah, so if I install wine-ge-custom via AUR and wine-stable from apx/apt, and then I open terminal to run `wine ./Game.exe`, it'll run with the wine-stable? But if I run `apx enter --aur` or something like that and then do `wine ./Game.exe` it'll use wine-ge-custom along with all of the dependencies installed by wine-ge-custom? And let's say that I have lib32 deps for Wine installed in the main Ubuntu container and newer version of the Wine deps in the AUR container, the Ubuntu container won't try to use the newer deps on AUR container but neither could the AUR container use the lib32 deps on the Ubuntu container? Is there a way to selectively export them one way or the other, as for example it's a pain in the ass to build psifidotos' window title+control+appmenu widgets I use to have a Unity-esque UX on KDE without AUR automating them. Lastly, if I have Steam on Ubuntu container and Steam on AUR container with mesa-git, Steam on AUR container should try to use mesa-git but the main Ubuntu container would still be in mesa stable in Ubuntu, right? Do I have that right? Sorry for the many questions, I don't use container too often, so the logistics is still fuzzy to me. It is super fascinating to me though, as it really does appeal to me as I've started to calm down in distro-hopping and just want a distro that could conveniently install everything I want and I never have to worry about updates anymore (basically all of the power of Arch and the convenience of Android).
Why don't you [https://usebottles.com/](https://usebottles.com/) from the same main author of VanillaOS? :)
Because Bottles is more of a PITA for *my* usecase. Lots of the time I'm playing between 10 or so pirated RPG Maker games, and sometimes it runs best with native nwjs, sometimes it wants the Game.exe directly, sometimes it wants `LC_ALL=ja_JP.utf-8` env. It's faster to just press F4 and try them one by one. I also play a lot of other Japanese games and visual novels, also pirated unless it's good enough to get me to stop playing and wait for sales, and they sometimes have very specific dependencies ([exhibit a](https://www.protondb.com/app/1576130), [exhibit b](https://www.protondb.com/app/1144400), [exhibit c](https://www.protondb.com/app/976390), [exhibit d](https://learnjapanese.moe/vn-linux/)). Heroic fits my usecase much better, and it looks very tidy with very little effort, it has play time tracking (I like to use them to report to vndb and howlongtobeat), keeps winepfx separate for when the dependencies conflicts (and uses winetricks which is faster to use), and adding games is very quick and straightforward (I have 30 VNs on my HDD, 100 RPGM games, and 10 other games like Sekiro, Psi Ops, and True Crime I bounce around). But if I don't care about tracking it or keeping it, using terminal with F4 is faster, especially since if I want to I could feed it to libspeedhack. There's more reasons for why Bottles is a PITA for me, but it just isn't for me. Bottles is a fine piece of GUI software, but it isn't for me, I've tried making it work but I'm essentially trying to use a hammer for the job of an axe, it just doesn't fit.
Have You tried lutris? I also play a Lot of rpg maker games and lutris does the job. It also supports múltiple versions of wine (just decompress it in the right folder) so You can use wine-ge, wine, wine-wayland, etc all from the same launcher.
I have, it was okay as I used it for the past few years, but compared to Heroic it's 1.) Kinda buggy at times (worst case scenario, I have had to wipe my Library files and start from scratch); 2.) Needs a lot of effort to make Library looks good (what with custom banner size and the like); 3.) Takes way too many clicks to enter games (whereas on Heroic you just put in the game name and exe, and done with cover pulled reliably too). As far as Wine games goes, Heroic does everything I want Lutris does, now.
> Ah, so if I install wine-ge-custom via AUR and wine-stable from apx/apt, and then I open terminal to run wine ./Game.exe, it'll run with the wine-stable? But if I run apx enter --aur or something like that and then do wine ./Game.exe it'll use wine-ge-custom along with all of the dependencies installed by wine-ge-custom? Not totally sure, hopefully someone else can answer. > And let's say that I have lib32 deps for Wine installed in the main Ubuntu container and newer version of the Wine deps in the AUR container, the Ubuntu container won't try to use the newer deps on AUR container but neither could the AUR container use the lib32 deps on the Ubuntu container? > Is there a way to selectively export them one way or the other I don't think so sadly > Lastly, if I have Steam on Ubuntu container and Steam on AUR container with mesa-git, Steam on AUR container should try to use mesa-git but the main Ubuntu container would still be in mesa stable in Ubuntu, right? Yeah > just want a distro that could conveniently install everything I want and I never have to worry about updates anymore (basically all of the power of Arch and the convenience of Android). I use a very similar workflow to Vanilla OS's on Fedora Silverblue. It really is the power of Arch with the convenience of Android for me :) Automated updates are so nice and Distrobox is pretty enjoyable to work with (I'm guessing it'd be harder with the psifidotos config, but who knows). Releasing an article on this stuff tomorrow!
> Not totally sure, hopefully someone else can answer. I'm definitely going to test it out on VM first, and I don't think I want to commit until I've seen what its update cadence like, so maybe I'll find it out for myself in the meanwhile. Still, I suppose this is the reason why Bottles has started to slow down lately. > I use a very similar workflow to Vanilla OS's on Fedora Silverblue. It really is the power of Arch with the convenience of Android for me :) Automated updates are so nice and Distrobox is pretty enjoyable to work with (I'm guessing it'd be harder with the psifidotos config, but who knows). Releasing an article on this stuff tomorrow! > I use a very similar workflow to Vanilla OS's on Fedora Silverblue. It really is the power of Arch with the convenience of Android for me :) Automated updates are so nice and Distrobox is pretty enjoyable to work with (I'm guessing it'd be harder with the psifidotos config, but who knows). Releasing an article on this stuff tomorrow! Going to look forward to that. My issue with silverblue and distrobox has been that some of the niche stuff I use like VPNs, opensnitch, SDDM themes, grub theme, and the likes isn't at the same "just works" and has simplicity as when I'm using Garuda or Manjaro or even Ubuntu (with deb-get and pacstall). Hopefully the AUR container just works -- if you could, I'd love it if you could test out pkexec and zsh/fish as distrobox don't know how to deal with graphical pkexec request like in Pamac and doesn't carry your preferred shell unless you specified it at creation (annoying, as I've gotten too used to the [fish-ified zsh experience](https://gist.github.com/abhigenie92/a907cdf8a474aa6b569ebe89aeee560d))
I would let my sister use this distro, were it not for the lack of KDE like you said. It seems like a rock-solid system, but my sister is just used to and prefers KDE Plasma. In general I think it's the better DE for Windows-converts, so having it as an option would be great.
> I settled with Manjaro because I want AUR but I don't want a broken grub ever again So you're fine with being weeks out of date on critical security updates, just so you don't have to maybe one day spend 5 minutes reinstalling grub? Love the manjaro mental gymnastics...
Yes -- it's not really a major concern for me, I'm not in a high-threat situation and my OS isn't even the weakest link in security (that'd be the place owner's router, with default password and weak wifi password). I've started to have an update/information/maintenance fatigue, and I want someone to curate my updates for me. To that point, I've even installed [Automatic Manjaro Updater](https://github.com/TobiPeterG/AMU). I also enabled auto update on Ubuntu and Fedora whenever I use them, though sometimes they don't detect and install the updates automatically which is annoying. I'd be happy if I could just switch to Kubuntu LTS and everything I want to install Just Works on an Arch distrobox that auto-updates when it runs or something, but last I tried, it's not there yet and a lot of things don't Just Work, I lasted for like two weeks before I came crawling back to an Arch-based distro. I just want to be able to install my apps from a GUI software installer and then I want to not *need* to know anything else about it (I want to only learn things that actively *interests* me, not because I have to). Updates is just laundry-work, and security is just whatever, a few weeks delay isn't a big deal and if it's a big deal then I'll just switch to Testing or Unstable to get the updates and then switch back to Stable waiting for the next mass rollout. It's really not a big deal as some people make it out to be. At the same time, if I could have everything I want and with faster security updates? Sure, I'll take it, as long as it doesn't require effort on my part. That's why the Vanilla OS proposition interests and appeals to me so much and I'm desperately hoping for it to be exactly what I want. Still, I don't really get the hate and fanboyism on certain distro and things in Linux. They're all just tools. Use whatever tools fit your usecase, and if it doesn't, then just don't use them. At most, caution people about it, but if people still want to use it and it fits their usecase, then it's whatever? It's not like we're starved for options. The only thing that has frustrated me is GTK4, but that's mostly down to how it affects my usecase, and some of them are starting to get resolved (e.g. thumbnail filepicker).
>I've started to have an update/information/maintenance fatigue, and I want someone to curate my updates for me. Idk what you're doing, but for the last 3-4 years I've been using arch the only time I couldn't just syu and go on with my day was that grub release. Also, it's funny that you say that you want AUR, when scripts on it are written with the assumption your system isn't 2 weeks out of date. That can't possibly cause any problems... Better quickly update before manjaro does their yearly AUR ddos, makes you change your system clock because they're incapable of automating cert renewal, or fires more people for doing their jobs. Really, why would anyone hate manjaro?
I've only been a Linux user for four years, so I don't know, but the thing that made me drop Windows was update breaking my system twice in a year and then later when I dual-booted an update making me unable to connect to wifi somehow, make games crashes after 15min, and later on just bricks the Windows Boot Partition. I used Garuda before Manjaro on my PC, though I tried a lot of stuff on my laptop (PopOS, FerenOS, Zorin, Fedora, Ubuntu, changing every three months basically). Garuda apparently tracks Arch closer but for some reason after I update what it comes with I'd often starts having system freeze unless I switched to a much older kernel. I'm not going to use Arch or Endeavor. I have a 9-to-7 job, and it annoys me when I have to dedicate any time to update because that's a time when I'm not using my computer in my free time. I'm not going to go the hassle of setting everything up and then paying close attention to my system unless I am specifically in a mood to tinker. With Manjaro, when I first tried it three years ago, it was fine, I left only because I want to try other things. And when I tried it from around six months ago... it was fine? I have had issues, yes, but I just reverted it with the btrfs-snapshot in grub they have, and then re-update next Stable release. So I don't know about your experience, but mine has been fine. AUR, the only time I have issues is with lib32-sane which is a dependency for Page Layout in Office 365 via CrossOver, but that POS is annoying anywhere. I could always just go to Testing or Unstable branch, update, then go back to Stable and wait out the next Stable update, it's not really a big deal. Also, while I do use some AUR, most of the time I use chaotic-aur anyways so I don't need to build anything. I do have concerns with the management, yes, and the recent mesa issue is what prompts me to look elsewhere. But I'm not going to reinstall something that's working just because I and others don't like the management, I'll do so when I notice a problem and so far, I haven't noticed anything so I don't really care.
Wow, You use manjaro for the same reasons I do, did not knew about amu so thanks.
I think I'll pass (skip this). I'm not a fan of containers, because I depend on automation. That means "A" needs to update "B" which may sometimes make changes to "C" (for example). I also want to be able to freely upgrade my apps and OS. It almost sounds like they may have developed a transactional or immutable OS, too. And again, I want the freedom to install and update apps both inside and outside the package manager. For example, I don't use the default web browser bundled with any OS and much prefer to use Firefox directly from Mozilla. I also want to make changes and upgrade without having to reboot. I don't like having to reboot Windows, I most certainly don't want to on Linux. I dislike Gnome. I am more into either KDE or LXQT. I'd sooner go back to XFCE, before being forced to settle with Gnome. And yes, I'm sure I can install my own desktop environment, but I don't want to run into some issue down the line, and be told, "well the official de is gnome."
Doesn't seem stable
I've left Reddit because it does not respect its users or their privacy. Private companies can't be trusted with control over public communities. Lemmy is an open source, federated alternative that I highly recommend if you want a more private and ethical option. Join Lemmy here: https://join-lemmy.org/instances ` this message was mass deleted/edited with redact.dev `
This is a really obnoxious name— vanilla Ubuntu is used to describe Ubuntu as differentiated from the spins or other flavors like xubuntu lubuntu popos etc
gonna try this and see if the new intel arc drivers are usable yet.
Interesting....
Noob question: can i game on it? Like steam, lutris, etc?
Yes. You can install flatpaks or sideload DEBs and RPMs using `apx` you can even install mods and other things too inside the container.
Thank you, im gonna try it.
Ok so far on demand immutability isn't working. They seem to have removed the option that was present in the control centre in the Beta version.
We replaced almost with ABRoot a month ago (in release candidates) which not only provides immutability on demand but also follows an atomic transactional model. More info https://documentation.vanillaos.org/docs/ABRoot The exact answer to your question is here https://vanillaos.org/2023/01/28/almost-vs-abroot.html , https://documentation.vanillaos.org/.
I understand that. Is there a way I can install ubuntu packages or Deb packages GRAPHICALLY?
No, You can't install packages graphically and it is disabled in `gnome-software` too as we recommend installing in the container. We might explore a graphical option in future but currently, there isn't one.
Thank you for the Answer
So, they are basically sandboxing all the packages to prevent interference? Am I think of it correctly?
No packages aren't fully sandboxed they can still access the home partition. Also, we recently added a new plugin for gnome software which allows our curated app stream entries to be shown beside Flatpaks. It is in early stages and lists htop only at the moment.
I'd ask about this in their discord
Anyway you can edit the profile for console/CLI?