TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!

[mikshaw]

I see what you're saying, and I suppose it is likely to be true.  There is also the language barrier, which sometimes causes misunderstandings.

What it looked like to me, though, is that Frink seemed to be making this thread for the purpose of listing everything he/she disagrees with, regardless of how petty the disagreement.  The very first post didn't help much either.  The tone of the title seemed to imply disapproval immediately.  Then there's the subject "Tiny Core from scratch".  There is no documentation for making Tiny Core from scratch, because it is a *distribution*.  It is, just like every other distribution, intended to be taken as-is...if the end user wants something different from it, that user makes changes to the distribution.  If you want to build a system from scratch, then you are not talking about an existing distribution, and TC does not fit with your plan.

[clivesay]

I am in agreement with mikshaw. It may be a language thing. I am not only here but in irc and hats tried and tried to have a discussion with this user about this subject. Although maybe unintentionally, this user became very belligerant because documentation for building TC from scratch was not readily available. He mentioned his "beef" was with roberts. He then moved his complaint to this forum. Here he laments why he has to document for other developers.

So, the tone was set by the user in IRC and then this thread. Everyone just needs to take a step back and not get into a war of words. It's a ridiculous excercise that goes nowhere.

Personally, I feel that roberts has provided a lot of information in this thread and that you have to expect that some things should be left for user trial, error and discovery.  Shoot, we are still experiencing those same things as a development team. This project is not even a month old!

So, let's please get back to working to move tinycore forward by working together and not against one another. 

Thanks,

Chris

[tobiaus]

fair enough, that sounds reasonable clivesay.

as someone who has done the linux world a great service by "remixing" one distro into another, i'm sure roberts will do what he can to help when the time comes for other people to do so with tc, with the understanding that primarily his interest is in tinycore, not in a hypothetical tiny-core-from-source. as far as i know he has never stood in anyone's way when it comes to the openness of linux, and it's too bad that the irc chat was not more productive. this issue- which may not be an issue at all- is likely to resolve itself as people find more time to document tc's features, but tc is rather new.

[Micon Frink]

It's now apparent from the last two weeks I've spent with TinyCoreLinux that nobody was prepared for someone like me who starts by asking how to take things apart while everyone else is trying to put things together. I guess it's the hacker in me. This is why I love open source...

A special word of thanks to mikshaw, clivesay and tobiaus for helping analyze this thread and keeping it from turning into a flame war. I often post terse language. It doesn't mean I'm mad at anyone. Just not at the best of terms with the current situation... - It's a Lemur Thing!


Roberts, I'm sorry if I've offended you. It was never my intent... I'm trying to figure out how to completely compile TinyCoreLinux from scratch for other architecture. I'd love to have a step by step guide but none exists. Thus, I'm logically inspecting the system so that I'll be able to make an exact copy when I do the cross-compile.

Curaga, you are right that I will probably ultimately be doing my own LFS. However, I've decided to first document building TinyCoreLinux from scratch. - I'm sure I won't be the last person seeking to build TinyCoreLinux for his/her own reasons. It seems that my questions were a nuisance to everyone so I'm attempting to alleviate the that burden by documenting my actions here.

Mikshaw, you are technically correct in your comments on copyright. However, when remixing software from many sources it gets legally complex. I've merely stated fact: Most script files are not labeled with a copyright notices or traceable origin. Since I come from a Debian background I'm more sensitive to legalities...

Hats, thank you for editing your earlier post to add more information. I've since edited mine also to remove some of the harsh edge off my frustration and explain myself better. As I said in the beginning of this post: It's more frustration at the situation than at any person.  - Again thanks for all your help!


I think if all scripts were provided in a tar with a LICENSE file it would solve the legal problems. I will create such a tarball as a part of my rebuild. I'd be happy to submit it back to the TinyCoreLinux team. This should make maintenance much easier as the number of scripts and custom files grows...

My note on lacking Makefile is not a complaint but a statement of fact. No Makefile means manually compiling each file. It is not a problem. These projects are insanely simple. However, it does mean that I must create a map of their install locations. My notes are nothing more than a careful map to recreate these pieces of the puzzle. It would be helpful to create a Makefile for these apps to aid in automated compiles.

