Smaller graphical install than basic on Eee PC 701.

[Akuna]

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".

A Salix configuration panel has been on my mind & todo list for a little while... if there is real interest for it I could start working on it in earnest. It wouldn't be re-inventing the wheel, but it would gather all of Salix (native & otherwise) configuration utilities in a centralized & visually organized spot.

I'll let Gapan discuss the kernel & applications topics.

If you already made a personalized CD, even if it is not that polished yet, maybe you could give a link so that we can play with it & better apprehend your concept. I have quite a few 'ordinosaures' (not sure if that term makes sense in English, basically means very ancient computer, 'ordinateur + dinosaur' in French) around & I'll be curious to see how they respond.

P.S.: If you have a developer's IRC channel I will be happy to discuss what I am doing there.

ATM, we don't have a dedicated developer's channel, but most of us usually hang on Salix Jabber room (salix@chat.meticul.eu), especially in the evenings... (Western European times), you can also grab some of us on Salix IRC channel (#salix at irc.freenode.net).

[thenktor]

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.

What browser is available without gtk/qt?

EDIT: OK, there is Dillo and I've never tried the 2.x series.

[gapan]

@caitlyn

I'm usually the only one from the dev team hanging in the irc channel, but most other devs use only our jabber room. If you can join us there at some time (hopefully at a time when someone is available ), it would be great. The time difference could be a problem though. The mailing list might be a better place to discuss this too.

I think there is no major problem with using a lighter kernel. One potential problem would be that ndiswrapper would not work out of the box, but maybe we can create a separate package, targeted at that kernel. Could another solution be to use the slackware kernel-generic instead of kernel-huge and add a initrd with support for a couple of filesystems on top? Maybe there's no need to support all filesystems that the standard kernel provides for the root filesystem, ext4 and ext2 may be enough?

About the packages built with sbbuilder, I can't be sure until I have a look at them. What the scripts need to be though, is cross platform. We need to have the same scripts for i486 and x86_64 (and probably also arm) targets. BTW, have you looked into slkbuild at all?

I have actually tried PekWM some time ago. Not bad, it will have some people scratching their heads, but it is indeed very fast and the tabbed windows feature is great. I see you prefer fbpanel, no problem with that, but maybe lxpanel does exactly the same job? The default application selection is a think to talk about obviously. What kind of applications are you considering, apart from the web browser? And for that matter, what web browser are you considering?

Isn't cpu frequency scaling working out of the box anyway? Or are talking about the user being able to the cpu speed manually with a GUI tool?

You article about vl-hot got me wondering. So, I thought I could do a small, completely un-scientific, experiment. I turned my netbook on, charged it fully, I then let it run on battery and timed how long it would take for the battery to reach 50%. I took exactly 52min34sec. The screensaver was disabled and I wasn't actually doing anything with it, I was only watching the battery meter drop. I charged it back to 100% then, disabled hal completely and let it drop to 50% again. This time it took 52min19sec. So, while in theory it seems that polling might be an issue with battery drainage, it isn't really, at least not here. So, staying with hal and all the features it provides seems like a better idea to me. You can try to replicate the "experiment" if you like. Another thing that we definitely need hal for, is to configure different keyboard setups in xorg.

Right now LXDE core+basic package directories are ~240MB. This could be easily stripped down a lot if we removed all development packages and other packages not needed on a netbook (jfsutils for example), replaced vim with elvis etc.

Anyway, these are my thoughts so far, I think we can definitely make this work.

[thenktor]

I see you prefer fbpanel, no problem with that, but maybe lxpanel does exactly the same job?

I doubt that it's possible to build a usable system without gtk/qt, but if we really want to try I'd suggest tint2 as panel (no gtk dep)

[caitlyn]

I doubt that it's possible to build a usable system without gtk/qt, but if we really want to try I'd suggest tint2 as panel (no gtk dep)

It is possible since Damn Small Linux did it. Please note that the ultralight build idea is just that: an idea, not something I've already worked on. Right now my focus would be on the mini build since that is something for which there is a clear need. Low end netbooks with tiny SSDs are still being sold today. Of course, a lot of them are ARM or MIPS based machines and that is an entirely different discussion. My concern right now is building an i486 and possibly an x86_64 version that can install in 1GB of space.

[caitlyn]

I think there is no major problem with using a lighter kernel. One potential problem would be that ndiswrapper would not work out of the box, but maybe we can create a separate package, targeted at that kernel. Could another solution be to use the slackware kernel-generic instead of kernel-huge and add a initrd with support for a couple of filesystems on top? Maybe there's no need to support all filesystems that the standard kernel provides for the root filesystem, ext4 and ext2 may be enough?

I'm off on a business trip right now and don't have the time to reexamine the Slackware kernel. I'll do that this weekend.

About the packages built with sbbuilder, I can't be sure until I have a look at them. What the scripts need to be though, is cross platform. We need to have the same scripts for i486 and x86_64 (and probably also arm) targets. BTW, have you looked into slkbuild at all?

This could be the deal breaker for me. I have looked at slkbuild and it just seems like a lot more work for a lot less result. sbbuilder (at least as I modified it) does produce one cross-platform script. I have not included ARM because of the unique problems with that platform, or should I say "platforms". Nothing is standard and what works on one machine with one BIOS won't work on another with a different BIOS. Then look at all the chip variations and how wide the differences are. Unlike Intel, ARM stuff doesn't follow any sane standards and a single build will not work on a variety of machines.

I have actually tried PekWM some time ago. Not bad, it will have some people scratching their heads, but it is indeed very fast and the tabbed windows feature is great.

I don't think people will have a lot of problems with it if the creature comforts they are used to are included with other pieces of the desktop, as in pcmanfm and a panel of some sort. I wanted to create something unique not just another LXDE clone of SalixOS. Besides, once you use the tabbed window feature on a netbook with limited screen space, particularly something with a 7" screen, you won't want to give it up

I see you prefer fbpanel, no problem with that, but maybe lxpanel does exactly the same job?

When I wrote that article lxpanel was a buggy mess. It is better now and I need to reconsider it as well as tint2. No final decisions on anything have been made. BTW, lxpanel is based on fbpanel and thetwo share a lot of code.

The default application selection is a think to talk about obviously. What kind of applications are you considering, apart from the web browser? And for that matter, what web browser are you considering?

The most likely web browser for a default at this point would be Kazehakase. I am also considering Midori and Arora. I also want to package dillo for legacy machines that need something super light but I don.t want that to be the default. Other apps for the mini (not ultralight build) would include a lot of things already in SalixOS including abiword, gnumeric, claws-mail, xmms, gftp. I probably would use a smaller/lighter burning program and possibly ripperX. flphoto is another if I use fltk. I do plan on including the Fox toolkit, adie as the default text editor and shutterbug for screenshots. None of this is set in stone, of course. All of these are packages which could be added to the SalixOS repos without impacting what already exists.

Or are talking about the user being able to the cpu speed manually with a GUI tool?

Yes. You need that to do away with the underclocking on early EeePC models as well as some Everex Cloudbook versions and the Sylvania g.

You article about vl-hot got me wondering. So, I thought I could do a small, completely un-scientific, experiment. I turned my netbook on, charged it fully, I then let it run on battery and timed how long it would take for the battery to reach 50%. I took exactly 52min34sec. The screensaver was disabled and I wasn't actually doing anything with it, I was only watching the battery meter drop. I charged it back to 100% then, disabled hal completely and let it drop to 50% again. This time it took 52min19sec. So, while in theory it seems that polling might be an issue with battery drainage,

Try it on some old, legacy hardware like a Toshiba Libretto SS1010 with 96MB of RAM and get back to me. The performance difference is striking.

Right now LXDE core+basic package directories are ~240MB. This could be easily stripped down a lot if we removed all development packages and other packages not needed on a netbook (jfsutils for example), replaced vim with elvis etc.

I know. Please remember that what I have now is decidedly not SalixOS. At this point it is something different. I would need to make significant changes to bring it back to something that looked like SalixOS.

Anyway, these are my thoughts so far, I think we can definitely make this work.

Glad to hear it. I really don't have adequate time to properly support a new distro. The people who are helping me are doing it in limited ways as time permits. Doing a SalixOS variant/respin puts the support issue to bed as anyone who knows SalixOS could answer questions. I also don't want to do things like a separate website, wiki, forum and mailing list. Aside from the time involved I have no desire to reinvent the wheel. I'm also very impressed with the SalixOS developers and community so working within your framework is very appealing to me.

[caitlyn]

A Salix configuration panel has been on my mind & todo list for a little while... if there is real interest for it I could start working on it in earnest. It wouldn't be re-inventing the wheel, but it would gather all of Salix (native & otherwise) configuration utilities in a centralized & visually organized spot.

People have asked about it in the forum before. If you do it I think you'll have plenty of interest. I certainly think it's an easier way to find things, particularly for people not familiar with the distro.

If you already made a personalized CD, even if it is not that polished yet, maybe you could give a link so that we can play with it & better apprehend your concept.

Let me clean it up a bit more and then I can do it. I wouldn't in it's present state.

[klanger]

Matchbox window manager is designed for netbooks & smartphones with small screens.

It opens all apps in fullscreen mode.

It works OK even with GIMP (you just have to switch screen between toolbox and main gimp screen).

As an eeepc 900 owner I have to say that panel is the least needed stuff on such a small screen. Grun or similar (eg. pekwm includes one by default) + a good collection of keybindings are just fine.

There is also Adcomp's python script that allow you to make something like gnome-shell (screen full of buttoms) that could play a role of a control center for an OS.

Uzbl is also an interesting option for your task - it is a webkit browser that can be "tuned" to play a central role in little computing (keybindings that allow you to run apps within/from uzbl)

[thenktor]

I doubt that it's possible to build a usable system without gtk/qt, but if we really want to try I'd suggest tint2 as panel (no gtk dep)

It is possible since Damn Small Linux did it.

As far as I can see they are using gtk+1, so they are not completely without gtk+ What I wanted to say is that a usable system needs a usable browser nowadays and that probably is a challenge.

]I have not included ARM because of the unique problems with that platform, or should I say "platforms". Nothing is standard and what works on one machine with one BIOS won't work on another with a different BIOS. Then look at all the chip variations and how wide the differences are. Unlike Intel, ARM stuff doesn't follow any sane standards and a single build will not work on a variety of machines.

Even if this is off topic: This of course is not completely true. ARM computers usually don't have a BIOS comparable to a PC. They usually use a boot loader that loads the kernel from flash memory. Therefore there is no standard boot method like on a PC. But similar to x86 there are some different chip versions and a majority is compatible (just like i686 is compatible to i486). So building executables is no problem, you just have to provide a kernel, that fits to your CPU.

[globetrotterdk]

I just discovered nFluxOS: http://multidistro.com/ I haven't tried it yet myself, but perhaps it could provide some inspiration for a mini footprint Salix OS version? There are both Ubuntu, Debian and Slackware based versions.