Nothing screams integrity like using proprietary crap

He is calling his own stuff crap anyway, lol.

View this comment - View article - View full comments

Since it won't (ever) fully implement all the DX7, it's sort of missing the point. May be wined3d will eventually have Vulkan path for it. For now you can use wined3d + zink for that.

And yeah, I wouldn't touch any dgvoodo2 stuff if its author can't figure out what open source is for.

View this comment - View article - View full comments

I'm glad they are switching to Qt! This also can serve as a mixer for pipewire to some degree.

View this comment - View article - View full comments

I wonder if Valve is considering an ARM CPU for the Steam Deck 2.

I see no benefits for them to do it. Unless AMD will make an APU with ARM CPU cores (supposedly AMD does plan something like that). And even then, how would it be better than x86_64 APU?

And for a handheld performance penalty for emulating x86_64 on ARM is going to make it additionally problematic.

View this comment - View article - View full comments

I wonder if they are running games using vkd3d or vkd3d-proton?

View this comment - View article - View full comments

I'll check Podman, never used it. I only experimented with lxc which is Linux's own container feature.

View this comment - View article - View full comments

I prefer real time + pause mechanic myself, but it's cool they are adding an option for turn based mode. I wish games with turn mode only did the same the other way.

View this comment - View article - View full comments

I prefer VMs over containers for development. I played around with lxc containers, but it always felt much easier to set up a user session qemu/kvm + libvirt VM (in something like virt-manager) than jump through the hoops of setting a non privileged lxc container and all permissions for it. lxc seems to be better prepared for privileged use cases. Or may be I just need more experimenting with it.

I'm not really sold on immutable distros for normal desktop use cases anyway, I don't see a major benefit in losing flexibility for general purpose needs. So far the only case where I'm using one is with OpenWRT [External Link] for my router. Immutability makes sense there due to special installation requirements on the embedded devices. Customization with packages there is possible using overlayfs. It doesn't need to generate a new image, it keeps immutable components separate from installed packages.

If a kernel module you need is not there, you will need to create a "custom image" that bundles the kernel module you need.

Which sort of starts defeating the purpose of using such approach. It's easier to build just a module than to build a whole new image to use a single module.

View this comment - View article - View full comments

Very nice! Now I can remove all 32-bit packages from my Debian installation.

View this comment - View article - View full comments

Of which the vast majority of normal users won't even notice.

That depends on what you call normal. Can you for example configure kernel modules there or immutability prevents that? Can you run stuff like VMs? "Normal" is too loose to describe it. I'd always see immutable distro as limiting and not general purpose enough.

If it covers your use cases - then it's useful. It is most fitting for console set ups in the gaming context.

View this comment - View article - View full comments