Tiny Core Linux

Tiny Core Base => TCB Q&A Forum => Topic started by: Micon Frink on December 22, 2008, 08:49:24 PM

Title: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 22, 2008, 08:49:24 PM
"So where are the TinyCoreLinux from scratch docs?" - Said the Lemur to the Forum.

"There are none" - Said Hats.

"That's just not right!" Said the Lemur. "I must build my system from scratch. I guess if there are no docs I will have to find my way through the jungle alone..."

This is a chronicle of that journey...



I have a processor setup with special needs. Actually I have several processors with special needs including different architectures. While, I could just compile LFS (Linux From Scratch) I would still have to recreate most of the optimization/customizations that TinyCoreLinux has - such as running from RAM, acting as a network boot, light footprint etc.

I have decided to take it upon myself to document the process of building TinyCoreLinux from scratch to help others that might be interested in producing this low-fat portable Linux. In the process I'll be able to compile for my architectures and get what I need out of it. It would be great if you could provide background info on how TinyCoreLinux was created. Otherwise I'll hack away until I figure it out on my own.  Any help would be appreciated...
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: ^thehatsrule^ on December 22, 2008, 11:23:24 PM
TC is designed to be a solid base in which the user can easily build around it.  Do you mean you want to compile for another processor/platform?

In any case, here is my attempt to answer your question (afaik) since I suppose someone else may want to ask it:

Some 'history':
- started building on finnix (might have had some some stuff from slitaz), then the rest was done on TC
- init/startup scripts created/included/adapted, for busybox and others
- included c++/fltk apps that were ported/recoded from rs's original lua/fltk ones
- standard libs included in base
- others built with compiletc which itself had its own early stages built on DSL-N (not sure what exactly was (re)built with it - I know at least the kernel was though)
- additional fixes, changes

Perhaps you were looking for exact step by step instructions, rather than some history - iirc, there were problems that occurred on the (original) machine that prevents getting the starting data/steps.  However, I believe that compiletc is quite robust.  I'm pretty sure one could use that to build another TC "from the start", if you wish to go down that path... though I can't see why you'd want to atm.

And LFS is a good place to start and for reference - though I can't say how much was used as a guide
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Juanito on December 23, 2008, 12:20:01 AM
- others built with compiletc which itself had its own early stages built on DSL-N (not sure what exactly was (re)built with it - I know at least the kernel was though)
dsl-n was used as the host system in a linux-from-scratch type build/re-build of gcc to create compiletc
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: curaga on December 23, 2008, 03:09:39 AM
It's possible LFS matches your needs more, as it's a complete guide for making your own system.

