• redjard@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    4
    ·
    6 hours ago

    It’s very controllable.
    You start out with control over everything, but that also means you have to do everything and know everything. Then you can hand back that control by automating on your terms, and gentoo provides a lot of tools for that.
    But you always have that confidence that when something is weird, you can go back, take the control, see what happens, redo the automation. Or keep it manual.
    Gentoo won’t ever touch your config files (It proposes changes you approve), and if something happens you didn’t want you can always trace it back to your own mistakes.

    I’ve never gotten the same feeling of being in control with any other distro. There is always that time it fucks up my ssh config, or breaks due to some oddity I chase back down to a decision by some maintainers.

    It’s stable only based on your decisions and skill. It will make you a lot better at using linux. But also if you don’t have the time, or the will to keep automating and scripting and learning new things, then you won’t be able to use it and you’ll have a really bad time.

    It does bring automation but only up to a still very manual level. You can’t go “fuck this shit mode” and turn it into opensuse with a config option. For example you can do your own kernel, or add a few changes to a default kernel and use it without init system, or follow a tutorial to pull default binaries and just have what most other distros have, but you won’t find an installer to check that as an option, you are forced to still understand what components you are putting in where, connecting how, automating with what commands and tools.

    Also protip if you do your own kernel start with the binkernel config not the default the fresh kernel repo starts out on. You’ll never find all the footguns autoconfigured to make your system weirdly choppy. And recompiling stuff you forgot in a module then loading that into the old kernel usually works but can crash your system.
    Change all the options, be my guest, but at least start from a working state so you have a chance of knowing what you fucked up and which flag you didn’t understand.

      • redjard@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        1
        ·
        4 hours ago

        If it’s something outside packages, like say the filesystem, it should be similar to fix to what you did in the initial setup. You already have to know how to partition your system, so at worst you’d have to relearn that if you installed a very long time ago.

        If you mean break some regular file, you can reinstall the package it belongs to or everything if you have the time.

        Gentoo has a proper package manager (portage), so most things you can rebuild. If you fuck some config, you can probably rebuild and get the default files back.

        If you break portage config somehow, you’ll probably have to start from scratch in essence. Though there too once you start to redo your setup you’ll likely run into the same issue and have to figure it out.


        Because all distro-problems will be caused by you, the only escape is to understand the issue.

        Any “rebuild” would just be you copying in all your old stuff and repeating all the settings, you could just as easily revert your settings till it works again and pinpoint what is causing it.


        I have no specific automation for setting up a system from scratch (did it 2 more times on different systems but manual copy was good enough), but automating it wouldn’t be hard. Just dump all the commands I run during setup into a script, and add a few scp to pull in my own stuff (or I could even put it in an official gentoo repo and pull it in with one portage config file).
        But why would I? I don’t regularly set up copies of my system, and this is the same as just looking at my system. It can’t break itself past what those config files and setup commands do. The system won’t diverge from your commands so there is no need to force reset it to your commands.

        I suppose the fact I comment my package set (the config file that contains all the packages I have installed) with install reasons is the same as starting from scratch. I simply reevaluated all my installed packages when I wrote it.


        In a way I did once “fuck my system”. I switched to wayland (end of '22, before it was cool) and wanted to remove all X flags from all packages (a global flag unset). So I endlessly figured out what packages really needed that flag, added exceptions, and after months still ran into occasional issues, instability, or the weirdest dependencies. Whenever I had any problem I started considering if it was somehow caused by that.
        I knew it was stupid, I knew plenty issues it had caused, everyone was telling me it was in fact stupid. Basically I was test-running 200 packages at once under settings noone had ever intended. So my “rebuild” was just to remove that -x from my make.conf and rebuild all affected packages. (I may have even rebuilt the entire system just in case).

        The only way I see you actually starting from scratch is if you

        • Did something stupid from lack of knowledge or out of fun
        • forgot about it
        • couldn’t trace it back nor anyone else could figure it out
        • it’s in something not logged (which I’m fairly certain doesn’t exist unless you explicitly turn it off)

        The most “I’m fucked, rebuild everything” moment in my memory was me doing an update after half a year when kde6 was released. What happened was I had manually specified a bunch of kde system components (instead of stripping down the kde meta package via flags) and some were removed in kde6, so portage tried building a kde6 system with kde5 and failed in enough ways to generate like 5k lines of error.
        I was unable to read that error, and while someone in the gentoo irc was able to, I would have had to “rebuild” my package selection otherwise.
        Meaning leave the system running as is, remove stuff from the installed packages config until the update finds a valid config, add back stuff while it keeps working, and be left with in this case the packages that were removed, where I would have then checked them and seen they were removed in kde6.
        This would have essentially been me “rebuilding my installed packages”, so “rebuilding the system”, but while still using that same system and with the final “apply” being a regular update using my fixed config. No need to throw everything away in the mean time, it may destroy my valid package state but the system doesn’t mind (it just stays outdated). I could have even updated only specific important packages and delayed the package rebuild for more months.

        The main flaws here are me (adding stupid dependencies) and portage producing unreadable errors (to be fair there are so many ways to fuck up package configs it’s gotta be really hard to make every case readable and traceable to some sane cause).

        Without fixing it I ofc could not have gone to a different system and copied over my stuff (automated or not) since that would also have refused to build all my selected packages.