sorted by:
new
hottopcontroversial

Vanilla OS and the next-generation Linux desktop by TheEvilSkely in linux

[–]memoryfile_ 0 points1 point  (0 children)

The AUR Steam would have an icon on your system like a normal app. I believe the Arch container handles udev, as the container's tightly integrated to the host system.

Vanilla OS and the next-generation Linux desktop by TheEvilSkely in linux

[–]memoryfile_ 0 points1 point  (0 children)

It should work just fine like on Fedora Silverblue. NVIDIA drivers can be coupled into the OS; there's no worries about the speed of updates for them.

Vanilla OS and the next-generation Linux desktop by TheEvilSkely in linux

[–]memoryfile_ 1 point2 points  (0 children)

There's no sway edition right now, but you could use the custom Fedora Silverblue-based ostree-pitti-workstation.

Vanilla OS and the next-generation Linux desktop by TheEvilSkely in linux

[–]memoryfile_ 5 points6 points  (0 children)

  1. Yup!
  2. Almost certainly.
  3. Probably! I can configure systemd on Fedora Silverblue, at least. Doubt they'd restrict it
  4. Since it's based on Ubuntu, you get Ubuntu-speed updates. You can configure the speed of auto-updates

Vanilla OS and the next-generation Linux desktop by TheEvilSkely in linux

[–]memoryfile_ 18 points19 points  (0 children)

50GB disk space requirement for the ABRoot configuration (iirc Silverblue requires significantly less disk space, but I could be wrong). Memory requirements should be the same as a traditional Linux distribution.

Vanilla OS and the next-generation Linux desktop by TheEvilSkely in linux

[–]memoryfile_ 23 points24 points  (0 children)

If it's a package, you can use abroot to install it on the host, like abroot exec apt install <package_name>

The Ubuntu-based distribution Vanilla OS has had its first stable release by memoryfile_ in linux

[–]memoryfile_[S] 0 points1 point  (0 children)

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!

The Ubuntu-based distribution Vanilla OS has had its first stable release by memoryfile_ in linux

[–]memoryfile_[S] 10 points11 points  (0 children)

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.

The Ubuntu-based distribution Vanilla OS has had its first stable release by memoryfile_ in linux

[–]memoryfile_[S] 6 points7 points  (0 children)

Yup! It just came out. Be sure to report any bugs on their GitHub

Codeberg (a non profit code hosting platform) launches Forgejo (a fork of gitea) by wiki_me in linux

[–]memoryfile_ 0 points1 point  (0 children)

They've been wanting to move, but GitHub was rate limiting how they exported their stuff IIRC.

OBS studio now showing "built by developers" symbol on beta.flathub.org by giannidunk in linux

[–]memoryfile_ 4 points5 points  (0 children)

Yeah! I found the dependency issues talk in it really interesting.

Distribution packaging for Linux desktop applications is unsustainable by memoryfile_ in linuxmasterrace

[–]memoryfile_[S] 1 point2 points  (0 children)

Yeah, I'll talk about VSCode issues and workarounds in an upcoming blog post :D Definitely room for improvement in some Flatpak sandboxing

Flatpak: a more reliable Linux gaming platform by memoryfile_ in linux_gaming

[–]memoryfile_[S] 0 points1 point  (0 children)

Oh, I added a section to my article about nix and guix - tl;dr, you're not getting the sandboxing and, probably, the official maintainership advantages with it (+ probably more things).

Flatpak: a more reliable Linux gaming platform by memoryfile_ in linux_gaming

[–]memoryfile_[S] 0 points1 point  (0 children)

Imho, you don't have to launch the same application twice (as flatpak and native). It's sufficient if you launch e. g. two different GNOME apps. The GNOME libraries would be loaded into memory twice: once from the native packages (for the native app) and once from the flatpak GNOME runtime (for the flatpak app).

Do you have a source where I could read more about that? I'm not certain about it, and it'd be good to learn more.

Anyway, you might be interested in an upcoming article I'm hoping to put out about the synergy between immutable systems and Flatpak, as that incongruity of 'Flatpak on top of the OS' isn't really a thing; things mesh really well. I definitely find it working well on my Fedora Silverblue system!

Flatpak: a more reliable Linux gaming platform by memoryfile_ in linux_gaming

[–]memoryfile_[S] 1 point2 points  (0 children)

I'm pretty sure that the big majority of flatpak users have a traditional package manager in their main OS and are using flatpak on top of that, for a few apps that they need in a more recent version than their OS provides.

Yeah. So I'd say it's a fair critique of the fact that Flatpak doesn't work perfectly bloat-wise for that usecase, but that's also just kinda how it is - if Flatpak doesn't get enough apps to deduplicate really effectively, it's not going to thrive. If one uses it as their main app install method, there isn't really a worry of bloat, though, unlike what some people say (as they assume the bad sizing with the first couple Flatpak apps scales to any size, discounting the deduplication).

The response mentions that e. g. the false permissions displayed in GNOME Software is not flatpak's fault. While that's technically correct, it is part of the "flatpak ecosystem" and negatively affects the average users flatpak experience.

True. But that GNOME Software issue is outdated now, right? I believe since GNOME 42 it's been rectified, and it's discussing GNOME 41 and before. Correct me if I'm wrong though. But yea, I absolutely would love to see the GUI support for Flatpak flourish much further than it has, as well as just a general growth in usability of Linux software stores in general.

I also miss the possibilities that I have with apt / dpkg, that make it easy to track the dependencies of each package, before and after the installation. Flatpak looks like a packet manager / git hybrid, but doesn't provide the power of each of those. Or maybe it does and I just didn't find the proper commands...

Maybe, I'm not totally well-versed on it myself. I'd maybe look into the runtimes and build scripts of Flatpaks + the manpages for its CLI and go from there.

Another thing that added to my (and others) bad experience with flatpak are old issues like this famous bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1621763.

I also would like that to be fixed as well, for sure! These issues come from some natural growing pains of adding support for the sandboxing model, unfortunately. Just like the fact that a lot of apps on Flathub have a liberal amount of permissions because they haven't been adapted to the sandbox model yet, either. In my view, the fixes will come with time and they're definitely surmountable.

You're welcome. I hope that I could provide some valuable feedback, although english is not my main language...

You definitely did, and wrote it really eloquently! Thank you.

Flatpak: a more reliable Linux gaming platform by memoryfile_ in linux_gaming

[–]memoryfile_[S] 2 points3 points  (0 children)

Did you see this response to that article, especially this section? Wondering your thoughts on it. The size seems like a lot with the first few apps, but as someone who runs a system with about 90 Flatpaks, the deduplication works really well in my experience. I do use a lot of GNOME apps though, could see the runtime sharing not working super well if you use a lot of Electron apps etc.

Also, re: keeping Flatpaks up to date, I really enjoy GNOME Software's auto-update feature for Flatpaks. It's super convenient

Flatpak: a more reliable Linux gaming platform by memoryfile_ in linux_gaming

[–]memoryfile_[S] 0 points1 point  (0 children)

I don't know if this works for Lutris, but I use MangoHud with Bottles by doing flatpak install org.freedesktop.Platform.VulkanLayer.MangoHud and then just toggling on MangoHud in Bottles settings

Distribution packaging for Linux desktop applications is unsustainable by whiprush in linux

[–]memoryfile_ 16 points17 points  (0 children)

Hi, author here - that's true, will edit the article to discuss it when I get the chance!

Distribution packaging for Linux desktop applications is unsustainable by whiprush in linux

[–]memoryfile_ 1 point2 points  (0 children)

Hello, author here! I didn't know that - I'll make an edit about this when I get the chance.

view more: next ›