-
"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...
-
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
-
- 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
-
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.
-
This was my big bang! I used finnix to create my first cpio initramfs with hello.
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.
-
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
-
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
-
/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...
-
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.
-
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
-
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.
-
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
-
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.
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.
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.
None of these scripts are included in the TinyCoreLinux source directory.
Scripts are already in source form.
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.
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.
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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...
-
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.
-
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.
-
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, ...
-
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!!!"
-
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.
-
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..."
-
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.
-
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.
-
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
-
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.
-
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.)
-
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.
-
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.
-
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.)
-
Thanks guys
-
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!
-
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!
-
IIRC, those machines lacked a MMU.
-
Check recent linux kernel supported arch.
-
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.