ryuukk

Think twice before abandoning Xorg. Wayland breaks everything!

Source: https://x.com/LundukeJournal/status/1940441670098809093

Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.

Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.

Over the years I have designed a strong medecine from various documentation, a berevage that helps greatly to improve the immune system. I use it on a regular basis, and has made my body strong against any infection. With this I haven't been ill in the last 5 years (not even sneezing). This recipe will protect you, your friend and familly against many viruses.

You first need to get equiped with a Thermos (thermal carafe) and a kettle.

Buy the following

Green tea (mint tastes good) (tea must be green not black)
Ginger root
Turmeric root (or powder if you don't find as root)

Windows 10 - Using Git Bash With TMUX

Why Not Use WSL?

I tried the WSL and it isn't quite seamless enough for me. I ran in to problems when editing in VSCode and having watchers on my files (ng serve, dotnet watch run, etc.). In addition, I kept running in to problems that only manifest themselves when running in WSL. For example, this issue with doing production builds and the terser plugin has made many a developer rage-quit on using WSL. Just figuring out that it was an issue with the WSL took a lot of time.

That terser plugin issue was never resolved and I ended up having to keep a git bash window open in addition to my WSL console window so I could do production builds. To make matters worse, my npm packages were platform-dependent so I couldn't use the same project folder. So, my procedure was: commit whatever changes to test branch, push to repo, git pull on my "windows" project folder, and do a production build there

Normalize volume level with PulseAudio and simultaneous output

This should work conceptually on any Linux OS with PulseAudio but these particular instructions are for Ubuntu. There are two major reasons for using simultaneous output. The first is self-evident - we can output to say a bluetooth headset and wired headphones at the same time to enable two people to watch a movie with headphones on a single computer. The second reason is a sort of a convenience for setup. We know the simultaneous sink name so the default.pa config would work without modification so long as simultaneous output is enabled. If we were to set this up without that, we'd have to customize the config with our specific device sink name. That's totally doable but personally I always setup simultaneous output. That's why I haven't described the alternative in this gist.

	bass_enable=false
	bass_maxgain=5
	compression_aggressiveness=10
	compression_enable=false
	compression_maxatk=0
	compression_maxrel=195
	convolver_enable=false
	convolver_file=""
	convolver_optimization_mode=0
	convolver_waveform_edit="-80;-100;0;0;0;0"

	{
	"output": {
	"bass_enhancer#0": {
	"amount": 5.0,
	"blend": 0.0,
	"bypass": false,
	"floor": 20.0,
	"floor-active": false,
	"harmonics": 8.5,
	"input-gain": 0.0,

	-- awesomewm fancy_taglist: a taglist that contains a tasklist for each tag.

	-- Usage:
	-- 1. Save as "fancy_taglist.lua" in ~/.config/awesome
	-- 2. Add a fancy_taglist for every screen:
	-- awful.screen.connect_for_each_screen(function(s)
	-- ...
	-- local fancy_taglist = require("fancy_taglist")
	-- s.mytaglist = fancy_taglist.new({
	-- screen = s,

	#include <event2/bufferevent.h>
	#include <event2/buffer.h>
	#include <event2/event.h>
	#include <event2/dns.h>

	#include <arpa/inet.h>

	#include <iostream>
	using namespace std;