Not my experience at all. It's the one distro that stopped my distro hopping.
Besides, something goes fucky or (more likely in my case) I fuck something up, I can just roll back the changes with a single command and reboot. It's awesome. I've also used to just test things out, removed all KDE stuff, installed GNOME, tested it out for a while and then did a snapper rollback. The system was just like I hadn't changed anything. It's really cool, more distros need this feature.
Wild, every time I've tried using it on both metal and as a VM it has self destructed rather quickly. The last few times, just doing an update after the initial install broke the system for various reasons... but everyone has different hardware and software mixes I suppose
Just got a new laptop and put an arch flavor on it, keep thinking of going back to Tumbleweed. I've kept on Arch derivatives cause of the AUR, but I haven't actually touched the AUR in a while, and a couple of the things I used the AUR for are now being published as flatpaks by the creators because of the Steam Deck.
God, nearly every time I Google a problem I have, it's NVIDIA.
The rest is that I want to share my steam library from my windows-installation on a NTFS drive
Just get a CRT with speakers instead, and then that's basically the same thing, with the bonus that it wiggles and your eardrums split open when you play anything at a volume higher than 10
Don't bother with the tty. If experienced chess players can play entire games in their heads, why can't you just do the same to use a computer? Just type away and use your superior power usering skills to visualize the output in your head.
Nvidia Arch user here, are you just forgetting to rebuild your kernel modules after a kernel or nvidia driver update?
You can just add a pacman hook that triggers mkinitcpio -P after the linux or nvidia packages are updated. I've never had a no-GUI situation from a stray update... maybe one or two that were my own doing when trying to set up UKI's though.
I just followed the note that's mentioned on the top of your link and installed the Nvidia driver as dkms package. I originally did that because of trouble with a new driver version and temporary downgrading is much smoother with dkms.
Also never had issues with the DE starting properly after upgrade since then.
I'm usually using nvidia-beta drivers from AUR because they're newer, so I just added the hook as an insurance policy.
The DKMS drivers are probably the safer option because they'll handle rebuilding the kernel modules. Even though (like EddyBot said) the kernel and nvidia packages are supposed to get updated together, sometimes you can spam pacman -Syu at the wrong time and only one package is updated and things go wonky...
There's a difference between "can" and "want." For example, OP might have been planning to watch his home vids with your mom, but couldn't due to a rolling update.
What did you edited ? Arch user here, never had this kind of issue. Also if you managed to install Arch, you should be able to fix it(maybe you switched from terminals, try ctrl+alt+1-9)
Yeah I dealt with that for a long while. Always used lynx or similar to go download the latest Linux driver from nvidias website, then manually install it lol. What a pain in the ass.
You were just lucky. For some of us ut was just about having the wrong hardware at the wrong time.
Not complaining, I knew the risks going in and still love my distro, but arch updates totally can brick a PC with no PEBCAK involved. It does happen. :3
@Titou@Nisaea Well, in my case it once broke due to a conflict between pahole and nvidia that caused errors. Games would crash every now and then. I was going crazy until I found that the update broke nvidia :}
@Titou proprietary drivers, dkms version.
Official repos.
Both my friend and I experienced this, a few minutes later pahole was reverted to previous version on the repos and the update was delayed until fixes were made.
I migrated from nvidia to amd last summer and no issues since then ( a few crashes in Minecraft, its the only game capable of crashing the GPU, dont know why or how ).
I have not experienced it but half of the arch users on reddit seem to have experienced it. Also it's not a continuous problem but rather a problem with a certain arch and grub version. However the fact it happened once (to many people) means it can happen a second time
Arch breaking grub has happened to me twice. Second time I couldn't even recover the install.
You learn a lot of good practices by using arch, eg a separate home partitjon, git repositories for your config files, maintaining a clean package tree etc. Installing Arch is also really useful for noobs like me to learn some Linux basics.
Pacman used to be really bad at removing unneeded dependencies. I think pretty much every package manager has this facility now. For instant apt auto remove.
Suppose you installed gnome to try it out, gnome installs like 1000000 packages. The thing about some of those dependencies is that they're really useful. It's not uncommon for another package you have installed to use it as an optional dependency. In that case it doesn't get flagged for autoremoval when you uninstall gnome.
When you apply this logic a couple layers deep they start to compound.
Also libraries and random python scripts tend to just exist forever in your system long after you used it lol.
I started developing the habit of checking what dependencies are being installed and to uninstall immediately when I realize I don't need it.
This logic applies to language specific managers like cargo or pip too.
They all have really good tooling to figure out leaves, orphaned nodes etc. I just didn't start using those until I got into the arch hype.
I'm quite excited but also mildly worried about Arch. I am currently on EndeavourOS, so I'm used to day-to-day usage of an Arch-based system, but I do worry about not following some best practices that screw me over in the long run during the install or forgetting some crucial security things. I do believe 95% of what I could mess up is going to be covered in the install guide, but who knows what I'll overlook. And I know Archinstall exists, but I might as well stay on EOS if I was gonna use that, as I primarily intend this to be a learning opportunity. We'll see how things go!
I agree. I think that's why nix-os is getting so popular these days.
I love the idea of declarative system builds even beyond just reproducability. The idea that you can essentially make your own distro without much difficulty is really cool.
Plus all the benefits of roll backs, light backups, etc.
Plus if you can dig deep enough you can craft a system that never breaks by pinning certain versions.
One of these days I want to check it out. As well as LFS. Oh but for the want of time.
About NixOS specifically, I actually made a post on !linux and overall the feedback seemed to be that Nix is a mixed bag, and that unless you want to duplicate your system a bunch of times, it's probably smarter to stick to Arch, and a few people said I should use immutable Fedora for some reason despite that not being the question.
A grub breaking thingy happened to me too.
I was saved by having multiboot, with every OS having their own GRUB version installed. (just selected one using the motherboard's interface)
The problem occurred when, after pacman -Syu, I read notes in the output, one of which hinted I would want to update GRUB and went - "Sure, I'll try the new GRUB update" and ran GRUB update.
When it didn't startup after a restart, I just used the debian's GRUB to login to the OS in question, downgraded GRUB, reinstalled GRUB and then ran pacman -Syu again.
I feel like mine wasn't the problem instance that goes on around the web, mostly because:
None of the mentioned fixes worked in my case.
I feel like people won't go out of their way to update GRUB most of the time.
As long as I can get into the terminal I can fix the GUI. What really sucks is when it something that runs in the DM init sequence was using Python but a Python upgrade changed the import path and no it keeps restarting and I need to boot from a USB to disable that service so I can log into something and properly fix it.
Pass something stupid via your bootloader so it aborts boot and dumps you in an initrd busybox shell. No usb required.
This was my poor man's boot environments when I was using zfs on root. I had a pacman hook to snapshot before package transactions, then if it became unbootable I'd interrupt the following boot attempt, edit my grub command line with something wrong so I'd get dumped in the busybox shell, import my zfs pool and roll back before finally rebooting again.
That's nice. I've later googled it and found out that I could have added 3 to the end of the grub command to make it boot in runlevel 3 which does not trigger the GUI, but I guess your way could also bypass boot issues that prevent even non-gui boot.
I also see that there is runlevel 1, which is kind of an emergency mode, so maybe that would be the best thing to use?
I usually just do a full reinstall, it's faster, requires less storage, and it's more futureproof. I have my home folder at a different partition, so the files aren't a problem. Archinstall made this a lot easier, and i love it.
After being with my current distro and install for several years I've accumulated so many small changes and tweaks into the system that it'd take ages for me to get back to where I am with a fresh install. Snapper snapshots for life