Robert Elder Software Linux Operating System | Hacker News Reader

Robert Elder Software Linux Operating System

blog.robertelder.org

104 pointsrobertelder14 comments

Linux from Scratch is amazing. In 2002, I built an LFS system and used it for a semester and a half. I got tired of saving all my ./configure flags and switch to Fedora for a bit. I truly learned to appreciate package management afterwards. :-P

Today I'm a Gentoo/Funtoo users, which is sorta like LFS with package management. I've had to do a lot of work with embedded systems and Linux servers in my career, and I feel like using LFS for nearly a full school year in University really helped me understand Linux fundamentals.

Hm. I wonder if the bash patching is actually necessary - a syntax failing command like '|foo' still goes into the history, so you could pick it up from there, maybe via a prompt command. https://github.com/nvbn/thefuck seems like kinda-sorta prior art for this.

(and if I'm wrong and/or the bash patch just makes things lots easier, then I'd love to see it posted somewhere people who know the bash source well can see if they can help turn it into a real feature, because custom error handlers seem as awesome as custom completion handlers)

I tried very hard to create the feature I was looking for without changing the source, but it just wasn't possible. I went through 3 or 4 prototypes, and eventually decided to just change bash itself (which was a good call in hindsight). I've had to make a few more change since too.

The source patch is located at

~/.fop/patched-executables/bash-4.3.30-post-patch-call-python-hook.patch

is has been applied after the LFS bash patch.

This patch is extremely sloppy and breaks certain things, but it does what I need for now. The way it works for bash commands is before handing a line of input off to be processed, it calls an external python hook which decides whether that line of input should be ignored or not, gives the hook a change to perform it's own custom behaviour (such as print an error message).

Ah, I was thinking about "let it fail with the normal error message, and then print an explanation" - that way people learn to recognise the real error too for when they take the training wheels off.

(I checked, even malformed lines like '|foo' go into the history)

Yeah, there are a few situations where it's a difficult call between getting them used to the 'real' environment vs holding their hand and telling them "bash: syntax error near unexpected token `|'". If I end up modifying it too much, then they start learning an alternate thing that isn't portable knowledge, but in this case I think it should be OK. I would make sense to possibly have a graduated progression where you expose them more and more to the real horrors of using the command line. I guess I'll see how it evolves.

Another couple reasons I patched bash: Being able to detect when users use tab completion and using the up key to check history. Those are 2 massive productivity enhancements, and I wanted to created modules where I can verify that they used these.

A patched up system to provide a learning environment for newbies? I may not need it, but I'm a fan.

Robert Elder is such an interesting guy. If you haven't seen his "one-page CPU", definitely check it out. http://recc.robertelder.org/

There is also levinux: http://mikelev.in/ux/

td;lr

Has patched versions of bash and nano to fit in with the author's intention to provide a learning tool. Designed to run under virtualbox, not as a traditional install. The .ova image includes training material.

also check slitaz.org

I can't see any valid argument for going through the hoops of an LFS in the authors article.

For educational purposes it's acceptable but still less effective than simply creating an educational environment on an existing distro.

Acceptable only because you won't have as much exposure and therefore security maintenance won't need as much of your time as it would in a distro used for servers or clients.

Still though, my point is that there are very little valid reasons to build your own distro these days. To distribute a certain set of tools and defaults you have the option to base your distro off of Debian or Ubuntu for example. Fedora has great options for making "spins" of their distro.

And the things the author mentions as custom bash and custom nano for example, those things could just as easy be in a virtual environment using aliases, cgroups or a number of other features available in any Linux distro or shell.

Let's call it what it is, three dead trolls had the right of it; "setting it up is half the fun". That's exactly what this project was for the author. A fun but largely pointless exercise in setting up a Linux distro.

New distros should bring something more unique to the market than just a toolset. A properly made package manager, albeit a major change, should easily be deployed on any distro.

Most distros even have well developed support for custom kernels, as long as you package according to their guidelines.

"A fun but largely pointless exercise in setting up a Linux distro."

When it comes to using C keep in mind a lot of developers are interested in lower-level interactions--perhaps at the hardware level. There is probably value in creating simplified, isolated environments that can test certain features in a VM.

"For educational purposes it's acceptable but still less effective than simply creating an educational environment on an existing distro."

How is it less effective? If anything the author now knows more about setting up a full environment and can tailor make a minimal setup to showcase some specific features. These minimal setups can then be hosted in a VM preconfigured for students.

Just some thoughts. I've never done LFS or taught C programming. Though I do use C often and enjoy the language, warts and all :)

Sorry but I don't see it.

>How is it less effective?

It's simply overkill and insecure to not use an established distros patch and package management.

The most effective thing is to create packages, or if you want some larger modifications a "spin" in fedora language.

I can't see any reason why you'd be restricted by packages. You can deploy your own compilers, your own shells, your own init system if you want. You can deploy patched kernels as long as you follow packaging guidelines.

It's smarter to spend time on packaging guidelines and internal yum repos than to build everything from scratch.

This may be a useful learning tool for the author. For a "newbie" ubuntu/fedora or any mainstream distro is a better choice because of the abundance of the support information. With the customized basic tools this even hurts beginners as they get used to things not part at standard environments.

Overall this is a project born dead if its true intention is to be a useful tool for the beginners.

Reply on news.ycombinator.com