Wait, does everybody die together now?

I still install mpv instead of using celluloid. With more than 400 audio files, mpv works like a boss but celluloid struggles to even display the song covers.

One thing with Tails and its persistent storage (also the dotfiles feature) is that I still can’t find a way to keep the wallpaper across sessions. I tried to copy $HOME/.local/share/backgrounds/wallpaper.jpg into the dotfiles dir but it doesn’t work.

Other than that, Tails is pretty good for what it does and quite stable.

You look proprietary.

Archive link to the rescue: https://web.archive.org/web/20250624214542/https://blogs.gnome.org/alatiera/2025/06/23/the-fascist-maggots/

You’re correct about command substitutions, the $(...) part. I had initially thought putting it inside a sh would be clearer and avoid problems with substitutions. However, $0 is the name of the shell or the script. To fix this, we can put {} inside a variable, like this: file="{}". Then, we can use the variable $file for the rest of the command.

I also think using for loops makes the command easier to read. But dealing with files that have spaces in their names can be really frustrating when you use for loops.

This helps distinguish commands that find runs from its own arguments. Imagine how find would figure out which commands it’s executing, and what their arguments are. The easiest way to do this is to use the standard end-of-command character. That way, you don’t need to create a special way to separate things. You can even put one find command inside another.

find /your/mp3/directory -type f -name "*.mp3" -exec test -f "/your/mp3/directory/$(basename -s .mp3 {}).txt" \; -exec mp3splt -A "/your/mp3/directory/$(basename -s .mp3 {}).txt" {} \;

This one liner should still work, even if your file names have spaces in them because find now looks at each individual match, not the entire output. Using a for loop with the results of find would create a lot of extra pieces of the file names because spaces separate the arguments. However, this single command is harder to read than using a for loop.

The idea behind this one is that search operators in find evaluate to true or false. The first exec tells find to run the second exec only if the file exists. If the file doesn’t exist, it just ignores it.

Watching this video brought back memories of when I first started using Linux. I really connected with him. Linux makes you feel like you have a lot of control – like you can change things easily. Windows, on the other hand, often feels frustrating and doesn’t really help you much.

What I noticed about the video is that he encourages you to try new things and be willing to make mistakes. He doesn’t seem to get upset when things go wrong, which I think is helpful for viewers. He also admits that Linux isn’t for everyone, which is a realistic acknowledgement. It’s a good video for introducing Linux, but it doesn’t overhype it either.

I’m not entirely sure how it works, but I think it’s read from top to bottom. If you need to control the order of execution, I’d suggest writing shell scripts and adding them to the config file. It should make things easier to manage.

First, make sure to include the full path to the script in your config file, like exec /home/your_username/path/start_cmus.sh or exec ~/path/start_cmus.sh. If you just use ./start_cmus.sh, there will be a complaint as it doesn’t know where to look for the script.

Another thing to keep in mind is that swaymsg is usually the better choice (man sway) when you want to send commands to sway. You can write your script as swaymsg -t command 'workspace 10; exec wezterm -e cmus' and then put the whole thing in your config file.

To make debugging easier, I like to add some echo or notify-send commands to my script to see if it’s working as expected. I’ll put those in my config file, run it, and check if the debug commands are being executed correctly like echo "first: $first_output" && commands && echo "second: $second_output". It’s a simple trick that can save you a lot of time. Also, don’t forget to check out journalctl for more info.

Yes, they are different because they are for different flatpak applications.

What’s in the files? Do they have a line called sockets? Is that line set to x11 or x11-fallback? Have you tried adding those options like sockets=wayland;x11;x11-fallback? I usually get an error saying I can’t connect to the display or that X is missing when I revoke access to x11 or wayland. Or did you remove x11 from your system?

It’s likely because it can’t access X11 or Wayland. To fix this, try editing the files in /home/your_username/.local/share/flatpak/overrides/ like I mentioned earlier. Specifically, look for the sockets line and make sure it includes wayland, x11, and x11-fallback like sockets=wayland;x11;x11-fallback;. This should help you launch flatpaks that need X11 access.

man 1 flatpak-override

Overrides the application specified runtime requirements. This can be used to grant a sandboxed application more or less resources than it requested.

By default the application gets access to the resources it requested when it is started. But the user can override it on a particular instance by specifying extra arguments to flatpak run, or every time by using flatpak override.

The application overrides are saved in text files residing in $XDG_DATA_HOME/flatpak/overrides in user mode.

Scroll down, you will see the --reset option to remove the overrides.

I noticed you used sudo to run the command, so I think the override files are stored in /var/lib/flatpak/overrides/. To get everything back to normal, try deleting everything inside that directory.

If you want to override the system-wide settings, you can create files in the same format as the ones in /var/lib/flatpak/overrides/, but put them in /home/your_username/.local/share/flatpak/overrides/.

To generate the pre-config settings for a flatpak, you can use the flatpak -m info app_id command. This will show you some info about the flatpak, and the -m option will print out the metadata. You can also save this info to a file by running flatpak -m info app_id > ~/.local/share/flatpak/overrides/app_id.

When you edit the file, pay attention to the Context, System Bus Policy, and Session Bus Policy sections and delete everything else. By default, flatpak is set to share some resources, but you can deny access by adding an exclamation mark before the resource, for example, you could change shared=network to shared=!network.

If you’re looking for a user-friendly way to manage flatpak permissions, I recommend checking out flatseal. It’s a great GUI tool that can make it easier for you in this case.

That being said, it’s always a good idea to be cautious when using commands posted online. Make sure you understand what you’re doing before copying and pasting anything into your terminal. And if you’re ever unsure about something, there are some great resources available to help you out.

One of the best places to start is the Arch wiki, and I think, man is a friend everybody needs!

If you want to share your script with others, I think it’s a good idea to make it as easy to read as possible.

If you’re just keeping it for yourself, that’s fine. But if you’re sharing it with me, the more readable it is, the easier I’ll be able to understand what you’re trying to do and how you’re solving the problem. This will make it easier for us to discuss ideas and improvements together. To be honest, one-liners can be a bit confusing because they can do multiple things at once. Breaking things down into individual steps makes it easier for me to follow along and for you to understand why you made certain decisions.

Plus, it’s a good habit to get into for your own future reference - you’ll be able to look back and understand your thought process more easily.

As the famous saying from SICP goes:

programs must be written for people to read, and only incidentally for machines to execute

F5panic

Chalk Radio from MIT OpenCourseWare

I really enjoy this podcast. It’s great to hear that the professors at MIT share their passion and expertise with students and the wider world. One of my favorite episodes is Prof. Eric Grimson’s story about making computer science more accessible to everyone. It’s really motivating to think that there are so many talented teachers and resources available, which makes me feel confident and excited to keep learning on my own.

This isn’t an echo chamber. You and I are on Lemmy, and we, lemmings, love free and open-source software. But I bet you that many people still use proprietary software as their daily drivers. Many of them still use Windows as their main OS, and many are still on iOS. However, that’s not the end of the story. They also use plenty of FOSS software, like Firefox, VLC (you can’t deny the love of people for VLC), OBS, and qBittorrent. And that’s a good thing! It’s not a binary choice that you have to either go this way or this way. That’s not healthy.

Even if this is an echo chamber, so what? I see it as an effort to set a norm for the community. ‘Hey, I love Linux, you should try it!’ ‘I have the same experience, you should give it a go.’ ‘I’ve used Linux for a long time and I love it, feel free to ask me any questions.’ When there are many people willing to help, others are less scared to try new things. And when we move together, we fear nothing!

Do you like hurting other people?

The answer for 1 from EFF: Is my phone listening to me?