Tiny Core Linux is a very small (10 MB) minimal Linux
Desktop. It is based on Linux 2.6 kernel, Tiny X, Busybox, 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.
The user has complete control over which applications and/or additional hardware to have supported, be it for a desktop, a nettop, an appliance, or server, selectable from our online repository.
Tiny Core Linux, not being a complete Desktop, requires the internet to access to our repository of applications. Everyone should take the time to read this document and understand the design philosophy behind Tiny Core Linux. This will insure a more pleasant experience.
Philosophies
As a quick summary, Tiny Core:
* Loads itself into RAM from storage, then Mounts applications on storage, or
* Installs applications to RAM from storage.
Tiny Core is different because users are not encouraged to perform a 'traditional', hard-drive installation of the operating system. Sure, a hard drive installation is possible, but Tiny Core is designed to run from a RAM copy created at boot time. Besides being fast, this protects system files from changes and ensures a pristine system on every reboot. Easy, fast, and simple renew-ability and stability is a principle goal of Tiny Core.
Boot codes
Depending upon how how Tiny Core is installed (GRUB, LILO, CD, USB stick ...), users have the option to use boot codes on each reboot (CD, etc), or to store those codes in a boot configuration file (GRUB, LILO, etc.).
Boot codes (boot arguments) affect how Tiny Core operates by defining options at boot-time. There are lots of boot codes. To view all the available options, peruse the boot code lists by pressing F2 or F3 at the CD boot prompt.
The boot code base is notable. Use base to simulate Default Mode and skip all application extension installing or mounting. This is a useful tool for trouble-shooting, extension building, upgrading ... and just checking out how fast Tiny Core can boot on your hardware.
USB and External Storage Devices Special Requirements
Tiny Core can be instructed to search for data on external devices at boot time:
a USB pen drive, compact flash, or other portable media. Below, the Mode Descriptions discuss Personal Persistent Repositories of extensions (PPR) or Installed applications (PPI) - those are prospects for external storage.
Sometimes, hardware doesn't wake up fast enough for Tiny Core's boot sequence, though. If the hardware doesn't wake up in time, Tiny Core will move on and finish booting without that data.
If you use a PPR or PPI on external media, it may be necessary to use the boot code waitusb=5 or similar. This pauses the pauses the boot process for five seconds, waiting for slow devices to register with the system bus.
Dependency Checking and Downloading
Tiny Core makes application-getting as easy as possible. The Appbrowser provides application details from individual .info files - this is enlightening reading material when choosing applications. Always read the .info files, and re-read them before upgrading to catch changes and concerns.
Dependencies are the pieces (other applications) required for an application. In short, the Tiny Core Appbrowser will take care of downloading and checking dependencies for you.
Modes of Operation
The Modes of Operation mix up how Tiny Core Loads, Mounts, and Installs at boot time (see Philosophies, above, if you want to clarify what those three things mean here). Tiny Core has three main Modes:
* Default Mode: Cloud/Internet
* Mount Mode: TCZ/Install
* Copy Mode: TCZ/Install + copy2fs.flg/lst
* And one 'other mode': Hybrid Mode: persistent /usr/local
Again, some may say there is a "Traditional Mode: Install to Hard Drive", but that's not really a Mode at all. If you want to do it, go right ahead. It's just not one of the original goals of the project, so expect the normally slim documentation to be slimmer.
Details on each Mode follow in the "Mode Descriptions" below.
The Default Mode: Cloud/Internet
By default, Tiny Core Linux operates like a Cloud/Internet client. In Default Mode:
* Tiny Core boots entirely into RAM.
* Users run the Appbrowser to browse the repository and download applications.
* Application Extensions (downloaded applications) last only for the current session.
* Tiny Core just uses as much RAM as possible.
Since Cloud/Internet Mode operates out of RAM, it runs fast. Cloud/Internet Mode is nomadic and quick-booting. Application extensions are lost on reboot, but only the system files have to be restored.
If you would like applications stored locally and set up on each reboot, then consider the Mount and Copy Modes.
The Mount Mode of Operation: TCE/Install
In Mount Mode:
* Applications are stored locally in a PPR: Personal Persistent Repository.
* Applications are optionally mounted on reboot (see onboot.lst in forum and wiki).
* Mounting applications saves RAM for other uses.
Tiny Core always searches for and uses a Personal Persistent Repository (PPR) of downloaded extensions. Applications stored in the PPR are searched and optionally mounted at boot time.
Tiny Core uses the Appbrowser to place application extensions in the PPR and flag them as either "Install" (mount at boot) or "On Demand" (do not mount at boot).
To establish a PPR, see the wiki and forum topics on the tce= and max_loop= boot codes, tcz extensions, and use of squashfs in application extensions. For information on optionally mounting applications at boot time, see the forum and wiki topics on the onboot.lst file and how to use the Appbrower.
The Copy Mode of Operation: TCE/Install + copyfs indicator
If you haven't, read the Mount Mode description above.
In Copy Mode:
* Application Extensions are copied into RAM instead of mounted.
* Applications can be RAM-loaded in bulk (copy2fs.flg), selectively loaded into RAM (copy2fs.lst), or mounted.
* The Appsaudit program tracks installation/loading options (bulk copy, selective copy, etc).
* Boot times are longer, since copying to RAM takes more time than mounting.
Copy Mode briefly extends the boot time to gain some of the RAM-run speed of Default Mode and the persistence of a pure Mount Mode.
In Copy Mode, it is important to note that extensions can be either mounted or copied into RAM. The Appsaudit program makes this flexibility possible by keeping track of user selections.
The Hybrid Mode of Operation: Local/Install
In Hybrid Mode:
* Tiny Core System Files are copied into RAM as normal.
* Application extensions are installed to disk using "Install", and mounted as a tree at /usr/local.
* RAM is saved for other uses (as in Mount Mode).
* Boot times are very low.
* Tiny Core loses a pristine renew-on-reboot.
* Tiny Core ignores downloaded extensions and the Personal Persistent Repository (PPR) of application extensions.
Hybrid Mode installs applications to a partition or loop back file in a traditional "one file tree" way. This copy of /usr/local, a Personal Persistent Installation (PPI), is mounted into the main file system on reboot using the boot code local=.
As with most typical environments, installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix. Because of this inevitable "system rot," the Mount and Copy Modes are strongly preferred to Hybrid Mode.
Early in Tiny Core history (around 2.4 and before), not all applications supported PPI installation because some of their dependencies might not have been in the /usr/local tree. Individual extension .info files still hold those details.
To set up a PPI of /usr/local, see the wiki and forum topics on the local= boot code, the "Create Loop Back File" menu option, and the tclocal dirctory or loop back.
Backup/Restore and Other Persistence Options:
Aside from the PPR (Personal Persistent Repository of application extension) and PPI (Personal Persistent Installation of application extensions), Tiny Core supports persistent/permanent:
Backup and Restore of personal settings, and
Persistent /home and /opt directories.
Backup/Restore
Tiny Core includes filetool for saving personal settings and data. The text file /opt/.filetool.lst lists files and directories to be backed up at power down and restored at reboot. The list may be changed manually (using vi, nano, etc) or via the scripts in the Tools menu; note that the entry for /opt/filetool.lst should never be removed from the list itself. filetool also supports exclusion of particular files via /opt/xfiletool.lst.
By default, filetool.lst includes the entire home/tc directory, and xfiletool.lst excludes some unnecessary caches and temporary directories.
filetool writes backup mydata.tgz. The location of mydata.tgz can be initially set using the boot option restore=hdXY, restore=hdXY/directory, or, after boot, by selecting Backup/Restore from the Control Panel. If the restore code is no used, Tiny Core will search for mydata.tgz in available root directories at boot. Conversely, the boot option norestore ignores any existing backup files, a useful tool for trouble-shooting and upgrading.
Further settings and configurations are stored or executed using /home/tc/.xsession, /home/tc/.profile, /opt/bootlocal.sh, and /opt. Search the forum and wiki for information on these and other custom settings files.
Persistent Home
Just as Tiny Core offers persistence options for downloaded application extensions, so does it for your home directory. These are set using boot codes/options.
home=hdXY will automatically setup /home/tc to "bind" to /mnt/hdXY/tchome. When using the home boot code, mydata.tgz is not created - personal data backups must occur in a more traditional way. The home boot code lets Tiny Core coexist with other Linux installations by inserting the tc user directory under a pre-existing /home directory. Be careful, as the initial use of the boot code will creat this directory and its content. Also, Tiny Core cannot auto-detect a persistent home directory, so the home boot option is always required.
Product's homepage
What's New in This Release: [ read full changelog ]
· Patched wbar to support --nofont.
· Apps & ScmApps title moved to window title area.
· Dropped tinycore-scm.desktop.
· Restored xirc2ps_cs.ko.gz
· Apps load local sort order and GUI adjustments.
· Expanded boot menu for TinyCore.iso
Softpedia Mirror Download
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.
The user has complete control over which applications and/or additional hardware to have supported, be it for a desktop, a nettop, an appliance, or server, selectable from our online repository.
Tiny Core Linux, not being a complete Desktop, requires the internet to access to our repository of applications. Everyone should take the time to read this document and understand the design philosophy behind Tiny Core Linux. This will insure a more pleasant experience.
Philosophies
As a quick summary, Tiny Core:
* Loads itself into RAM from storage, then Mounts applications on storage, or
* Installs applications to RAM from storage.
Tiny Core is different because users are not encouraged to perform a 'traditional', hard-drive installation of the operating system. Sure, a hard drive installation is possible, but Tiny Core is designed to run from a RAM copy created at boot time. Besides being fast, this protects system files from changes and ensures a pristine system on every reboot. Easy, fast, and simple renew-ability and stability is a principle goal of Tiny Core.
Boot codes
Depending upon how how Tiny Core is installed (GRUB, LILO, CD, USB stick ...), users have the option to use boot codes on each reboot (CD, etc), or to store those codes in a boot configuration file (GRUB, LILO, etc.).
Boot codes (boot arguments) affect how Tiny Core operates by defining options at boot-time. There are lots of boot codes. To view all the available options, peruse the boot code lists by pressing F2 or F3 at the CD boot prompt.
The boot code base is notable. Use base to simulate Default Mode and skip all application extension installing or mounting. This is a useful tool for trouble-shooting, extension building, upgrading ... and just checking out how fast Tiny Core can boot on your hardware.
USB and External Storage Devices Special Requirements
Tiny Core can be instructed to search for data on external devices at boot time:
a USB pen drive, compact flash, or other portable media. Below, the Mode Descriptions discuss Personal Persistent Repositories of extensions (PPR) or Installed applications (PPI) - those are prospects for external storage.
Sometimes, hardware doesn't wake up fast enough for Tiny Core's boot sequence, though. If the hardware doesn't wake up in time, Tiny Core will move on and finish booting without that data.
If you use a PPR or PPI on external media, it may be necessary to use the boot code waitusb=5 or similar. This pauses the pauses the boot process for five seconds, waiting for slow devices to register with the system bus.
Dependency Checking and Downloading
Tiny Core makes application-getting as easy as possible. The Appbrowser provides application details from individual .info files - this is enlightening reading material when choosing applications. Always read the .info files, and re-read them before upgrading to catch changes and concerns.
Dependencies are the pieces (other applications) required for an application. In short, the Tiny Core Appbrowser will take care of downloading and checking dependencies for you.
Modes of Operation
The Modes of Operation mix up how Tiny Core Loads, Mounts, and Installs at boot time (see Philosophies, above, if you want to clarify what those three things mean here). Tiny Core has three main Modes:
* Default Mode: Cloud/Internet
* Mount Mode: TCZ/Install
* Copy Mode: TCZ/Install + copy2fs.flg/lst
* And one 'other mode': Hybrid Mode: persistent /usr/local
Again, some may say there is a "Traditional Mode: Install to Hard Drive", but that's not really a Mode at all. If you want to do it, go right ahead. It's just not one of the original goals of the project, so expect the normally slim documentation to be slimmer.
Details on each Mode follow in the "Mode Descriptions" below.
The Default Mode: Cloud/Internet
By default, Tiny Core Linux operates like a Cloud/Internet client. In Default Mode:
* Tiny Core boots entirely into RAM.
* Users run the Appbrowser to browse the repository and download applications.
* Application Extensions (downloaded applications) last only for the current session.
* Tiny Core just uses as much RAM as possible.
Since Cloud/Internet Mode operates out of RAM, it runs fast. Cloud/Internet Mode is nomadic and quick-booting. Application extensions are lost on reboot, but only the system files have to be restored.
If you would like applications stored locally and set up on each reboot, then consider the Mount and Copy Modes.
The Mount Mode of Operation: TCE/Install
In Mount Mode:
* Applications are stored locally in a PPR: Personal Persistent Repository.
* Applications are optionally mounted on reboot (see onboot.lst in forum and wiki).
* Mounting applications saves RAM for other uses.
Tiny Core always searches for and uses a Personal Persistent Repository (PPR) of downloaded extensions. Applications stored in the PPR are searched and optionally mounted at boot time.
Tiny Core uses the Appbrowser to place application extensions in the PPR and flag them as either "Install" (mount at boot) or "On Demand" (do not mount at boot).
To establish a PPR, see the wiki and forum topics on the tce= and max_loop= boot codes, tcz extensions, and use of squashfs in application extensions. For information on optionally mounting applications at boot time, see the forum and wiki topics on the onboot.lst file and how to use the Appbrower.
The Copy Mode of Operation: TCE/Install + copyfs indicator
If you haven't, read the Mount Mode description above.
In Copy Mode:
* Application Extensions are copied into RAM instead of mounted.
* Applications can be RAM-loaded in bulk (copy2fs.flg), selectively loaded into RAM (copy2fs.lst), or mounted.
* The Appsaudit program tracks installation/loading options (bulk copy, selective copy, etc).
* Boot times are longer, since copying to RAM takes more time than mounting.
Copy Mode briefly extends the boot time to gain some of the RAM-run speed of Default Mode and the persistence of a pure Mount Mode.
In Copy Mode, it is important to note that extensions can be either mounted or copied into RAM. The Appsaudit program makes this flexibility possible by keeping track of user selections.
The Hybrid Mode of Operation: Local/Install
In Hybrid Mode:
* Tiny Core System Files are copied into RAM as normal.
* Application extensions are installed to disk using "Install", and mounted as a tree at /usr/local.
* RAM is saved for other uses (as in Mount Mode).
* Boot times are very low.
* Tiny Core loses a pristine renew-on-reboot.
* Tiny Core ignores downloaded extensions and the Personal Persistent Repository (PPR) of application extensions.
Hybrid Mode installs applications to a partition or loop back file in a traditional "one file tree" way. This copy of /usr/local, a Personal Persistent Installation (PPI), is mounted into the main file system on reboot using the boot code local=.
As with most typical environments, installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix. Because of this inevitable "system rot," the Mount and Copy Modes are strongly preferred to Hybrid Mode.
Early in Tiny Core history (around 2.4 and before), not all applications supported PPI installation because some of their dependencies might not have been in the /usr/local tree. Individual extension .info files still hold those details.
To set up a PPI of /usr/local, see the wiki and forum topics on the local= boot code, the "Create Loop Back File" menu option, and the tclocal dirctory or loop back.
Backup/Restore and Other Persistence Options:
Aside from the PPR (Personal Persistent Repository of application extension) and PPI (Personal Persistent Installation of application extensions), Tiny Core supports persistent/permanent:
Backup and Restore of personal settings, and
Persistent /home and /opt directories.
Backup/Restore
Tiny Core includes filetool for saving personal settings and data. The text file /opt/.filetool.lst lists files and directories to be backed up at power down and restored at reboot. The list may be changed manually (using vi, nano, etc) or via the scripts in the Tools menu; note that the entry for /opt/filetool.lst should never be removed from the list itself. filetool also supports exclusion of particular files via /opt/xfiletool.lst.
By default, filetool.lst includes the entire home/tc directory, and xfiletool.lst excludes some unnecessary caches and temporary directories.
filetool writes backup mydata.tgz. The location of mydata.tgz can be initially set using the boot option restore=hdXY, restore=hdXY/directory, or, after boot, by selecting Backup/Restore from the Control Panel. If the restore code is no used, Tiny Core will search for mydata.tgz in available root directories at boot. Conversely, the boot option norestore ignores any existing backup files, a useful tool for trouble-shooting and upgrading.
Further settings and configurations are stored or executed using /home/tc/.xsession, /home/tc/.profile, /opt/bootlocal.sh, and /opt. Search the forum and wiki for information on these and other custom settings files.
Persistent Home
Just as Tiny Core offers persistence options for downloaded application extensions, so does it for your home directory. These are set using boot codes/options.
home=hdXY will automatically setup /home/tc to "bind" to /mnt/hdXY/tchome. When using the home boot code, mydata.tgz is not created - personal data backups must occur in a more traditional way. The home boot code lets Tiny Core coexist with other Linux installations by inserting the tc user directory under a pre-existing /home directory. Be careful, as the initial use of the boot code will creat this directory and its content. Also, Tiny Core cannot auto-detect a persistent home directory, so the home boot option is always required.
Product's homepage
What's New in This Release: [ read full changelog ]
· Patched wbar to support --nofont.
· Apps & ScmApps title moved to window title area.
· Dropped tinycore-scm.desktop.
· Restored xirc2ps_cs.ko.gz
· Apps load local sort order and GUI adjustments.
· Expanded boot menu for TinyCore.iso
Softpedia Mirror Download
Tidak ada komentar:
Posting Komentar
Hanya manusia yang berkomentar baik dan sopan. sedangkan hanya binatang yang berkomentar buruk dan tidak memikirkan perasaan dan tidak menghargai orang lain... Trima kasih....