The small Linux distro known as Levinux (download ~20 MB)
…is a tiny virtual Linux server that runs from USB or Dropbox with a double-click (no install or admin rights required) on Macs, Windows or Linux PCs—making it the perfect controlled environment for learning Linux. Think of it as an introduction to old-skool—more relevant now then ever as Linux/Unix (*nix) gets embedded into everything (the Internet of Things – IoT). Optionally build a full Python/Flask web app that you can crack open and modify. It’s being wrapped into more and more classroom environments where there’s no better fit. Here’s a quote from a parent about what Levinux can help achieve:
Something has changed in the way he sees a computer that I was not expecting. He is no longer consuming media he is creating. The family computer has changed from a flashy pass time to a tool for creativity.
Learn about Levinux being used for Linux Controlled Assessment.
Levinux may be for you if:
- You’re looking for how to learn Linux and nothing’s worked for you yet.
- You want to use Linux with Python and are looking for how to get started.
- You’re an educator looking for actually viable Python school projects.
- You just need a really small Linux that none of the desktop versions fix.
What I propose…
There are many approaches to learning to program, and reasons to do so. You might want to build an empire, or just have a few extra skills in your back pocket. Levinux supports either goal and everything in-between. It does this by using a particular minimalistic approach: learning the least-possible tools of the most broadly applicable and timeless nature in order to let you do the most interesting things. It can be your primary programming environment, or just sort of a safety-net while you pursue other more sexy platforms like mobile app development. Programming is just automating machines to do your bidding—with more control than The Sorcerer’s Apprentice. But that story still provides us with a good model for the important concepts of machine automation that you’ll be mastering with me:
Like The Sorcerer’s Apprentice
Even if you never programmed before, I propose starting teaching you how to do it “old skool” within minutes of reading this. Your ability to control computers through the plain old-fashioned text-based terminal is increasingly valuable—and is easier than you think! Text-based computer operation increases the number of problems you can tackle across different hardware and OSes, while asking for you to spend less money, and prepares you for the “Internet of Things” (IoT).
Download and double-click Levinux, and follow the instructions. After playing a bit with this cool (but slow) virtual machine, I propose putting a real server into your hands (like the $35 Raspberry Pi) to continue with real physical hardware. The stuff you learn will be universally applicable for the rest of your life—and decrease your dependency on vendors trying to lock you in (Xcode, Visual Studio… and even Java!)
What does Levinux look like?
When you double-click the launch script, a black window that looks much like this will pop up. The first time you run Levinux, it will “inflate” by hitting a software repository to pull down a webserver and an SSH server. You need an Internet connection and not-too-restrictive firewall for this to work correctly.
The Path Less Traveled
My approach is at-odds with today’s vendor-driven “power-tool” mentality—and that is precisely why it will give you an edge over the competition. In short, I propose you take up certain core technologies that are both powerful and lurking right beneath the surface of nearly every computing device—instead of the heavyweight bloated frameworks like .NET.
Small tool-sets like the Unix/Linux commands, the Python programming language, the vim text editor and the git code version-control system will truly serve you for the rest of your life, and become a sort of Swiss Army Knife in your pocket—no matter what other tech you also choose. Levinux merely illuminates one path, focusing on Python code-execution on a highly portable platform, made possible by QEMU and Tiny Core Linux. The result is all-at-once minimal, powerful and universal.
A journey of a thousand miles begins with a single step
The videos below will give you a little more idea what to expect. The first goal here is to make an easily reproducible positive old-school Linux Server experience for you, no matter what platform you’re starting out on (controlled conditions). It is my heartfelt belief many more people can make the jump to text-only *nix-like platforms than people give themselves credit for. This stuff just looks intimidating. But just like anything else, once you get through the difficult initial first tries and stick with it, everything starts to make sense, and come naturally to you. So, have no fear. There is nothing you can screw up. You can just unzip Levinux again and try over, resetting it back to initial state. So, join me on this learning adventure, knowing there’s nothing you can’t undo!
- Github: miklevin / levinux
- The Levinux Fanpage on Facebook
- The YouTube Levinux playlist (post in the video comments)
- And the one-page forum embedded right at the bottom of this page!
Here’s what Levinux looks like booting the 1st time
Under The Hood (for you Reddit’ers)
Note: this will read like blah, blah, blah to newbies who can focus on the videos. But here’s the it is for all you Reddit and HackerNews folks…
Levinux is based on Tiny Core Linux and QEMU. Tiny Core is an extremely minimal distribution of Linux created by Robert Shingledecker, the guy who “matured” Damn Small Linux (DSL) into such a creative and popular distro and was responsible for the United States’ first large-scale municipal government Linux install. Tiny Core’s philosophy comes from the world of embedded systems where operating systems aren’t generally installed across hard drives nor allowed to accumulate cruft over time. Instead, embedded systems re-initialize into a perfect pristine state on every startup boot. Upgrades feel more like replacing a part than installing software.
Tiny Core Linux itself is able to be so small based on another piece of software in-turn, called BusyBox—basically, a ~500KB (half a megabyte) replacement to nearly the entire Linux command set known as GNU, but which people popularly just call Linux. What’s often called Linux is really GNU/Linux—only one particular flavor (minimally ~200MB) of what you can bake of Mr. Torvald’s Linux kernel. Busybox/Linux (of which Levinux is an example) is yet another (much smaller) flavor. And so on. Things in the Unix world are very similar, and proprietary versions of all this are called things like QNX, VxWorks and such. Android is yet another spin on all this. Okay, so Levinux is a minimal Busybox/Linux. But how is it it actually “run”?
It’s run on QEMU! QEMU is an x86-based computer emulator that is frequently used in Android development, Oracle VirutalBox and is still part of the Linux kernel virtual machine. It’s roughly the equivalent of VMWare, VirtualPC or Parallels—except the free and open source version. I am currently using the most popular mainstream binaries pointed-to by the QEMU website after a long adventure of trying to compile my own, and am in the process of recruiting QEMU and Linux kernel gurus to help with this project. Yes, there’s nothing wrong with starting out with Debian, Arch, Fedora, CentOS or any of the other fine GNU-based Linux distros, but ~20MB versus a minimum of 200MB and usually closer to 1GB makes a big difference in how fast you can try out out, and the amount of freedom you have in experimenting, nuking a system, and bravely retrying.
If it makes you feel better, 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, instead of fiddling around with LiveCDs or hard drive partitioning. And the work you accomplish here is as valid as the work you accomplish anywhere else. Python is still Python. vim is still vim. git is still git. Using git, push your code up from Levinux to Github or Bitbucket and pull it down from whatever other system you end up using in the future—thereby hopping OFF of Levinux and onto something else *nixy. You might even learn something more than starting with Debian or some other desktop-flavored Linux, because a minimal system has only has what you intentionally put there and plan on using—which is also a better security model, scales better, and installs on a wider variety of hardware, and once again more closely fits the IoT world of embedded computing now upon us.
Pretty much any modern Mac, Windows or desktop Linux system with about 60MB free on the hard drive will do. I’m still working out problems from 64Bit Linux desktops, and will put the full list of tested OSes and versions here at some point in the future. But since it’s only a ~18MB download that inflates fully out to only about 60MB after the Python, vim and git server build, and no install is required on your host system, why not just download it and give it a try?
- A lot of firewalls break Levinux’s secondary Python/Pipulate build. If this happens, just reset your Levinux and stop trying! the firewall is blocking you, and proxy solutions are too complicated for me to support. Just run Levinux somewhere else, if you’re determined.
- Many things like Google AppEngine host conflicting websites on port 8888.
- It’s tricky to zip the file so it decompresses with proper permissions for all OS host platforms. I’m always trying to strike the right balance, but what fixes issue-X on platform A often causes issue Y on platform B.
- Some Linux distros refuse to run .sh files with a double-click regardless of permissions. The ever-increasing Ubuntu Unity Nautilus has settings that will let you run the .sh file with a double-click. Usually, it’s labeled something like “Run in Shell and Approve every time”.
My Search For The Perfect Platform & The Rise of Levinux
So, where did all of this come from? Why Levinux? Why Busybox Linux, Python, vim and git as my chosen and recommended tool-set? Why QEMU and Tiny Core Linux to glue it all together as a quick-intro to *nix for newbs? Because I have a deep, compulsive attraction to encoding-automations. Robots, in other words. Disney’s The Sorcerers Apprentice has a special appeal for me, and I read SciFi and love Asimov. The Amiga computer lit a flame in me, and nothing until my most current work has even come close to re-capturing that feeling. But re-capture it, I did in this project—and I thought I’d share.
It was 1982, and I was 12 when I started learning these things at sleep-away science Camp Watonka near lake Wallenpaupack in the Poconos—mountains in northeastern Pennsylvania. The Radio Shack TRS-80s were text-only and generally ran BASIC and were not very exciting. People fought over the few Apple II’s at camp, but I didn’t think those were very exciting either—even with it’s minimal graphics. Soon-after, at 13 years old, I got a Coleco Adam, once again jumping on the wrong bandwagon. I had a long streak of bad luck getting started with computers.
Then, I happily found the ultimate tech/artist-geek bandwagon in the form of the Commodore Amiga, then in short order got beamed up to the mothership, amazingly in my back yard—about a 40 minute drive to Commodore Computers in West Chester, Pennsylvania. I ended up working for them as a student intern from ’88 through ’90. I thank Ed Flocco, Marc Rifkin, and Tony Antonnucio for these wonderful Amiga-related experiences from my youth.
I also thank the Harry Copperman regime at Commodore at the time, and the Educational Marketing department led by Howard Diamond an John Harrison that opened the door to me, and Fred Holland who took me under his wings, keeping out of (too much) trouble on my trade-show trips to CES, Comdex, and the other shows I went to as a Commodore employee at the time. I thank the CATS team (Commodore Application Technical Support) and Carl Hermann and Larry Feldman of Gene’s Books in the King of Prussia mall—an important pre-Internet part of my youth that gave me that Internet-fix—who were also CATS guys.
The, I thank Dale Larson who gave me all his books when he moved to Hawaii, through which I first heard of the LISP programming language, and started to realize how much more interesting the computing world was than what I had been exposed to so far. But ultimately, I thank Paul Calkin and his side-kick Jesse (last name?) who explained to me how in the bigger perspective, the Amiga is a kooky game machine that got a lot of things right, and while it had some very interesting features, the future was still in Unix.
The Amiga, they explained to me, was an anomaly—a sexy anomaly true—and one that Commodore just stumbled into (long story), but Unix was destined to be a universal standard in computing, because it does all the things a computer should do, and is being taught in every computer science curriculum in the world. The fact that the Amiga kicks everything’s ass right now graphics-wise is not long-term. It’s more important to be standardized and commoditized and graphics performance will just catch up through formalized APIs, and the boring world will gradually become as interesting and exciting as today’s Amiga world…
Wow! This blew my mind, and I was skeptical. But when Linux started popping up, I figured I’ve give that world a try and installed it multi-boot on my first-generation Pentium (and first x86 PC) and was unimpressed. How could I love this non-graphical AmigaDOS-ish thing with no kick-ass Deluxe Paint-running “front end”. Well, I turned back to the Microsoft world—the other major alternative at the time, because Mac pre-OS X wasn’t so exciting (for the cost) either. And Windows at that time meant active server pages (ASP) running on IIS and usually with a SQL Server as the database.
About a year earlier, I had tried switching to Java with Servelets, and hated it. Then about a year later, I tried Ruby and ROR recognizing all the joyful convention-over-config files that I was using in the generalized system… but it was… I don’t know… too object-oriented or something. Why all this OO? Ohhhh… languages mattered. Both Java and Ruby were OO by-design, and maybe that’s what I hated. Everything was subtly difficult and counter-intuitive. I was making a real study of what my next platform should be, so that I could both love it, and not go obsolete. My study became a study of computer history.
I started at Charles Babbage and Ada Lovelace. This led me to Multics and Unix and C and Ken and Dennis, respectively. Discovery led to discovery as I learned the names and the players and the evolutionary branches. Of course I soon found GNU and Richard Stallman and Linux and Linux Torvalds. By all accounts, Standard C or Common LISP should be my programming choice for durability and applicability, but every attempt I made showed my why ground-swell cannot possibly occur on either platform—there’s such a thing as too much power and the whole Spiderman schtick—with great power comes the need to make a career out of it to keep yourself sharp. What is needed is a take-it-up-quick and rapidly re-familiarize-able language. This logic fast leads you to PERL and the other family of related scripting languages that were in great part, the enablers of the early web.
And so, I relented and tried Python, and discovered Guido van Rossum and that whole happy FOSSy import this world. Wow! PEPs (Python Enhancement Proposals) and the willingness to gradually obsolete old versions to do the right thing. The right thing? Correcting old mistakes and gradually and iteratively approach pragmatic perfection. Python embraces its C and Unix brethren. Tie-ins with almost everything in every industry. Super support. Supper community. Super sensible (no object orientation forced when you don’t want it—except in the urllib2 library, which they’re fixing).
So, I had my language. But what about the rest of my platform? I wanted to stay as mainstream as possible, but once you take up Python, staying mainstream has a lot of interesting sub-choices. For my first project, to provide the bridge to the Web-world, I chose Apache2 and mod_python. At some point into the project, I became aware of the WSGI webserver-standard in Python, and how mod_python was not it—and, my mistake. So, on my second big Python project, I decided to strip nearly everything extraneous away, and see how little I could get away with as a still-powerful, still-viable, still-flexible, and very obsolescence-resistant platform. What is my webserver in Levinux? Busybox and Python itself—not even nginx… but I could switch to it at any time, because of WSGI. Things are really nice now in terms of future-proofing precautions. But what about a minimal OS to run Python on?
Dig enough into bare minimum tiny Linux and eventually you discover Damn Small Linux (DSL), and dig deeper and you’ll learn about the schism that occurred in the project that drove Robert Shingledecker, the second major contributor on the DSL project to go off and do his own thing—Tiny Core Linux. Try TCL and you’ll feel the sensible undertones of Debian and the appeal of an utterly different approach to a small Linux distros that feels less tied to a time-and-place in history, like the Gnome and KDE desktop-linuxes all feel like. I researched SliTaz, Aboriginal, Linux From Scratch, Coyote Linux and a bunch of others that promise smallness. But TCL just works so friggn well, it keeps re-asserting its rightness for the Levinux project.
So, Linux and Python were set. But what of code control? What of my text editor? Long stories, but after long diversions down paths that went away and away and away or didn’t survive my platform switches—CED (Cygnus Editor), programmer file editor (PFE), Edit Plus and Notepadd++… when I finally settled onto Mac as my day-to-day desktop, I wasn’t going to be suckered into TextEdit (and I’m glad I didn’t, given it’s current status) or even Sublime when it came along. I bought into the cult-of-vi and by extension, vim which I was delighted was developed originally on the Amiga. And git… long story. But yes, git is now a part of the core tool-set. And there it is: Linux, Python, vim and git. Now, just make it instantiate anywhere without installation or permission issues… oh yeah, QEMU! Levinux is born.
It seems there are some dots to be connected here… all I have to do is static-compile QEMU on every major modern platform with all the dependencies baked-in and have a nice portable binary for each major platform… oh, whoops! Wow, is that hard to actually pull off successfully. I’ve had mixed success on each platform, and had to back off and revert to the old time-tested tried-and-true binaries that are linked-to from qemu.org. Sighhh. It’s something of a defeat and a compromise, but you know what? It’s the perfect application of the 80/20 rule until something better comes along. Dots connected. Sat on it for a year. Realized it was useful to other people, if nothing else then as an educational curiosity. So, I finally released it on my website and soon-after on Github.
And that’s it. That’s where it stands today. While I myself cant’s stand the slowness of the Levinux platform as a main programming platform, I still see the incredible value of such a system. I can’t just sit on it, so I release it in Github and invite others in to help on the more rough-around-the-edge QEMU binary parts that are over my head. There’s other parts to the story, like the discovery of the built-in tftp server in QEMU that can shuttle files from host-to-vm-guest at boot-up (intended for netboot scenarios) that make it all possible. But describing everything would make this way too long for anyone to read. If you’re interested, let me know and I’ll break out a separate article.
Revision History (View files)
Current (March 21, 2016)
- Upgraded to Tiny Core Linux 7.0
- Significant upgrade. Reverted to stable, well-known Mac & Windows QEMU binaries.
- Updated to Tiny Core Linux version 5.4 (the latest)
- Integrated my free and open source SEO Tools project from Github called Pipulate.
- Took vim install out of second-stage server build script.
- Added a bunch of Alice in Wonderland “discovery” features, such as drinkme.sh.
- Attempted to make the Mac binary more broadly compatible. Tested on 10.8.5
- Mac QEMU compiled in Homebrew again. QEMU version 2.0.0.
- Removed 64 Bit Linux files for simplification of testing. 32 Bit runs on 64 Bit systems.
- Mac QEMU (version 1.6.1) now being compiled from source via Homebrew
- A lot of .dylib files added for new Mac dependencies (until I solve Homebrew static linking issues)
- Radical altering of start script for Mac version to use text-only curses mode and eliminate pointer grabbing
- 64 Bit Linux QEMU now being compiled from source (now in parity with 32 bit version)
- Moved keymap files out of subfolder so Mac qemu binary could find them.
- Added efi-1100.rom for Mac qemu binary dependency.
- Changes in this version will only be visible to 32-bit Linux users
- Ubuntu users MUST now click “Run in Terminal” after double-clicking Levinux.
- Big step towards using updated qemu binaries, but only on 32-bit Linux
- Replaced qemu-system-i386 with a static compiled curses enabled version
- This should eliminate pointer-grabbing on 32-bit Linux
- This is a prelude to doing it across all platforms: Windows, Mac and 64-Bit Linux
- This is also a prelude to formal GPL compliance
- Broke Webapp2 out into optional Libraries menu
- Added color coding to Libraries menu to show what’s been installed
- Added support for OpenSUSE 12.3 64-bit
- Added the requests object for Python, because it is the right thing to do.
- Added webapp2 framework to make it similar webdev to Google App Engine.
- Made entire /usr/local/lib/python2.7/site-packages directory persistent after every time “filetool.sh” -b is run. This makes pip package installation and persistence MUCH easier under Levinux.
- Added libSDL-1.2.so.0 for Ubuntu 13.04 64 bit compatibility
- Added a menu for easily adding common client libraries, starting with Google core APIs
- Made pip persistent.
- Added missing libraries for some 32-bit Linux systems.
- Updated the README.txt based on user feedback.
- Using an appended path for LD_LIBRARY_PATH for 64-bit Linux.
- Corrected issues with Ubuntu 64-bit Linux
- Replaced qemu Linux binary with qemu-system-i386 and qemu-system-x86_64
- Changed Linux launch script to auto-sense 32 or 64 bit and use correct binary.
- Added tce-load -wi python-distribute to Python.sh
- Added sudo easy_install pip to Python.sh
- Added entries to .filetool.lst to make pip persistent
- Added pxe-rtl8139.bin and vapic.bin to MacOS folder per net feedback
- Set the stage for a git video tutorial
- Added curl and expat2 requirements for git when Python server builds
- Added “export GIT_SSL_NO_VERIFY=true” to .ashrc for git pushing
- Greatly enhanced tutorials at localhost:8080
- Added bottle.py Python Web framework
- Opened port 8888 for Python web development work
- Added menu option #4 for installing Python, vim & git
- Expanded Reset scripts to clean up Dropbox collision files
Planned longer term improvements
- Eliminate use of SDL library. Replace with ncurses and pdcurses.
- Get rid of “flashing” problem in Linux
- Get rid of pointer-grabbing
- Find or compile the “perfect” binary for each platform (older qemu’s?)
- Find or compile the “perfect” Linux kernel (less hardware support)
- Compile & submit my own optimized Tiny Core Linux extensions
- Get rid of XLibs and other graphics related overhead
Call For Help: QEMU & Linux Kernel Gurus
I need QEMU compiled with barebones hardware support and ncurses/pdcurses support. The binaries should be as small as possible, with as few dependencies as possible—which means probably not the latest version of QEMU. So, I need to choose the ideal QEMU version, and strip out as many of the hardware support options as possible, for Linux, Mac and Windows platforms. I also need a similarly minimal Linux kernel. If you’re a QEMU or Linux kernel guru interested in helping with the Levinux project, I want to hear from you (use the contact form on the side).
Minimal Linux Distro Considerations
I chose Tiny Core Linux due its all-in-RAM embedded Linux philosophy along with its decent software repository system, but I am always keeping my options open, looking for better cloud compatibility. Here are some versions I’m keeping tabs on:
- Tiny Core Linux – Chosen due to nearly incorruptible all-in-RAM embedded OS philosophy.
- TTYLinux – Installs on Amazon EC2 and uses the more standard pacman package manager. Very strong contender.
- Slitaz – Seems more popular and “user friendly” than Tiny Core.
- Aboriginal Linux – Aboriginal Linux is a shell script that builds the smallest/simplest linux system capable of rebuilding itself from source code.