On Tue, 04 Mar 2008 21:54:50 +0100, Michael Prokop wrote:
grml wants to take part in the Google Summer of Code 2008 and therefor we are collecting ideas for our proposal. . .
- About live CD building
* add tool/feature so as the iso can be put on USB easily. I know there is grml2usb, but slax' method seems easier and more straightforward. * how about add an option to build the cd so as it boots with Grub. * is this case Grub4Dos seems to be more appropriate since it can boot CD/USB/HD using the same method.
Mika, this is very exciting, how are you going to coordinate it? Any way to keep interested grml fan like me in the loop?
BTW, As for "Create a live CD of your running system", I believe that is not too difficult to do with the linux live script.
Another possible project,
How about provide Linux-VServer by default in grml (at least from medium)?
I've recently put up a package containing all info that I collected on Linux-VServer.
Linux-VServer is a jail mechanism in that it can be used to securely partition resources on a computer system (such as the file system, CPU time, network addresses and memory) in such a way that processes cannot mount a denial-of-service attack on anything outside their partition.
Booting a virtual private server is then simply a matter of kickstarting init in a new security context; likewise, shutting it down simply entails killing all processes with that security context. The contexts themselves are robust enough to boot many Linux distributions unmodified, including Debian and Fedora Core.
Virtual private servers are commonly used in web hosting services (or ssh/ftp servers etc), where they are useful for segregating customer accounts, pooling resources and containing any potential security breaches. To save space on such installations, each virtual server's file system can be created as a tree of copy-on-write hard links to a "template" file system. The hard link is marked with a special filesystem attribute and when modified, is securely and transparently replaced with a real copy of the file.
Advantages
* Virtual servers share the same system call interface and do not have any emulation overhead. * Virtual servers do not have to be backed by opaque disk images, but can share a common file system and common sets of files (through copy-on-write hard links). This makes it easier to back-up a system and to pool disk space amongst virtual servers. * Processes within the virtual server run as regular processes on the host system. This is somewhat more memory-efficient and I/O-efficient than whole-system emulation, which cannot return "unused" memory or share a disk cache with the host and other virtual servers. * Processes within the virtual server are queued on the same scheduler as on the host, allowing guests processes to run concurrently on SMP systems. This is not trivial to implement with whole-system emulation. * Networking is based on isolation rather than virtualization, so there is no additional overhead for packets.
Check the rest at
http://xpt.sourceforge.net/techdocs/nix/virtual/vt03-LinuxVServerInfo/
http://xpt.sourceforge.net/techdocs/nix/virtual/vt04-LinuxVServerSetup/