Since LFS has been mentioned, an easier task that will help you learn how things work is as follows:
* Build a custom kernel.
* Build your own busybox. (Make sure to choose the "force a static link" option until you're ready to learn about dynamic libraries.)
* Get your kernel to load and execute your busybox, at least to the point of getting a shell.

This isn't that hard, and you can use a VM or something called "user mode linux" for this purpose.
It's especially annoying when your Gentoo system has updates ready for packages like chromium, firefox, or libreoffice, which take a disproportionately long time to compile.

(Note: I did not use either libreoffice or openoffice when I was using Gentoo.)

Another thing: Why is portage much slower than apt, even if you ignore the time needed to compile each package?

Edit: yes, doing a build in a VM you can also make snapshots at various stages, either Gentoo or LFS would be easier to do in a VM, then in the worst case you also wouldn't lose internet access to look something up.

Browsers especially have gotten a lot of feature-creep in recent years: when they started phasing out proprietary Flash plugins and bolting everything onto Javascript so you can have a video player, 3d editor, PDF reader, and debugging tools in one window. Browsers now are more "full operating system" than Emacs. Someone is probably trying to port Emacs to Javascript so they never have to leave Chromium.

Don't ebuilds point to URLs around the web to download sources? It also does a few different checksums to make sure the version matches and nothing was corrupted or modified since the ebuild was created. Apt probably does gpg checks though, so that might not be relatively more. I'd wonder where the cycles are being spent: maybe it happens when portage has to build documentation, or if it runs test suites which distros would do only on the buildserver to create the package?

I remember finding things like dependency resolution to be slow.
Honestly, I sometimes think it would be nice to have a limited graphical browser that has a modern layout engine and understands HTML5, but dosen't implement things like JavaScript and audio; perhaps it also shouldn't play animations and video by default, either. This would certainly help when viewing sites you don't trust as much, or sites that have been known to be naughty.

(I'm wondering how easy it would be to rip V8 out of Chromium, and how much smaller and lighter the browser would be without JavaScript or anything dependent on it.)

In that case I'd assume it has to rebuild the dependency models based on what the USE flags are for every applicable package. Toggling many of those flags can alter what is required or optional for subsequent packages, and maybe it doesn't cache that efficiently.

For those cases, I use something like cURL or wget to download the page, and only rarely the extra media like images or CSS which would let the layout look somewhat as intended. Depending on how suspicious the page is, sometimes I read the HTML with "less", or for most cases I pipe the HTML into lynx: lynx -dump -stdin < a.html |less; which makes most blogs and articles look like a textfile.

In this case, however, I may want to browse the site interactively, perhaps go through a search engine, or following a lot of links, like when browsing Wikipedia or tvtropes (warning: the latter site can cause you to fall into a bottomless whole of links).

(One reason for wanting a less featured browser is to minimize resource use, especially if using the browser on a machine that's doing heavy work (like a kernel compile), or that is not that powerful (like a netbook or Raspberry Pi (especially a Raspberry Pi Zero).)

(Also, it would be nice to have a browser of this sort for Android that works with a touch screen, but doesn't implement anything fancy.)

Wow, this has suddenly been revitalized. Does anyone even use HTML 5 anymore? It seems like everyone went back to plain scripting, but maybe that's my imagination.

drm9009, if you're a digital rights enthusiast then why the hell are you on this website? I'm not trying to be rude or to criticize, but I'm just curious, because that seems like the opposite attitude from that of a website that seeks to destroy DRM (not you personally, but you know what I mean).

I've looked at this LFS and it seems crazy. By the way, I've never quite understood, how can one write an operating system? I mean I understand how the code works to do everything, but how would it be compiled, or for that matter, debugged? I mean if the operating system must run under everything else then how can a debugger run it? Or do you just have to compile it, reboot using it to test it, then reboot again in the other OS to tweak the code, repeat, etc.?

It would be compiled by running a compiler. Just like with any other program. You can take gcc and build Linux. You can take clang or gcc and build a BSD.

For debugging, there are multiple approaches. Indeed, compile, reboot, test is one way. Sometimes devices have a hardware debug port that allow you to single-step the CPU, among other things. Kernels can have a debugger built-in. Remember, debugging really just boils down to inspecting the state of the system, and there's generally no reason the kernel can't inspect its own memory.

Originally, programmers had to manually program machine code into a computer via switches; then eventually came such inventions as punch cards (better than manually programming switches, but still cumbersome), assemblers (so programmers didn't have to memorize every opcode), compilers (because assembly language is still too low-level for big projects), and interactive environments (to eliminate the punch card, allowing code to be typed into the computer).

In modern times, one can use a virtual machine, or failing that, an emulator, to develop an operating system. With a VM, one doesn't need to keep rebooting a physical machine for every iteration; furthermore, attaching a debugger is also possible with a VM.

Furthermore, Linux has a variant (in the upstream source) called User Mode Linux, which runs as a userspace program on x86 and x86_64 Linux (unfortunately, no ARM, which is a shame because it would be nice to have this for systems that lack hardware virtualization, like the Raspberry Pi 0).

There's also the idea of a cross-compiler, if you want to compile an OS for a CPU architecture other than the one you're working on. For example, you can write a program on a desktop Linux system (or even a Windows system, especially with the likes of cygwin or WSL) but compile it for the Raspberry Pi.

clarry, I hadn't thought of the fact that the OS can read it's own memory, but that's still not really a debugger, because you're not seeing the source code that gets compiled to become the kernel.

dtgreene, I'm aware of the evolution from punch cards and all that, but I didn't realize that virtual machines can run debuggers for operating systems. That's interesting. As for a cross-compiler, I've never heard of any program being compiled on one processor or in one OS which is intended to run on a different kind of processor or in a different OS, except for using an interpreted language like Java.

Showing source code was never part of the definition of debugger. Sometimes you have to debug things without source code. Many times. I attached a screenshot of a kernel debugger in my previous post, here is its manual: http://man.openbsd.org/ddb

You might also have the option of using a remote debugger, in which case you can have source code on a different computer than the system you're trying to debug. I use cross compilers pretty much every day. Compile things on amd64 laptop, run them on arm devices. It's very common, given that many of these wimpy arm machines don't have enough storage & RAM for compilation anyway, and not all of them are supposed to run a full blown OS anyway.

Cross-compiling is very common in the embedded world.

Consider the Arduino Uno, for example. This particular device has the following specs:
* CPU: ATmega328P (AVR), 16MHz
* RAM: 2 KB (can't execute code from here)
* Flash Memory: 32KB (can execute code from here, but can't re-write it at run-time)
* EEPROM: 1 KB (can't execute code from here, but at least this can be re-written at run-time and keeps its contents after power down)
* I/O: Plenty of this, useful for controlling things like LEDs and servo motors, but you do not get a monitor, keyboard, or mouse with this. There's a USB serial connection, which allows uploading code to the device, and can be used to communicate with a host computer.

Anyway, we notice a few things about this:
* One would not be able to type the code into the device.
* 2 KB isn't much RAM, and would not be enough to run a compiler on the device.
* Even if you could run a compiler on the device, you would have no way to execute the code, as there's no area of memory that is both writable and executable.

Therefore, to program an Arduino Uno, you need to compile it on a computer (a Raspberry Pi works for this), and then upload it to the device.

Another common example is GPU shaders; GPUs are very different from CPUs architecturally, so you can't just copy code over without compiling it, and while GPUs are good for certain tasks, compiling software is not one of them.

Like, for example, if you're trying to make a ROM hack, or you just want to figure out how a game calculates something and observation isn't good enough.

Or, you could be analyzing some hostile piece of software, like a virus or copy protection scheme, in order to figure how it works and disable it. (Note that, in this case, the developers of the software may impose counter-measures to make debugging harder.)

You could be trying to make a crappy game not crash when you run it on a PC that's been up for a few months. https://www.gog.com/forum/painkiller_series/if_painkiller_crashes_immediately_at_startup_try_rebooting

Oh, are you both talking about writing firmware and programming for ROMs and whatnot? I hadn't thought of that, but I suppose you'd need to write something to compile onto that, even though that's not the chip you're using for actually writing the code on or compiling it. But I guess I was thinking of things like, if I have a C++ compiler that runs in Windows but compiles programs that can then run on MacOS or vice versa. I've never seen that before (though I've looked for those kinds of compilers but never found them).

I mean I primarily write code on amd64 linux and run it on arm linux. There's just no point trying to get compilers and everything to run on the arm device itself. There are compilers like that. Some are a bit of a pain to set up (though I imagine you can find a pre-made image for just about anything on docker hub today). Others are very simple to use: https://ziglang.org/#Cross-compiling-is-a-first-class-use-case

https://mxe.cc/