All of us who at one point compiled our own kernels and now no longer do, are the killers that we are partly because we did things like that at least for a bit. It only makes sense not to now, after having done it.

It's not true to suggest (or to read these stories as a new bystander and come away with the idea that) "if I were smarter I never would have wasted time on that"

However, I think that the statement below might be better with a bit of nuance.

> It's not true to suggest (or to read these stories as a new bystander and come away with the idea that) "if I were smarter I never would have wasted time on that"

I would say its "not true always," in some cases doing the action really wasn't worth the time.

Related to this, I believe the sentiment people have about regretting wasting time on some endevour, is a misalignment of what their intention was to begin with.

For example, if someone wanted to compile their own kernal because they wanted to learn and understand more about their computer its unlikely that they would walk away from that experience with regret. However if they wanted to compile their own kernal because they believed that in doing so they would make 10x more money in the long run (through learning so much), and that goal failed to materialize. They would likely tell others to not waste their time learning to compile their own kernal.

Not trying to be pedantic, or argumentative, I aggree with your point deeply, however I wanted to discuss it a bit further. Let me know your thoughts.

If you can, try to get access to OpenVMS or Cisco IOS, it's an entirely different world in terms of user experience.

At best, we are at least a bit confused about it all.

The flags were just icing on that cake.

Chrome, git, ssh, docker, netbeans

I know it's not mainstream to use NetBeans these days, but I don't care, I'm just used to it and it gets the job done. Maybe I'm just getting old.

The only cool thing about it is that it’s declarative: nix-darwin everything and a fully working and customized machine is up in 10 minutes with one command

Nowadays most people are swimming in CPU cores and gigabytes of ram and terabytes of solid-state memory, so fine-tuning is a waste of time (unless you play bleeding-edge games). But it wasn't always such.

Unless you run javascript 'applications'. Games are already optimized.

Yeah, I'm calling bullshit on this one. At least, it doesn't line up with my experience. In my experience, games are optimized _just enough_ for a decent playing experience (and not always then). Games devs, as a whole, are the worst offenders of expecting their users to just throw more money (hardware) at the software to achieve usable/enjoyable experiences. There are, of course, exceptions. But, for every Carmack, there's 10s of thousands of developers scrambling to make their deadline, doing just enough to ship.

The games themselves though are a different story. Outside of open sources games (which are usually less demanding than commercial ones), you don't have the source code to rebuild it. Even if you did, enabling optimizations beyond what the developer used risks breakage so you will have to do your own testing. Even then, simply rebuilding the software wouldn't address the quality of the code created by those developers who are scrambling to meet a deadline with as little effort as possible.

Back in the day, I spent a fair amount of time working on gutting the DLL because frankly, it was atrocious. My memory is a little fuzzy as it's been +10 years since I've looked at it, but things I remember seeing:

* over use of C/C++ preprocessor macros where an inline function would have been more appropriate to say, get the array/list of CvPlots (tiles) that needed to be iterated over all the time. * lack of hoisting loop invariants out of loops. It is common to see usages of the non-trivial macros above in the bodies of tight loops, often tight nested loops. Optimizing compilers are great, but they're not _that_ great. * the exposure of the C++ types to Python was done...poorly. It was done using Boost Python (which, while a great library for its day had a _huge_ learning curve). For every Cv type in the C++ DLL, there was a corresponding Cy type to expose it to Python. Collection types were _copied_ every call into Python code, which was quite frequent. The collections should have been done as proxies into the underlying C++ collections, instead of as copies.

Most of the changes I made were quite small, but over the course of a month of part-time hacking on it, I'd gotten late game turns down to a couple of minutes from 30-minutes and memory usage was extremely reduced; and I never did get around to fixing the Python wrapper as it would have too intrusive to fix it properly. I could have made more aggressive changes if I had full access to the source, but being constrained by DLL boundaries and C++ types being exported limited what could be done w/o breaking the ABI (had to be extremely careful about not changing object sizes, affecting vtable layout, etc).

