The intended way of installing software is either via brew, flat pack or in distrobox. os rpm tree is used to create a layer over the base os, you definitely don't want to keep stacking those layers. Ptyxis is used as it integrates with distroboxes very well. Kinda like Windows Terminal with WSL.
How do you determine who is or is not a bot? Is it that they make unrelated comments of advocacy? That in and of itself should not be the sole determinor. But I see this all the time now, that whomever is commenting on anything with comments enabled, when faced with a comment on an opposing side always accuses someone of being a bot. Where's the proof?
@@PHDWhom wtf bro 💀 use common sense their account is usually created 1 day to 2 months ago with some girl pfp with some random bs that doesn't make sense to the current video
Hey DT, just an FYI as I was doing research on this distro after you showed it. The devs of this distro recommend to NOT use rpm-ostree. But another tool called "brew". Either way, perhaps it was impacting the speed at which things were running when you were attempting to install software. Regardless, I'm really interested in this distro now. Thanks for showing it off!
Hey DT, thanks for the great work! About the distrobox arch installation. I had a similar problem on bluefin. Using one of the other arch images from distrobox it works flawlessly!
Hi Dt! I think you should revisit this "distro" and do a proper review. You are not supposed to use rpm-ostree. Brew is now pre-installed and is the suggested package manager for cli programs. Please read the docs a little bit, because the whole ublue mindset is very different to old school distros.
I was going to say the same thing. When using rpm-ostree it’s going to add a Layer for just that app. This is something you don’t want to do unless the application is not in Flatpak, Brew, or can’t run in a Distobox.
i think i figured out why i dont have issues but you do, i have my own images which include everything i would need and more that i need already included(i dont really care about bloat) the host-spawn commnd might be needed so to some other stuff i that dont get into the container at init time
@@bigpod Well, I don't have issues with any boxes made before a specific day, but then after that any subsequently made Arch based boxes would fail with the exact issue he's having here. Never got around to reporting it because I wasn't sure if it was just an issue with my own setup or not.
8:56 I think this is a distrobox+podman problem (?). I was using distrobox-ephemeral to spin up some temporary binary stuff, and the official Arch docker image had this same problem. As i was using podman (and i believe Aurora should as well because RH did podman iirc), I assume it is an issue on that front. Note that if you had chosen Bazzite-Arch image instead, it should work ootb (granted it has a bunch of gaming related stuff like steam, lutris, etc installed alongside paru as the aur helper). Not sure why this is the case but it is that way on my system (which is just Arch lol. I know using Arch under Arch is a bit weird but i need a quick way to install something without ruining my main system sometimes).
Hey dt. As I understand it, distrotube is meant to install a package from another distribution. It's intended use would require a minimal intallation of the other system, not additional packages that you can use on your main system.
Hey DT, do you plan to take a look at the new COSMIC DE when that comes out? Its tiling features, speed, workspaces, keybind support, and config-file-based configuration basically make into a DE-meets-a-Tiling-WM. Also, now that explicit sync (the largest Nvidia-related issue on Wayland) is fully fixed, do you intend on trying out Wayland?
It is a recommendation simply because upgrades get much longer and in some way more error prone, and why is that because rpm-ostree still has to work with limitations or should i say faults of traditional package managers rpm-ostree just moves the install from you main image to a layer on top of it which lowers chances but it still inherets all stupid faults of traditional package managers
I just started exploring Aurora and I have to say the quality of this distro is exceptional. Everything works right off the shelf and very well integrated. However, running alongside Kubuntu, I notice that Aurora runs a lot slower. Can anyone chime in as to why that is the case? Is there anything I can do to optimize Aurora?
@@bigpod Pretty sure Snaps can't be installed on immutable distros because they need rootFS access and they do whacky stuff like make loop devices for containerisation. I don't know if the latter is an issue on immutable distros though, just something that stops me from trying ngl
OpenSuse's upcoming new distro Aeon (current in RC) does immutable much better than Fedora. Its more like an immutable version of a rolling release and gets automatically updated every nite under the covers.
So does ublue, and i would disagree opensuse does things worse as it relies very much on filesystem to do anything in regards to the immutable system including previous versions of the os and such therefore your os is locked into a single filesystem btrfs. While you in theory could create an image process basex on my read is complicated, on other hand i think silverblue and co but especially ublue do that job much better and images should be every tinkerers dream i honestly could not really tinker with my os without using images
It doesn't really solve the core issue immutability solves with image based distros like Ublue, or even declarative distros like NixOS - configuration drift. Every change you make on MicroOS/Aeon still changes the base system, and you only roll it back using filesystem snapshots. Ublue/Silverblue uses ostree to keep track of changes made to the base image and whenever you update it applies those changes on top of the new image like applying a patch.
Universal Blue also does automatic updates behind the scenes with daily snapshots hosted in Github going back 90 days. Also, the main developer behind Aeon does not care for KDE support.
I don't get who the audience for these types of distros is supposed to be. If you just install regular Fedora and leave the "system" packages alone, install "apps" as flatpaks and maybe use distrobox/brew/nixpkgs for esoteric stuff, then you're going to have the same experience just without the extra bloat. It's not like updates/upgrades regularly break Fedora and even if you get hit by a bug you can still dnf rollback and versionlock. Some kind of large scale deployment where you want the users to be able to freely install software without being able to break things perhaps, but those types of environments usually want way more control than that.
Just because it works for you, doesn't mean this is the experience for everyone else. I've run into endless issues with Fedora updates (even while also primarily using Flatpak). The atomic nature of these are ideal for those of us who want stability. So much so, that the atomic nature is what powers the SteamDeck (granted from an Arch distro). Please don't be narrow-minded and assume it's useless. It simply discredits everything you say from here on.
upgrading between major fedora versions is a minor nightmare every time. it also decouples the system and apps entirely so if you run into package bugs with either of them, they can't bring each other down.
hell, just the other day, i ran into an issue on my thinkpad where it didn't output video after an update. all i had to do was reboot into the previous image using grub and wait until upstream fixed it.
@@bigpod looking at the partitions, there would have to be 2 big equal size partitions right? i have observed this partition structure for vanella os and blend os.
@@the1trancedemon there are multiple approaches to atomicity what you refer to is called ABroot as in you have A and B root filesystems and you swap between them, but there are other approaches for example fedora way which is also used by ublue set of tools uses something called ostree which is a tool most simply described as git for filesystems and to get to a root file system it at boot time does some hard linking between /sysroot which is where ostree repo lives on your system and your root partition this brings you same atomicity as AB root, uses in theory less storage and allows any number of previous versions to be stored on device, i for example store current version and last one and a version from the time of install . its in my opinion a better approach but it isnt as simple
well yes cause its doing some really good stuff like layering on top of RootFS instead of installing into rootFS but being hampered by every fault of traditional package managers
its also important to note rpm-ostree is more a composition tool then actually a package manager like rpm or dnf. its more ment for build the image seperately then pull the image in and replace one that is already there
Software installation is recommended via flatpak, else `ujust` scripts, else homebrew, else in a distrobox container. `rpm-ostree install` is specifically for layering software ontop the base image when no other approach is sufficient.
Man, I must be getting old. Why do all these presenters talk so fast and not take a breath? No one talks this way in real life. It's tiring. I guess I could slow the playback speed, but does anyone know why this is the norm nowadays?
The intended way of installing software is either via brew, flat pack or in distrobox. os rpm tree is used to create a layer over the base os, you definitely don't want to keep stacking those layers.
Ptyxis is used as it integrates with distroboxes very well. Kinda like Windows Terminal with WSL.
thanks for taking a look at this distro :) Might want to remove the bot comments though...
just report em. enough people do that and youtube will take it down.
How do you determine who is or is not a bot? Is it that they make unrelated comments of advocacy? That in and of itself should not be the sole determinor. But I see this all the time now, that whomever is commenting on anything with comments enabled, when faced with a comment on an opposing side always accuses someone of being a bot. Where's the proof?
@@PHDWhom You're literally playing devil's advocate for porn spammers.
oh yeah, these people probably just love spending 18 hours a day leaving like and link farm comments on completely unrelated videos @@PHDWhom
@@PHDWhom wtf bro 💀 use common sense their account is usually created 1 day to 2 months ago with some girl pfp with some random bs that doesn't make sense to the current video
Hey DT, just an FYI as I was doing research on this distro after you showed it. The devs of this distro recommend to NOT use rpm-ostree. But another tool called "brew". Either way, perhaps it was impacting the speed at which things were running when you were attempting to install software. Regardless, I'm really interested in this distro now. Thanks for showing it off!
rpm-ostree is more a composition tool then a package manager you nomally would use on other distros
Man Plasma 6 is getting there. Cant wait for new XFCE update.
Good show DT!
Good review DT, thanks.
Hey DT, thanks for the great work! About the distrobox arch installation. I had a similar problem on bluefin. Using one of the other arch images from distrobox it works flawlessly!
The Aurora-dx version has more stuff preconfigured and preinstalled such as virt manager etc
Hi Dt! I think you should revisit this "distro" and do a proper review. You are not supposed to use rpm-ostree. Brew is now pre-installed and is the suggested package manager for cli programs. Please read the docs a little bit, because the whole ublue mindset is very different to old school distros.
I was going to say the same thing. When using rpm-ostree it’s going to add a Layer for just that app. This is something you don’t want to do unless the application is not in Flatpak, Brew, or can’t run in a Distobox.
You should have installed brew via the ujust --choose. Instead of using rpm-ostree.
They encourage you to use containers.
Distrobox has been bugged out (particularly on creating new Arch boxes) for me for the past week as well. Not sure what's going on with that.
Interesting havent seen any problems myself
i think i figured out why i dont have issues but you do, i have my own images which include everything i would need and more that i need already included(i dont really care about bloat) the host-spawn commnd might be needed so to some other stuff i that dont get into the container at init time
@@bigpod Well, I don't have issues with any boxes made before a specific day, but then after that any subsequently made Arch based boxes would fail with the exact issue he's having here. Never got around to reporting it because I wasn't sure if it was just an issue with my own setup or not.
@@mckendrick7672 it think its something with either arch image or distrobox
It has broken for newer arch images, atm you have to use distrobox git
8:56 I think this is a distrobox+podman problem (?).
I was using distrobox-ephemeral to spin up some temporary binary stuff, and the official Arch docker image had this same problem. As i was using podman (and i believe Aurora should as well because RH did podman iirc), I assume it is an issue on that front.
Note that if you had chosen Bazzite-Arch image instead, it should work ootb (granted it has a bunch of gaming related stuff like steam, lutris, etc installed alongside paru as the aur helper). Not sure why this is the case but it is that way on my system (which is just Arch lol. I know using Arch under Arch is a bit weird but i need a quick way to install something without ruining my main system sometimes).
Hey dt. As I understand it, distrotube is meant to install a package from another distribution. It's intended use would require a minimal intallation of the other system, not additional packages that you can use on your main system.
Hey DT, do you plan to take a look at the new COSMIC DE when that comes out? Its tiling features, speed, workspaces, keybind support, and config-file-based configuration basically make into a DE-meets-a-Tiling-WM.
Also, now that explicit sync (the largest Nvidia-related issue on Wayland) is fully fixed, do you intend on trying out Wayland?
How does Aurora compare to Vanilla OS?
4:20 They asked to not use rpm-ostree, but rather brew
It is a recommendation simply because upgrades get much longer and in some way more error prone, and why is that because rpm-ostree still has to work with limitations or should i say faults of traditional package managers rpm-ostree just moves the install from you main image to a layer on top of it which lowers chances but it still inherets all stupid faults of traditional package managers
Good to know
Great too see you try this not a distribution
I just started exploring Aurora and I have to say the quality of this distro is exceptional. Everything works right off the shelf and very well integrated. However, running alongside Kubuntu, I notice that Aurora runs a lot slower. Can anyone chime in as to why that is the case? Is there anything I can do to optimize Aurora?
can you use snaps on an immutable fedora distro? I'm not a fan of them but I need snap to install a few sdks I use regularly
ooo maybe distrobox will work
seeing as he uses flatpaks in the video, I would say yes... unless I am critically misunderstanding what an immutable distro is
Sure
why couldnt you
@@bigpod Pretty sure Snaps can't be installed on immutable distros because they need rootFS access and they do whacky stuff like make loop devices for containerisation. I don't know if the latter is an issue on immutable distros though, just something that stops me from trying ngl
Might check it out, though I always have issues with anything that is Fedora based. I don't know why?
Ahh the joys of Linux
OpenSuse's upcoming new distro Aeon (current in RC) does immutable much better than Fedora. Its more like an immutable version of a rolling release and gets automatically updated every nite under the covers.
So does ublue, and i would disagree opensuse does things worse as it relies very much on filesystem to do anything in regards to the immutable system including previous versions of the os and such therefore your os is locked into a single filesystem btrfs. While you in theory could create an image process basex on my read is complicated, on other hand i think silverblue and co but especially ublue do that job much better and images should be every tinkerers dream i honestly could not really tinker with my os without using images
It doesn't really solve the core issue immutability solves with image based distros like Ublue, or even declarative distros like NixOS - configuration drift. Every change you make on MicroOS/Aeon still changes the base system, and you only roll it back using filesystem snapshots. Ublue/Silverblue uses ostree to keep track of changes made to the base image and whenever you update it applies those changes on top of the new image like applying a patch.
Universal Blue also does automatic updates behind the scenes with daily snapshots hosted in Github going back 90 days.
Also, the main developer behind Aeon does not care for KDE support.
Fedora's way will win, because it's more popular, there's already ublue, and now even RHEL 9.4 has image mode.
@@sheevys fedoras way is also extremly custumizable you can easily make an perfect image for you specially if you take ublue as base
Arch discrimination!
I don't get who the audience for these types of distros is supposed to be. If you just install regular Fedora and leave the "system" packages alone, install "apps" as flatpaks and maybe use distrobox/brew/nixpkgs for esoteric stuff, then you're going to have the same experience just without the extra bloat. It's not like updates/upgrades regularly break Fedora and even if you get hit by a bug you can still dnf rollback and versionlock.
Some kind of large scale deployment where you want the users to be able to freely install software without being able to break things perhaps, but those types of environments usually want way more control than that.
Just because it works for you, doesn't mean this is the experience for everyone else. I've run into endless issues with Fedora updates (even while also primarily using Flatpak). The atomic nature of these are ideal for those of us who want stability. So much so, that the atomic nature is what powers the SteamDeck (granted from an Arch distro).
Please don't be narrow-minded and assume it's useless. It simply discredits everything you say from here on.
upgrading between major fedora versions is a minor nightmare every time. it also decouples the system and apps entirely so if you run into package bugs with either of them, they can't bring each other down.
hell, just the other day, i ran into an issue on my thinkpad where it didn't output video after an update. all i had to do was reboot into the previous image using grub and wait until upstream fixed it.
@johnbergman955 wouldn't the OP's suggestion cover that though? Untouched vanilla Fedora system + flatpaks + distrobox containers?
why are there bots doing palestine propaganda using hot girls profile pics? lmao
Idk probably supporting the 'current thing'
no, they all have scam links on their site and are on all YT pages
おはようございます
Decided to pass at 6.9 GIGS just for the download.
Hey Dt!
14:06 hmmm immutable distro but not atomic based on the looks of the partitions.
Why woulsnt it be atomic?
Because it is atomic
@@bigpod looking at the partitions, there would have to be 2 big equal size partitions right? i have observed this partition structure for vanella os and blend os.
@@the1trancedemon there are multiple approaches to atomicity what you refer to is called ABroot as in you have A and B root filesystems and you swap between them, but there are other approaches for example fedora way which is also used by ublue set of tools uses something called ostree which is a tool most simply described as git for filesystems and to get to a root file system it at boot time does some hard linking between /sysroot which is where ostree repo lives on your system and your root partition this brings you same atomicity as AB root, uses in theory less storage and allows any number of previous versions to be stored on device, i for example store current version and last one and a version from the time of install .
its in my opinion a better approach but it isnt as simple
@@bigpod wow thanks for letting me know. noted.
🖥 😁 👍 ⚡ 👌🖥
Naah. Wouldn't use it. Immutable distros are not for me
rpm-ostree is really dog slow, even snap is faster :D
Overall, looks like great distro
well yes cause its doing some really good stuff like layering on top of RootFS instead of installing into rootFS but being hampered by every fault of traditional package managers
its also important to note rpm-ostree is more a composition tool then actually a package manager like rpm or dnf. its more ment for build the image seperately then pull the image in and replace one that is already there
Software installation is recommended via flatpak, else `ujust` scripts, else homebrew, else in a distrobox container.
`rpm-ostree install` is specifically for layering software ontop the base image when no other approach is sufficient.
@@taraskywalker453 So it only adds headache, while adding ~nothing to make packaging situation better?
Man, I must be getting old. Why do all these presenters talk so fast and not take a breath? No one talks this way in real life. It's tiring. I guess I could slow the playback speed, but does anyone know why this is the norm nowadays?
Looks like someone ate Windows and digest Linux. I personally don't like this.
That's just KDE ...
Sorry, not sorry. Not watching 18 mins. of content to get the actual point of this video. Make it short and sweet or lose views.
100% agree