It seems that TinyCoreLinux could be the ideal system for young hackers. I'm trying to provide a trail of breadcrumbs as I learn what makes TinyCoreLinux tick. I hope others asking similar questions find answers from this discussion. TinyCoreLinux is an awesome system: Beautifully Simple!!!

To answer my previous question: buildroot was not used for TinyCoreLinux. I missed in Roberts' earlier posts explaining that he chose not to use uClibc. Using buildroot seems like an ideal situation for my problem to automate the cross-compile generation of the core system. However, I will need to find a way around the use of uClibc if the goal is still to build a 100% copy of TinyCoreLinux.

More research needs to be done here...

"Why compile yourself when it's already been built?" - Said Microsoft to the Lemur...

[mikshaw]

I'm trying to figure out how to completely compile TinyCoreLinux from scratch for other architecture.

Now I'm beginning to understand your frustration.  My impression of "from scratch" has always been that it is a process of creating a fully customized system when existing distros don't suit your needs.  Even though it was mentioned more than once, for some reason I was overlooking that what you want is not to recreate TC in order to change it, but to recreate it so it will be exactly the same on a different processor.  I can understand how documentation for this would be very helpful, but as with any project the docs will always be a low priority until someone is found who actually enjoys writing them.  Not only is TC a very young project, but it also has a very small community made mostly of people who would much rather dive into the software than to document the process.

[tobiaus]

i very much hope you're able to figure it out, micon. there has been a lot of drama in the past with a couple of other source-related issues, and i side with roberts on that. ianal, but i follow gpl with great interest, and i'm reasonably certain he's always complied, even beyond what the license required. but i don't want to open that can of worms again.

i don't think this is about his compliance, but your desire to remix tc while complying with the gpl requirements you must follow. that's why you have to ask. if you are unable to eventually get the sources (and scripts) with the notices you need so that you can comply, then you may as you said, be required to sort of recreate the wheel. i hope it won't be necessary, but either way i hope you manage to build the distro you have in mind.

there is one other thought. asking the fsf how -you- may be able to comply and remix tc may yield an answer. more likely if you ask them than if you ask rms, who will probably not want to help someone remix a distro that (like almost all distros) includes those dreaded binary blobs. (though for me, i will probably be using binary blobs until the fsf opens a hardware store.)

what i'm saying is, the history of other distros has made "copyright" and "sources" words that makes everyone in the world of mini livecd's uneasy, and without need, mostly because of misunderstandings. tread lightly and best luck. i use linux because it can be remixed, and i probably care about it as much as you do. taking your time may decrease the amount of frustration for all involved and help in your effort. time may also offer additional options. i'd like to know how your project moves along.

[florian]

This thread is actually interesting as I too would really like to see tc (base + compile extension) running on other platforms than x86, especially on ARM on devices like the N800 Nokia internet tablet. I guess I'm also looking as tc as a potential lightweight alternative to mobile platforms like Android, iPhone, Maemo, ...

[Micon Frink]

florian: Welcome to the discussion. Please, feel free to contribute...

mikshaw: Glad you understand now. From scratch means starting with a blank slate. It doesn't have anything to do with intentions. Thanks again for your feedback.

tobiaus: The legal status of this project is very easily sorted out because the only issue in question is the scripts. (Which would likely to be replaced if TinyCore is used as a base.)

BusyBox has enough lawsuits out there to show developers how to comply. Basically, all we need to do is provide source and leave the copyright notices alone and we're on the golden path.

Most of Roberts scripts are GPL anyway - I think. Should the need for a remix arise it would be fairly easy to get Roberts to comply and host a tarball with GPL notice in a LICENSE file as mentioned earlier. (Especially if we provided the work of taring the stuff!) But using TinyCore as a jumping off point, most of the scripts would likely be excluded or completely rewritten so this is really a non-issue.

My cross-compilation to-do list:

• The scripts need to be extracted from the current iso and put into a tar.gz source file.
• The misc little cxx projects need to have Makefiles written so they can be scripted and preferably also tarred so it's easier for the toolchain to download them.
• Either buildroot or bitbake needs to be customized to build TinyCoreLinux from the provided sources...

