#DistroBox

[andmaybegayer]

laziness level: instead of figuring out where to put a venv of pelican on my computer for local blog builds, just installed pelican globally in a distrobox

[masonicon]

My thoughts on Virtual Machine programs

DOSBox-X: suitable for Windows 3.11 and 9X GuestOSes 86box: for Windows 9X and other 90s OSes(including Windows NT/2000) GuestOSes VirtualBox/VMWare: for more modern GuestOSes Distrobox: for running Linux Distros outside SteamOS in Steam Deck Qemu: for Mac OS(and any OS requiring different architectures) VMs

[unidentifiedfuckingthing]

most disappointing thing about moving to linux is using FOSS programs with huge userbases and finding out that theyre wildly buggier than they were on windows. in hindsight like, of course, the number of people on windows is probably an order of magnitude higher, but it kind of feels like. you cant do that. its supposed to be the other way around

[nksistemas]

Distrobox 1.8 se Estrena con Soporte Ampliado para Distribuciones de Contenedores

Después de más de cinco meses de desarrollo, la nueva versión de Distrobox 1.8 finalmente ha sido lanzada, trayendo una serie de mejoras, correcciones de errores y nuevas características que hacen que esta herramienta sea aún más versátil y fácil de usar para los entusiastas de Linux. ¿Qué es Distrobox? Distrobox es una herramienta de software de código abierto para sistemas Linux que permite…

[antpalmer]

I just spent my entire fucking day dealing with initramfs issues (and a shit ton of help from a discord server) after upgrading from Ubuntu 22 to 24. I'm so fucking done with this distribution, I just need it for one class. Next time Im using mint and a distrobox.

Like

From 11 pm to 2 am all I did was hunt SO posts only for the issue being the ramfs file in kernel 6.8 being broken (it took an hour to restore) but guess what? IT NEVER RESTORED. I had to wipe 6.8 from the face of the earth god bless the fact that it still had 6.5.

[yappg]

First dev blog

Hi! I can't believe this is the first dev blog for yappg (or rather, this iteration of yappg. There are dev blogs for the previous attempts that can be found on youtube or gamejolt).

I wanted to wait until I had an icon, but turns out I found something to talk about.

yappg is made with gamemaker. Partially because it's a nice engine, partially because it's one I am familiar with, but mostly because it's the same project I keep trying to make in that engine for around 5+ years. I really want to do my best to finish it this time, hence the tumblr blog. But how I used my computer was very different 5 years ago. Today, I am on Arch Linux (let's get this out of the way : i use arch btw). Arch is not a supported operating system for the GameMaker engine. I think the issue is pretty easy to figure out.

Up until now, I have been using distrobox to manage a podman container based on Ubuntu 23.10. While solutions like debtap exists in order to convert .deb packages into Arch Linux compatible packages, it doesn't really work with GM. The container approach gives me a near native experience. It's not perfect. Either due to configurations issues or just container issues, the GM debugger doesn't work, the game itself seems to run at a very low fps when ran from inside the container (like, for example, when testing) and any attempt at making an executable fails around 1/8th of the times (but don't quote me on the number tho). Good enough to develop, but there are some time lost dealing with bugs. Plus, I have to run the Beta version of the GameMaker IDE.

But this isn't what made me write this post. Oh no. GameMaker has 2 different ways to create an executable file. You can either use the VM or the YYC. The VM option runs the game in a virtual machine (a bit like Java), while the yyc option compiles the game. This compilation comes with a performance boost, but it takes alot longer to build and features like the debugger are disabled. And as it turns out, something breaks in my container setup when trying to compile an executable using yyc. But at least, that's better than what happens when I try to do a remote build from the container to an ubuntu vm. Because the build doesn't fail... but the engine forgets how the room order works or something.

This object is in the first room of the game. Every build has that specific object, and the alarm event was left untouched since it's creation. Why is this an issue now???

