Screenshot of QEMU VM showing an ASCII Gentoo Logo + system info

I followed Mental Outlaw’s 2019 guide and followed the official handbook to get up-to-date instructions and tailored instructions for my system, the process took about 4 hours however I did go out for a nice walk while my kernel was compiling. Overall I enjoyed the process and learnt a lot about the Linux kernel while doing it.

I’m planning on installing it to my hardware soon, this was to get a feel for the process in a non-destructive way.

  • @H2207@lemmy.worldOP
    link
    fedilink
    810 months ago

    How exactly? On idle Gentoo uses almost no resouces comapred to Windows 11 for example. If you’re on about needing to compile every package, then think how often is someone actually installing a new package and for how long is the processor working to do that? Also on a binary distro, then large servers are used to compile every last package, no matter how big or small, in that distro’s repos, then more machines are used to provide those binaries to the users.

    The whole pipeline for Gentoo is much simpler, the end user’s system is a lot simpler and uses far less resources.

      • @Llewellyn@lemm.ee
        link
        fedilink
        610 months ago

        You get to actually know what code ends up in your binaries

        Do you, though? Do you check e-signatures and do you look at the every row of the code?

          • @Pantherina@feddit.de
            link
            fedilink
            4
            edit-2
            10 months ago

            This is true. In theory its the best way, but ita crazy to think compiling Firefox can take like multiple hours of full computing power. And I like to update my software a lot.

            Lets do a small comparison:

            Linux power efficiency tier list

            Desktops / WMs

            1. WMs with Wayland?
            2. WMs with X11?
            3. LXDE, LXQt, Xfce, Cinnamon
            4. KDE, Budgie, Mate
            5. GNOME ?

            Packaging

            1. Native
            2. Snap (less runtimes)
            3. Flatpak (shared resources), Containers
            4. Appimage (everything duplicated

            Distro type

            1. Traditional binary native packages, ESR
            2. Traditional binary native packages
            3. A/B root (traditional packaging but with one seperate system as backup)
            4. OSTree (diffs downloaded but whole system built locally)
            5. Own repos for everything, small distro
            6. Compiled from source

            Behavior

            • adblock at DNS level
            • low brightness, light theme on LCD helps
            • energy saving CPU, disabled cores, throttled
            • laptop instead of desktop, no huge 4K screens
            • dont Game lol
            • dont stream stuff lol
            • digital minimalism lol

            So uhm I guess I should switch to Debian 12, update once a week and go out on a hike or something.

      • @constantokra
        link
        310 months ago

        It’s not duplicated work, because it’s optimized for your system and usage. If it was actually duplicated it wouldn’t be any better than Debian plus waiting 20 minutes every time you use apt.

        • @Llewellyn@lemm.ee
          link
          fedilink
          2
          edit-2
          10 months ago

          Is your system unique, though? There’s only so much of a processor architectures. And rest of differences seem to be just a fluff to me.

          • @Kangie@lemmy.srcfiles.zip
            link
            fedilink
            210 months ago

            I regularly compile packages with tweaked options for various purposes. Maybe I want a stripped down cURL for container health checks. Maybe I want cURL with HTTP/3 for development against Quic server. Maybe I want to build only the QT6 frontend for freeciv because I don’t need the dependencies that come with GTK.

            These are all real examples, from packages that I maintain and use cases that I’ve seen or are my own.

            Portage makes doing all of this trivial through the implementation of USE flags; it’s certainly not fluff.

            Gentoo still ships a sane set of defaults for when users don’t want / need to change these things, but having the option is fantastic.

            • @Pantherina@feddit.de
              link
              fedilink
              110 months ago

              Interesting, in my experience apps use either GTK or KDE and often KDE just uses GTK? I dont know how this works on GNOME, I guess it forces GTK somehow anyways.

              Not technical enough to understand the rest haha.

              • @Kangie@lemmy.srcfiles.zip
                link
                fedilink
                2
                edit-2
                10 months ago

                Oh, I missed this response, sorry!

                The example in question there is freeciv, which supports each of those frontends. Typically you’re going to pick the one that your DE uses, but because I maintain the package I had to go through and test it all when I updated it and converted it to the meson build recently. :)

                https://github.com/gentoo/gentoo/blob/master/games-strategy/freeciv/freeciv-3.1.0_beta2.ebuild#L106-L140 should give you some indication of the complexity that I had to handle here. Not every app supports every toolkit, and this supports more than most!

                Edit:

                All that complexity means that if I set, for example, USE='sdl qt6' the build will produce a client for each of those toolkits. Most users don’t have to worry because at least one will be inherited from their profile!

          • @constantokra
            link
            110 months ago

            It’s fluff these fays if you’re talking about optimizing for speed… unless you’re using very specific hardware for a specific purpose. But if you want to compile in support for something you want to be able to do that most people wouldn’t need, then yeah it’s a real advantage.

            • @Pantherina@feddit.de
              link
              fedilink
              110 months ago

              I am not sure anymore. There are two Appimages of Gimp at minimum. All are unofficial, but this one is incredibly fast.

              On my regular Laptop the Lava render is TWICE as fast as the other versions of GIMP, Flatpak or even from the arch repos.

              I heard this is because it uses Arch libraries instead of being compiled to run on this system. Not sure if this is true, but its crazy how fast it is. Poorly not maintained anymore, but now I wonder how fast a system could be if every app was compiled like that.

              • @constantokra
                link
                110 months ago

                That’s interesting. I’ll have to check it out.