idk man I use /dev/sdX when running commands interactively and PARTLABELs in my /etc/fstab. All those letters and numbers in UUIDs are too much for my monkey brain to handle lol

Ooh, I've never heard of bcachefs, sounds exciting! I see it supports encryption natively, which btrfs doesn't. Pretty cool!

Personally I've never had any issues with btrfs, but I did start using it only a couple years ago, when it was already stable. Makes sense that you'd stick with zfs tho, if that's what you're used to.

I find myself inventing new curses for those who screwed things up with these overblown, over complex, minimally functional abominations

Gosh, tell me about it. I once tried writing a custom wifi signal strength indicator app that got its information from network-manager. Apparently the only way to programmatically communicate with network-manager is through dbus, which is just terrible. Scarce to no documentation, poor support for any language other than C/C++, and once you do get it working, it's the most disgusting and overly verbose code you've ever seen, just to query the status of the wifi card. Could've exposed the API through raw unix sockets or something, but nope, they had to reinvent the wheel on that one as well.

Just give me vi and the basic configuration files and let me get on with it!

I'll take this opportunity to shill for Void Linux, it sounds like exactly what you're describing. I've been a happy user for like 5 years now. I particularly like how nothing ever breaks, because there's not much to break on such a minimal system.

...well, actually, a few things did break over the years, but most of those were due to user error haha.

Thanks! Memes as education material / propaganda FTW

I can think of a single instance where a Redhat-ism is better

I don't know if it would be accurate to call it a redhat-ism, but btrfs is pretty amazing. Transparent compression? Copy-on-write? Yes please! I've been using it for so long now that it's spoiled me lol. Whenever I'm on an ext4 system I have to keep reminding myself that copying a huge file or directory will... you know... actually copy it instead of just making reflinks

I'd do away with network-manager on a stationary system too, but I'm on a laptop, and unless there's some trick I don't know about, configuring wifi by hand for every new network I come across sounds like a bit of a pain. Especially for corporate/institution network that use fancy things like PEAP

Thanks! I love this format so much. I can't find it now, but one of my favourite memes in this genre was something like this:

STOP DOING

• Tasks were never meant to be completed
• Years of working, but there's STILL MORE SHIT TO DO
• Wanted to get some work done anyway, for a laugh? We had a tool for that: it was called SIMULATION GAMES
• "Please let me sacrifice a third of my life to justify my existence. Please let me spend eight hours a day working just to be able to do it again the next day" - statements dreamt up by the utterly deranged

Look at what people have been demanding our respect for all this time, with all the schedules and todo lists we have built for them:

These are REAL things done by REAL people

<Pictures of gmail, microsoft outlook, and some TODO list app>

They have played us for absolute fools

What I really don't understand is why distro maintainers feel the need to actually go along with these changes. Like, sure, if this predictable interface naming thing worked as intended, I can definitely see how it can be useful for server administrators. You could just hardcode the automatic interface names instead of assigning them manually in /etc/mactab. But why would the rest of us ever need this? Most personal machines have at most one wifi card and one ethernet device, so wlan0 and eth0 are perfectly predictable. And even if you have multiple wifi or ethernet adapters, your networking is probably handled by network-manager, so you never actually have to put interface names into config files. Why force enterprise-grade bloat on users who just want a simple desktop experience?

No, the "old scheme" is the one that assigns wlan0, wlan1, eth0, eth1, and so on by default. I would say these names are pretty usable.

The part you quoted is what you need to do if you specifically need to be sure that a specific card gets a specifc name 100% of the time. You don't have to bother with it unless you have a reason to.

"reddit makes a linux distro" would be hilarious and terrifying

Thanks, glad you like it! I spent quite some time re-making the template from scratch in inkscape, because the original meme din't have enough space for the text

Oh man are we sharing mpd scripts? I have this one that lets me search through music directory and add anything to the play queue (so I can add a single track or an entire album or whatever):

#!/bin/bash

MUSIC_DIR=$(grep -m 1 -E '^\s*music_directory\s+' "$XDG_CONFIG_HOME/mpd/mpd.conf" | awk '{printf $2}' | tr -d \" | tr -d \')
MUSIC_DIR="${MUSIC_DIR/#\~/$HOME}"

cd "$MUSIC_DIR"
CHOICE="$(find . | cut -c 3- | dmenu)" || exit 1;

mpc insert "$CHOICE"
mpc play

There's also this one that lets me save the currently playing song to a playlist of my choice. It's good if I'm listening to a new album or a new artist and suddenly think "yeah, this song really fits with the mood of X playlist":

#!/bin/bash

MUSIC_DIR=$(grep -m 1 -E '^\s*playlist_directory\s+' "$XDG_CONFIG_HOME/mpd/mpd.conf" | awk '{printf $2}' | tr -d \" | tr -d \')

choice="$(mpc lsplaylists | dmenu)" || { echo "No choice." ; exit 1; }
MUSIC_DIR="${MUSIC_DIR/#\~/$HOME}"

mpc current -f '%file%' >> "$MUSIC_DIR/$choice.m3u"

Here's my script to shuffle play an existing playlist as well:

#!/bin/sh

choice="$(mpc lsplaylists | dmenu)"
mpc clear
sleep 0.1
mpc load "$choice"
sleep 0.1
mpc shuffle
sleep 0.1
mpc play

The sleeps are to prevent Cantata (graphical mpd client) from shitting itself if I run this script while it's open. Also notice mpc shuffle instead of mpc random on. It shuffles the current playlist, but keeps the linear play order, so that I can add songs to play right after the current one.