If you want to have it more easily and use TC as the base, optimizing everything has very small effects on the end result; by optimizing the parts you use the most, you can gain almost as much as by optimizing everything, but much more easily. This would mean busybox as it has the shell, the kernel, and then your specific apps and the libs they use.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: roberts on December 23, 2008, 07:59:01 AM
This was my big bang! I used finnix to create my first cpio initramfs with hello.
Quote
1   ramfs, rootfs and initramfs
2   October 17, 2005
3   Rob Landley <rob[AT]landley[DOT]net>
4   =============================
5   
6   What is ramfs?
7   --------------
8   
9   Ramfs is a very simple filesystem that exports Linux's disk caching
10   mechanisms (the page cache and dentry cache) as a dynamically resizable
11   RAM-based filesystem.
12   
13   Normally all files are cached in memory by Linux.  Pages of data read from
14   backing store (usually the block device the filesystem is mounted on) are kept
15   around in case it's needed again, but marked as clean (freeable) in case the
16   Virtual Memory system needs the memory for something else.  Similarly, data
17   written to files is marked clean as soon as it has been written to backing
18   store, but kept around for caching purposes until the VM reallocates the
19   memory.  A similar mechanism (the dentry cache) greatly speeds up access to
20   directories.
21   
22   With ramfs, there is no backing store.  Files written into ramfs allocate
23   dentries and page cache as usual, but there's nowhere to write them to.
24   This means the pages are never marked clean, so they can't be freed by the
25   VM when it's looking to recycle memory.
26   
27   The amount of code required to implement ramfs is tiny, because all the
28   work is done by the existing Linux caching infrastructure.  Basically,
29   you're mounting the disk cache as a filesystem.  Because of this, ramfs is not
30   an optional component removable via menuconfig, since there would be negligible
31   space savings.
32   
33   ramfs and ramdisk:
34   ------------------
35   
36   The older "ram disk" mechanism created a synthetic block device out of
37   an area of RAM and used it as backing store for a filesystem.  This block
38   device was of fixed size, so the filesystem mounted on it was of fixed
39   size.  Using a ram disk also required unnecessarily copying memory from the
40   fake block device into the page cache (and copying changes back out), as well
41   as creating and destroying dentries.  Plus it needed a filesystem driver
42   (such as ext2) to format and interpret this data.
43   
44   Compared to ramfs, this wastes memory (and memory bus bandwidth), creates
45   unnecessary work for the CPU, and pollutes the CPU caches.  (There are tricks
46   to avoid this copying by playing with the page tables, but they're unpleasantly
47   complicated and turn out to be about as expensive as the copying anyway.)
48   More to the point, all the work ramfs is doing has to happen _anyway_,
49   since all file access goes through the page and dentry caches.  The RAM
50   disk is simply unnecessary; ramfs is internally much simpler.
51   
52   Another reason ramdisks are semi-obsolete is that the introduction of
53   loopback devices offered a more flexible and convenient way to create
54   synthetic block devices, now from files instead of from chunks of memory.
55   See losetup (8) for details.
56   
57   ramfs and tmpfs:
58   ----------------
59   
60   One downside of ramfs is you can keep writing data into it until you fill
61   up all memory, and the VM can't free it because the VM thinks that files
62   should get written to backing store (rather than swap space), but ramfs hasn't
63   got any backing store.  Because of this, only root (or a trusted user) should
64   be allowed write access to a ramfs mount.
65   
66   A ramfs derivative called tmpfs was created to add size limits, and the ability
67   to write the data to swap space.  Normal users can be allowed write access to
68   tmpfs mounts.  See Documentation/filesystems/tmpfs.txt for more information.
69   
70   What is rootfs?
71   ---------------
72   
73   Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is
74   always present in 2.6 systems.  You can't unmount rootfs for approximately the
75   same reason you can't kill the init process; rather than having special code
76   to check for and handle an empty list, it's smaller and simpler for the kernel
77   to just make sure certain lists can't become empty.
78   
79   Most systems just mount another filesystem over rootfs and ignore it.  The
80   amount of space an empty instance of ramfs takes up is tiny.
81   
82   What is initramfs?
83   ------------------
84   
85   All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
86   extracted into rootfs when the kernel boots up.  After extracting, the kernel
87   checks to see if rootfs contains a file "init", and if so it executes it as PID
88   1.  If found, this init process is responsible for bringing the system the
89   rest of the way up, including locating and mounting the real root device (if
90   any).  If rootfs does not contain an init program after the embedded cpio
91   archive is extracted into it, the kernel will fall through to the older code
92   to locate and mount a root partition, then exec some variant of /sbin/init
93   out of that.
94   
95   All this differs from the old initrd in several ways:
96   
97     - The old initrd was always a separate file, while the initramfs archive is
98       linked into the linux kernel image.  (The directory linux-*/usr is devoted
99       to generating this archive during the build.)
100   
101     - The old initrd file was a gzipped filesystem image (in some file format,
102       such as ext2, that needed a driver built into the kernel), while the new
103       initramfs archive is a gzipped cpio archive (like tar only simpler,
104       see cpio(1) and Documentation/early-userspace/buffer-format.txt).  The
105       kernel's cpio extraction code is not only extremely small, it's also
106       __init text and data that can be discarded during the boot process.
107   
108     - The program run by the old initrd (which was called /initrd, not /init) did
109       some setup and then returned to the kernel, while the init program from
110       initramfs is not expected to return to the kernel.  (If /init needs to hand
111       off control it can overmount / with a new root device and exec another init
112       program.  See the switch_root utility, below.)
113   
114     - When switching another root device, initrd would pivot_root and then
115       umount the ramdisk.  But initramfs is rootfs: you can neither pivot_root
116       rootfs, nor unmount it.  Instead delete everything out of rootfs to
117       free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
118       with the new root (cd /newmount; mount --move . /; chroot .), attach
119       stdin/stdout/stderr to the new /dev/console, and exec the new init.
120   
121       Since this is a remarkably persnickety process (and involves deleting
122       commands before you can run them), the klibc package introduced a helper
123       program (utils/run_init.c) to do all this for you.  Most other packages
124       (such as busybox) have named this command "switch_root".
125   
126   Populating initramfs:
127   ---------------------
128   
129   The 2.6 kernel build process always creates a gzipped cpio format initramfs
130   archive and links it into the resulting kernel binary.  By default, this
131   archive is empty (consuming 134 bytes on x86).
132   
133   The config option CONFIG_INITRAMFS_SOURCE (for some reason buried under
134   devices->block devices in menuconfig, and living in usr/Kconfig) can be used
135   to specify a source for the initramfs archive, which will automatically be
136   incorporated into the resulting binary.  This option can point to an existing
137   gzipped cpio archive, a directory containing files to be archived, or a text
138   file specification such as the following example:
139   
140     dir /dev 755 0 0
141     nod /dev/console 644 0 0 c 5 1
142     nod /dev/loop0 644 0 0 b 7 0
143     dir /bin 755 1000 1000
144     slink /bin/sh busybox 777 0 0
145     file /bin/busybox initramfs/busybox 755 0 0
146     dir /proc 755 0 0
147     dir /sys 755 0 0
148     dir /mnt 755 0 0
149     file /init initramfs/init.sh 755 0 0
150   
151   Run "usr/gen_init_cpio" (after the kernel build) to get a usage message
152   documenting the above file format.
153   
154   One advantage of the configuration file is that root access is not required to
155   set permissions or create device nodes in the new archive.  (Note that those
156   two example "file" entries expect to find files named "init.sh" and "busybox" in
157   a directory called "initramfs", under the linux-2.6.* directory.  See
158   Documentation/early-userspace/README for more details.)
159   
160   The kernel does not depend on external cpio tools.  If you specify a
161   directory instead of a configuration file, the kernel's build infrastructure
162   creates a configuration file from that directory (usr/Makefile calls
163   scripts/gen_initramfs_list.sh), and proceeds to package up that directory
164   using the config file (by feeding it to usr/gen_init_cpio, which is created
165   from usr/gen_init_cpio.c).  The kernel's build-time cpio creation code is
166   entirely self-contained, and the kernel's boot-time extractor is also
167   (obviously) self-contained.
168   
169   The one thing you might need external cpio utilities installed for is creating
170   or extracting your own preprepared cpio files to feed to the kernel build
171   (instead of a config file or directory).
172   
173   The following command line can extract a cpio image (either by the above script
174   or by the kernel build) back into its component files:
175   
176     cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames
177   
178   The following shell script can create a prebuilt cpio archive you can
179   use in place of the above config file:
180   
181     #!/bin/sh
182   
183     # Copyright 2006 Rob Landley <rob[AT]landley.net> and TimeSys Corporation[DOT]
184     # Licensed under GPL version 2
185   
186     if [ $# -ne 2 ]
187     then
188       echo "usage: mkinitramfs directory imagename.cpio.gz"
189       exit 1
190     fi
191   
192     if [ -d "$1" ]
193     then
194       echo "creating $2 from $1"
195       (cd "$1"; find . | cpio -o -H newc | gzip) > "$2"
196     else
197       echo "First argument must be a directory"
198       exit 1
199     fi
200   
201   Note: The cpio man page contains some bad advice that will break your initramfs
202   archive if you follow it.  It says "A typical way to generate the list
203   of filenames is with the find command; you should give find the -depth option
204   to minimize problems with permissions on directories that are unwritable or not
205   searchable."  Don't do this when creating initramfs.cpio.gz images, it won't
206   work.  The Linux kernel cpio extractor won't create files in a directory that
207   doesn't exist, so the directory entries must go before the files that go in
208   those directories.  The above script gets them in the right order.
209   
210   External initramfs images:
211   --------------------------
212   
213   If the kernel has initrd support enabled, an external cpio.gz archive can also
214   be passed into a 2.6 kernel in place of an initrd.  In this case, the kernel
215   will autodetect the type (initramfs, not initrd) and extract the external cpio
216   archive into rootfs before trying to run /init.
217   
218   This has the memory efficiency advantages of initramfs (no ramdisk block
219   device) but the separate packaging of initrd (which is nice if you have
220   non-GPL code you'd like to run from initramfs, without conflating it with
221   the GPL licensed Linux kernel binary).
222   
223   It can also be used to supplement the kernel's built-in initramfs image.  The
224   files in the external archive will overwrite any conflicting files in
225   the built-in initramfs archive.  Some distributors also prefer to customize
226   a single kernel image with task-specific initramfs images, without recompiling.
227   
228   Contents of initramfs:
229   ----------------------
230   
231   An initramfs archive is a complete self-contained root filesystem for Linux.
232   If you don't already understand what shared libraries, devices, and paths
233   you need to get a minimal root filesystem up and running, here are some
234   references:
235   http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
236   http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
237   http://www.linuxfromscratch.org/lfs/view/stable/
238   
239   The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is
240   designed to be a tiny C library to statically link early userspace
241   code against, along with some related utilities.  It is BSD licensed.
242   
243   I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net)
244   myself.  These are LGPL and GPL, respectively.  (A self-contained initramfs
245   package is planned for the busybox 1.3 release.)
246   
247   In theory you could use glibc, but that's not well suited for small embedded
248   uses like this.  (A "hello world" program statically linked against glibc is
249   over 400k.  With uClibc it's 7k.  Also note that glibc dlopens libnss to do
250   name lookups, even when otherwise statically linked.)
251   
252   A good first step is to get initramfs to run a statically linked "hello world"
253   program as init, and test it under an emulator like qemu (www.qemu.org) or
254   User Mode Linux, like so:
255   
256     cat > hello.c << EOF
257     #include <stdio.h>
258     #include <unistd.h>
259   
260     int main(int argc, char *argv[])
261     {
262       printf("Hello world!\n");
263       sleep(999999999);
264     }
265     EOF
266     gcc -static hello2.c -o init
267     echo init | cpio -o -H newc | gzip > test.cpio.gz
268     # Testing external initramfs using the initrd loading mechanism.
269     qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero
270   
271   When debugging a normal root filesystem, it's nice to be able to boot with
272   "init=/bin/sh".  The initramfs equivalent is "rdinit=/bin/sh", and it's
273   just as useful.
274   
275   Why cpio rather than tar?
276   -------------------------
277   
278   This decision was made back in December, 2001.  The discussion started here:
279   
280     http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html
281   
282   And spawned a second thread (specifically on tar vs cpio), starting here:
283   
284     http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html
285   
286   The quick and dirty summary version (which is no substitute for reading
287   the above threads) is:
288   
289   1) cpio is a standard.  It's decades old (from the AT&T days), and already
290      widely used on Linux (inside RPM, Red Hat's device driver disks).  Here's
291      a Linux Journal article about it from 1996:
292   
293         http://www.linuxjournal.com/article/1213
294   
295      It's not as popular as tar because the traditional cpio command line tools
296      require _truly_hideous_ command line arguments.  But that says nothing
297      either way about the archive format, and there are alternative tools,
298      such as:
299   
300        http://freshmeat.net/projects/afio/
301   
302   2) The cpio archive format chosen by the kernel is simpler and cleaner (and
303      thus easier to create and parse) than any of the (literally dozens of)
304      various tar archive formats.  The complete initramfs archive format is
305      explained in buffer-format.txt, created in usr/gen_init_cpio.c, and
306      extracted in init/initramfs.c.  All three together come to less than 26k
307      total of human-readable text.
308   
309   3) The GNU project standardizing on tar is approximately as relevant as
310      Windows standardizing on zip.  Linux is not part of either, and is free
311      to make its own technical decisions.
312   
313   4) Since this is a kernel internal format, it could easily have been
314      something brand new.  The kernel provides its own tools to create and
315      extract this format anyway.  Using an existing standard was preferable,
316      but not essential.
317   
318   5) Al Viro made the decision (quote: "tar is ugly as hell and not going to be
319      supported on the kernel side"):
320   
321         http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html
322   
323      explained his reasoning:
324   
325         http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
326         http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
327   
328      and, most importantly, designed and implemented the initramfs code.
329   
330   Future directions:
331   ------------------
332   
333   Today (2.6.16), initramfs is always compiled in, but not always used.  The
334   kernel falls back to legacy boot code that is reached only if initramfs does
335   not contain an /init program.  The fallback is legacy code, there to ensure a
336   smooth transition and allowing early boot functionality to gradually move to
337   "early userspace" (I.E. initramfs).
338   
339   The move to early userspace is necessary because finding and mounting the real
340   root device is complex.  Root partitions can span multiple devices (raid or
341   separate journal).  They can be out on the network (requiring dhcp, setting a
342   specific MAC address, logging into a server, etc).  They can live on removable
343   media, with dynamically allocated major/minor numbers and persistent naming
344   issues requiring a full udev implementation to sort out.  They can be
345   compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,
346   and so on.
347   
348   This kind of complexity (which inevitably includes policy) is rightly handled
349   in userspace.  Both klibc and busybox/uClibc are working on simple initramfs
350   packages to drop into a kernel build.
351   
352   The klibc package has now been accepted into Andrew Morton's 2.6.17-mm tree.
353   The kernel's current early boot code (partition detection, etc) will probably
354   be migrated into a default initramfs, automatically created and used by the
355   kernel build.
I opted not to use uClibc and the external cpio for easy remastering.
Most of the concepts of design philosophy I created over the last five years as the main developer of the Damn Small Linux project. I ported them and improved them. Actually when I created DSL-N, it too was a tiny core, but I was strongly discouraged from  releasing it. The new capability inherit in the 2.6 kernel was exactly what I was looking for. to host my philosophy. Originally I also deployed Siltaz lzma kernel patches for even smaller core, but later dropped lzma for improved speed in booting.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 23, 2008, 12:23:15 PM
Thanks Roberts, Hats & Curaga!

Especially thanks to Hats for the edits to his post which make things much clearer. I understand much better the philosophical composition choices made. Now the real question is finding the list of customize script from the base system.

Roberts: Didn't you keep some kind of development log or something? Seems kinda irresponsible to just post source code without compilation instructions. I guess this is a work-in-progress and not yet well documented. It'd be nice to know exactly what was done from the base system.

- FRINK
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 24, 2008, 11:20:56 AM
OK! ...So I've been snooping around in TinyCore taking it apart.  Basically, snooping because nobody is explaining how it works and I've gotta compile for some really different situations... Anyhow, so far I've found the following:

/init is linked to /bin/busybox (this is the initial process run by the kernel)
/bin/busybox runs /etc/inittab
/etc/inittab starts /etc/init.d/rcS which is linked to /etc/init.d/tc-config
/etc/init.d/tc-config is 468 line init script that brings everything up...

Most of /etc/init.d is custom:

/etc/init.d/tc-config - startup script
/etc/init.d/rc.shutdown - shutdown script
/etc/init.d/dhcp.sh - dhcp init script (called by rcS)
/etc/init.d/tc-functions - common include file
/etc/init.d/tc-restore.sh - script to restore personal data
/etc/init.d/functions.lua - may be residue left over from DSL since there is no LUA in TinyCore
/etc/init.d/dropbear - ssh server

The system seems pretty much stock from make install except for these scripts.
But I've not gone through with a fine-toothed comb...

- FRINK
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 24, 2008, 02:00:09 PM
/etc/dialogrc - customized with Slackware colors (seems to be non-stock)
/etc/hostname - "box"
/etc/hosts - "127.0.0.1   box   localhost"
/etc/inittab - commented tty2-6 lines also added:

    ::sysinit:/etc/init.d/rcS

    ::restart:/etc/init.d/rc.shutdown
    ::restart:/sbin/init
    ::ctrlaltdel:/sbin/reboot
    ::shutdown:/etc/init.d/rc.shutdown

/etc/issue - "Tiny Core GNU/Linux Kernel"
/etc/modt - contains:

     (?-
     //\  Tiny Core is distributed with ABSOLUTELY NO WARRANTY.
     v_/_           www.tinycorelinux.com

/etc/network.conf - default addresses specified
/etc/shadow - tc was added I'm not sure what others...

    tc::13646:0:99999:7:::

/etc/sudoers - added tc:

tc   ALL=NOPASSWD: ALL

everything in /opt/ is custom.
everything in /etc/skel/ is custom. (these are all dot files so you have to use ls -a)
everything in /root/ is custom. (these are all dot files so you have to use ls -a)

---

To my knowledge these are all the custom files present in the system. I'm sure there are more that I missed. It's a bit frustrating going through things this way but I guess if there is no documentation someone needs to do it. "Leave it to the Lemurs" - I always say.


- FRINK

Coding without documentation is like rice without curry... Oh well, guess I'm providing the curry...
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: ^thehatsrule^ on December 24, 2008, 03:17:55 PM
Please remember the previous conversation, your assumptions, and the previous replies in this thread.

Also, there is the edit button if you plan on changing your post.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 24, 2008, 09:20:04 PM
Hats,

Building software from source should be a community affair. However, the documentation for building the source into a fully functioning TinyCoreLinux is missing. How are others supposed to download the system and improve it to submit changes without a basic "howto from scratch"? Thus I'm going at it piece by piece. You can help document the thing or sit back and watch. It's really your choice...

- FRINK
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: ^thehatsrule^ on December 24, 2008, 10:55:31 PM
Okay then.  I'll give one reminder: respect is paramount in communities.

Hints on starting rolling your own was given, and it was already explained that there was no build system, nor retrievable 'log'.  And that busybox was used, scripts are plaintext, etc.  I'll still say that I am not sure what you are trying to ask for (vague).  To answer your previous question though, currently improvements are done by modifying the corresponding parts of the system.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 26, 2008, 02:36:25 AM
Hats, I have the utmost respect for the community and for your lack of understanding. Thanks for your input - I really do appreciate it. Sorry I'm not communicating in your brand of English. I'll post a build script when I've got one I guess...

Looking at the unique parts I wonder if buildroot (http://buildroot.uclibc.org/buildroot.html) was have used to generate the base system. If this is true it would be helpful to have the buildroot config files. However, I don't find these in the source so perhaps the base file system was made by hand. Then again the init scripts are not in the src either. Hm... I'll be testing out this theory next week and post my results...


I noticed that most of the contents of /usr/bin/ are custom scripts and programs.

The following is a list of scripts unique to TinyCoreLinux:

desktop.sh, exitcheck.sh, filetool.sh, floppytool.sh, getTime.sh, menu.awk, mkcryptohome, mktclocal, search.sh, set_jwm_background.awk, showbootcodes, startx, tce2tcz.sh, tce-fetch.sh, tce-load, tc-terminal-server, tcz-unistall, text2lp0, wbar.sh, xsetup.sh

These scripts are not included in the TinyCoreLinux source directory so they will need to be copied from the current distro ISO directly. Ideally these should be placed in a tarball in the source tree. Perhaps I can create that tarball.

LEGALITY: Many of these scripts do not bear proper reference to copyright. Some of them don't seem to originate with TinyCoreLinux but have no reference information to their origination. Could it be that these are carry-over from DSL?


The following binaries are also included in the /usr/bin/ directory:

add2file, appbrowser, cpanel, datetool, exittc, fdtool, filetool, flrun, help, mnttool, mousetool, netcardconf, popask, popup, settheme, stats, swapfile, tcemirror, wallpaper, watcher

All of these are original work for TinyCoreLinux and their source resides in the fltk_projects/ directory of the source tree. There is however, one exception: watcher is in the base of the source tree. None of these apps have a Makefile but usually consist of three files <foo>.cxx, <foo>.h and <foo>.fl

LEGALITY: Some of these programs seem to have originated with DSL but there the references in source are incomplete. I'm not sure if there are any license issues with this as both distros use the same license.


SIDE NOTE: The source tree and releases have been removed from the tinycorelinux.com server and now reside on distro.ibiblio.org/pub/linux/distributions/tinycorelinux/
 (http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/). This was not noted on the main site so I thought I'd mention it here. I was frustrated for a  minutes trying to find the source. The link to the download directory on the tinycorelinux.com website has been changed to reflect this new location. Not a big deal just a minor frustration that takes up space here...

- FRINK
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: mikshaw on December 26, 2008, 05:50:56 AM
There's an English expression (probably derive from an earlier source) "making mountains out of molehills".  Much of what you have just mentioned has no real importance.

Quote
Many of these scripts do not bear proper reference to copyright.
It's up to the author to decide whether copyright is necessarily included.  If there is no copyright notice in these scripts, there never was one.
Quote
Some of them don't seem to originate with TinyCoreLinux but have no reference information to their origination.
They originate with roberts and others who wrote for roberts.
Quote
None of these scripts are included in the TinyCoreLinux source directory.
Scripts are already in source form.

Quote
None of these apps have makefiles but usually consist of three files <foo>.cxx, <foo>.h and <foo>.fl.
Makefiles are not a requirement for building software.
Quote
Some of these programs seem to have originated with DSL but there the references in source are incomplete.
As with the scripts, they were written by roberts and his minions.  It is not necessary for an author to reference the origin of his own work.

Quote
This should be noted prominently on the website but wasn't. However, the link to the download directory has been changed to reflect this new location.
What is the complaint here? The server changed, that's all.  All the links are the same as they were; it's just as easy to access the source.


Doing things differently is not the same as doing things wrong.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: roberts on December 26, 2008, 06:03:18 AM
Yeah, your're right I don't always put a copywrite banner on every dinky plain text script that I write. And that most of Tiny Core consists of my custom stuff. So what.
Now this thread is turned into your personal blog area, where you are the critic down to the minutiae. I find your actions and attitude very curious. You seem to have nothing to contribute but only to complain about absolutely everything. 
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: tobiaus on December 26, 2008, 04:04:09 PM
Okay then.  I'll give one reminder: respect is paramount in communities.

Hints on starting rolling your own was given, and it was already explained that there was no build system, nor retrievable 'log'. 

Yeah, your're right I don't always put a copywrite banner on every dinky plain text script that I write. And that most of Tiny Core consists of my custom stuff. So what.
Now this thread is turned into your personal blog area, where you are the critic down to the minutiae. I find your actions and attitude very curious. You seem to have nothing to contribute but only to complain about absolutely everything. 

whoa whoa whoa! this is totally unnecessary... no one's said anything to make it necessary to come down on him like this. no one's being disrespectful. this same thing happened with puppy linux years ago... and i've always known dsl and roberts to be far less uptight about these things. in general, i've always counted on the dsl community to if nothing else, have a more professional image, or at least a more meticulous, less sloppy one.

as for "so what," i mean no disrespect either. only that in the open source world, it's expected that you be able to modify things, just as dsl was (THANKFULLY) modified by roberts, and thus made into the best dsl that dsl ever was. some people just take code and aren't careful with it. they mean well, and no one's being accused of anything. only sometimes people want to make a new distro, or adapt it to a new platform (that's the case here,) and they want to follow all the rules.

that means they have to ask where the stuff comes from. so if no one provided copyright information, that's not a problem for roberts, because roberts is the author.

it's only a problem for the original poster, who wants to respect roberts copyright and use it per a gpl license or something. he just wants to respect the rules. so unless roberts gives him formal permission (or writes copyright information on each script, or as a collection of scripts) then anyone trying to respect roberts (and the gpl) has to ask more than once.

please don't be mad at him for that. if anything, he should be applauded. and it is certainly not disrespectful.

Please remember that this is a public forum, so interpreting messages 'lightly' in general would be helpful.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: mikshaw on December 26, 2008, 06:42:14 PM
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: clivesay on December 26, 2008, 07:52:13 PM
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
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: tobiaus on December 26, 2008, 09:32:09 PM
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 28, 2008, 03:32:21 AM
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...

Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: mikshaw on December 28, 2008, 11:04:21 AM
Quote
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: tobiaus on December 29, 2008, 08:49:52 AM
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: florian on December 29, 2008, 11:11:41 AM
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, ...
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on December 30, 2008, 09:51:52 PM
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:


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!!!"
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: tobiaus on December 31, 2008, 07:14:35 AM
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Micon Frink on January 06, 2009, 03:32:53 AM
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..."
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: tobiaus on January 06, 2009, 10:52:23 AM
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: Juanito on January 06, 2009, 07:42:57 PM
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: rhausafus on January 06, 2009, 08:10:48 PM
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

Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: dentonlt on January 16, 2009, 02:08:56 PM
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.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: tobiaus on March 23, 2009, 10:27:04 PM
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.)
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: ScorpKing on April 08, 2009, 06:22:44 AM
Some of the comments here make me sad. I'm still looking for documentation on how to remove all the GUI stuff. How do I remove extentions and how do I add them? What do I do if I want to use TinyCore to run a small website from a liveCD on my local network? It would be extremely usefull to have a document that explains how everything works in detail. I'd love to contribute to the project but it will take some time to figure everything out first. Where do I start? Btw, I'm in love with TinyCore and a big thank you & well done to those who made it.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: bigpcman on April 08, 2009, 07:16:26 AM
Some of the comments here make me sad. I'm still looking for documentation on how to remove all the GUI stuff. How do I remove extentions and how do I add them? What do I do if I want to use TinyCore to run a small website from a liveCD on my local network? It would be extremely usefull to have a document that explains how everything works in detail. I'd love to contribute to the project but it will take some time to figure everything out first. Where do I start? Btw, I'm in love with TinyCore and a big thank you & well done to those who made it.

We all have to start somewhere. I started out last December with very little knowledge about TC with some of your same objectives. I used this forum to guide me through all the areas that were new to me. Many times you will find there is no generic documentation that will apply to your specific problem. I have found this forum to be of immense help covering many different subjects that go beyond TC. My advice is to just get started and post questions. You will find forum members will help you.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: tobiaus on April 08, 2009, 08:53:37 AM
Some of the comments here make me sad. I'm still looking for documentation on how to remove all the GUI stuff. How do I remove extentions and how do I add them?

when you first boot tc, you have no extensions. i would love if the entire gui was an extension (so long as it was included in the .iso file!) then you'd only need to delete the extension from your "frugal" install (or use a boot code to ignore it on cd) to not load it into ram. gui users would have it just as easy as they do now, non-gui users would have it easier than they do now.

without extensions, tc consists of a bootloader, and bzImage, and tinycore.gz. in other words pretty much everything you see the first time you boot (including the gui) is in tinycore.gz, known as the "core" or the "base."

remastering instructions (on the wiki) tell you how to open up bzImage and tinycore.gz so you can remove things from the base. i realize i haven't answered all your questions, but then i don't know all the answers, so hopefully this is a useful place for you to begin.

(it's also possible to boot: tinycore text to boot into text mode, but that's probably not what you wanted, because all the stuff for the gui is still being loaded into ram and startx will start the gui.)
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: ScorpKing on April 08, 2009, 08:58:03 AM
Thanks guys
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: nickispeaki on April 09, 2009, 12:06:51 PM
So....
I hoped Frink make a miracle and we (i) 'll see rising star - TCFS! But....

So, I'm looking for answers on my question - how tcl make desktop-friendly system? Of course, sound, video, flash, unrar, text editor and fast and little and simple. And beautiful! ;-)

Thanks to Robert and co for this distro!

Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: madshib on October 09, 2013, 05:48:02 AM
This is very interesting!

Has there been anyone tackling the idea of porting TC to other, older platforms....such as the m68k?

I think that those still running Amigas and Ataris could most certainly benefit from a distro of this size and nature!
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: gerald_clark on October 09, 2013, 06:04:36 AM
IIRC, those machines lacked a MMU.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: bmarkus on October 09, 2013, 06:16:53 AM
Check recent linux kernel supported arch.
Title: Re: TinyCore from SCRATCH - NADA -ZILCH - ZIP - NULL - - - THE BIG BANG!!!
Post by: madshib on October 09, 2013, 05:45:00 PM
http://www.debian.org/ports/m68k/

Debian developers are currently working on reviving support for the architecture. I am anxious to see this realized, but also am a big fan of the smaller distros, despite my lack of experience with their usage. I have messed with Puppy a bit, but am excited to try Tiny Core. Seeing it's light nature, it could be perfect for older machines. It is exciting to see this type of development.

Linux kernel 2.6 seems to be the last kernel for the architecture sent with Debian 4.0. I have seen "Etch" boot on a 68030(40 mhz) powered Amiga and it is sssllllooooowwww. I recognize it's large by nature though and this plays a big part of that. If I had the knowledge, I'd give it a shot but have been low on time.