WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux  (Read 17687 times)

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #15 on: February 17, 2013, 10:15:30 AM »
I tried out your offering, and could not find your source to browse.
I asked to see your source.
You said you don't have it available.
I pointed out that you are required to have it available.
You are the one being difficult here,not me.

Offline MikeLevin

  • Newbie
  • *
  • Posts: 26
    • Mike Levin
Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #16 on: February 17, 2013, 10:26:43 AM »
I tried out your offering, and could not find your source to browse.
I asked to see your source.
You said you don't have it available.
I pointed out that you are required to have it available.
You are the one being difficult here,not me.

It's beta. This is the type of thing I am working out. I didn't compile anything, so I will mirror the respective sources. Folks here who are worth their salt helped me see that is my responsibility under GPL2. You did not with your terse flippant responses. You are an unfriendly person. Good day, sir.

Offline althalus

  • Sr. Member
  • ****
  • Posts: 351
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #17 on: February 17, 2013, 04:54:27 PM »
Some thoughts after a quick poke:

- I would greatly prefer 3 seperate downloads for the 3 seperate platforms with layouts that make sense on each platform. The current download is a bit of a mess. (I understand it's a beta product, but I hope you have plans on cleaning this up eventually)

- Why g-wan? From what I can see, it doesn't support any real protocols - fastcgi? SCGI? WSGI? If the intent is a dev box that can be used for real world learning and development, it would make sense to equip it with a web server better equipped for real world web development - nginx, apache, lighttpd...

- What exactly IS the intent? You mention as a learning environment, but there aren't any tools or useful intructions provided on how to use it as such. (And Core is not really the most friendly of distros for beginners, so you really do need some clear getting started instructions, and some more included-by-default stuff to be a useful environment)

- The default site g-wan loads is broken. The examples links don't work.

- Why is it so slow? I have run qemu and virtualbox tinycore guests on this machine with much better performance than your double-click script is giving.

- What dots are you connecting that no one else has considered before? Pre-configured VMs have been available for a long time, and a large part of learning linux is getting the damn thing running in the first place, so I assume it's something more than that.

Offline MikeLevin

  • Newbie
  • *
  • Posts: 26
    • Mike Levin
Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #18 on: February 17, 2013, 09:45:55 PM »
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.
« Last Edit: February 17, 2013, 10:47:12 PM by MikeLevin »

Offline althalus

  • Sr. Member
  • ****
  • Posts: 351
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #19 on: February 17, 2013, 10:02:52 PM »
but then I encountered the resident junkyard dog

I don't have time to read and respond to your whole post right now, but while it's on my mind:

Without people like gerald_clark, my own understanding of linux would be miles behind where it is now. No offence intended to anybody on this board, but core tends to attract people who appear to more or less fit the grumpy old linux user stereotype to anybody outside the community - Don't assume that just because a response is very terse, that your idea is being shot to pieces, don't go immediately on the defensive just because someone wasn't as polite as you think they should have been, just ask for clarification.

Offline MikeLevin

  • Newbie
  • *
  • Posts: 26
    • Mike Levin
Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #20 on: February 17, 2013, 10:36:03 PM »
Yeah, I worked with that type at Commodore—lots of Unix and VAX types there. But Gerald suggested I remove the Linux kernel and the operating system from a distribution of a Linux kernel and an operating system on the grounds of it would be "easier" than abiding by GPL2.

There are plenty of alternative options that GPL2 allows in cases like this. Would you call his advice just being grumpy, or intentionally misleading and contrary to the spirit of Linux, the GPLs and a so-called remastering & remixing forum? Either way, I won't let one person turn me off to TCL. Thanks, althalus.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #21 on: February 18, 2013, 09:57:38 AM »
I made no such suggestion.
I simply asked where you posted your sources, and pointed you to the forum rules.

Offline MikeLevin

  • Newbie
  • *
  • Posts: 26
    • Mike Levin
Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #22 on: February 18, 2013, 03:02:18 PM »
I made no such suggestion.
I simply asked where you posted your sources, and pointed you to the forum rules.

You're right. It was sebus who made that comment, who had otherwise been supportive. I guess in hindsight, he's saying it somewhat facetiously—that it would be easier to just remove the OS than deal with the intolerant pedantics. But really, I never originally posted in this section. It was moved here by Rich from Micro Core.

So let me ask you flat-out Gerald—will rounding-up everyone's source code from the binaries I used and presenting it on links next to the link to the standalone version (like so many other GPL2 projects do) satisfy you (it certainly would satisfy the GPL2). Yes/no?
« Last Edit: February 18, 2013, 03:04:53 PM by MikeLevin »

aus9

  • Guest
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #23 on: February 18, 2013, 03:58:30 PM »
MikeLevin

Hi

But you appear to have read tinypoodle's link so probably know you need to look at
Quote
If you distribute binaries via FTP, you should distribute source via FTP.
for unchanged binaries

Speaking for myself, I don't think anyone here is going to report you, even tho you may have suggested people here are unfriendly
If you think of  unfriendly GPL policing can do to you, refresh your memory on the issue Mepis faced?
http://archive09.linux.com/articles/55285

But he was not distributing unchanged code. (I am not a lawyer just your local village idiot)

and as the local village idiot, whats wrong with supplying the source code at the same site?

Offtopic I know, but each extension submitted for checking has to include the source code. And TC puts that source code up here
http://tinycorelinux.net/4.x/x86/tcz/src/

of course I am aware there are some who don't use x86, this is just an example of compliance to guide you.

good luck


« Last Edit: February 18, 2013, 04:06:53 PM by aus9 »

Offline althalus

  • Sr. Member
  • ****
  • Posts: 351
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #24 on: February 18, 2013, 04:39:43 PM »
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
So, basically, I think I overlooked the role dropbox plays in your ideas.

Quote
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.
To be fair, an initial read of the docs doesn't make it clear how I could run most any of the code I've written, looked at, or worked with over the past 4 years. I'd be hesitant to even suggest using something like that for the small company I work at, let alone for enterprise level projects.

Quote
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.
Your idea sounds nice, but only emphasises the need the for rock solid documentation, though you seem to already be aware of and planning for that.


Quote
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.
Makes sense, and I'll be interested in seeing if you come up with a method for addressing the slow-ness.

Thanks for your reply. It will be interesting to see how your project pans out in the future.

Offline MikeLevin

  • Newbie
  • *
  • Posts: 26
    • Mike Levin
Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #25 on: February 18, 2013, 04:43:03 PM »
I now plan on distributing a copy of the source code to the binaries once I round them up. I have no problem with that. If it were put that way, I wouldn't have criticized the vibe here.

It's repeatedly telling me I'm breaking the rules of this section when I didn't even post here. I posted in another section that didn't have such rules, and it was transferred here.

It was also suggested I'd have to bloat the heck out of a 15MB file with all that source code or not be in license compliance. Who could ever do an embedded system?

When I said I'd put the source code download link main download, I just kept getting sent links as if to say that's still a violation, when its clearly compliant.
« Last Edit: February 18, 2013, 04:45:05 PM by MikeLevin »

Offline MikeLevin

  • Newbie
  • *
  • Posts: 26
    • Mike Levin
Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #26 on: February 18, 2013, 04:53:19 PM »
Althalus, you nailed it. Refinement of the beta will be HEAVY on documentation, a better initial "recipe" and a smoother transition of the README.txt into more docs accessible from the less command on another file after an SSH login to the VM from host, and then to more docs accessible over http://localhost:8080 and so on. Thanks for the feedback.

aus9

  • Guest
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #27 on: February 18, 2013, 05:27:33 PM »
MikeLevin
Quote
It was also suggested I'd have to bloat the heck out of a 15MB file with all that source code or not be in license compliance. Who could ever do an embedded system?

I think you are choosing your words pooly here, Sir. I don't believe anyone has made such a request. The suggestion is to have a download site where they download the fruits of your labour and downloads for the source code.

cheers

Online Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11178
Re: Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #28 on: February 18, 2013, 05:55:13 PM »
Hi MikeLevin
Quote
It's repeatedly telling me I'm breaking the rules of this section when I didn't even post here. I posted in another section that didn't have such rules, ....
The reason I moved this thread is because you posted an announcement for a repackaged Microcore, which means
it is no longer a Tinycore Linux product, but a MikeLevin product (Levinux ), which qualifies it as a respin.
As far as breaking rules is concerned, the only rule you broke was not making the sources available for download, and
that's not just a rule of this forum, but of the GPL which Microcore is licensed under. It applies because you offer your
respin to others, regardless of whether you ever posted on any of the Tinycore sub-forums.
« Last Edit: February 18, 2013, 06:29:06 PM by Rich »

Offline MikeLevin

  • Newbie
  • *
  • Posts: 26
    • Mike Levin
Run virtual linux for USB or Dropbox with no install on OS X, PCs or Linux
« Reply #29 on: February 18, 2013, 06:24:24 PM »
MikeLevin
Quote
It was also suggested I'd have to bloat the heck out of a 15MB file with all that source code or not be in license compliance. Who could ever do an embedded system?

I think you are choosing your words pooly here, Sir. I don't believe anyone has made such a request. The suggestion is to have a download site where they download the fruits of your labour and downloads for the source code.

cheers

Sorry, that's the way it came off: "Where's the source code, where's the source code, link, link, link..." I marked it clearly as beta, and collecting the source from these binaries and putting it on a download site is now clearly one of the things I need to do to refine the beta. And the README that was already there really does start to address this. It just came off as kicking.

The handling of me here was less than an inviting experience—hardly any explanation of the issue and absolutely no acknowledgement that my proposed solution of side-by-side download links would satisfy the GPL2.
« Last Edit: February 18, 2013, 06:43:59 PM by MikeLevin »