diff options
author | Jack Sangdahl <[email protected]> | 2024-10-01 00:24:59 -0600 |
---|---|---|
committer | Jack Sangdahl <[email protected]> | 2024-10-01 00:24:59 -0600 |
commit | d2ad4ebc1dfb365eed85f42c032ea4a743698c42 (patch) | |
tree | 463d6fd1eb364b642b707d467cde47f1636b3f28 | |
parent | b86b4a5ad0e4b0497b9377a6ec2eebeea0ff4d7b (diff) | |
download | site-d2ad4ebc1dfb365eed85f42c032ea4a743698c42.tar.gz site-d2ad4ebc1dfb365eed85f42c032ea4a743698c42.zip |
Update Gentoo system notes
Signed-off-by: Jack Sangdahl <[email protected]>
-rw-r--r-- | gentoo.html | 203 |
1 files changed, 94 insertions, 109 deletions
diff --git a/gentoo.html b/gentoo.html index 5ef3d53..d170810 100644 --- a/gentoo.html +++ b/gentoo.html @@ -3,10 +3,24 @@ <meta charset="UTF-8" /> <title>Gentoo</title> <link rel="stylesheet" href="style.css" /> - <link rel="apple-touch-icon" sizes="180x180" href="data/favicon/apple-touch-icon.png"> - <link rel="icon" type="image/png" sizes="32x32" href="data/favicon/favicon-32x32.png"> - <link rel="icon" type="image/png" sizes="16x16" href="data/favicon/favicon-16x16.png"> - <link rel="manifest" href="data/favicon/site.webmanifest"> + <link + rel="apple-touch-icon" + sizes="180x180" + href="data/favicon/apple-touch-icon.png" + /> + <link + rel="icon" + type="image/png" + sizes="32x32" + href="data/favicon/favicon-32x32.png" + /> + <link + rel="icon" + type="image/png" + sizes="16x16" + href="data/favicon/favicon-16x16.png" + /> + <link rel="manifest" href="data/favicon/site.webmanifest" /> <style> code { color: #505050; @@ -32,12 +46,10 @@ tinkering project for 150USD. While this is not the most powerful device, it is suitable for just about anything I encounter on a daily basis and is used as my primary system. My intentions for this system are reliability and - speed most importantly. Follows is a tidy system with minimal kernel parameters - set, fine-tuned USE flags, and a system I'm rather familiar with. Much of my - configuration can be found - <a href="https://git.pngu.org/dots" target="_blank" - >here</a - >. <br /><br /> + speed most importantly. Follows is a tidy system with minimal kernel + parameters set, fine-tuned USE flags, and a system I'm rather familiar with. + Much of my configuration can be found + <a href="https://git.pngu.org/dots" target="_blank">here</a>. <br /><br /> <img src="data/gentoo/laptop.jpg" alt="laptop image" /> <img src="data/gentoo/laptop_open.jpg" alt="laptop open image" /> @@ -92,7 +104,7 @@ as it lasted about 15 minutes after being charged and would lose power randomly. A suitable <a - href="https://www.amazon.com/Replacement-Battery-MacBook-7200mAh-Laptop/dp/B07SDBKDDK" + href="https://www.amazon.com/RayHom-MacBook-Air-A1405-Battery/dp/B0837L72TR" target="_blank" >replacement</a > @@ -107,25 +119,25 @@ </div> <div id="kernel"> <h3>Kernel</h3> - After spending quite some time narrowing down kernel enabled, I have a - 7.8MB kernel image with ~4000 parameters set. Note, this configuration is - very hardware and user specific. I opted for zero modules since I don't - need any out-of-tree hardware support. I also did not configure anything - very drastically in either direction, like extreme security, sacraficing - usability, etc. I chose to use + After spending quite some time narrowing down kernel parameters enabled, I + have a 7.8MB kernel image with ~4000 parameters set. Note, this + configuration is very hardware and user specific. I opted for zero modules + since I don't need any out-of-tree hardware support. I also did not + configure anything very drastically in either direction, like extreme + security, sacraficing usability, etc. I chose to use <a href="https://packages.gentoo.org/packages/sys-kernel/gentoo-sources" target="_blank" >gentoo-sources</a > to provide kernel source as it contains some handy patches and is easy to - obtain via emerge. A base 6.10 kernel builds locally (with 4 cores!) in - approximately 17 minutes, which is not too much of a pain when - troubleshooting on bare metal. I also chose to omit an initramfs, which - means CPU microcode can/should be built directly into the kernel. This can - be achieved by first installing <code>sys-firmware/intel-microcode</code>. + obtain via <code>emerge</code>. A base 6.10 kernel builds locally (with 4 + cores!) in approximately 17 minutes, which is not too troublesome when + working on bare metal. I also chose to omit an initramfs, which means CPU + microcode can/should be built directly into the kernel. This can be + achieved by first installing <code>sys-firmware/intel-microcode</code>. This is also a good time to add microcode signature to - <code>/etc/portage/make.conf</code> + <code>/etc/portage/make.conf</code>: <pre> $ iucode_tool -S -l /lib/firmware/intel-ucode/* iucode_tool: system has processor(s) with <b>signature 0x000306a9</b> @@ -136,7 +148,7 @@ selected microcodes: </pre> CPU's signature is found in bundle 1, so the filename to use is <code>/lib/firmware/intel-ucode/06-3a-09</code>. Ensure the following - kernel options are set approximately, where the argument passed to + kernel options are set appropriately, where the argument passed to <code>CONFIG_EXTRA_FIRMWARE</code> is the filename of our microcode <pre> CONFIG_MICROCODE=y @@ -144,20 +156,22 @@ CONFIG_FW_LOADER=y CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" </pre> - Check dmesg for microcode output to ensure all was successful. Specific - configuation for this machine can be found at + Check <code>dmesg</code> for microcode output to ensure all was + successful. Specific configuration for this machine can be found at <a - href="https://git.pngu.org/dots/tree/.config/kernel.config" target="_blank" + href="https://git.pngu.org/dots/tree/.config/kernel.config" + target="_blank" >6.10.0 .config</a - >. For some more kernel related stuff, see <a href="kernel.html">here</a>. + >. For some more kernel related stuff, see + <a href="kernel.html" target="_blank">here</a>. </div> <div id="bootloader"> <h3>Bootloader</h3> Spoiler: there is none. For the duration of my time using Linux, I have used GRUB across various systems. In my experience, it's been ok, it does - what it needs to, allows for extensive configuration like theming and - requiring a password. However, some time ago it went kaput on this machine - and despite manually setting the root partition in + what it needs to, allows for ample configuration like theming and + security. However, some time ago it went kaput on this machine and despite + manually setting the root partition in <code>/boot/grub/grub.cfg</code>, it seems the incorrect value was passed to the kernel at boot and the partition could not be found. Every time I would reboot I would have to manually set it from GRUB command line (which @@ -181,11 +195,11 @@ CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="root=PARTUUID=<uuid> ro" </pre> Where root is set to the <code>PARTUUID</code> value of the root - partition. Use <code>blkid</code> to obtain this Once kernel has been + partition. Use <code>blkid</code> to obtain this. Once kernel has been recompiled, copy the image to the EFI partition and create a new boot - entry. It is also wise to remove unneeded entries to conserve limited - space. (below command selects the first entry with <code>-b</code> and - deletes it with <code>-B</code>) + entry with below command(s). It is also wise to remove unneeded entries to + conserve limited space. (below command selects the first entry with + <code>-b</code> and deletes it with <code>-B</code>) <pre> # efibootmgr -b 1 -B # cp arch/x86/boot/bzImage /boot/efi/gentoo/bzImage-x.y.z.efi @@ -194,59 +208,43 @@ CONFIG_CMDLINE="root=PARTUUID=<uuid> ro" Reboot and the bootable system should be shown in Mac's EFI program. </div> <div id="portage"> - <h3>Portage</h3> - <h4>Profile</h4> - When initially setting this up, I opted for a multilib system as I was - still using some 32-bit programs at the time. Since, I have switched to a - no-multilib profile. Unlike adding multilib support to a 64-bit only - system, going from multilib to no-multilib is quite easy. - <pre> -# eselect profile list - ... - [12] default/linux/amd64/17.1/no-multilib (stable) - ... -# eselect profile set 12 -# emerge -auDN @world -# emerge --depclean - </pre> - It was pleasant to see 80+ packages removed after the switch. And have - much reduced overhead in my system overall. I did have to manually set a - few USE flags the were originally set by default profile. + <h3>Other System Bits</h3> + <h4>C Library</h4> + I opted to use <a href="https://musl.libc.org" target="_blank">musl</a> on + this system, over the traditionally used glibc. While there are + never-ending debates over which library is better, using musl has some + clear benefits on this machine. Namely, meaning shorter compile times -- + musl compiles in roughly 2 minutes, versus glibc's 2 hours. Omitting glibc + also removes the dependency for GCC, another hefty package. As for the + reduced "compatibility" when using musl, in terms of non-POSIX compliant + code, Flatpak is an adequate solution. I currently use Flatpak packages + for proprietary applications whose binaries are linked against glibc, and + Firefox, as NodeJS has a strict runtime dependency of GCC. <h4>Compiler</h4> - As Clang/LLVM has become more and more stable and is able to compile - (almost) all packages installed, I chose to switch the default compiler, - linker and other bits over from GCC. This is easy enough in - <code>/etc/portage/make.conf</code>. - <pre> -CC="clang" -CXX="clang++" -AR="llvm-ar" -NM="llvm-nm" -RANLIB="llvm-ranlib" - </pre> - For packages that Clang fails to compile, a GCC fallback environment can - be made containing the previous variables, then applied to certain - packages (e.g. + As you may have guessed, this system's default compiler infrastructure is + provided by <a href="https://llvm.org">LLVM</a>. Clang and its + counterparts have become much more widely used and are compatible with + just about all code I encounter on this machine. Some advantages of this + are of course the reduced system overhead of not depending on GNU's + compiler collection, slightly faster compilation times and reduced memory + usage, and potentially overall safer binaries. + <h4>Profile</h4> + Subsequently, this system uses a somewhat custom Portage profile, or at + least a combination of existing ones. A <code>musl/llvm</code> profile + exists, but I also wanted to omit multilib support from this system, as I + do not need to run or build any 32-bit applications. With the way that <a - href="https://packages.gentoo.org/packages/gui-apps/waybar" + href="https://wiki.gentoo.org/wiki/Profile_(Portage)#Combining_profiles" target="_blank" - >gui-apps/waybar</a - >) by adding an entry in <code>/etc/portage/package.env</code>. Some - advantages of using Clang over GCC are slightly faster compilation times - and reduced memory usage, and potentially safer binaries overall. - <h4>USE Flags</h4> - My USE flags and related options are quite minimal. Global flags include - <pre> -USE="alsa bluetooth clang dbus elogind gles2 jpeg png \ - pulseaudio sdl udev wayland X -systemd -vulkan -nls" -ACCEPT_LICENSE="*" -ACCEPT_KEYWORDS="~amd64" - </pre> - For reference, some primary features used on this system are Wayland, - audio, elogind, and OpenRC. Since no-multilib already has very few things - enabled, not many flags needed to be disabled, although I have quite a few - package specific USE flags disabled to help reduce compile times and - remove dependencies that may only be required for one or two packages. + >cascading profiles</a + > + work in Portage, this was quite easy to combine with the + <code>no-multilib</code> profile. For reference, some primary features + (USE flags) used on this system are Wayland, Pipewire, elogind, and + OpenRC. Since no-multilib already has very few things enabled, not many + things need to be explicitly disabled. Although, I have quite a few + package-specific USE flags disabling unneeded features to help remove + dependencies that may only be required for one or two packages. </div> <div id="applications"> <h3>Applications</h3> @@ -293,8 +291,6 @@ fi <b>Notifications: </b ><a href="https://github.com/emersion/mako" target="_blank">Mako</a ><br /> - Requires <code>x11-libs/libnotify</code> and to be manually started - via Sway configuration. </li> <li> <b>Lock Screen: </b @@ -306,37 +302,26 @@ fi <b>Keyboard Manager: </b ><a href="https://github.com/rvaiya/keyd" target="_blank">Keyd</a ><br /> - For many months, I used - <a href="https://github.com/kmonad/kmonad" target="_blank">KMonad</a>, - which was suitable for most of what I needed, but lacked a couple - things, namely key combos. The - <a - href="https://git.pngu.org/dots/tree/.config/keyd.conf" - target="_blank" + I'm able to almost fully replicate my more functional + <a href="https://git.pngu.org/qmk_me/about/#layout" target="_blank" + >layout</a + >. Its + <a href="https://git.pngu.org/dots/tree/.config/keyd.conf" >configuration syntax</a > - is also incredibly simple. After creating an OpenRC service script, it - was ready for use. - <pre> -#!/sbin/openrc-run -command=/usr/bin/keyd -command_background="true" -pidfile="/run/keyd.pid" - </pre - > + is also incredibly simple. </li> <li> <b>Terminal: </b - ><a href="https://git.pngu.org/st" target="_blank">st (fork)</a - ><br /> - While st was originally written as an X program and can be run under - Wayland via Xwayland, it would be nice if it were natively supported. - I have a + ><a href="https://git.pngu.org/st" target="_blank">st (fork)</a><br /> + While <a href="https://st.suckless.org" target="_blank">st</a> was + originally written as an X program and can be run under Wayland via + Xwayland, it would be nice if it were natively supported. I have a <a href="https://git.pngu.org/st/tree/?h=wl" target="_blank" >branch</a > which is fully functional and does not require Xwayland, although I am - yet to port my current st patches to it. + yet to port my current st patches to it... </li> <li> <b>Shell: </b |