All excellent points, althalus. You renew my faith. I need this kind of feedback to temper this thing and put an edge on it. Each question you ask deserves a paper written on the topic, but here it goes.
FILE LOCATIONS
I see no need to separate and organize the files from what they are now. I think I achieved the perfect cross-host-OS robust balance for what I'm trying to accomplish.
First, there really are so few files. If you can read a manifest in the README.txt, you'll know what these dozen-or-so files are by name & location—much more than most people can know about each and every file in your standard bootstrapped 150MB "core" OS these days.
Second, so many of the tricks that go into a "no install" double-click-to-run are very path-sensitive as to where they find their libraries. I.e. paths are brittle. Every system has slightly different rules, and paths relative to executable is the common denominator.
In other words, the most sure-fire way to eliminate brittleness in launch-scripts across different host OSes is to script everything relative to the directory in which the executable is found, and the command-line was cd'd into when executed. You can't rely on paths relative to root for a drag-anywhere, run-on-any-OS bundle designed to be launched from where it resides—especially in this new Dropbox world.
And they all have shared resources like the hard drive files. Three separate downloads means three separate systems. Why not start out working on a Windows at work, then later move to a Mac at home, then still later continue working on a Fedora system, and you have the exact same VM and work files across all three? Literally the same VM. Three different distro's completely defeats the unified persistent and acrobatic objective of the VM.
So why not subdivide the directories within the master instance for organizational reasons? Well, because for newbie usability I'm click-counting from reading about Levinux on some website to having it running on your desktop. Extra directories are too many extra clicks and choices—and what for? To introduce more difficult path issues to launch scripts? When the user is presented with three OS choices of what to run Levunux on, a README.txt file and a RESET directory, what are they going to do? Click on the one that corresponds to their OS—or read the README.txt. Either option, not too shabby. And if it screws up, there's exploring the RESET folder.
Finally regarding file-org issues, everything that surrounds Levinux/Levinux on Mac.App/Contents/MacOS that seems nonsensical or redundant, that's by convention of the Mac App Bundling feature. Meaning, I have to abide by Apple's hierarchy rules to get double-click on a Mac to work on a directory, and not resorting to a .command bash file or AppleScript.
So to the observant, you may notice I'm only presenting three OSes double-click-to run options plus a README.txt and a RESET folder. I don't present a sixth item of where QEMU and all the support files are located—not even as invisible files (another brittle feature to avoid in cross-OS distribution). So, where are all the files actually stored? In the Mac directory, which is double-click to run, with a beautiful icon and all—when you're on a Mac. You should really see it. So, why not hide everything else in there, as well?And so I did.
I put everything I needed right in the same location that the Mac magic that makes this transparent bundling trick possible wants its executable (or script) to be in to launch properly. They share resources like the virtual drive file, so it only makes sense. It's also a great place to drop .dll's, .so's, common bios' and other things with path issues at launch time.
Because its designed for n00bs, it serves a valuable purpose to present as few choices as possible after download and unarchiving. And those few items presented are the names of the three target OSes as the launch "scripts", a README.txt file containing everything needed to know to get started including Lesson #1 (not in beta 1) and paths to licenses and mirrored source code.
And if something screws up? Well, it is my hope people will think to check in the RESET folder. And it can be reset and run under different conditions when all the repositories are reachable. Again, here's the simple system and the game-like dynamic. Reset, retry, reset, retry. I could get rid of a potential point of failure by including the repository archives with the distro, and let the recipe system retrieve and build from local parts. But then, the distro gets bigger and it defeats the purpose of showing off the recipe system that can build any sort of server. I envision having a cookbook is recipes for all sorts of JeOS boxes distributed with Levinux.
WHY G-WAN & BETA RECIPE?
In many ways, the choice of g-wan was arbitrary. With the recipe system configurable on the host-side, you could define any type of server to build. But to have an enterprise performance caliber webserver working with like under a single 500K download download and unarchive—and almost no configuration but renaming a single folder—well, it's remarkable.
I invite you to switch my system over to a similarly working nginx example and send it to me. I'll examine it and maybe make it the default. My thought is as I come out if beta, I won't even include a standalone webserver at all, but rather use Python's built-in webserver ability—the script to make it so will be the second or third Levinux tutorial. I'm not really interested in promoting a particular xyz-CGI webserver API. The protocols that are important to me is what network protocols you can make Python or some other language speak to the world.
But Python is a 40MB pull—way too big for a beta 1 server build recipe. G-wan at ~500K is about right. And why not give an underdog endeavor like g-wan that has a similar no-install, lean, make everything relative to executable philosophy as Levinux some exposure?Good people. Good product. And Pierre gave me permission. You could even start running just-in-time compiled C code with it (feels like a Ruby, Python, PERL scripting but is compiled C) on g-wan without gcc or other compiler! But still, it's just my choice for beta. Though I am toying with the idea is a starter-C tutorial on g-wan.
INTENT
The intent is to provide a "reasonably easy" path for newbies to work their way up the ladder-of-capabilities on Unix-like operating systems, to become equal parts systems-programmer, sysadmin and devops. I want to formula-tize an approach to future generations to never have to look for a "technical cofounder" in pursuing their own endeavors with a large information technology component.
I want it to be as core and generic as possible to provide a sort of future-proofing against fads and unfortunate vendor dependencies. I want to start making old-school cool for a new generation, and make something like the genuine old PERL geek culture alive again in a new generation—but with better tools. I envision those to be vim, some language (probably Python) and some DVCS—probably git but maybe Mercurial.
It's a short-stack education. That's also plenty of tools to also cover HTML5/CSS, XML/JSON and all the other must-know goodies of browser-based client stuff, because this VM is always reachable by web browser (in addition to SSH) from the host computer. Over the years, I also hope to cover Standard C, Common LISP and maybe one or two others to round out the education.
Initially, I intend for Levinux to play just a little bit like a game, because the README.txt will contain this "manifesto-like" stuff (a lot like this) and enough historic context to support it (Babbage, Turing, Ken&Dennis, etc.) and lesson one to get started. Lesson one will scavenger-hunt you along to Lesson 2, and so on. Lesson #1 is really just SSH'ing into your new VM—such a small thing, but really so door-opening—and so challenging in Windows systems and to Windows folks. We take these things for granted.
I think of Levinux as something like The Young Ladies Illustrated Primer in Diamond Age—but not so grandiose in scope. Maybe, I plan for Levinux to be more like the hints left by the ruling programming class to create a constant trickle of newbie influx from among the underclass in Ira Levin's SciFi This Perfect Day—all with crediting and educating about the giants on whose shoulders we stand—even with our short stack.
Think of it as part book, part game ( in the sense of Code Hero) and partly me just expanding my own personal abilities career-wise by creating something for which I hope to build a movement and tribe (again). Combining with the Tiny Core Linux one seems ideal—but then I encountered the resident junkyard dog.
PERFORMANCE
Performance is slow because to isolate dependencies and provide maximum portability even across different Linux distro's, I've decided to not rely on the kernel virtual machine libraries or acceleration / optimization facilities even though they may be there. That gives up access to a lot of native hardware capabilities in exchange for working more places. Using the KVM would mean specific kernel version and compile option dependencies. So, slow it is. I hope to address this somehow.
DOTS BEING CONNECTED
Hmmm, where to start. I guess thumb drive Linux, and distro's like Robert & John's DSL that are perfect for virtualization is dot 1. And the portability of VMs across OSes through standardization of virtual hard drive formats like qcow is dot 2. How these combine into a perfect storm with cloud drives that have broad OS support like Dropbox—launch it from same "install" from any (of 3) OS—is dot 3.
How the Mac OS X .App packaging system reduces the number of user choices is dot 4. How QEMU's built-in TFTP service for file transfer between host and VM and how that will enable a "build-any-server" recipe system manageable with human-readable scripts from your familiar VM's host is dot 5.
Oh yeah, you guys. A corruption-resistant Busybox-ish core Linux with a minimalist boot kernel and repository system suitable for bake-a-server automation is dot 6.
Timing is dot 7—now is the largest vulnerability to Microsoft since Vista due to the forced Windows 8 paradigm shift—some group of people will look around for obsolescence-proof paths with less frequent dead ends than Windows. I plan for this to be one of the things to be there. ASP = fool me once. .NET = fool me twice—not really me, but a lot of people are in that boat. Sudden platform liquefaction. People might actually be open to a little minimalist old-school thinking.
I could probably go on with dots, but I think I've written quite a lot. In the end, the dots are not being connected to make a pre-configured VM, but rather one that the whole world of people wanting to explore going old-school can climb onboard easily and join on with sort of a movement of other people going the same direction. It should work no matter what sort of host system they're coming from. Even people with that level of newbie expertise could pick apart the recipes and learn something, or go through the initial SSH lesson and get to the second lesson.
Because recipes make the direction you could go with Levinux totally open-ended (efficiently distributed JeOS boxes, etc.) I have to lock-in on one particular thing I'm advocating as a learning platform as I come out of beta, so it creates a great example and embarks the student on a lifetime adventure in Unix-like OSes and programming.
I love the vim text editor for its muscle-memory, IDE-ishness, ubiquity and improving-your-skills-for-a-lifetime characteristics. I also love distributed version control systems like git & hg and view them as necessary pillars of a modern tech platform & education. And finally, I like Python for being as equally suitable to a newbie as to a seasoned programmer.
If the whole of connecting these dots is greater that the parts, then participants will have an always ready-to-run virtual machine sort of vibrating forward through time and across OSes. I see it as riding the waves of Dropbox accounts (and other such syncing mechanisms), forever advancing QEMU, and ever-more-popular embedded-Unix-style system design—reinforced by DVCS like GitHub or Bitbucket and lots of incidental copies, considering its tiny file size.
Your life might get turned upside down—but you'll never lose that place to run your code, or the code itself. With such a deliberately designed momentum-preserving and timeless-seeming environment, I see possibly improving the ratio of newbies who are actually able to cross over to that very powerful place. Or, at least that is a worthwhile mission.
Welcome
FAQ
Downloads
Wiki
