Earlier quoted context omitted.
until very recently you couldn't even do OS development without a boot loader, so asserting that that would be the last thing you would write is just nonsensical
Let me rephrase. We already have a bootloader. "Linux from scratch" involves Linux, not Libreboot, not Grub (just to mention instances of BIOS/UEFI and bootloader). We already have means to test the new OS. What I meant with my previous post is "newer" bootloader (which are actually pretty old, like grub), came after OSes passed a certain complexity. Previously we technically had bootloaders, but they were interactiv…
Linux from Scratch
111–117 of 117 posts
Re: Linux from Scratch
#112Earlier quoted context omitted.
>LFS is how the rubber meets the road Again I disagree. Way too much time is spent building software than actual practical OS development.
LFS is not OS development. You build a distribution by assembling all the components. If you want to develop an OS from scratch, perhaps you're looking for osdev.org.
Re: Linux from Scratch
#113Earlier quoted context omitted.
LFS is not OS development. You build a distribution by assembling all the components. If you want to develop an OS from scratch, perhaps you're looking for osdev.org.
What is the point of making a distro, if not to make an OS? It's the same thing.
Re: Linux from Scratch
#114Re: Linux from Scratch
#115Earlier quoted context omitted.
"Requires"/"needed". LFS is about the muscle memory; the documentation; the cohesiveness. I always recommend it to people and consider it foundational to my understanding of How Stuff Works. Whether that amounts to a hill of beans in the AI world remains to be seen.
It is more how stuff is compiled than how stuff works. Fundamental things like how processes are scheduled are not explained by LFS.
Re: Linux from Scratch
#116Earlier quoted context omitted.
The step by step is the right approach... but you'll discover that many 'components' are _INSANE_ and that includes their SDK. Bare LFS is not enough (I run my own): you need a kind of userland (above glibc) multi-version system which some kind of "atomic-ish" switching (always have a stable SSH running in case something goes wrong, better than unplugging the system disk and fix it on another computer). For linux, sa…
If you think that's an abomination, try corporate billed-by-the-hour enterprise software where nothing ever changes unless it's approved by several layers of management. I promised myself not to work for any of those anymore :)
Modifications and changes must be weighted very carefully. For instance "removing" (including in the SDK) is usually a less worse modifications than the others and it decreases the global technical size and complexity/number of layers of the stack/SDK (which is top priority in "security"), namely most of the time but not everytime a good thing.
Because, on most complex software (open source or not), a "believed" benign modification can be disastrous. It is even worse if close to bare metal involving complex hardware (even with massive QA[testing]).
Re: Linux from Scratch
#117Earlier quoted context omitted.
If you think that's an abomination, try corporate billed-by-the-hour enterprise software where nothing ever changes unless it's approved by several layers of management. I promised myself not to work for any of those anymore :)
Well, in this very case, it is more complicated than that: they have to protect their software against planned obsolescence and developer tantrum (it would be the same for any "in production software"). Modifications and changes must be weighted very carefully. For instance "removing" (including in the SDK) is usually a less worse modifications than the others and it decreases the global technical size and complexity…
That said, port trees usually have devel-* sections. Does that count?