> Additionally, by the time I started messing with RPM packaging, I had already packaged for Gentoo, Arch, and Ubuntu, so I think I had already developed some intuitions for how to explore packaging systems and their documentation.
Ah, that might have helped I suppose. I haven’t done any sort of packaging in the past so that might have not helped.
> but all of those were added to pacman within 2 or 3 years of when I stopped daily driving Arch-based distros.
Ah, that would explain why I hadn’t experienced that myself, having only switched to Arch about a year ago now.
> it only examines version constraints for new stuff or updates it's grabbing from the repo. This is part of why 'partial upgrades' aren't supported and all of why your AUR-installed packages are liable to break after `pacman -Syu`, requiring sane AUR wrappers to rebuild your AUR packages after each system upgrade.
Isn’t this, while being slightly inflexible, reasonably logical with Arch being rolling release? I was under the impression that you weren’t supposed to upgrade anything individually, as that upgrade might cause the need for a newer version of some dependency, which could break other packages.
> make it easy to tell when an upgrade or installation might require you to change the 'supplier' of a given package
This has worked fine for me with packages installed from the AUR (through yay), although I can’t think of any examples, but I think it’s only happened once or twice.
> Honestly I should probably try running Arch again for a while to help update what I think of pacman.
I would recommend that you do, as Arch is the best distribution ever! :P
Thanks for sharing that information, as I’ve never heard anyone talking about pacman at that time, so I’d assumed it was always like it is now. It was very enlightening.
I don’t see where you might experience incompleteness in pacman, although I might see how you could experience it to be clunky. Do you mind humouring me and explaining this further?
> flexibility
I’m also not sure where dnf is more flexible, although I probably never explored it fully. What do you find about pacman to be inflexible?
> nicer CLI
This I most definitely understand. Even after over a year of using pacman I don’t try to understand why flags are named what they are (looking at you —-Sync), but having memorised them I do quite enjoy pacman.
> I’m fairly sure I created at least some of their spec files from scratch
It could just be my low intellect manifesting itself I suppose, so next time I have a Linux install using rpm I’ll try again.
Thanks for replying to my questions, it’s always interesting to hear from Linux veterans!
Have you ever tried pacman? I’ve used pacman, zypper, dnf, apt, and apk (a few times), and found that (for me) pacman is the best, with its flags, while not making sense to a beginner, are very versatile, e.g. -Syu (sync and update all packages), -Rsn (remove a package and all its dependencies unneeded by other packages and its config files), etc. apk might be a tad faster, but I’ve found pacman to be much faster than dnf, although I can’t remember exactly how fast zypper is since it’s been a few months since I used OpenSUSE. PKGBUILDs are also a great part of the pacman system, and while I’ve not written any yet myself, I can mostly understand what they are doing, and I’m fairly sure I would be able to write one if needed, whereas when I tried to write an RPMspec (? might have gotten that name wrong) I gave up after an hour of trying.
I would suggest Fedora with Gnome as it's a quite polished experience OOTB that shouldn't end up having lots of weird random issues that, for example, my Arch install has (although that's probably due to user error lol).
Signal can't be used at all in China anyway since the verification texts are blocked. I've tried contacting Signal support about this (I live in China and want to use Signal) but as soon as I tell them I love in China and have a Chinese phone number they stop replying :)
I use ImgBB, they are probably stealing your images and not deleting them if you set it to auto delete but for screenshots like this it probably doesn't matter.
It seems like every lift I've been in in China ( been here for 8 years) has this functionality where if you press the same button in rapid succession about 5 to 15 times, it will depress.
That I will agree makes no sense whatsoever but usually that would be installed by default through the dependency list in your package manager. Dunno why it wasn't.
I wouldn't have said this is really fixed, I think this is more of a workaround because KDE doesn't want to lose the names of their software. I think that an approach similar to Gnome's should be taken, where it has Files or Text Editor as the main name but if I search for nautilus or gnome-text-editor (or gedit) it will show the correct result. I do agree that it is better than nothing however.
I can't remember what Eye of Gnome is called in the shell, but it's probably something like Photo Viewer. I agree which you that Mac OS and Windows do this as well, but Windows at least calls it File Explorer, instead of just Explorer, at least on the graphical side. I think that Gnome and maybe also Pantheon do this best, with descriptive names that help new users, with code names that are used in the terminal, I suppose to differentiate between maybe Dolphin and Nautilus if someone has both installed.
Tbh KDE is worse at this because at least when you are using Gnome it won't call Nautilus Nautilus. It will call it Files, unlike on Plasma where Dolphin will be called Dolphin instead of being called Files or File Manager, which means that people who don't know Dolphin is the file manager will just be really confused as to what Dolphin is, especially if they don't already know that this icon always means file manager no matter what 0S you're on. Linus actually had this issue when he couldn't figure out what Kate was because he saw Kate and he thought what's Kate. Whereas on Gnome it would just say Text Editor instead of gedit. If you are using the terminal, you are more likely to know the actual name of the program so that's less bad for me. And on KDE if you are opening graphical applications through the console, you still have to open them through their weird code names. For example, Dolphin which makes no sense whatsoever. Just the same as Nautilus makes no sense whatsoever so that arguement is somewhat disingenuous.
Ah, that might have helped I suppose. I haven’t done any sort of packaging in the past so that might have not helped.
> but all of those were added to pacman within 2 or 3 years of when I stopped daily driving Arch-based distros.
Ah, that would explain why I hadn’t experienced that myself, having only switched to Arch about a year ago now.
> it only examines version constraints for new stuff or updates it's grabbing from the repo. This is part of why 'partial upgrades' aren't supported and all of why your AUR-installed packages are liable to break after `pacman -Syu`, requiring sane AUR wrappers to rebuild your AUR packages after each system upgrade.
Isn’t this, while being slightly inflexible, reasonably logical with Arch being rolling release? I was under the impression that you weren’t supposed to upgrade anything individually, as that upgrade might cause the need for a newer version of some dependency, which could break other packages.
> make it easy to tell when an upgrade or installation might require you to change the 'supplier' of a given package
This has worked fine for me with packages installed from the AUR (through yay), although I can’t think of any examples, but I think it’s only happened once or twice.
> Honestly I should probably try running Arch again for a while to help update what I think of pacman.
I would recommend that you do, as Arch is the best distribution ever! :P
Thanks for sharing that information, as I’ve never heard anyone talking about pacman at that time, so I’d assumed it was always like it is now. It was very enlightening.