Soon, Purple Hat should be charging for systemd and hopefully other corpos and organizations will move back to sanity.

From systemd licenses readme:

Unless otherwise noted, the systemd project sources are licensed under the terms and conditions of LGPL-2.1-or-later (GNU Lesser General Public License v2.1 or later).

New sources that cannot be distributed under LGPL-2.1-or-later will no longer be accepted for inclusion in the systemd project to maintain license uniformity.

I can understand critism of systemd for its tools only working with itself and not with any other Unix tools. But it's absolutely a conspiracy theory to think they'd want to charge for systemd. Though I do agree that if someone was charging for systemd (which they can't because its open source), open source alternatives would pop up.

Those are all good reasons. XFCE aims to support Wayland with the next release, so if they choose to use an established compositor it shouldn't be too buggy.

With XFCE porting their apps over the setup shouldn't change much, unless you're using Xorg specific tools.

Over the last few years most features I'd expect from a windowing system were added to Wayland, so I expect the drama to cool down. (I don't even know what's still missing (except accessibility), with VRR, tearing, DRM leasing (VR), and global hotkeys being done. It's just apps like Discord that have to cave in under the pressure to fix their apps.)

Once everything works, there's no point talking about it.

@Furycd001@fosstodon.org

I wonder how long it'll be possible to build Gnome with Xorg support. If I had to guess I'd say there won't be any support within the next 3 years, because keeping future Gnome working with Xorg is work nobody wants to put in.

That said, Xwayland will likely keep being around for the foreseeable future.

Out of curiosity, do you use Xorg and if yes, what's keeping you from using Wayland?

I'm using Proxmox with a NixOS LXC for Jellyfin/*arr. The media is stored on a single btrfs HDD, because high uptime (RAID) isn't necessary for me and it's media I can simply redownload.

I'm looking into switching to NixOS on bare metal, because I don't need the UI of proxmox and most other features.

Symphonium is great for music, even though it's closed source and paid. I'm mostly using Spotify though.

Findroid is an awesome native Android app for watching tv/movies, altough it doesn't support transcoding.

Fedora also has their own flatpak remote, which only includes flatpaks build from Fedora rpms.

I'd say flatpak isn't the future because it's already here and seems to be universally accepted as the cross-distro package manager.

I do like how the Nix package manager handles dependencies, but it's not suitable for app developers packaging their own apps because of its complexity.

If a better flatpak comes around I'd use it too, but at least for graphical apps I don't know what it'd have to do to be better. In my opinion, flatpak is a prime example of good enough, but not perfect and I'd be surprised if there was a different tool with the same momentum in 15 years (except snap, but they seem too Ubuntu specific).

This post was posted two times, so you might want to delete one of them.

Bookmarks and GPX export is a great addition. OrganicMaps continues to improve and I find myself using OsmAnd less and less (unless I need specific features).

I've now added the date to the title to make it more clear the article is from two months ago. The article is a good read and wasn't posted on here, so I thought it's still worth sharing.

https://www.qualcomm.com/developer/blog/2024/05/upstreaming-linux-kernel-support-for-the-snapdragon-x-elite

Spotify and Crunchyroll also require DRM, like almost all commercial video sites.

Ungarn hat in seinem Arbeitsprogramm angekündigt, die Verhandlungen zur Chatkontrolle voranzutreiben.

Leider werden wir noch mehr von der Chatkontrolle hören.

It seems the Determinate Nix installer supports Fedora Atomic and SELinux.

On topic:

I really like Nix and home-manager. I've mostly switched to NixOS because it's more convenient for window manager setups than building ublue images imo.

Having to mess with containers for different dev environments and keeping the up to date is imo more annoying than creating a shell.nix

Also being able manage my dorfiles with home-manager and installing software declaratively helps in keeping the system free of clutter.

The source of the determinate nix installer has some mentions of SELinux. E.g. they have an .fc file, but I really don't know anything about SELinux.

https://github.com/DeterminateSystems/nix-installer/tree/main

Yes, that's likely the case.

The ahayzen/silverblue-nix guide uses bind mounts from /var/lib/nix to /nix. The latter being created by making / temporarily writeable with chattr +i /.

It seems the Determinate Nix installer supports Fedora Atomic with SELinux enabled.

supporting SELinux and OSTree based distributions without asking users to make compromises

https://github.com/DeterminateSystems/nix-installer

Edit:

disabling SELinux

I hope this is not a serious suggestion?

Since no nix installer supported SELinux at the time, it was the only way to use nix on Fedora Atomic. With a better option available disabling SELinux is a bad idea indeed.

https://gitlab.com/ahayzen/silverblue-nix#using-nix-on-fedora-silverblue

It's possible to install nix on Fedora Atomic by disabling SELinux and using bind mounts.

Removing nix is mostly done by deleting /nix, and removing some systemd services, as well as deleting some nix-related users or groups (iirc nixblkd)

Because almost all of nix happens in /nix it doesn't clutter much of the system.

Great to see Unified Push on the list. As well as improved Wayland input method support, whatever that exactly means.

I personally prefer top level subvolumes (@, @home, @var-log, @var-cache), because it makes it easier to know which system folders are subvolumes and back them up accordingly. They are then mounted at their respective location under /.

E.g.. I do snapshots looking at the btrfs filesystem and its top level subvolumes. I'm not doing snapshots going from the mounted root filesystem. I.e. I'd do a snapshot of @home, not a snapshot of /home.

If you want to use backup/snapshot automation tooling, I'd recommend looking at how they expect the subvolumes to be set up. E.g. snapper and timeshift expect a specific layout (which can stil be done manually after OS installation, but why bother).