Free spin software for linux

Fedora Core Live-Spin is a Live CD based on Fedora Core.

The Fedora Unity Project is proud to announce the release of CD and DVD ISO Live-Spins. These Live-Spins are live, bootable, ready-to-use ISO images of Fedora Core with no need for installation.

Official Fedora Live images are something we all have been looking forward to seeing in the Fedora Community. Kadischi will be the tool to create such live images. Fedora Unity has recently joined forces with Kadischi to help provide testing and to release live images which we are calling "Live-Spins."

The Fedora Unity Project is proud to announce the release of a new Live-Spin CD and DVD ISO image of Fedora Core 5. These Live-Spin ISOs are based on Fedora Core 5 and all updates released as of August 21st, 2006. They are available for the i386 architecture via BitTorrent starting Monday, August 28th, 2006 via BitTorrent.

The Fedora Core 5 CD image features a 2.6.17-1.2174_FC5 kernel and GNOME 2.14.3, along with applications such as xchat, gftp, OpenOffice.org 2.0.2, and other utilities. The DVD image includes roughly "everything but the kitchen sink."

Also available at this time are "pristine" FC6T2 Live ISO images from the initial FC6T2 release.

pungi project is two things:
1. pungi is a free opensource tool to spin Fedora installation trees / isos. It will be used to produce Fedora releases from Fedora 7 on until it is replaced by something better.
2. pungi is a set of python libraries to build various compose like tools on top of. Pungi provides a library with various funtions to find, depsolve, and gather packages into a given location. It provides a second library with various functions to run various Anaconda tools on the gathered packages and create isos from the results.
Enhancements:
- Dont quote ISO label, not running mkisofs in shell
- Apply sparc patches (spot)
- Fix cached downloads comparing correctly
- Shorten development to devel in default config, more space for mkisofs
- Handle config file missing better (jgranado)
- Fix comments in default config file

