Chad's Linux Distro Project
From Bookofchad
These are notes on a new Distro I'm thinking of doing. It makes very heavy use of 2.6-era Linux features and does a few things that other distros haven't done yet, possibly for good reason.
If I go ahead with a cramfs system I might call it crammix. Maybe Ceramix [Linux]?
Contents |
[edit] Package Model
Basically instead of discrete packages you wind up "installing" blocks. Each block contains an entire functional area. -dev packages provide whatever you need to compile further applications that fit with the block. qt3-dev for instance would include the devel headers and libraries, but core-dev would have to contain gcc et al.
[edit] Package Format
Packages will be complete compressed filesystems (format unknown - cramfs perhaps?) that can be mounted with fuse. There will be a very small .PACKAGE directory with a dependcy file, and another file with menu information.
Packages can be constructed using any method desired as long as the .PACKAGE directory's data is formatted correctly.
[edit] Sample Packages
- initfs - busybox, udev, hardware detection, "package management"... Tenatively this always remains loaded.
- core - bash, ssh fileutils, diskutils, fdisk... What you usually expect in a command line system. - core-dev - gcc, binutils... this can build core and initfs from their -source tarballs
[edit] User Model
When a user logs in a new chroot environment is prepared using remounted directories. This is less inefficient than it sounds given 2.6-level technology.
The user directory itself is held in a different method that should provide a reasonable modern replacement for NIS/YP: The user files are contained on a "server" - the admin can define what the server actually -is-, and then a fuse network daemon of some sort is run providing access to the user directory. The login agent may even dynammically create users on the client side and delete them once their sessions are finished.
I wish linux had UUID uid's instead of 16-bit UID's. Then no collision could ever occur and we could always replicate a particular ID # even if each box had different users. Could get around it using a UID server, but I want something that will -always- work. Bleh.
