
Robert Elder Software Linux Operating System - robertelder
http://blog.robertelder.org/robert-elder-software-linux-operating-system/
======
djsumdog
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.

------
mst
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](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)

~~~
robertelder
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).

~~~
mst
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)

~~~
robertelder
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.

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

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

------
dkarapetyan
There is also levinux: [http://mikelev.in/ux/](http://mikelev.in/ux/)

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

------
softwarelimits
also check slitaz.org

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

~~~
wangchow
"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 :)

~~~
INTPenis
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.

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

