4 ms·

How easy is it to administer gentoo servers? Is it on-par with nix/arch or harder?

by flipped 9mo ago

jonfw 9mo ago
In my experience (this was about 5 years ago mind you) it was no more complex than an arch installation, but with a smaller community and less documentation.
yndoendo 9mo ago
I have not directly used Gentoo in years. It was chosen so I could learn, maximize system performance, and have proper AMD64 support before the other distros supported the new CPU specs. Gentoo also had the best documentation in those years. Id Software provided a Doom 3 Linux client when the game was first released. I found Doom 3 ran better on a custom built Gentoo Linux system compared to Windows XP. Are you look at Gentoo to maximize performance with compiling everything with custom build parameters and kernel configuration versus pre-built binaries and a generic kernel loaded with modules? Custom Gentoo just adds more time with having to wait to install software upgrades. It is like having all your Arch packages only being provided by AUR. There is also a chance the build will fail and the parameters might need to be changed. Majority of the time everything compiles without issue once the build parameters are figured out. It was rare when something did not.
- anthk 9mo ago
  Tecnically with just a kernel optimized for your CPU, realtime patches, NTSync and a custom MESA build (with -O2 and -march set to your CPU) would give a good boost instead of trying to recompile verything.
speed_spread 9mo ago
General administration is similar to Arch or any other regular distro. Package updates necessarily take longer because of recompiling but that's just CPU time. There are precompiled versions of big popular binaries (open office, Firefox, etc) that allow you to save a lot of time if you want. Where you lose time is in trying to optimize your system and packages using the multiple switches that Gentoo provides. If you're the OCD twiddler type, Gentoo can be both extremely satisfying and major time sink.
- flipped 9mo ago
  I don't understand the time sink. Isn't spending time knowing intricate details about your system a good thing? You know better than most if you've gone that deep.
  - speed_spread 9mo ago
    It's good for learning for sure but It's very easy to go too deep and spend time on pointless optimizations and customization instead of doing actual work.
- techcode 9mo ago
  When you say "There are precompiled versions of big popular binaries" - were you thinking of "firefox-bin" and such? I think that for some years already - Gentoo has been providing binaries for "normal" packages - as long as your config/use-flags match (and if you turned on the option/flag to use binary packages). And of course places with more than just a few Gentoo boxes were usually already running their own BINHOST setups long time ago.
M95D 9mo ago
TLDR: Installation is a pain, initial configuration is a pain and there's always something more to tweak, update is a lesser pain, but still a pain. But it's fun, BDSM-style... Installation is done by booting a liveCD, manually partitioning your storage, unpacking a Gentoo STAGE3 archive, chrooting in it, doing basic configuration such as network, timezone, portage (package manager) base profile and servers, etc., compiling and installing a kernel and then rebooting into the new system. Then you get to play with /etc/portage/make.conf which is the root configuration of the package manager. You get to set CPU instruction sets (CPU_FLAGS), gcc CFLAGS flags, MAKE flags, video card targets, acceptable package licenses, global USE flags (those are simplified ./configure arguments that usually apply to several packages), which Apache modules get built, which qemu targets get built, etc. These are all env vars that portage (the package manager) uses to build packages for your system. The more you use Gentoo, the more features of make.conf you discover. Never ending fun. Then, you start installing packages and updates (same procedure): 1) You start the update by reviewing USE flags for each added/updated package - several screens of dense text. For example, PHP has these USE flags: https://packages.gentoo.org/packages/dev-lang/php https://packages.gentoo.org/packages/dev-lang/php - mouse hover to see what they do. You get to play with them in /etc/portage/package.use and there's no end to tweaking them. If you have any form of OCD, stay away from Gentoo or this will be your poison forever! 2) Then the compilation begins and that takes hours or days depending on what you install and uses a lot of CPU and either storage I/O or memory (if you have lots of memory, you can compile in a tmpfs a lot faster). I'm not sure it is OK to compile the updates on a live server, especially during busy hours, but Gentoo has alternatives, including binary packages (recently added, but must match your USE flags with theirs), building packages remotely on another system (distcc), even on a different arch (crossdev). You could run an ARM server and build packages for it on a x86 workstation. I didn't use "steve", so I can't tell you what wonderful things that tool can do, yet. 3) Depending on architecture, some less used packages may fail to compile. You get to manually debug that and submit bug reports. You can also add patches to /etc/portage/patches/<package> that will automatically be applied when the package is built, and that includes the kernel. I recommend you to run emerge with --keep-going to have the package manager continue after an error with the remaining packages. 4) When each package is done compiling, it's installed automatically. There are no automatic reboots or anything. The files are replaced live, both executables and libraries. Running services continue to use old files from memory until you restart them or reboot manually - they will appear red/yellow in htop until you do. There were a few times, very very few, when I had crashes in new packages that were succesfuly built. It only happened on armv7, which is a practically abandoned platform everywhere. In those cases you can revert to the old ones and mask the bugged version to prevent it from being updated to next time. 5) Last step is to review the config changes. dispatch-conf will present a diff of all proposed changes to .ini and .cfg files for all updated packages. You get to review, accept, reject the changes or manually edit the files. That's all. Simple. :)