sdparm utility outputs and in some cases modifies SCSI device parameters. When the SCSI device is a disk, sdparms role is similar to its namesake: the Linux hdparm utility which is for ATA disks that usually have device names starting with "hd".
More generally sdparm can be used to output and modify parameters on any device that uses a SCSI command set. Apart from SCSI disks, such devices include CD/DVD drives (irrespective of transport), SCSI and ATAPI tape drives and SCSI enclosures. A small set of commands associated with starting and stopping the media, loading and unloading removable media and some other housekeeping functions can also be sent with this utility.
This utility currently contains over 500 entries spread across generic mode pages, transport specific mode pages, vendor specific mode pages, Vital Product Data (VPD) pages and their attributes. Rather than try and document all of these here (or in the man page), another approach is taken. This utilitys internal tables can be searched and output with the --enumerate option. Additional explanatory information is output when the --long option is used (and more if the --long option is used twice).
SCSI mode pages
Mode pages hold meta data about a SCSI device which can, in some cases, be changed by the user. In SCSI parlance the "device" is a logical unit of which there may be several in a SCSI target. In the case of a SCSI disk connected directly to a Host Bus Adapter (HBA) the disk is both a SCSI target and a logical unit. The "user" in this case is the person using sdparm which is a SCSI "application client" and it feeds commands into a SCSI initiator. The SCSI initiator is found in the HBA. At the command level SCSI is a client-server protocol with the logical unit (or target device) being the server that responds to commands sent by the application client via the SCSI initiator.
Mode pages are defined in SCSI (draft) standards found at www.t10.org . Mode pages common to all SCSI devices are found in the SCSI Primary Commands document (SPC-4) while those specific to block devices (e.g. disks) are found in SBC-3 and those for CD/DVD drives are found in MMC-5. This diagram shows how various SCSI and associated standards interrelate. Often device product manuals detail precisely which mode pages (and parts thereof) are supported by a particular model and describe the way that the device will react if the generic description in the SCSI (draft) standard needs amplification. There are also transport protocol specific mode pages for transports such as "spi" (the 25 year old SCSI Parallel Interface), "fcp" (Fibre Channel Protocol) and "sas" (Serial Attached SCSI). There are also vendor specific mode pages. Mode pages that are not transport protocol specific or vendor specific are sometimes referred to as "generic" in sdparms documentation.
To see a list of generic mode page names that sdparm has some information about use: sdparm -e. To see a list of transport specific mode page names that sdparm has some information about use (for example) sdparm -e -t sas. Both lists are sorted alphabetically by mode page abbreviation.
Mode pages are not the only mechanism in SCSI devices for holding meta data. Information which seldom if ever changes for a particular device may be found in the Vital Product Data (VPD) pages which are obtained via the SCSI INQUIRY command. Performance statistics are held in log pages which are obtained via the SCSI LOG SENSE command. Recent CD/DVD drives hold a lot of information in feature and profile descriptors (see MMC-4 and MMC-5) which are accessed via the SCSI GET CONFIGURATION command (see the sg_get_config utility in the sg3_utils package).
Each mode page has up to four tables associated with it. These can be thought of like tabs on a spreadsheet, with each tab containing the same size table. The four tables are:
current values: those values that are active at this time
changeable values: bit masks showing those values that the user may change
default values: the manufacturers default values
saved values: those values that will be active after the next power cycle (or format)
The saved values are optional. If the mask in the changeable values indicates a field can be changed then the corresponding field in the current values may be changed. A bit of 0 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may not be changed. A bit of 1 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may be changed. At the point when a current value is changed, the user may also choose to change the corresponding saved value.
The manufacturer obviously knows a lot about the characteristics of its devices. Hence if a current field value (and saved field value) is different from the default field value then there should be some rationale.
Some current values represent a state within the target device or logical unit. If that state changes so does the current value. Such values are not usually changeable by the user.
The sdparm utility has a --get, --set, --clear type of command line interface in which mode page fields are identified by an acronym. In many cases these acronyms will correspond precisely to the standard (e.g. "WCE" for Writeback Cache Enable in the caching mode page of SBC-3). For some longer fields the standards "spell out" a field name (e.g. "Write Retention Priority" in the caching mode page of SBC-3). In such cases the sdparm utility uses an acronym (e.g. "WRP"). In sdparm, acronyms across all generic mode pages are unique (i.e. an acronym matches at most one field of one generic mode page). Each transport protocol has its own namespace of acronyms so that an acronym is unique within a transport protocol. By default, saved values are not changed by --set and --clear. When changing the current values, the saved values can be changed as well by adding the --save. All the current values in a mode page can be changed back to the manufacturers defaults with the --defaults option (and the --save option here will additionally change the saved values back to the manufacturers defaults).
Changing some mode page fields is like jumping off a cliff holding onto a rope which you are not sure is properly secured. If in doubt, change the current value without using the --save option. That way if the setting is disastrous, power cycling the device will restore the previous setting. Once the new setting is known to be safe, then the sdparm utility can be re-executed with the --save option added.
sdparm commands
The --command= option allows a command to be sent to the given device. The currently supported commands are:
capacity: sends a READ CAPACITY and if successful reports the number of blocks, block length and capacity expressed in MibiBytes (1048576 bytes). Valid for disks and CD/DVD drives with the appropriate media loaded.
eject: stops the medium (if it is spinning) and ejects it from the drive. Note that this may be prevented by software in which case use the unlock command first.
load: loads the medium and then spins it up
ready: reports whether the medium is ready for IO. Ready usually means that it is present and spun up. If the device is not ready then the exit status will be 2 (see exit status section below).
sense: reports sense data (from a REQUEST SENSE SCSI command); can include power condition information, a progress indication for a time consuming command (e.g. format) or a report an informational exception (when MRIE=6)
start: spin up the medium
stop: spin down the medium
sync: send a SYNCHRONIZE CACHE SCSI command to the device.
unlock: instructs the device to allow medium removal (i.e. an eject). Beware, the OS may have had a good reason for preventing removal of the medium (e.g. it contains a mounted file system). Use at your own risk.
These sdparm commands send SCSI commands to the given DEVICE. If they dont seem to work, adding a verbose flag (i.e. -v or -vv) may provide more information. The "ready" and "sense" commands need read permissions on the DEVICE while the other commands need both read and write permissions.
Enhancements:
- Changes to SCSI mode and VPD pages that were introduced by t10.org since the last release were incorporated.
- The pass-through interface was updated, and code which is written in C was made to compile cleanly with C++.

Goodgoat is an easy to use desktop that can run from a bootable cd or it can be installed to the hard drive.

Goodgoat uses portage to handle updates for the installed version. I started goodgoat as an os for my low cost computer. I thought that the Linux I had created would be useful to other people.

I have hand picked the best of breed applications and left an easy to use desktop. I start with xfce4 which is light weight and easy to use. I added firefox, evolution for email, openoffice and many other applications.

