Live data from Hacker News

Linux from Scratch

linuxfromscratch.org

111–117 of 117 posts

Re: Linux from Scratch

#111

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…

oh. I'm talking about authoring OS and boot loaders from an absolute blank slate. like starting from the world where you toggled them in from switches, and later by burning proms

Re: Linux from Scratch

#112

Earlier 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.

What is the point of making a distro, if not to make an OS? It's the same thing.

Re: Linux from Scratch

#113

Earlier 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.

One supports the other, they aren't laid in opposition, but they are different, well-defined disciplines

Re: Linux from Scratch

#115

Earlier 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.

OK: "How *nix tools functioned together in command-line days".

Re: Linux from Scratch

#116
post #79
post #75

Earlier 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 :)

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/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

#117
post #79

Earlier 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…

Free software doesn't typically have an SDK. A compiler is just one of the available programs. So is a text editor, a shell and script interpreters, some incarnation of make, etc. There's nothing really special about the compiler and you can write perfectly fine programs without ever touching it.

That said, port trees usually have devel-* sections. Does that count?

Post reply on HN