This is awesome. Computing is becoming more and more ubiquitous but at the same time it is becoming more and more opaque. Approaches like levinux are an excellent way to make it more open and accessible not just from the consumer perspective but from the hacker/maker perspective as well.
Just had a play around and I'm very impressed. I'm pretty sure I'll be using this in September for all my CS students.
We've been looking at various ways in which we could introduce our Year 7s (11-12 yo) to Linux, and this checks all the boxes. It'll fit nicely within our existing schemes of work that go through HTML/CSS and JavaScript, and then lead onto Python in the next year.
This looks awesome, but I'm slightly confused with the mission of this project. Is it meant to provide a simplified operating system to encourage tinkering, or a minimal "old-school" environment in which to learn "higher-level" programming on?
There are tons of approaches to learning to program, and reasons for doing so. You might want to build an empire, or just have a few extra skills in your back pocket. Levinux supports your pursuit either goal and everything in-between. It does this by focusing on one particular “short stack” approach: learning the least-possible software possible of the most timeless nature to enable you to do interesting things. It can be your primary programming environment, or just sort of a safety-net as you pursue other more sexy platforms like mobile app development.
This is quite nice. The approach fits well with ubiquitous computing.
If anyone is interested in another tiny Linux version, not necessarily for education, but personal use, I'd recommend CrunchBang (based on Debian). If you have an old laptop you want to give someone or a new netbook that doesn't have a CD drive, it's very easy to install via USB.
Edit: I just realized, "tiny" doesn't quit fit CB. So let's call it efficient and simple instead.
For a tiny distribution, puppy or slitaz work quite well.
Also, I would say that Arch Linux can be as tiny as you want, but it's not a fire and forget solution and I wouldn't want to maintain an Arch system for friends or relatives ;)
Uh yeah probably shouldn't jump into the tiny Linux debate, but I recommend looking into Rich Shingledecker's attitude towards desktop distribution bloat even on versions considered "tiny" vs the 6 to 12 MB distro that he turned into Core Linux. Divergent philosophies, and I found it best to leave the desktop world behind when approaching Linux education. Best not to confuse what's being worked on to compete with iOS, Android, OS X and Windows with the education that will serve you best on servers and embedded systems. Even Puppy and SliTaz are large-ish desktop versions of Linux in comparison.
He mentions "transferability" as a goal. Whatever a person learns in the context of this small Linux is directly applicable to other Linux distributions. Granted, whatever a person learns in the context of any Forth is applicable to the Forth that one might use on Windows, Mac, Linux, FPGAs, or whatever. It just seems that that wasn't his aim. He does after all state that this project is constrained by his imagination and his resources.
Forth doesn't seem to be what he had in mind or was prepared to provide. If you personally like learning and teaching Forth, then you're right, why not start with Forth?
Hi. Levinux creator here. More modern platforms will always offer developers speed-to-productivity advantage, but the platforms themselves are constantly moving targets. If you invest yourself wholly into them, you're caught in the cycle of what Joel Spolsky calls fire-and-motion. But if you also learn a good terminal-oriented old-skool in a way that will work on most (but not all) embedded systems, you'll always have a fallback plan. The short stack is ideally Unix, C, a ubiquitous text editor, and the compiler tool chain. But we're not in an ideal world and I want it to be approachable by newbies. So, Python comes before C for the sake of positive initial experience and movement towards C, and vim is the text editor choice because of the ubiquity. I know tons of arguments can be made different ways, so I'm making a my flavor of Levinux, then making it as spinnable in different ways as possible. Forth versions should be no problem, and I anticipate a node-oriented version and such. But time and imagination constrained as I am, I'll be focusing my tutorials and server recipes on my idea of an newbie-accessible short stack.
Wouldn't it make sense for levinux to ship with a C compiler then? It wouldn't make much difference to the file size and would let people start with C if they wanted to.
(Please correct me if I'm wrong - I just started levinux, ran the initial download, then sshed in and tried 'cc', 'gcc', 'clang', and 'tcc' before giving up).
The distribution zip is under 20MB. Even with vim, git and Python, it's still just 60MB. The GNU toolchain pushes it much larger, and it's not part of the early education curriculum I'm proposing. C compiling is something I'll be working people to after several positive experiences with Python. Also, it's just one repository command away from being installed, so I figure I'll add it as one of those menu options that you get presented with after startup.
This absolutly got my attention, going to check for sure. I'm older, and when I was in school we learn OS with Minix, a port of UNIX on the 8086 architecture. But this is so much more!
Believe it or not, I considered Minix for this project, as I did BSD and BareMetal OS. In the end, "some Linux" won, and at this time only Tiny Core Linux roughly estimates the ease of a Debian-like repository system to support server-building scripts, while still being a minute distro (under 10MB without the Levinux parts) and not being a hard drive install while still offering persistence... well, the list goes on. It was a very tall order I was trying to fill, and at the time, the QEMU+Tiny Core Linux combo nicely fits the bill.
While this is certainly a fast (and convenient) way to get hands-on experience with Linux, I'm not that sure about the "short stack" being the best option for beginners.
First of all, learning the command line, git, vim, and Python is a bit too much for a beginner to handle all at once. IMHO, vim alone will scare off a lot of people.
Second, being exposed to a lot of different programming languages is very beneficial for a beginner.
I agree with this. I find that a lot of enthusiasts get caught up in learning to use tools, instead of understanding fundamentals.
Vim, git and Linux are great, but they are tools for getting a job done. Once the fundamentals of computer science are learned, these tools can be picked up rather quickly.
I'm all for this approach, as I'm a huge Linux/vim/git fan, but all of this must come after the fundamentals are in place. It's very easy to overwhelm someone with too much information about tools and terms.
Now if you're the next Linus Torvalds, then this is an excellent approach. Us mere mortals shall marvel at your talents from afar.
I think vim is OK if it is explained as ":i to modify, ESC :wq to save and exit".
Keeping the first explanation to this two use cases keeps it short and easy to remember, and not much more difficult than the other command line editors. pico or nano have the command in plain sight but I find them worse to type for beginners, and there is not much of a learning path from there.
You'd also want to map something more convenient to ESC. Like jk.
That way you won't have people immediately cursing this system that requires them to find the ESC key every time they finish editing a piece of text. Something more convenient can be mapped to :wq as well.
Actually....I think I'm with vukmir on the beginner in education being somewhat overwhelmed and I'm confused as to why Linux Server skill is being conflated with programming.
"consider Levinux a stepping stone for newbs, because it gives you a taste of Linux Server and sets you on your way to being able to do SOMETHING within minutes......Push your code up from Levinux and pull it down from whatever other system you end up using in the future."
"Code for life" is a big part of my philosophy. Over the years, I've found that one of the biggest obstacles was code-loss due to various causes, not the least of which is just losing interest and forgetting where everything is.
The only defense against this seems to be the two-fold approach of getting your code into more than one place, and being able to rapidly reproduce your code execution environment. For getting it into more than one place, I take many lines of defense: making Levinux so small that it's easy to copy, partitioning the hard drives so that syncing an entire virtual machine over Dropbox is still fast and efficient... and finally, distributed version control.
I've found in my work with git and Mercurial, workflow is totally transformed always for the better. And while neither git or vim are technically part of the code execution stack, they are both fundamental to what I'm trying to teach. I'm taking some creative license in how I define a stack :-)
I'd also propose that the motivation is that some sort of short stack will be all that's available on the tiny embedded processors that are being increasingly built into things. If you want to get under the hood, you're going to have to be able to connect by terminal or serially. Not everything has a screen or keyboard, and this more primitive way of working is a lowest common denominator. It also doesn't hurt that it is a viable approach on bigger hardware and the cloud as well. Back to the Swiss Army Knife analogy.