Honestly, HOW??? And I can confirm that the issue is with the container, because after having installed the beta ide on the same virtual machine and compiling the game there, the room order works again, and the game is compiled without any issues.

The tl;dr here is to not run the GameMaker beta IDE inside of a container, but that's too late for me. Fortunately, I can keep developing for vm until I am close to being done, at which point I can switch to yyc and fix whatever bug might pop up

[pulipuli]

看看網頁版全文 ⇨ 雜談：總算把架設了Stable Diffusion WebUI Forge / TALK: Finally Set Up Stable Diffusion WebUI Forge https://blog.pulipuli.info/2025/01/talkfinally-set-up-stable-diffusion-webui-forge.html 由於之前硬碟毀損，導致我用來做AI繪圖的Stable Diffusion環境全部消失。 這次乾脆全部重來，用Stable Diffusion WebUI Forge重建整個繪圖環境吧。 ---- # Stable Diffusion環境與Docker / Stable Diffusion Environment and Docker。 大家會把Stable Diffusion的環境架設在哪裡呢？。 網路上大部分的教學都是基於Windows的環境。 一方面是因為使用者眾多、為Windows環境開發的懶人工具也很多；二來是Windows環境也相對單純，WSL2穩定的表現讓人印象深刻。 不過這些都跟我這個Linux使用者沒有關係。 Linux使用者常常會受到發佈版和套件相依之苦，安裝系統和轉換的時候往往會遭遇很多困難。 現在有許多方案都在嘗試解決跨平臺(Linux自己的平臺)的各種問題，有針對套件管理的AppImage、snap、Flatpak、有針對運作環境的distrobox、也有強調Windows相容的PlayOnLinux、Bottles。 不過在伺服器的情境下，Docker應該還是目前最多人選擇的虛擬化方案。 在使用Linux電腦的這三年之間，我認知到這電腦就是註定常常損壞的設備。 因此我所建立的系統環境首要目的就是容易管理、容易遷移，而這也是我選擇Docker的原因。 https://github.com/AbdBarho/stable-diffusion-webui-docker/blob/master/README.md。 因此，一開始我的Stable Diffusion環境是基於AdbBarho所建立的stable-diffusion-webui-docker來架設。 當時AdbBarho很用心地將Stable Diffusion主流的創作環境AUTOMATIC1111、ComfyUI、Sygil-webui、InvokeAI都整合了進來。 我們在啟動Docker的時候可以自由切換需要的環境。 而各個環境背後使用的模型，則在Docker巧妙的設定中能夠共享。 ---- 繼續閱讀 ⇨ 雜談：總算把架設了Stable Diffusion WebUI Forge / TALK: Finally Set Up Stable Diffusion WebUI Forge https://blog.pulipuli.info/2025/01/talkfinally-set-up-stable-diffusion-webui-forge.html

[hackernewsrobot]

Distrobox: Use any Linux distribution inside your terminal

https://github.com/89luca89/distrobox Comments

[helix-editor]

Distrobox! It lets you run a little tiny other distro and then run apps (including GUI ones) from there!

*shaking crying and pissing my pants* I'm thinking about dual booting two Linux distros.

[andmaybegayer]

Any recommendations/cautions about using Alpine Linux on the desktop? It's always intrigued me and you're the only person I've seen post about it

Alpine is pretty good for desktop, very stable, good security practice, professional development philosophy, broad package availability. You will run into some very obvious pitfalls, although they can mostly be obviated by using some modern applications.

The Alpine wiki is a little sparse and at times can be weirdly focussed, like spending a lot of the installation page talking about the very specific usecase of a diskless install. Nonetheless, it's quite good and should be your first port of call. A lot of the things I'm mentioning here are well covered in the article on Daily Driving for Desktop use. I'm basically just editorializing here.

