DOCSLIB.ORG

Deep Compression

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Deep Compression COVER STORY Cloop DEEPBlock device compression COMPRESSION with the cloop module KYRO, photocase.com KYRO, The cloop module lets you manage compression at the block device 512 bytes), and they are usually used for random access storage like ramdisks, level. Read on to learn how Knoppix and other Live CDs fit all that CD-ROMs, floppy disks, hard disks, and hard disk partitions. software on a single disc. BY KLAUS KNOPPER Filesystems are a logical representa- tion of ordered data that is often present loop is a kernel block device block-based devices. If you look into the on a block device. A filesystem turns raw module used in Live CDs such output of ls -l /dev, you will easily recog- data into the familiar directory/file view. Cas Knoppix. The cloop module nize these devices by the prefix – c for The mount command is the bridge be- allows the system to read compressed character-based and b for block-based tween a block device partition and its data, usually from a file, thus creating devices – at the beginning of the output projection into a mount point directory. compressed virtual disks. Using cloop, line (see Listing 1). a Linux installation of about 2GB fits on Character-based devices, such as tape Cloop: A Compressed a single 700MB CD-R disc. In this article, drives, mice, and gamepads, provide se- Loopback Block Device I look at how cloop works and provide quential, character-by-character access One block device included in any Linux some insight into general kernel struc- to data. kernel is loop, which maps a plain file to tures of a block device. Block devices instead allow direct ac- a block device node in /dev/loop A Unix system traditionally distin- cess to arbitrary blocks of data, indexed [number]. The loop-attached file can guishes between character-based and by block number or sector (segments of then be mounted like an ordinary hard 32 ISSUE 86 JANUARY 2008 032-036_cloop.indd 32 15.11.2007 10:17:18 Uhr Cloop COVER STORY been successfully port write operations would probably be Plain file read and decom- very inefficient because, at each write or pressed, and it operation, the compressed block struc- Disk Image never terminates ture would have to be reordered, and or interrupts ac- blocks on a block device can never be cess to the under- “deleted,” since the block device has cloop lying device. That no information about whether or not modprobe cloop file=/path/to/file.cloop way, even partly data is actually needed. damaged data can Also, when compressing a block, the still be restored, resulting block size is not really predict- Filesystem/Mount and crashes be- able. In fact, a compressed block can be cause of read er- slightly larger than an uncompressed mount −r −t iso9660 /dev/cloop /mnt rors are unlikely block, in case that the data is already (though, of stored compressed. When exchanging Mountpoint with visible course, an execut- compressed blocks, the block index table directories and files able program that would have to be recalculated (all offsets / has been damaged after the changed block will also /usr /home will most likely change). Therefore, cloop is very opti- refuse to run and mized for reading data, but writing is terminate with a not currently supported and probably Figure 1: (C)loop maps a hard disk image file to a block device and lets segmentation never will be. you mount the image like a real hard disk partition. fault). This feature If you need write support on read-only may give cloop media, you are better off with a filesys- disk, optionally with encryption. How- a slight advantage against compressing tem such as AuFS or Unionfs that merges ever, this driver still only provides a filesystems, in which an entire file be- the read-only directory with a directory translation between different data repre- comes unreadable if there is a read error offering write support. sentations of the same size. right at the beginning of that file. In Cloop can handle parallel accesses to Cloop, which was first written in 1999 cloop, at maximum, one block is missing multiple cloop image files. If you have for kernel 2.2 by iptables author Paul when read errors occur within this to split files because of size limits in the ‘Rusty’ Russell, uses a blockwise com- block. underlying filesystem, this is important pressed input file that reduces the neces- One disadvantage is that cloop is read- (i.e., the 2GB and 4GB maximum file sary space to around 1/3 of the original only. Attempting to rewrite cloop to sup- size in FAT32 and iso9660, respectively). size for executable files. I ported, and later rewrote, cloop for newer kernel ver- Listing 1: Character and Block Device Nodes sions, extending the module to support 01 crw-rw---- 1 root root 10, 1 2007-10-18 10:41 /dev/psaux 64-bit file access (thus allowing file sizes 02 brw-rw---- 1 root disk 3, 0 2007-10-18 10:41 /dev/hda beyond 4GB), multiple input files, and ioctl extensions to permit the exchange 03 brw-rw---- 1 root disk 240, 0 2007-11-01 21:38 /dev/cloop of input files on-the-fly. Since cloop is a block device and not a Listing 2: Attaching a New Cloop Image filesystem like squashfs, the compressed 01 $ sudo losetup /dev/cloop1 /media/cdrom/backup.cloop image can be anything, from raw data to arbitrary filesystem or database struc- 02 $ sudo mount -r -t ext2 /dev/cloop1 /mnt tures. On a Live CD, the cloop image 03 $ dmesg | tail -2 usually contains an iso9660 file system, 04 cloop: Initializing cloop v2.622 which is the most popular read-only and 05 cloop: loaded (max 8 devices) read-optimized filesystem used for data CDs. Cloop supports all filesystem fea- 06 cloop: losetup_file: 3571 blocks, 65536 bytes/block, largest block tures necessary for a Unix system is 65562 bytes. through the standard RockRidge exten- sion (long file names, permissions, Listing 3: Starting the Cloop Block Device symlinks, etc.). 01 register_blkdev(major=240, cloop_name="cloop"); Cloop also comes with several validity checks that return non-fatal error codes 02 for(i=0; i<cloop_max; i++) cloop_dev[i] = cloop_alloc(i); to the calling application in case invalid 03 if(file) { compressed data is read or read errors 04 initial_file=filp_open(file,O_RDONLY|O_LARGEFILE,0x00); occur (scratches on the CD surface 05 cloop_set_file(0,initial_file,file); sometimes make data partly unread- able). Cloop only uses data that has 06 } JANUARY 2008 ISSUE 86 33 032-036_cloop.indd 33 15.11.2007 10:17:26 Uhr COVER STORY Cloop Cloop images can be attached and de- If a file is given as module parameter Block devices have two methods for tached at run time using the standard file="/path/to/first/image", this file is reading from the device. The direct losetup command (see Listing 2). opened and associated with the first method is setting up a request function Cloop can work with input files that cloop device /dev/cloop0. that will be called each and every time a are mounted over NFS. This feature is How does /dev/cloop0 know what to read() on the device is performed. This important if you plan to run completely do when a process opens the block de- request function is then associated with diskless clients with filesystems vice and reads from it? Unlike filesys- the default block queue that has been mounted over cloop. Another interesting tems, block devices have a more com- created for the major device ID of cloop feature of cloop is that it can read and plex way of performing input and out- when the block device was set up (see decompress data asynchronously using put. Listing 5a). a kernel thread, so it’s not blocking a Depending on which kind of block de- cloop_request_fn() has to find out process group and not staying in kernel vice you are using, there are some opera- which device was accessed and then space for a noticeable time. tions that have to be supported and oth- transfer data from the cloop file into the Access to cloop image files can be sus- ers that won’t. In case of a disk or parti- memory space that was given in buffer_ pended while they are in use (a feature tion, you can use a structure like the one head. This direct method was used until introduced by Fabian Franz). The idea in Listing 4, which tells the kernel what cloop version 2.06. behind this feature is that you can tem- to do if someone opens or closes a /dev/ A disadvantage of this direct method porarily remove a storage device that is cloop* file. is that the entire device is blocked until in use by cloop without getting read er- cloop_open() needs to increase the use cloop_request_fn() returns. Actually, rors. After receiving a special ioctl call, counter of the device so that the module probably because of this, the direct cloop will patiently wait until the under- knows it is in use. cloop_close() does the method ceased to work for cloop starting lying file is activated (and re-analyzed) opposite. cloop_ioctl(), which is a special from kernel 2.6.22. again, so you could eject a Live CD case that handles losetup for exchanging while an OS is running from it. the underlying cloop image file, also sus- Per-Device Wait Queue One drawback is that all processes pends device operations in case the The new approach to block device I/ O is that access the cloop device will be CLOOP_SUSPEND ioctl is sent.
Load more

Recommended publications
  • HTTP-FUSE Xenoppix
    HTTP-FUSE Xenoppix Kuniyasu Suzaki† Toshiki Yagi† Kengo Iijima† Kenji Kitagawa†† Shuichi Tashiro††† National Institute of Advanced Industrial Science and Technology† Alpha Systems Inc.†† Information-Technology Promotion Agency, Japan††† {k.suzaki,yagi-toshiki,k-iijima}@aist.go.jp [email protected], [email protected] Abstract a CD-ROM. Furthermore it requires remaking the entire CD-ROM when a bit of data is up- dated. The other solution is a Virtual Machine We developed “HTTP-FUSE Xenoppix” which which enables us to install many OSes and ap- boots Linux, Plan9, and NetBSD on Virtual plications easily. However, that requires in- Machine Monitor “Xen” with a small bootable stalling virtual machine software. (6.5MB) CD-ROM. The bootable CD-ROM in- cludes boot loader, kernel, and miniroot only We have developed “Xenoppix” [1], which and most part of files are obtained via Internet is a combination of CD/DVD bootable Linux with network loopback device HTTP-FUSE “KNOPPIX” [2] and Virtual Machine Monitor CLOOP. It is made from cloop (Compressed “Xen” [3, 4]. Xenoppix boots Linux (KNOP- Loopback block device) and FUSE (Filesys- PIX) as Host OS and NetBSD or Plan9 as Guest tem USErspace). HTTP-FUSE CLOOP can re- OS with a bootable DVD only. KNOPPIX construct a block device from many small block is advanced in automatic device detection and files of HTTP servers. In this paper we describe driver integration. It prepares the Xen environ- the detail of the implementation and its perfor- ment and Guest OSes don’t need to worry about mance. lack of device drivers.
    [Show full text]
  • How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise
    How to Create a Custom Live CD for Secure Remote Incident Handling in the Enterprise Abstract This paper will document a process to create a custom Live CD for secure remote incident handling on Windows and Linux systems. The process will include how to configure SSH for remote access to the Live CD even when running behind a NAT device. The combination of customization and secure remote access will make this process valuable to incident handlers working in enterprise environments with limited remote IT support. Bert Hayes, [email protected] How to Create a Custom Live CD for Remote Incident Handling 2 Table of Contents Abstract ...........................................................................................................................................1 1. Introduction ............................................................................................................................5 2. Making Your Own Customized Debian GNU/Linux Based System........................................7 2.1. The Development Environment ......................................................................................7 2.2. Making Your Dream Incident Handling System...............................................................9 2.3. Hardening the Base Install.............................................................................................11 2.3.1. Managing Root Access with Sudo..........................................................................11 2.4. Randomizing the Handler Password at Boot Time ........................................................12
    [Show full text]
  • QEMU Version 4.2.0 User Documentation I
    QEMU version 4.2.0 User Documentation i Table of Contents 1 Introduction ::::::::::::::::::::::::::::::::::::: 1 1.1 Features :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 2 QEMU PC System emulator ::::::::::::::::::: 2 2.1 Introduction :::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.2 Quick Start::::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.3 Invocation :::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2.3.1 Standard options :::::::::::::::::::::::::::::::::::::::::: 3 2.3.2 Block device options :::::::::::::::::::::::::::::::::::::: 12 2.3.3 USB options:::::::::::::::::::::::::::::::::::::::::::::: 23 2.3.4 Display options ::::::::::::::::::::::::::::::::::::::::::: 23 2.3.5 i386 target only::::::::::::::::::::::::::::::::::::::::::: 30 2.3.6 Network options :::::::::::::::::::::::::::::::::::::::::: 31 2.3.7 Character device options:::::::::::::::::::::::::::::::::: 38 2.3.8 Bluetooth(R) options ::::::::::::::::::::::::::::::::::::: 42 2.3.9 TPM device options :::::::::::::::::::::::::::::::::::::: 43 2.3.10 Linux/Multiboot boot specific ::::::::::::::::::::::::::: 44 2.3.11 Debug/Expert options ::::::::::::::::::::::::::::::::::: 45 2.3.12 Generic object creation :::::::::::::::::::::::::::::::::: 54 2.3.13 Device URL Syntax ::::::::::::::::::::::::::::::::::::: 66 2.4 Keys in the graphical frontends :::::::::::::::::::::::::::::::: 69 2.5 Keys in the character backend multiplexer ::::::::::::::::::::: 69 2.6 QEMU Monitor ::::::::::::::::::::::::::::::::::::::::::::::: 70 2.6.1 Commands :::::::::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Smaller Flight Data Recorders{
    Available online at http://docs.lib.purdue.edu/jate Journal of Aviation Technology and Engineering 2:2 (2013) 45–55 Smaller Flight Data Recorders{ Yair Wiseman and Alon Barkai Bar-Ilan University Abstract Data captured by flight data recorders are generally stored on the system’s embedded hard disk. A common problem is the lack of storage space on the disk. This lack of space for data storage leads to either a constant effort to reduce the space used by data, or to increased costs due to acquisition of additional space, which is not always possible. File compression can solve the problem, but carries with it the potential drawback of the increased overhead required when writing the data to the disk, putting an excessive load on the system and degrading system performance. The author suggests the use of an efficient compressed file system that both compresses data in real time and ensures that there will be minimal impact on the performance of other tasks. Keywords: flight data recorder, data compression, file system Introduction A flight data recorder is a small line-replaceable computer unit employed in aircraft. Its function is recording pilots’ inputs, electronic inputs, sensor positions and instructions sent to any electronic systems on the aircraft. It is unofficially referred to as a "black box". Flight data recorders are designed to be small and thoroughly fabricated to withstand the influence of high speed impacts and extreme temperatures. A flight data recorder from a commercial aircraft can be seen in Figure 1. State-of-the-art high density flash memory devices have permitted the solid state flight data recorder (SSFDR) to be implemented with much larger memory capacity.
    [Show full text]
  • Building a Self-Contained Auto-Configuring Linux System On
    Building a self-contained auto-configuring Linux system on an iso9660 filesystem Klaus Knopper [email protected] ¡ http://www.knopper.net/knoppix/ Abstract Bootable CD-Roms with a small Linux rescue system in business card size [1, 2] or regular size live demonstration CDs [3] are becoming popular re- cently. Also, some of the commercial Linux distributors as well as non-profit Open Source groups are developing self-running demos that are preconfigured for certain hardware, or contain a configuration frontend. Knoppix (Knopper’s *nix) is an attempt to not only create a fully featured rescue/demo system on a single CD, but also to unburden the user from the task of hardware identi- fication and configuration of drivers, devices and X11 for his or her specific hardware. The resulting product is supposed to be a platform CD with a stable GNU/Linux base system, that can be used to customize static installations for a specific purpose. Goal: Creating a fully functional and usable Reducing space limitations by compression Linux system running completely from a sin- The core system of about 200 MB (uncompressed) is gle CD currently based on the popular RedHat [4] distribution A frequently asked question asked by people who ”just and contains all basic commands and tools for a generic want to have a glance” on Linux to check out how use- Linux system. That leaves, on a standard 650 MB CD- ful it could be for them is, ”How can I test Linux with- Rom, over 400 MB for custom applications, which can out having to change anything on my computer?”.
    [Show full text]
  • Building Embedded Linux Systems with Buildroot
    Embedded Linux Conference Building embedded Linux systems with Buildroot Thomas Petazzoni Free Electrons http://free-electrons.com/ 1 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Rights to copy © Copyright 2009, Free Electrons [email protected] Document sources, updates and translations: http://free-electrons.com/docs/buildroot Corrections, suggestions, contributions and translations are welcome! Attribution ± ShareAlike 3.0 Latest update: Apr 28, 2009 You are free to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions Attribution. You must give the original author credit. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/3.0/legalcode 2 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Leveraging free software Thousands of free software packages are available and can be leveraged to build embedded systems With free software You have control over the source Bugs can be fixed New features can be added Your system can be customized In theory, the system designers and developers have a lot of flexibility thanks to free software However, leveraging the existing free software packages may not be very easy.
    [Show full text]
  • Smaller Flight Data Recorders{
    Available online at http://docs.lib.purdue.edu/jate Journal of Aviation Technology and Engineering 2:2 (2013) 45–55 Smaller Flight Data Recorders{ Yair Wiseman and Alon Barkai Bar-Ilan University Abstract Data captured by flight data recorders are generally stored on the system’s embedded hard disk. A common problem is the lack of storage space on the disk. This lack of space for data storage leads to either a constant effort to reduce the space used by data, or to increased costs due to acquisition of additional space, which is not always possible. File compression can solve the problem, but carries with it the potential drawback of the increased overhead required when writing the data to the disk, putting an excessive load on the system and degrading system performance. The author suggests the use of an efficient compressed file system that both compresses data in real time and ensures that there will be minimal impact on the performance of other tasks. Keywords: flight data recorder, data compression, file system Introduction A flight data recorder is a small line-replaceable computer unit employed in aircraft. Its function is recording pilots’ inputs, electronic inputs, sensor positions and instructions sent to any electronic systems on the aircraft. It is unofficially referred to as a "black box". Flight data recorders are designed to be small and thoroughly fabricated to withstand the influence of high speed impacts and extreme temperatures. A flight data recorder from a commercial aircraft can be seen in Figure 1. State-of-the-art high density flash memory devices have permitted the solid state flight data recorder (SSFDR) to be implemented with much larger memory capacity.
    [Show full text]
  • Filesystems in Livecd
    Filesystems in LiveCD J. R. Okajima 2010/12 In the majority of cases, LiveCD uses Squashfs, tmpfs, and AUFS. This report compares usage of squashfs with others to implement LiveCD. Ancient Age A long long time ago, there was an approach to implement LiveCD by “shadow direc- tory”. It may be a rather old name but used very widely. For example, when we have source files under src/, and if we build it under the directory for multiple architec- tures, then we will need to remove all the built files for each build. It is a waste of time. In order to address this problem, make another directory obj/, create symbolic links under it, and build under obj/. This is the shadow directory approach. All the built object files are created under obj/ and the developers do not need to care about the difference of the build directory. LiveCD implemented by this approach (readonly FS + tmpfs + shadow dir) suc- ceeded to redirect the file I/O, eg. read from readonly FS and write to tmpfs, but it brought huge number of symbolic links. Obviously it was not the best approach. Squashfs and AUFS Later LiveCDs adopt a stackable filesystem, eg. Unionfs or AUFS. They both intro- duce a hierarchy to mounting filesystems, and mount a writable filesystem transpar- ently over readonly filesystems, and provide essential features of redirecting file I/O to layers and internal copy-up between layers which enables modification the files on the readonly filesystems logically. Since readonly filesystems can be specified more than one, LiveCD can handle them as an application packages such like compiler package, office suite.
    [Show full text]
  • O'reilly Knoppix Hacks (2Nd Edition).Pdf
    SECOND EDITION KNOPPIX HACKSTM Kyle Rankin Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo Knoppix Hacks,™ Second Edition by Kyle Rankin Copyright © 2008 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Brian Jepson Cover Designer: Karen Montgomery Production Editor: Adam Witwer Interior Designer: David Futato Production Services: Octal Publishing, Inc. Illustrators: Robert Romano and Jessamyn Read Printing History: October 2004: First Edition. November 2007: Second Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. The Hacks series designations, Knoppix Hacks, the image of a pocket knife, “Hacks 100 Industrial-Strength Tips and Tools,” and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. Small print: The technologies discussed in this publication, the limitations on these technologies that technology and content owners seek to impose, and the laws actually limiting the use of these technologies are constantly changing.
    [Show full text]
  • Proxmox VE Administration Guide Ii
    PROXMOX VE ADMINISTRATION GUIDE RELEASE 7.0 July 6, 2021 Proxmox Server Solutions Gmbh www.proxmox.com Proxmox VE Administration Guide ii Copyright © 2021 Proxmox Server Solutions Gmbh Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Proxmox VE Administration Guide iii Contents 1 Introduction 1 1.1 Central Management....................................... 2 1.2 Flexible Storage......................................... 3 1.3 Integrated Backup and Restore................................. 3 1.4 High Availability Cluster..................................... 3 1.5 Flexible Networking........................................ 4 1.6 Integrated Firewall........................................ 4 1.7 Hyper-converged Infrastructure................................. 4 1.7.1 Benefits of a Hyper-Converged Infrastructure (HCI) with Proxmox VE.......... 4 1.7.2 Hyper-Converged Infrastructure: Storage........................ 5 1.8 Why Open Source........................................ 5 1.9 Your benefits with Proxmox VE.................................. 5 1.10 Getting Help........................................... 6 1.10.1 Proxmox VE Wiki..................................... 6 1.10.2 Community Support Forum................................ 6 1.10.3
    [Show full text]
  • Secure Boot Cds for VPN HOWTO Secure Boot Cds for VPN HOWTO Table of Contents Secure Boot Cds for VPN HOWTO
    Secure Boot CDs for VPN HOWTO Secure Boot CDs for VPN HOWTO Table of Contents Secure Boot CDs for VPN HOWTO.................................................................................................................1 Jeffery Douglas Waddell jefferydouglaswaddell (at) gmail (dot) com...................................................1 1. Introduction..........................................................................................................................................1 2. Theory..................................................................................................................................................1 3. Technologies........................................................................................................................................1 4. Implementation....................................................................................................................................1 5. Maintenance.........................................................................................................................................1 6. Advanced Issues...................................................................................................................................1 7. Features................................................................................................................................................1 8. Troubleshooting...................................................................................................................................1
    [Show full text]
  • Proceedings of the 4Th Annual Linux Showcase & Conference, Atlanta
    USENIX Association Proceedings of the 4th Annual Linux Showcase & Conference, Atlanta Atlanta, Georgia, USA October 10 –14, 2000 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2000 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Building a self-contained auto-configuring Linux system on an iso9660 filesystem Klaus Knopper [email protected] ¡ http://www.knopper.net/knoppix/ Abstract Bootable CD-Roms with a small Linux rescue system in business card size [1, 2] or regular size live demonstration CDs [3] are becoming popular re- cently. Also, some of the commercial Linux distributors as well as non-profit Open Source groups are developing self-running demos that are preconfigured for certain hardware, or contain a configuration frontend. Knoppix (Knopper’s *nix) is an attempt to not only create a fully featured rescue/demo system on a single CD, but also to unburden the user from the task of hardware identi- fication and configuration of drivers, devices and X11 for his or her specific hardware. The resulting product is supposed to be a platform CD with a stable GNU/Linux base system, that can be used to customize static installations for a specific purpose. Goal: Creating a fully functional and usable Reducing space limitations by compression Linux system running completely from a sin- The core system of about 200 MB (uncompressed) is gle CD currently based on the popular RedHat [4] distribution A frequently asked question asked by people who ”just and contains all basic commands and tools for a generic want to have a glance” on Linux to check out how use- Linux system.
    [Show full text]