Some highlights of the system is that it has all the regular desktop application, video and audio player, and auto configuration of the network and x windows setup.

For the system administrators I have added iscsi server and client tools. You can run /etc/init.d/iscsi-target start and you are sharing hd0. Goodgoat has qemu which is the poor mans vmware only it works better if you ask me (compressed filesystem).

To install goodgoat all you need to do is install the cd version (iso file) and use the installer in the prefs menu. Some parts of the installer take a few minutes but as long as the firefox circle is spinning you just have to wait until the installer finishes. While you wait you can open a new tab or a new window and browse the web or play one of the many games included in goodgoat.

Why should you use goodgoat? Its fast and everything you need is right at your finger tips. Goodgoat works well on older computers and doesnt need a lot of memory. Goodgoat works with desktops laptops, and wifi.

If you like gentoo all you have to do is install goodgoat and run su -; emerge sync from the xterm and you have a gentoo system. I add a few additional applications that are not included with gentoo and I installed newer applications than gentoo supports by default.

Goodgoat is about as easy to install as it gets. The installer is simple in function and easy to use.

Linux on a Stick is an attempt to make a Live-CD/USB-Flash server Linux distro. At its heart is a very small and simple Linux distro that boots off CD/Flash and runs from RAM (Ie no spinning hard drives of death).
This approach allows us to strip the OS to its very basic components, which minimizes the amount of resources required. This distro is targeted towards Server administrator who are familiar with Linux, its only configuration method is the command line.
Enhancements:
- Linux kernel 2.4.33 was replaced with 2.6.18.8.
- A USB booting problem that would prevent it from booting on some BIOSs (Namely AMI) was resolved.
- The ARDIS iSCSI target was replaced with the Enterprise iSCSI target (v0.4.14).
- The Open iSCSI initiator (v2.0.754) package with kernel modules is included.
- The distribution now boots on more than just Intel CPUs.
- Userland tools (v3.6.19) and kernel FS support were included for ReiserFS and XFS.
- The PHP CLI is included in php-5.2.0 in root.gz initrd.

Booting Ubuntu To RAM is an article aims to document the process of creating a customized Ubuntu that loads an image from the hard disk to RAM, then boots an entire Ubuntu session out of RAM. It is intended for intermediate to advanced Ubuntu users who are familiar with the shell, and may have limited experience customizing the livecd (LiveCDCustomization) and shell scripting. We will customize a LiveCD and copy it to the hard drive, and make a few modifications to bootup scripts so that it copies to RAM via our good friend tmpfs.
WARNING: The author asserts that this procedure works for him, but cannot guarantee that this procedure works for anyone else. Although this procedure is meant to be 100% safe, it is feasible that there may be mistakes, or a chance of misunderstanding the instructions in a manner that causes loss of data. Please make a backup and do not attempt on mission critical systems. Read through this article thoroughly, and do not attempt if you do not comprehend or feel comfortable about any of the instructions!
CAUTION: I hope this is intuitively obvious, but Ill humor you and state it bluntly: Changes you make under the live session are NOT saved and WILL BE LOST when you reboot or shut down. Dont save anything important to the "home directory" and expect it to still be around! If you want to save data permanently, mount a permanent medium (such as your hard drive), plug in a thumbdrive, or use some network functionality built into Ubuntu to save your data to a non-volatile destination.
There are many cases where one would like to boot Ubuntu to RAM:
- Performance: The desktop performance is dramatically improved. A 400MB squashed filesystem in RAM, that holds 1200MB of data, is read back on a 1.6GHz Core Duo in about 3 seconds, including decompression time.
- Power, Noise, Durability: Although modern hard disks dont use much power compared to other system components, this may still be important for some. In laptops, hard disks are often the noisiest components, so this setup can reduce system noise. With the hard disk spun down, a laptop can potentially withstand greater shocks without damage.
- Abrupt poweroff: Since the hard disk is only momentarily used in read-only mode during boot, then never touched again, there are few or no negative consequences of an abrupt poweroff. If a system is used where power is inconsistent, or the system is regularly used in a context where fast shutoffs are required, this is very handy.
- Privacy: Anything you do in this session are lost when you reboot or power off. This is great for kiosks or other systems where permanent modification are not desired. (Note that by default the livecd user has full sudo access, so potentially a malicious user can still make permanent changes by mounting the hard drive and following this HOWTO)