Tiny Core Base > TCB Tips & Tricks

HD install for special purpose.

<< < (2/8) > >>

tobiaus:
there seems to be some room for an easy solution here. knoppix begat feather and dsl which begat tinycore, and knoppix and/or feather had an "hd install (experimental)" option from the menu.

if tinycore's developer believes tinycore is better without an hd install, and yet tinycore's users feel the option is important, it's as simple as adapting the script or process already provided, putting it in the menu, and entitling it either "hd install (experimental)," hd install (not recommended!)," something of that nature. the trick here is that earlier knoppix-related distros have already established the convention of unsupported hd installs. they don't need to become a big deal or anything more than semi-official. to really make it tinycore-esque, you could still add it to the menu with such a title, but you could actually create the script and menu addition as a .tce extension, and ensure that fewer people bother to try it.

softwaregurl:
It seems to me that a hybrid of Tiny Core  HD install, persistent /usr/local/, persistent home and backup of anything else, burnt to CD, and even stripped of mods not used by the box it's dedicated to could be practical.  This would give the pristine state because the CD is not writable.  What slows me down on small distros is the processor usage to uncompress.  There was a theory about early disk compression that a slow drive and a fast processor would benefit from compression because less data had to be read from the disk.  Now I find the opposite true (financially).  It is a lot cheaper to grab a used "big" fast hard drive or fast CD-ROM then to get a faster processor and the board to support it.

I think I have seen that either tar or mkisofs can use lower compression ratios but I have not had the time to investigate further.  I am not so sure that the actual size of a distro is much more then a status symbol (other then saving bandwidth).

S.G.

tobiaus:

--- Quote from: softwaregurl on December 28, 2008, 02:12:21 AM ---I am not so sure that the actual size of a distro is much more then a status symbol (other then saving bandwidth).
--- End quote ---

must disagree there. it's a conclusion that's easy to reach, until you're booting with 256 ram (or less) and intend to use a livecd, and you want performance, too. then the size is one of the main factors in choosing, if not the first. and if you're customizing a distro, and want to strip out anything you're not using, a truly minimalist core like tc means you don't have to strip things out, simply don't add anything you don't want :) been looking for tc for a long time, it just didn't exist until recently. the closest to it was basiclinux. dsl was a good compromise that had better extensions and was easier to use.

roberts:
In regards to compression and size...

First let me state that TC does not run from a compressed image, like KNOPPIX or DSL.
It was the kernel developers, who in v2.6 enhanced the initrd capabiliites of such with the new initramfs in which they, the kernel developers, decided on cpio and gzip. There decisions are documented.

So, TC boots from a gzipped cpio image into ram. TC runs extremely fast as it runs from ram uncompressed.

If size was paramount, I would use a much higher compression other than gzip, i.e., lzma. In fact, it appears that lzma will a supported option for such, as the build of the current system, using lzma would have meant using patches. Lzma patches was in fact not selected as the uncompress time was noticeable, i..e., slower booting than our current deployment.

The pristine boot that I have championed for five years during my involvement with DSL, is what I am still an ardent proponent. You don't need to be booting from cdrom to achieve it. Instead my recommended method to "install to hard drive" is frugal. That is copying two files bzImage and tinycore.gz to any partition of your hard drive and point your bootloader to it. I recommend using grub for easy editing of additional boot time options.

On my developement machine I have grub set to boot TC in all the various operating modes:


--- Code: ---title Tiny Core on hda3 (tce=hda3/tcZ restore=hda3/tc_backup nolocal)
kernel (hd0,2)/tinycore/bzImage quiet restore=hda3/tc_backup tz=US/Pacific settime nolocal tce=hda3/tcZ
initrd (hd0,2)/tinycore/tinycore.gz

title Tiny Core on hda3 (tce=hda3/tcE restore=hda3/tc_backup nolocal)
kernel (hd0,2)/tinycore/bzImage quiet restore=hda3/tc_backup tz=US/Pacific settime nolocal tce=hda3/tcE
initrd (hd0,2)/tinycore/tinycore.gz

title Tiny Core on hda3 (tclocal=hda1 restore=hda1)
kernel (hd0,2)/tinycore/bzImage quiet  tclocal=hda1 restore=hda1 tz=US/Pacific settime
initrd (hd0,2)/tinycore/tinycore.gz

title Tiny Core on hda3 (base norestore nolocal xsetup)
kernel (hd0,2)/tinycore/bzImage quiet tz=US/Pacific base norestore nolocal xsetup
initrd (hd0,2)/tinycore/tinycore.gz

--- End code ---

softwaregurl:
I was going to reword that sentence this morning but apparently instead of taking offense it sparked a discussion.  I have noticed that uncompressing is the slowest  part of the boot on 200Mhz or slower machines (but still faster then even Win 3.1x and much more capable).  If it was just TCB that would be fine but adding a bunch of extensions and as backups grow over time the boot gets slow uncompressing them all thus the speed benefit of persistent /usr/local and /home.  Also accessing a mountable compressed file system is noticeably slower. 

as far as memory usage, with mountable file systems its not so much an issue unless one wants the speed of running entirely in ram.  But if I am spending a lot of time at 100% processor usage then I've lost that benefit.  And I am going to have to strip even TCB to get it to run on an old laptop with 32 megs but the video uses some and I get a kernel panic.  I use it as wireless ssh client.

I guess what I'm getting at is optimizing compression for the individual machine and the users preferences.  finding the best balance of resource usage.   An insermountable task for a developer, but attainable by the user.

Navigation

[0] Message Index

[#] Next page

[*] Previous page