Frankly, I doubt the developers spent very much time at all, if any, with a profiler during the course of development with the game.

Civ had been a 2d game until then, it was their first 3d title.

Not to mention that it was turn based strategy, and the main performance problem was AI turn length in the endgame.

What AAA titles have you played around launch in the last 5 or so years?

For a single machine home install, the biggest value Gentoo has to offer is the learning experience. I ran it for about a year like 4 years ago, and I definitely learned a lot in that time. Hopped around a bit and I've since landed on GNU Guix, and I'm probably set for life now in the GNU world.

I used to believe that and was a huge Gentoo user for years back when it was initially released. Then one day I benchmarked Gentoo and a default RedHat install on every work load I cared about, and everything was within the margin of error.

A full day compiling stuff only for the base install, let alone everything else I would eventually need.

On my case, I decided to become another Scientific Linux tester.

But computing power is much higher now. The same compilation now would probably take 1-2 hours, max. Updates would be super fast.

Gentoo itself is considered generally stable and a pretty solid distribution, or it used to be.

I wonder if these days the flexibility and the engineering behind Gentoo might be worth taking another go at it.

It's really not much different than working with Arch in terms of complexity. Initial setup takes a bit, but if you've installed arch you are pretty familiar with everything you need (in fact, arch docs are helpful for a gentoo setup :D).

The docs are VERY good and easy to google.

Compilation time can be nasty depending on what you install but not terribly bad. I just rebuilt the world because a GCC update broke lto that I'm running. With about 2k packages that took about 6 hours to complete on a Ryzen 7950.

General updates take almost no time at all (especially using git for syncing). Usually less than 10 minutes often less than 1. As I write this, I'm currently rebuilding kde (if you are using your computer, rebuilding doesn't really get in the way. Especially if you are already working with a multicore system).

I’m not so sure. A lot of the power comes from multiple cores. Years ago I had one core, now I have eight. A lot of the compiles don’t use all the cores.

Software has also gotten bigger. rustc is huge, for example. It didn’t even exist when I used Gentoo years ago.

These days I’m on the Mac and I just switched to Homebrew after using Macports for years. It was for one of the same reasons I stopped using Gentoo: compiling takes too long. Whenever I upgraded Mac OS versions, Macports required me to recompile everything. This was no problem at all for, say, tree. But something was pulling in gcc (emacs needed it for some reason??) and this took ages to compile.

At least Macports worked though. When I used Gentoo, it took so long to compile things that I would leave it overnight, and of course often in the morning I would see that the compilation stopped halfway through because something was broken. Hopefully that’s improved. Or of course maybe the binary packages will help with this.

But if I wanted a build-your-own, rolling-release binary system, I don’t see why I wouldn’t just use Arch.

I rather use programming languages ecosystems that favour binary libraries for a reason.

I was working with a 486 around 1995. Compiling your own software was the norm and compiling your own kernel could have significant performance benefits (even if it was just to conserve the limited memory supported by machines of the day, to head off some of the swapping). By the time I learned of Gentoo, that was not really the case: most of the software one could obtain was provided in binary form and compiler optimizations were much less relevant (unless you had a special workload).

The tooling provided is important too. I was using NetBSD for a while. For the most part you just started the compilation process and walked away until it was done. (I imagine Portage is similar.) You didn't get the instant gratification, but it was not time intensive in the sense that you had to attend to the process. That was very much unlike my earlier experiences in compiling software for Linux, stuff that isn't in the repos, since it did have to be attended to.

Later on, to take advantage of my Pentium based computer, I would get Mandrake, with its i585 optimized packages.

Most of my Linux based software would be sourced via Linux magazines CD-ROMs, or Walnut Creek CD-ROM collections.

I used first Xenix in 1993-1994, and naturally wasn't compiling it from scratch.

I've installed Gentoo literally two times. Once per PC. Been using it for years. It's not like you have to keep tweaking it. It does help if you run a basic system like me, though (no DE, simple tiling WM, don't use much apart from Emacs and Firefox).

But yea, now-a-days I'm on Ubuntu LTS.