Adding swap /hibernation after install

Those are your words. I think he said it’s convoluted. I would agree. It’s hard to follow.

My pesonal opinion is that it’s GENERALLY done well. I don’t usually have many problems following it, I generally understand what it’s saying to do. But I do admit that it would be nice if they would sometimes explain things like they were talking to a little kid, because SOMETIMES I like to know the WHY of what I’m doing, and not just what it does.

I agree it’s extremely thorough on the technical side. But it’s like it never finishes a sentence and expects you to go read another sentence in order to understand what the first sentence was talking about. Everything leads to another link or term that has link instead of just saying flat out you need to install this and then enable this and start that? If it’s something you don’t know anything about well it really doesn’t help you get to the end result. I get by following some of it but it’s not something i want to spend my time doing reading page after page in order to try to understand what they are saying. For me it’s convoluted. There are always different ways of doing things and i try to do what is the simplest way.
Anyway …what matters is we learn something whether it’s using the wiki or not doesn’t matter. :slightly_smiling_face:

1 Like

Remember EndOS is simply an installer for an Arch based system, which is rolling and bleeding edge. You are really running Arch with a small handful of helper packages.

Given time Arch will eventually break in some form or another, if you don’t take the time to learn and understand how your specific system works then how will you fix it? Will you take the time to learn for yourself or just be a help vampire and ask others to do all the heavy lifting for you?

It is time consuming, and sometimes frustrating, nobody it presenting it any differently. When I first started reading the Arch Wiki I had to supplement it with lots of other sources, like Wikipedia, to fill in things I didn’t know. It took time.

The key is perserverance, not intrinsic knowledge, which is the key to using Arch.

Many people say Arch is too hard … but the reality is they are too lazy.

What this is telling me since this isn’t the first time I’ve helped with hibernation, and it’s come up several times now, I may have to do wiki write up to help folks.

1 Like

That is my biggest problem also. I’ve tweaked my system in so many ways after hours and hours of research and now I can’t remember a thing I did on it. Should I need to reinstall I’d need to do the whole research again. That’s where one-liners and copy-paste-able answers come in handy. For goldfish memory span people like me :slight_smile:
Also having to spin up a VM and test stuff before you enable some simple feature of your OS is counterproductive. It might be a fun thing to do for tinkerers with a lot of time on their hands, but not so much for tinkerers with no time on their hands :slight_smile:
At the end of the day the OS is not a hobby for me, but a production tool firstly and only secondly a hobby :stuck_out_tongue:

3 Likes

Take notes. Every time you change something of note take 2 minutes to record what you did and why you did it. Include url links you used in your research. I use Cherrytree for this.

Nobody remembers all the changes they have done. Welcome to the club, population everyone.

Most people have poor memories, mine is shocking, which is why understanding concepts is even more important. Assuming you want to avoid self inflicted silly system breakages.

If your machine is a production system then using Arch is probably not the best idea in the first place. Given the bleeding edge nature of Arch it will break eventually.

Also, it seems pretty irresponsible to not care or understand how a production system works or is configured.

Quite the opposite actually.

Before committing a change to your bare metal production system you test it in a VM. Particularly for those who don’t have much clue what they are doing. Any mistakes made are done there and you don’t damage or brick your actual system.

Cleaning up a borked system is more time consuming than testing first in a VM. Bugger it up there restore a VM snapshot and try again, until you get it right.

Who has time on their hands? You genuinely think the helpful people help vampires exploit have mountains of spare time?

Bottom line is learning and taking notes will SAVE you time in the long run, even though it is slightly inconvenient in the short term.

Wait, what? Would you say Endeavour is more or less stable than Arch?

What makes you say Arch will break eventually? Or are you just saying that because everything breaks effectually? It’s by miles been the most stable distro I’ve ever used, other than maybe Windows XP

Your EndeavourOS system IS Arch, just a different installation method … Calamares instead of the Arch Way and some different branding.

Once your system installation is complete you are running Arch packages installed and updated from the Arch repos, with a small handful of EOS quality of life helper packages in a separate EOS repo.

Its bleeding edge nature.

By break I don’t mean a bricked system, but issues after updates that negatively change or break system behavior due to bugs / regressions and need to be handled. Particularly using certain or older hardware with new kernels and drivers.

Just look at all the issues with linux 5.10 for instance. Some systems using F2FS had their file systems corrupted, a lot of intel wifi systems lost their wireless connectivity, btrfs had a 2000% (:exploding_head:) performance regression, a lot of amd laptops couldn’t boot due to an amdgpu driver regression, older nvidia cards stopped working until loqs provided a patch for the 390 legacy driver … etc.

And that is only the latest kernel release. There were also issues with kernel 5.9, particularly with nvidia, for instance.

These are regressions that get experienced first in Arch (usually) and reported upstream to be patched. This is why it is useful to read the Arch bugs page regularly. Some are caught in Arch Testing, some are not and make it to Arch Stable.

Arch is in a constant state of change, with many hundreds of packages updated monthly, law of average says you’ll experience issues with a package bug / regression at some stage.

Me too, but that may have something to do with my config being very stable and I run an AMD system. My setup is dialled in and perfect for me so I rarely tweak it much.

@otherbarry I’m not constantly tweaking my system either. Exactly because it is a production system.

Also, it is suitably stable enough for me, thank you very much. I was not complaining about its stability or anything about it, really.

On another note, I think this community manages to deal satisfactory with help vampires. I was not condoning help vampirism, merely saying that one-liners have their place in the grand scheme of things and are not necessarily a bad thing.

If I wanted to educate myself in every minutiae of the system I would’ve stuck to the Arch forum and read the fine manual all day long. When there is something I’m interested in I delve deep, or maybe just try to get the basic gist of things based on each case.

I have a working system and am happy about its stability and functionality. I take your reply as a well-intended (although a bit patronizing) nudge to adopt what you think is the best-practice in handling an Arch system. My workflow is not compatible with yours, so I’ll stick to what works for me. You’ll rarely see me asking for support, because most of the times I find the one-liners I seek by simply google-ing, as others have already answered it for other people looking for quick answers. I get instant solution for my queries and move on to do productive stuff. I stop by to answer questions as often as I can so I think things stay balanced and everyone benefits.

3 Likes