How easy is it to administer gentoo servers? Is it on-par with nix/arch or harder?

by flipped 9mo ago

How easy is it to administer gentoo servers? Is it on-par with nix/arch or harder?

jonfw 9mo ago

In my experience (this was about 5 years ago mind you) it was no more complex than an arch installation, but with a smaller community and less documentation.

yndoendo 9mo ago

I have not directly used Gentoo in years. It was chosen so I could learn, maximize system performance, and have proper AMD64 support before the other distros supported the new CPU specs. Gentoo also had the best documentation in those years. Id Software provided a Doom 3 Linux client when the game was first released. I found Doom 3 ran better on a custom built Gentoo Linux system compared to Windows XP. Are you look at Gentoo to maximize performance with compiling everything with custom build parameters and kernel configuration versus pre-built binaries and a generic kernel loaded with modules? Custom Gentoo just adds more time with having to wait to install software upgrades. It is like having all your Arch packages only being provided by AUR. There is also a chance the build will fail and the parameters might need to be changed. Majority of the time everything compiles without issue once the build parameters are figured out. It was rare when something did not.

anthk 9mo ago
Tecnically with just a kernel optimized for your CPU, realtime patches, NTSync and a custom MESA build (with -O2 and -march set to your CPU) would give a good boost instead of trying to recompile verything.

speed_spread 9mo ago

General administration is similar to Arch or any other regular distro. Package updates necessarily take longer because of recompiling but that's just CPU time. There are precompiled versions of big popular binaries (open office, Firefox, etc) that allow you to save a lot of time if you want. Where you lose time is in trying to optimize your system and packages using the multiple switches that Gentoo provides. If you're the OCD twiddler type, Gentoo can be both extremely satisfying and major time sink.

flipped 9mo ago
I don't understand the time sink. Isn't spending time knowing intricate details about your system a good thing? You know better than most if you've gone that deep.
- speed_spread 9mo ago
  It's good for learning for sure but It's very easy to go too deep and spend time on pointless optimizations and customization instead of doing actual work.
techcode 9mo ago
When you say "There are precompiled versions of big popular binaries" - were you thinking of "firefox-bin" and such? I think that for some years already - Gentoo has been providing binaries for "normal" packages - as long as your config/use-flags match (and if you turned on the option/flag to use binary packages). And of course places with more than just a few Gentoo boxes were usually already running their own BINHOST setups long time ago.

M95D 9mo ago

TLDR: Installation is a pain, initial configuration is a pain and there's always something more to tweak, update is a lesser pain, but still a pain. But it's fun, BDSM-style... Installation is done by booting a liveCD, manually partitioning your storage, unpacking a Gentoo STAGE3 archive, chrooting in it, doing basic configuration such as network, timezone, portage (package manager) base profile and servers, etc., compiling and installing a kernel and then rebooting into the new system. Then you get to play with /etc/portage/make.conf which is the root configuration of the package manager. You get to set CPU instruction sets (CPU_FLAGS), gcc CFLAGS flags, MAKE flags, video card targets, acceptable package licenses, global USE flags (those are simplified ./configure arguments that usually apply to several packages), which Apache modules get built, which qemu targets get built, etc. These are all env vars that portage (the package manager) uses to build packages for your system. The more you use Gentoo, the more features of make.conf you discover. Never ending fun. Then, you start installing packages and updates (same procedure): 1) You start the update by reviewing USE flags for each added/updated package - several screens of dense text. For example, PHP has these USE flags: https://packages.gentoo.org/packages/dev-lang/php https://packages.gentoo.org/packages/dev-lang/php - mouse hover to see what they do. You get to play with them in /etc/portage/package.use and there's no end to tweaking them. If you have any form of OCD, stay away from Gentoo or this will be your poison forever! 2) Then the compilation begins and that takes hours or days depending on what you install and uses a lot of CPU and either storage I/O or memory (if you have lots of memory, you can compile in a tmpfs a lot faster). I'm not sure it is OK to compile the updates on a live server, especially during busy hours, but Gentoo has alternatives, including binary packages (recently added, but must match your USE flags with theirs), building packages remotely on another system (distcc), even on a different arch (crossdev). You could run an ARM server and build packages for it on a x86 workstation. I didn't use "steve", so I can't tell you what wonderful things that tool can do, yet. 3) Depending on architecture, some less used packages may fail to compile. You get to manually debug that and submit bug reports. You can also add patches to /etc/portage/patches/<package> that will automatically be applied when the package is built, and that includes the kernel. I recommend you to run emerge with --keep-going to have the package manager continue after an error with the remaining packages. 4) When each package is done compiling, it's installed automatically. There are no automatic reboots or anything. The files are replaced live, both executables and libraries. Running services continue to use old files from memory until you restart them or reboot manually - they will appear red/yellow in htop until you do. There were a few times, very very few, when I had crashes in new packages that were succesfuly built. It only happened on armv7, which is a practically abandoned platform everywhere. In those cases you can revert to the old ones and mask the bugged version to prevent it from being updated to next time. 5) Last step is to review the config changes. dispatch-conf will present a diff of all proposed changes to .ini and .cfg files for all updated packages. You get to review, accept, reject the changes or manually edit the files. That's all. Simple. :)