The installation procedure is command-line only, but pretty straightforward, you run setup-alpine and follow the prompts, assuming you want a basic system. If you need special disk partitioning, you'll usually have to do it yourself. There's a whole whackload of helpers to get you set up, like setup-desktop which will help you install any of 'gnome', 'plasma', 'xfce', 'mate', 'sway', or 'lxqt'. Most of these are called by setup-alpine for you, but not the desktop one. You can call it at any time though.

Most obviously, musl libc, no glibc. Packaged software will work fine. There's a compatibility shim called gcompat that will usually work, but might fall apart on more complicated software expecting glibc, for example I've had no luck running glibc AppImages. For more complex software, Flatpaks are a good option, e.g. Steam runs great on Alpine as a Flatpak, I run the Homestuck Companion Flatpak. Your last ditch is containerization and chroots, which are fortunately really easy to handle, just install podman and Distrobox and you can run anything that won't run on Alpine inside a Fedora or Debian or Whatever container seamlessly with your desktop.

Less obviously: no systemd. Systemd underpins some really common features of modern Linux and not having it around means you have to use a few different tools that are anywhere from comparable to a little worse for some tasks. Packaged applications will work smoothly, just learn the OpenRC invocations, Alpine has a really great wiki. For writing your own services, it's a lot more limited than SystemD, you're not going to have full access to like, udev functionality, instead you get the good but kind of weird eudev system.

If you're mainly installing things from the repos you'll barely notice the difference, other than that every package is split up into three, <package>, <package>-docs, and <package>-dev. This is a container-y thing, to allow Alpine container images to install the smallest possible packageset. If you need man pages you'll have to install them specifically.

Alpine has a very solid main repo, and a community repo that's plenty good, and worth enabling on any desktop system. It'll generally be automatically enabled when you set up a desktop anyway, but just a notice if you're going manual. You can run Stable alpine, which updates every six months, or if you want you can run Edge, which is a rolling release of packages as they get added. Lots of very up-to-date software, and pretty stable as these go. You can go from Stable->Edge pretty easily, going back not so much.

There's also the Testing repo, only available on Edge, which I don't really recommend, especially since apkbuild files are so easy to run if you just need one thing that has most of its dependencies met.

Package management is with APK, which is fast and easy to work with. The wiki page will cover you.

Side note: if you want something more batteries-included, you could look at Postmarket, an Alpine derivative mainly focussed on running on smartphones but that is a pretty capable desktop OS, and which has a fairly friendly setup process. I run this on an ARM Chromebook and it's solid. Installation requires some reading between the lines because it's intended for the weird world of phones, so you'll probably want to follow the PMBootstrap route.

[unidentifiedfuckingthing]

ok so the problem with xapblr on linux is python-future right? i already had to go through a whole thing with that particular rude package for some other thing. but it seems to me like you could pretty easily set up a minimal arch container with python-future but not python 3.13 and then set up and run xapblr from there right? if i get a working compose file for that does anyone want it

[gruvbox-official]

I'm currently daily driving Bluefin (customized RPM-ostree image that uses GNOME but with some Ubuntu-esque customizations like dash-to-dock, plus some other stuff designed around container workflows, such as using Ptyxis as the terminal), and it's pretty neat.

admittedly I don't really use RPM packages outside of distrobox environments (basically running it in a docker/podman container), but I do recommend the Universal Blue project's custom images. They have a bunch of nice customizations like shipping with the rpmfusion repos already enabled, and with distrobox instead of toolbox. I think Bazzite (their SteamOS alternate) even runs Steam in an Arch distrobox rather than using the flatpak.

have any of you nerds tried Kinoite? (or silverblue) i want to switch to an immutable distro and i'm too cool to use nixos

[antpalmer]

Ubuntu part 2: jetpack (the nvidia SoC) dev environment requires ubuntu 14.04 if you want to write for an older chip.

Distroboxes are such a pain in the ass and I hate podman.

[yescs2020]

Distrobox: Try Multiple Linux Distributions via the Terminal