Thank you all for your positive replies. I am particularly thankful for the responses by gapan and Akuna as I know you are both core SalixOS developers.
To answer gapan's question, my initial test builds use SalixOS core as a starting point and I had fully intended to leverage the SalixOS repository rather than trying to build my own up from nothing. So... the end result should be fully compatible with both Slackware 13.1 and SalixOS 13.1.x.
Akuna, that is an incredibly astute question. The answer is that the original idea was simply a compact build. The focus wasn't on super lightweight. OTOH, to keep things small you do end up going with lighter apps (i.e.: no OpenOffice or Firefox in the iso) so the net result is that it should work as well as or perhaps slightly better than the existing LXDE edition on legacy hardware. My real goal, though, was to create something that would install in a small space and work on an original EeePC, Everex Cloudbook, Sylvania g or some of the later Toshiba Libretto models. The original EeePC had a 900MHz Celeron processor underclocked to 600MHz, 512MB RAM, a 7" screen at 800x480 and, as already noted, a whopping 2GB SSD. That is the baseline that the build has to run well in.
I had thought about eventually doing an ultralight build separately using some of the same principles that Damn Small Linux used, i.e.: eschewing GTK+ apps in favor of fltk or perhaps the Fox toolkit. That would require a lot more work including rewriting the GUI tools to use fltk if possible. I consider it a separate project, one I may never get to. I did effectively do it as a one-off for a friend, building a working SalixOS install from core plus stripped down X.org that runs well in 64MB of RAM and probably would function in as little as 32-48MB of RAM but it requires using the command line for administration and for wifi. If I did an ultralight build for real I would want it to have GUI tools.
Let me describe where I am now. The only place I decided to really go off on my own was the kernel and in the choice of some of the configuration tools. I could go with a vanilla Slackware kernel but as you know the huge kernels that you use by default do live up to their name. I went with a newer kernel and an initrd similar to what Vector Linux Light does. I also like the idea of a control panel approach to systems configuration as I think it is easier for people to learn and that left the salixtools out in the cold. Again, I could go back and use the salixtools to fit in with the rest of the SalixOS releases and I would certainly be willing to do so to get under the "Salix roof".
I build my packages using a modified version of the Vector Linux sbbuilder tool. (Yes, the modifications are a Caitlyn special. sbbuilder is just a very nice Perl script so no special coding skills were needed.) I can build packages that meet all of the SalixOS package building rules that way but the scripts look different than any of yours. For example, sbbuilder does generate the slack-desc right in the script. It also does a great job for python based packages
If that is acceptable for inclusion in the SalixOS repository then, again, it would be nice to get under the Salix roof and simply call this a respin.
The target audience is anyone who wants to use a netbook or nettop or other constrained system, old or new, to do real work rather than as an appliance. People who like Unity or Ubuntu Netbook Edition will positively hate what I am doing. My idea for the default desktop is the one I described in my 2009 article at
http://broadcast.oreilly.com/2009/03/im ... ce-ma.html. I really like the way PekWM makes it easy and intuitive to have a single tabbed window with a variety of applications. It's simply brilliant for small screens. I also liberally borrow (steal?) vcpufreq from VectorLinux to handle processor scaling. I am trying to get it working without HAL and with vl-hot as I describe at:
http://broadcast.oreilly.com/2009/02/vl ... rnati.html. I have run into some issues on that front so that piece is not ready for prime time or even an alpha release.
To do this as an alpha build of a SalixOS edition rather than as something separate I need to put back the artwork and the logo/graphics and branding which is pretty darned easy to do. Beyond that, I really need to know how far I can safely stray from what has typically been done for existing SalixOS editions and how much of what I describe above is acceptable and what isn't. I am willing to sacrifice a few personal preferences to work within the SalixOS family. What I am not willing to sacrifice is achieving maximum functionality for small systems in a small build. Right now the iso I have is ~205MB and fits on a mini CD-R.
Did I answer all the questions? Does this sound like something that could be made to work with the SalixOS framework?
