I personally hate global menu bars. They do not work with focus follows mouse. The way menus currently work is fine for me and I would not want to lose that to, IMO, a much worst system. Any global menu implementation would need to be able to be disabled and better to have it off by default. And I would rather see effort in developing other features personally - though mostly as I would never use this feature.

* in your commands is expanded by the shell before tar sees them. It also does not expand hidden files.

So when you do admin/* the shell expands to all non hidden files inside admin. Which does not include admin/.htaccess. So tar is never told to archive this file, only the other non hidden files and folders. It will still archive hidden files and folders nested deeper though.

In the second example * expands to admin and the other does which are not hidden at that level. Then tar can open these dirs and recursivly archive all files and folders including the hidden ones.

You can see what commands actually get executed after any shell expansions if you run set -x first. Then set +x to turn that off again.

Here is an example using ls:

$ set -x; ls -A foo/*; ls -A *; set +x
+ ls --color=tty -A foo/baz
foo/baz
+ ls --color=tty -A foo
.bar  baz
+ set +x

You should have a live USB of the distro you want to use and ensure you have backups of all the data you care about. Then the easiest/quickest/least error prone way is to just wipe the whole drive and reinstall the distro from the live USB. They typically have an option to wipe and install things from an empty drive. Then just restore your data from your backups.

You could also, after creating backups, from a live USB environment delete the windows partitions and resize the linux ones - being careful not to delete the EFI partition as that is where the boot loader lives. You can optionally delete the windows boot loader from the EFI partition as well. If done right you should still be able to boot into your linux system afterwards though when missing with partitions like this, especially when you don’t know what you are doing, it can be easy to break the boot systems. These can be fixed from a live environment and there are many guides out there on how to do that.

You can always just reinstall the system again if you mess things up and cannot figure out how to fix them - so always prep for that case by backing up everything you care about first.

--asdeps also works when installing something to immediately mark it as a dep. Can be useful for non dep packages if you only need it temporarily as it will be removed the next time you purge unused deps.

Clean orphaned dependencies: sudo pacman -Rs $(pacman -Qtdq)

In addition to this, or rather before, you can run pacman -D --asdeps package_name to mark a package as a dep. If it is no longer required by something else it will be removed with the above. This can be useful for things that are deps that you installed manually at some point for some reason.

And remember that you can recover from anything, even removing base packages or bootloader ones with a live cd and chroot or using pacman with a different root with the --root /mnt flag to pacman.

Otherwise if your system still boots it is just a matter of following the install instructions for whatever is not working like you did the first time.

I would not worry about virtual memory usage. Virtual memory can include memory mapped files and does not indicate actual ram usage - only the address space that the program has opened at some point. There is little point in worrying about it.

IMO the best thing is to just start using it. You will start to pick things up fairly quickly then. Puzzles don’t often ingrain different ways todo things and often focus on weird or niche things that don’t come up as often. They can be a nice supplement to not a substitute for just using it in real world usescases.

I do also find it helpful to read the shortcut keys on their site to get a feel for what is available. You won’t remember everything but it can be useful to know what is possible. Then when you hit a problem you may remember reading about something that can help and go look it up again.

Just dont format the drive when installing a new distro. BTRFS or not you can delete the system folders manually first if needed but I believe that some if not all distros will delete the system folders for you (at least ubuntu used to do this last I tried). And if not you can do it manually.

It does not matter if you have a separate partition or not for /home installers won’t touch it if it already exists except to create a new user if needed. Remember, all the installers do is optionally format the drives, mount them then install files into those drives. If you skip the formatting and manually do that partitioning (or using an existing partition layout) it will still mount and write to the same places regardless of it they are separate partitions or not. So a separate partition does not add any extra protection to your home files at all.

But regardless of what you do you should ALWAYS backup your home data anyway. Even with separate partitions or subvolumes the installer can touch or delete anything it wants to and you can easily click the wrong button or accidentally wipe thing. At most preserving your home saves you from restoring from a backup it should not be done instead of backup.

There is no problem with having home on a different disk. But why do you want swap on the slower disk? These would benefit from being on the faster disks. Same with all the system binaries.

Personally I would put as much as possible on the faster disk and mount the slower somewhere that the speed matters less. Like for photos/videos in your home dir.

/boot can be anywhere though if you are getting a grub error that suggests the UEFI firmware is finding grubs first stage but grub is having issues after that. Personally I don’t use grub anymore, systemd-boot is far simpler as it does not need to deal with legacy MBR booting.

My point is the different levels of just working are subjective, not objective. I personally have spent far more time fixing bugs or just reinstalling ubuntu systems then I have over the same period for Arch systems. So many of my ubuntu installs just ended up breaking after a while where I have had the same Arch install on systems for 5+ years now. Could never get a Ubuntu system to last more then a year.

Everyone has different stories about the different OSs. It is all subjective.

You can cherry-pick examples of problems from every OS. That is my point. They all have issues that you may or may not encounter and quite a few that would make people from other OSs scratch their head and think what the hell the devs are thinking. Pointing out one issue of one OS does not change any of that.

Which is proven by the other replys to your comment - others dont find this issue to be as show stopping as you do and just live with it or dont use it at all. How many issues do you do the same for on your favorite OS?

There is no perfect OS that just works for everyone. They are all software so they all have bugs. People how say an OS just works have never hit those bugs or have gotten used to fixing/working around or flat out ignoring them.

This is true of all OSs, including Windows, Linux and MacOS. They are all differently buggy messes.

Linux is the buggy mess that works best for me though.

Might I add the idea that your terminal emulator must support your shell is utterly ridiculous?

TBH I am starting to come around to the idea of a tightly integrated shell and terminal emulator support. There are just things you cannot do with these being separate things. I am very tempted to explore the idea from the other end though - writing a shell that has a emulator built into it (like screen/tmux basically are). But I do think that this integration is needed for any per command features that is not just printing out a prompt.

It would be interesting to see what could be done with this type of integration but will likely break support for existing shells. Unless you maybe launch a shell for each command you run or something 🤔. Would like to seem more people experimenting with stuff like this and see what new things we could drive forward. We have been stuck with the current tty system since like the 80s to support devices that just dont exist anymore.

Helix IMO has one huge benifit over Kakoune - inbuilt LSP and treesitter support and sane defaults. It takes the best bits of kakoune and neovim and improves on them both. This gives me an editor with enough IDE like support that I can use it for just about anything. All with only a few lines of config and zero plugins.

This means I don’t need to spend ages trying to configure my editor to work with various languages or working around its archaic defaults. I can just install it, optionally tweak some minor settings (like the theme and turning off auto bracers), install the LSP servers for the languages I need and I can get to coding.

And after years of fiddling with neovim/vim to get it to it behave in a reasonable, but not perfect, manor helix is a breath of free air. I did try kakoune for a very short time after getting pissed off with neovims configuration and plugins, but gave up on it quickly when I had to dive into getting more plugins configured for even basic things like LSP support (though this was years ago, back when helix was not in a daily usable state either).

Yeah, it would be nice to have plugins in helix (and they will come one day), but IMO the saner defaults and unbuilt support for most of what I used plugins for before is far nicer than getting support for the few bits that might be missing.

Kakoune promotes the idea that you should visually see the text you’re operating on before running the command.

This is what helix does as well, and it shares kakounes keybindings and input system. So it is more similar to kakoune in that regard than vim with different keybindings. Really it is more of a kakoune clone, with inbuilt support for LSP and treesitter like neovim.

For example, instead of it having a built-in sort command, you use the unix sort command to sort your lines.

You can do this in vim and helix as well. Both can run external commands, pipe your open file to external commands or just your current selection to them. I use the unix sort in helix to sort lines all the time.