Tiny Core Linux
General TC => Remasters / Remixes - Unofficial => Topic started by: MikeLevin on February 15, 2013, 11:01:24 AM
-
Hello everyone. I have had an on and off pet project over the years, connecting a few dots that I haven't seen anyone connect yet—like Tiny Core Linux does in other ways. Anyway, the result is a file you can download, unzip and double-click to get a persistent Micro Core Linux from the desktop on a Mac, Windows or other Linux machine. No intall nor admin privileges are necessary on the host machine. It works well from USB.
Levinux also works particularly well with Dropbox, so even if you have a PC at work, a Mac or Linux machine at home, just fire-up your VM from out of your Dropbox, and there's the exact environment you left. I'm planning on making this a general Linux server learning platform for n00bs, walking them through SSH'ing in for the first time, creating a file, and reaching it from localhost:8080 on the host computer's browser, and so on.
Anyway, if this piques anyone's interest, you can download it from http://mikelev.in/levinux/
-
Nice one, thanks, might be really handy...
-
Where is the source?
-
I'm documenting where the binaries came from. They are the most common of all QEMU binaries. The Mac one is the Q project, latest stable (ancient). The PC one is from that Japanese site qemu.org links to (I'll update the README.txt) and the Linux one is from an Ubuntu apt-get command. I didn't compile my own binaries, because after many, many, many attempts I couldn't get something as stable, small, few dependencies as these very popular binary distributions. The source isn't included with Levinux because I'm trying to keep it to around 15MB, and I just haven't gone collecting it up for all these older version QEMU binaries. On my roadmap is either updating the binaries, or more fully documenting the ones I'm using and why.
-
http://tinycorelinux.net/faq.html#license
-
http://tinycorelinux.net/faq.html#license
Yeah, it's a beta. Don't get bent. The source code is available from each respective project, and I will make sure their licenses remain intact and are prominently displayed along with the location of original source. Look at the manifest in the readme. I didn't modify any source code. It's just put together as a robust multi-platform bootable system with non-compiled scripts (so "modified" source is included by definition with human-readable scripts). Are the GPL2 license obligations what you're talking about or something else?
-
Tinycore respins must offer their own copies of the sources. Pointing to tinycore is not sufficient.
-
Not really a respin, just bootable media, without code change
Anybody can manipulate the files in Levinux.zip\Levinux\Levinux on Mac.app\Contents\MacOS
-
Thanks @sebus for taking a moment to look at it before giving a knee jerk GPL2-cop response.
It sounds to me like what you're advocating @gerald_clark is that every Linux distro has to include the Linux kernel and commands source code even if it modifies no source code and keeps all the licenses and copyright notices intact.
Is that correct? Is that what you're saying?
Could you please give me number and section of GPL2 where it states that, or other sections you think I am violating, so I can address?
Thanks.
-
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#UnchangedJustBinary
-
Yeah, so all I have to do is find the original source to the binaries I'm using—should be avail—and stick it on Dropbox and refer back to it in my distro, so my download can stay 15MB. That sounds reasonable.
I would also like to point out that they say this is the "general rule" so that original source doesn't stop getting distributed from original source. A general rule is not a hard-and-fast rule for every instance, and the terse dismissive response I got here really made me feel unwelcome in this community.
Thanks to those who actually posted something useful. I will better adhere to the suggested spirit of GPL2 for code preservation purposes—which actually required information off the FAQ to clarify—and not the license itself, which does not explicitly state this.
-
and not the license itself, which does not explicitly state this.
It's sections 3a and 3b in the license:
http://www.gnu.org/licenses/gpl-2.0.html
3b would be hard for you to do if you didn't have a copy of the sources in the first place.
-
Just take out the vmlinuz & microcore.gz out & link to instructions for users to put them in to have the whole package
Easier & less trouble, sadly it does make one feel unwelcome
sebus
I think you're wrong. All I have to is distribute the code side by side with the download link of the binary. You're just making incorrect blanket statements about GPL2 and making me feel unwelcome. Good thing I can see through such nonsense. The term "accompanying it with" in sections 3 means a download link with the original binary is sufficient. Otherwise, every FOSS project that offers a binary-only download (and many do) would be in violation. Are you suggesting Live-CDs of Knoppix be distributed without the Linux boot kernel and that all embedded Linux products that use Busybox have BB source in the embedded device? Ridiculous. Methinks I detect pedantic troublemaking for its own sake.
-
It is not a matter of making you feel welcome or not.
You must follow the forum and project rules.
Before posting here you are to read and follow http://forum.tinycorelinux.net/index.php/topic,5543.0.html
-
I did not post in this section. I posted in Micro Core and it was moved here.
And it absolutely is about feeling welcome... it is a forum based on community and helping each other. People who say forums are not about making people feel welcome—even if they have the intention to comply with all the rules—just drive potential influx of new lifeblood for the forum away.
And I am not necessarily not in compliance with GPL2, and if I'm not, I really appreciate the constructive help of those who are not reactionist high horse police, and actually try to provide something useful in the refining of a Beta version specifically to address issues like this.
If the game here is dogpile on the rabbit, then it explains why TCL hasn't gained more popularity. Are you (gerald_clark) really the best the TCL community has to offer?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I made no such suggestion.
I simply asked where you posted your sources, and pointed you to the forum rules.
-
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?
-
MikeLevin
Hi
But you appear to have read tinypoodle's link so probably know you need to look at
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
-
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.
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.
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.
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.
-
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.
-
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.
-
MikeLevin
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
-
Hi MikeLevin
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.
-
MikeLevin
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.
-
The reason I moved this thread is because you posted an announcement for a repackaged Microcore...
...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 it to others, regardless of whether you ever posted on any of the Tinycore sub-forums.
Yeah, but perhaps I would have delayed my encountering Gerald. It's not like I'm ignoring the issue, but had I myself posted here first, I would have read the rules of this area and I may have had these GPL issues worked out better before asking for beta 1 input.
-
Hi MikeLevin
Yes, we all get it. You feel you've been wronged by gerald_clark. Now please, get over it, and let bygones be bygones.
-
Hi MikeLevin
Yes, we all get it. You feel you've been wronged by gerald_clark. Now please, get over it, and let bygones be bygones.
Okay, agreed. Fresh start.
-
I asked to see the source code because I was playing with the Levinux and wanted to see what changes you may have made to the old version of Core.
I simply asked where the source is because I wished to look at it. Don't get so bent out of shape.
-
Hi MikeLevin
Thank you.
@ALL: Before this thread goes down that path, I just want to remind everyone that this forum is not to be used for
support for respins. So please consider your subject matter before posting. MikeLevin will have to provide
support on his own site.
-
I asked to see the source code because I was playing with the Levinux and wanted to see what changes you may have made to the old version of Core.
I simply asked where the source is because I wished to look at it. Don't get so bent out of shape.
Sorry, it didn't seem that way, Gerald. I just extracted the microcore.gz and vmlinuz files from the iso, and made a script to do one-time running of Recipe scripts pulled over on first boot, and repacked microcore.gz and dropped them into location.
This simple trick should work with any kernel file named vmlinuz and initramfs-style boot image named microcore.gz. Thinking of changing microcore.gz to initramfs.gz to make it more clear its a totally generic system.
The way it gets tied to Micro Core Linux (or just Core Linux if updated) is the nature of the recipe scripts it can run on startup to build this particular server-type or that. The bash script named Recipe.sh is very tied to the TCE repository system. Conceivably, it could be tied to any repository system. Recipes are just bash scripts edited on the VM's host.
The specialness comes not from any compiling, but just a sort of magical cocktail mix that results in a non-brittle persistent cross-host-OS VM that is particularly Dropbox friendly. I realize I have GPL issues to resolve as the beta moves forward, as I am redistributing other people's GPL binaries.
Apologies for my part in coming off like an asshole. Not my intention.
-
Hi MikeLevin
Thank you.
@ALL: Before this thread goes down that path, I just want to remind everyone that this forum is not to be used for
support for respins. So please consider your subject matter before posting. MikeLevin will have to provide
support on his own site.
Yep, support/beta feedback forum already set up on mikelev.in/ux
Thanks, Rich.