I've been busy with other stuff the last few days. The next things I'm looking at is setting up a cross-compile toolchain on my system and start cranking. I'm pretty sure that LFS (the toolchain used to create TinyCoreLinux) is not the best solution for a multi-architectural building. I'm still looking into buildroot but I've also started experimenting with bitbake. The later seems much more full-featured but adds a layer of complexity that I'm not sure is really worth the added benefit of extra features. After the toolchain is setup it should be pretty simple to create a scripted process of cross-compilation to re-create the build...

"Did I mention Linux rocks?" - Said the Lemur. 6 out of 10 Lemurs nodded in agreement...
^{"The others were misinformed" He muttered. "Microsoft and Google Nazis never sleep!!!"}

[tobiaus]

i think your intentions are reasonable, micon, you want to use a linux project the way you're used to using it, in the spirit of how linux works, in particular the licensing. be careful with the word "comply," it's a charged word, i know what you meant, but in the world of mini distro's there always seems to be two levels of compliance: adequate, and ideal. (there is another, but it's not relevant here.) given the many years that roberts has worked with linux professionally, (he is not a mere naive hobbyist,) he has always complied adequately. with people stirring things up in the past about non-compliance (when all necessary, but perhaps not all "ideal" notices were absolutely used) it's only going to make people think (perhaps quite mistakenly) that you're being hostile.

one of the biggest misunderstandings (and here i sympathize) is that if you do not put a notice on your own script, it is free to use. this is a convention sometimes found online and in fact it's quite legit in many countries where software is created. you know and i know (and i believe roberts knows) that linux rests on copyleft, which rests on copyright.

including bash scripts without a copyright notice (in the united states) of course, means they are still copyrighted, regardless of the author's intentions, without permission you (technically) cannot use them. i get it. it feels less "open source." but that's never been the spirit of the way roberts does things,  he's not in any level of compliance lower than the average mini livecd author, nor any level you can stress without being misunderstood.

for the smaller scripts, the good news is some of them are so simple you can consider them in the public domain. (ianal, so get confirmation.) but i'm thinking of /usr/bin/showbootcodes. all it does is cat /proc/cmdline ...since there's no other reasonable way to do that, it's public domain. i'm sure if you want to remix the other more unique scripts in tinycore you'll be able to, if you're patient. it's still rc9, and rc4 was a month ago. people always write these things and formalize them with time. if there's something specific you need and don't know where to find it, being specific ("where are all the sources?" will cause misunderstanding) with what you can't find the source to will help, as will understanding that even if all distros are a "work in progress," some are particularly.

i realize it's asking more etiquette than license, but if you want to be practical and avoid misunderstanding, my advice is stress your desire to comply further, not the author's. after all, the design was his. he's not making it proprietary, or  making linux closed source or non-free-as-in-speech, and any little details (it would make me as happy as you) can be worked out with more honey than vinegar, if you're tactful, i think.  step back from it, only slightly, and i don't believe you'll be denied anything you -need- for your project. and naturally i am not telling you to do this. it is merely advice from someone who's been there before. if it takes six months of being misunderstood, i think it will be worth it. that's how it goes in the world of mini livecd's, but what matters is it can and will work out for you and the spirit of linux, without too much pushing. if it hasn't a year from now, call me a liar. but if you (even unintentionally) call someone else one, it will almost always lead to misunderstandings. good luck.

[Micon Frink]

Tobiaus, thanks for the reminder concerning etiquette and politics. Egos are not in short supply in the dev world. But most devs are NOT English teachers or politicians. We're just gonna say it the way we do and if people don't like that we're using a less than hip word... Well, as I said: Egos are not in short supply. Also opinion and misunderstanding about copyright make these issues less than static free...

And now the RANT begins...

Man I wish somebody built an easy-to-use scriptable cross-compile suite!!! Over the last week I've tried all 7 of the major free alternatives. most would not come close to working with TinyCoreLinux since they are either focused on the embedded market (dependence on glibc) or on the workstation/server market (extra libs galore - UGH!).

