What is implied with alacritty not being customizable, what is then .config/alacritty/alacritty.toml meant for? That said, I'd argue kitty has hard coded what fonts can be used with it, though some might think this is good, but in my mind it's a limitation.
At any rate, this is a matter of taste. I use alacritty with screen. Some might argue kitty is better because of tabs supports, and if that's a thing for them, then that's fine...
At any rate, again, terminal emulators are a matter of taste...
IT might be, but librelinux for example really removes all binary blobs, although there's some tooling around doing that, so new cases might be missed without human inspection, but they are careful about binary blobs... So from the whole spectrum of open source stuff, if you care about binary blobs, chances are better on the libre/free SW side.
Probably Guix, and GNU endorsed distributions. Binary blobs are not allowed on free/libre distributions, or not on their official repos. That said, most gnu + linux distributions don't care about those. Most will take care, if they get to realize it, about distribution licenses, so if something has some sort of legal issue to be distributed, that will get purged from its repos most probably...
I'm not systemd user, and I generally see this absorbing as much as possible as a terrible practice. I don't usually comment on systemd stuff, since I'm happy just not being forced to use it.
However, even though I don't use it, the decision of people managing systemd really affects non systemd users. See by succeeding in getting all major distros into become systemd distros (somehow now governed by RH, if anyone cares), everything systemd absorbs tend to leave alternatives sooner or later deprecated, or abandoned.
Even autofs is no longer part of some official repos, given systemd has its own auto mount/unmount functionality... And there are several other examples...
At any rate, hopefully the more bloated systemd, doesn't make it the more vulnerable. And also hopefully, doesn't make life worse and worse to non systemd distros and users...
BTW, before sudo there was su, so a life without sudo is possible, :)
Uff, somehow missed your post. See mine. That's the FS I'm hoping to use next. I'm waiting for it to support swapfile, or alternatively read from official sources they won't ever support it, :). But yes, that's the one I'm looking forward to use.
How about bcachefs. I'm waiting for it to support swapfiles, which seems to be in the TODO list, but so far doesn't work. If you use swap partition[s], or prefer not to have swap at all (I never fell for this, and besides swap is required for hibernation if that's a thing for you), then bcachefs is ready for you. It's already part of linux since 6.7, and on Artix, current linux is 6.8.9...
To me is the FS to use. I'm still on luks + ext4 (no LVM) and do entire home backups with plain rsync to an external device. I'd have to learn new stuff, since ext4 is really basic and easy to configure if in need, but I think bcachefs is worth it, and as mentioned, just waiting for it to support swapfiles, :)
They don't run by themselves, they need a terminal emulator, or a console, underneath, so they can work. You can actually call screen on a console without graphical environment, and it'll provide the console all benefits of multiplexing. That doesn't make the multiplexer a terminal emulator by itself.
So, in my mind no, screen is not a terminal emulator, alacritty is, like xterm is, and so on. The multiplexor just adds extra capabilities to the terminal emulator.
At any rate, it's not worth going any further. What I meant is that neofetch was able to find out and show I'm using alacritty, whereas fastfetch doesn't show alacritty. And we can argue about the virtue of one or the other, but it'll boil down to taste. I prefer how neofetch shows alacritty, hehe. Some might prefer fastfetch showing screen. And most importantly, this is not critical at all.
There's an issue on fastfetch filed about it, and one of the devs indicated when using the screen multiplexer, they could find out the terminal emulator underneath, however they couldn't do the same with tmux. And to be consistent among multiplexers, they decided not to expose the terminal emulator underneath when using multiplexers, just show the multiplexer. I don't agree with that argument, but it's the dev right to choose to do that.
Actually while neofetch detects pretty well I'm using alacritty:
Terminal: alacritty
Probably they learned $TERM is really meaningless if using screen or tmux, but fastfetch totally misses this and mistakenly shows screen as the terminal:
Terminal: screen
The only thing I like of fastfetch over neofetch is that it's faster, :) And yes the display missing, but I've never considered that something of much interest for such output... To me neofetch is just fine, and on terminal it gives you a more accurate answer... In the end is a matter of taste... But what it does is well done, :)
pending for subscription, we'll see, and while pending, still not syncing properly...