It certainly can be noticeable, depending on where and at what you're looking. The issue can be that making a general "yes, you'll see a difference" statement is usually difficult; opinions of what counts as "a difference" vary wildly from person to person.

What you experience could be as small as shaving a few KiB off your executable or getting an extra 2-3 FPS in a game all the way up to "it just won't work unless I compile it this specific way because of <insert_variable>."

I thought that maybe the kernel would be a binary, so it would not have to be recompiled like how I would assume it usually does.

There are options for binary kernels, just so you are aware.

As for documentation related to configuration of portage and /etc/portage/make.conf, I would, of course, be remiss to not point you to the Gentoo Handbook. The wiki contributors do really great work and the community is generally quite welcoming and open to implementation-specific questions.

Any benefit — whether that be smaller overall binary size, reduced system requirements, removed dependencies on unneeded libraries, etc. — would be entirely dependent on the machine and what USE flags you're messing around with. I can't really be more specific without knowing your exact hardware configuration and needs. You would have to know what features Firefox has that you explicitly don't need and are available as flags, then you could start shaving your yak.

I can, however, say that in all my time using Gentoo I installed Firefox from source maybe a half-dozen times, and it was always just to test out the upgrade from one CPU to the next. I don't really need to trim all of the fat out of Firefox in most cases, so if I felt like I needed a really light GUI browser I'd probably just grab dillo or netsurf.

Yes, compiling modern browsers from source on a laptop will probably take a few hours. Same thing with rust and the usual suspects. This is, of course, where binary packages are not only useful but indispensable.

The benefits one could potentially gain from compiling something like a browser are often outweighed by practicality. Then again, a counter to that argument could be something along the lines of "you don't have to sit there and watch it compile, you could be doing something else."

You sure do get benefits, at least in the form of being able to select your compile-time options.

Now, does this always result in a tangible performance difference? Absolutely not. It's more about being able to make decisions like "I don't want <insert_favorite_software> to be compiled with <insert_least_favorite_options> and I want it all handled by my package manager."

How much of a benefit this would be to you or anyone else is worth exploring — at least in my opinion — and a large reason why Gentoo has its own unique role in the larger Linux world.

So, a few things:

The thing that's "equivalent to Arch" would be Arch. There is really no comparison between Gentoo and Arch outside of the "build your own system" approach; they use different package managers, different init systems (by default), etc.

Arch has the goal of providing user flexibility through its minimal nature — you're expected to choose the software you want and build up a system that fits your needs.

Gentoo, meanwhile, has the goal of providing user flexibility through its minimal nature as well as through skillful use of compiler flags and machine-specific hardware tweaks — you are quite literally expected to build your system, as in compile your software from source. Even the installation is like that: you grab a root tarball and do a good ol'-fashioned chroot installation, then edit /etc/portage/make.conf and let 'er rip.

Now, Arch has the ability to offer a certain amount of this flexibility as well; most people become familiar with it by diving deeper into the AUR than just installing yay or paru. With Gentoo you have portage and ebuilds baked into the system from the start. You can have complicated setups involving multiple build machines that can combine resources and have it all handled with some basic mucking around in /etc/portage. Gentoo also offers the concept of overlays, which add repositories like GURU that fill similar roles to the AUR but are handled by the default package manager.

Using binary packages — those that are offered — is missing out on a key strength of Gentoo and the primary reason one may choose it over another.

That all being said, I can answer at least one of these more specifically:

Do you lose any potential control over the system when using the binaries, rather than compiling from source, and, if so, what?

Well, obviously. You lose all of the ability to choose how the software is compiled, which is most of the point of Gentoo: tweaking compiler settings and optimizing for your specific hardware. Binary packages are built with a predefined set of USE flags and are meant to be run on a wide variety of systems.

There also aren't a ton of them, so you'll still likely be compiling the majority of your system from source which... may not be to your taste.

TL;DR: Gentoo offers a lot of the same sort of features that Arch users love — AUR vs GURU as an example — and many people use Gentoo with very little tweaking, but binary packages do not fundamentally change much for someone who has never used Gentoo. There will still be a curve and you will be learning.

I do, and rio loads basically instantly for me.

I use all three web browsers in 9front at different times: abaco, mothra, and netsurf.

My favorite is probably mothra, but netsurf handles most sites in a way that people expect (read: it supports CSS and JS).

ETA: use cases

• abaco

  • pros: acts like acme and supports viewing multiple pages simultaneously, best for text-only browsing

  • cons: very basic, many sites just don't work at all

 

• mothra

  • pros: simple, works for a wider variety of sites, can disable image loading entirely with a flag, moth mode is great

  • cons: no tabs, unfamiliar UI for most people, selecting text for snarfing is weird

 

• netsurf

  • pros: most "normal" web browser, supports CSS and JS, familiar UI

  • cons: no tabs, more bloated than other options, requires compiling a (small) web browser from source

I have a TempleOS theme set as well if this wasn't the weirdest thing you saw today.

How does one install that, and where?

Like any other operating system, really: by downloading the appropriate installation media and creating a bootable USB stick to install from. After reading the FQA and other documentation, of course.

rio is the window manager for Plan 9. People have created patches for other window managers like dwm that attempt to mimic some of rio's key features such as window "swallowing" and the ability to draw new windows by simply clicking+dragging with the mouse.

If this is your first time ever encountering Plan 9, I would highly suggest watching some of the videos by adventuresin9; they're a solid intro to what the whole deal is with Plan 9.

Is this in a VM or on actual hardware?

This is bare metal, specifically on a Thinkpad T420. It is my current daily driver.

...no, I definitely meant dmenu. sandy has keybindings that bring up (by default) various dmenu prompts as a substitute for the usual "command mode".

: or M-x to bring up a command prompt, C-\ for a "pipe to" prompt, M-\ for a sed prompt... you get the idea.

st is just the suckless terminal emulator; sandy can be run from any terminal emulator.

I'll give you six that I haven't seen mentioned yet:

• sim and vis, both of which focus on combining vim motions with structural regular expressions as used in...

• sam and acme from Plan 9, both of which are included in Plan 9 from User Space (aka plan9port). sam also has a modified/expanded version in the form of deadpixi/sam, while acme has spin-offs like a port to Go and a standalone version.

• mg, one of the three default text editors included with OpenBSD (the others being vi and ed).

• sandy, the abandoned suckless text editor. It uses dmenu and is fun to mess with for shits and giggles.

A different way to do the usual ..="cd .." and endless chains of ...="cd ../.." types of aliases:

bash/ksh version:

..() {
    local count="${1:-1}"
    local path="../"
    while (( --count > 0 )); do
        path="$path../"
    done
    cd -- "$path"
}

zsh single-line version:

..() { cd $(printf "../%.s" {1..${1:-1}}) }

These take the number of directories that you want to move up as an argument (e.g. .. 3), otherwise they move you up one directory when used with no arguments.

Permanently Deleted