crosstool-ng, buildroot, ptxdist and switchbox all fall short in so many ways. They promise to make it easy to script an entire distro cross-compile but they deliver their own requirements (python, extra libs, etc). I still like buildroot the most because it's both logical and simple. However, the over dependence on uClibc cannot make it work for building a glibc toolchain which is what TinyCoreLinux needs.  I've looked into many LFS tools and they aren't any better!

Why use a cross-tool script? To make it easy fr more SKs (Script Kiddies), the ones who will likely be using TinyCoreLinux, to make the leap into the really exciting world of compiling everything youself - without having to go to something with lage filesize and long compile time. It's convenient but not required. Also, I don't really want to write up a "howto build a cross-compile toolchain from scratch" when all of this gets transfered to the wiki...

Thus my eager request: PLEASE, someone help me find a suitable cross-compile toolchain to marry with this project... Oh wouldn't that be so nice!


As to myself, I'm more and more shying away from using TinyCoreLinux in it's present state. My requirements now mandate GTK+2.0 so there goes 5MB! (as least!) And the other bundled software is gonna have a paypload of about 15 MB. Gonna be ough to get it under 25MB - which was my original goal. If it goes much higher than that we start to loose speed advantages of loading the core into initramfs. I'm getting fed-up cause I don't have much more time to devote to this. So I'm gonna build the bootstrap from scratch and grossly modify beyond recognition. Heh. Isn't that what this whole thread is about? :-P

"Don't hack up hairballs in public. It's not rude. It's just plain wrong..."

[tobiaus]

i don't know why you're trying to avoid glibc, it's all over tinycore, although for all i know, only in the little gui tools.

then again, i never was certain why you chose tinycore for this project. if you wanted to keep as much of tc's unique functionality, in the form of scripts and extension support, that's one thing. if you're only looking for a miniature example of a linux kernel, is tinycore's kernel really that unique? i wouldn't know.

but i presume if it's small enough for everything it does, it's small enough to be used for your project.

the compile environment may be larger than you want, only an issue i presume if you want to include the compiler. in your custom distro. tinycore has a compile environment, but as mentioned earlier i think, it was compiled in a distro that was at least slightly larger.

[Juanito]

tinycore has a compile environment, but as mentioned earlier i think, it was compiled in a distro that was at least slightly larger.

..the first pass was compiled in a larger distro (dsl-n), but then it was recompiled in tc itself.

[rhausafus]

I'd just like to say that Tiny Core has lived up to the stated goal extremely well, even though it's at version 1.0.

"Tiny Core Linux is a very small (10 MB) minimal Linux Desktop. It is based on Linux 2.6 kernel, Busybox, Tiny X, Fltk, and Jwm. The core runs entirely in ram and boots very quickly.

It is not a complete desktop nor is all hardware completely supported. It represents only the core needed to boot into a very minimal X desktop typically with wired internet access."

Like most of the other casual users, I have had my share of minor issues.........  It took me a few hours of reading through the forums (both TC and Knoppix) to find booting with "tinycore noapic waitusb=3" would cure my laptop freeze-up and backup/restore issues but so what?  The journey and exploration is half of the fun, and for that I thank everyone involved.

Constructive comments, suggestion, and certainly contributions seem to be welcomed by roberts and the other key players.  When the conversations begin to get contentious, people may start to miss the whole point.  The ease of posting instantaneous retorts can escalate matters very quickly.

Sorry for the long post, but thanks again.
Bob

[dentonlt]

I think the original goal was a good idea, but then ... it digressed. Conversation was interesting, to say the least.

Although newbies [like me] are interested in documentation, I don't think we're so much interested in knowing who is politically or ethically right/wrong. I think it would be good to have a guide on building/gathering/mix-matching TC from source, but ... not if it means I have to read philosophy at the same time.

I'm interested to see what you got done, Frink. If it doesn't work out, maybe I'll try my hand at the same project.

[tobiaus]

A T2 TCL target would be a great asset to TCL in case of future upgrades (like if security holes were found in the TCL glibc)

i would understand it that was met with skepticism, but do you think a tcl target for t2 could match the current build for performance? (i may not have understood the goals of t2, i thought it was to provide a standardized, interchangeable kernel/config, i didn't realize there were implications of the project towards greater security.)