Spying Slack, Zenwalk, ....

[Kocil]

Ok friends ...
We are moving for VL-6 for sure.
So we should start looking around for some new ideas.
Here are some positives and negatives things of the others for us.

Slackware-12.0 rc1
---------------------------
I installed this on my computer yesterday.
The installation was ... slacky as ever, nothing has changed since Slack 3.x.
The system is running well, i'm using it for sending this post.
The plus:
+ It uses the newest kernel 2.6.21.5
+ As basic and clean as it get. No custom at all for xfce4, nor kde.
   (this is good, because that means we don't have to get rid any distro identity)

The minus:
- xorg packages .... damn, it is as modular as the sources.
  The slackware/x folder contains 289 packages !
- udev is still like that, no usb/cdrom/dvd automounting.
- The installer said, it requires 4 GB for full install !
  I took out some packages, leaving kde and just essential packages, it took 2.8 GB.

Zenwalk 4.4
-----------------
This distro is based on Slack 11.
The plus:
+ It really has a good repository, consistent with Slackware and minimally compliant with GPL.
   They don't distribute the full source code, but they include the slackbuild script in every package.
+ The udev system works, and it is leaner than vl-hot.
+ xorg 7.2 works, with only 3 packages (xorg, xorg-drivers, xorg-fonts-scalable).
+ it is already streamlined

The minus:
- Still using tgz format, dependency info for slapt-get is included, generated using requiredbuilder.
- They have upgraded some slackware 11 packages, thus it is not safe to use Slackware 11 repository anymore,
  especially packages from xap group.
- It is not so clean, there are a lot of customisation

SaxenOS
--------------
Successor of STX linux, derivative of Slackware and Zenwalk.
I haven't test it thoroughly, but I'm interested in it's graphical installer.

Tukani
---------
I did not see any significant progress since we took the tlz system.
Things that might be cool is, they can do network install.
The ethernet driver and basic TCP/IP is there,
also wget for downloading the packages.
We should replace wget with slapt-get.

https://sourceforge.net/projects/x11-pinkibuild/
------------------------------------------------------------------
This project provides script to build xorg modular sources into 6 packages.


LFS
------
LFS is really a good PURE start for building a new distro.
I've successfully tried it to build small distro for thin client system.
However, for big distro the effort is huge.
I'm still wondering if it is worth, while Slack has provided the stable base.

[Joe1962]

+ The udev system works, and it is leaner than vl-hot.

LOL, I'd really like you to dwell on that some more. I can't picture any leaner than a few lines in bash.

[Kocil]

+ The udev system works, and it is leaner than vl-hot.

LOL, I'd really like you to dwell on that some more. I can't picture any leaner than a few lines in bash.

Zenwalk uses NO bash at all for automounting.
Purely some configuration in /etc/udev/*
For xfce integration, they provide desktop icon, just like we did in SOHO 5.0 before the vl-hot era.
Thus I added hal and thunar-volman on top of it, wow ... works like charm !
Well, more than that actually.
It pop-ups thunar automatically everytime we insert usb-fd or cdrom,
and also desktop icons for unmounting.
Make me worry, this is worst than Windows 

[Joe1962]

I don't see how you can mount in udev without a helper app to determine partition type, etc.

[Kocil]

Hmmm ... maybe hal and thunar-volman do it.

[Joe1962]

That's what I figured. I hate polling demons like hal, and it's a reported resource hog on lower-powered boxes... . That's the main reasoning behind vl-hot (besides configurable flexibility).

[The Headacher]

Are you honestly suggesting using another base than Slack? I sure hope not. Let's look at slack some more:

+ It uses the newest kernel 2.6.21.5

Not sure how this is a pro. By the time VL 6 is starting to be anywhere near ready for the public the kernel versions will be higher. Also, we'll have a custom kernel anyways right (bootsplash, squashfs, etc.)?

- xorg packages .... damn, it is as modular as the sources.
  The slackware/x folder contains 289 packages !

That is overkill alright... I'm not a big fan using non-slack built packages for xorg though. Perhaps we could merge them into less packages. That should keep /var/log/packages a little cleaner while still using Slacks packages . Trouble with this approach is, that things start getting really weird when a security update for one of those 289 packages is issued. We'd have to get that 'module' from Slack, and then make a completely new Xorg package just for that one update.

  I took out some packages, leaving kde and just essential packages, it took 2.8 GB.

Crikey... that's a lot for something that's going to be used as a base... can't it be trimmed down just a tad more?

Anyways, I'm hoping to trying Slack 12 when it's released on my box, it's looking very promising:

+ completely updated toolchain (glibc, gcc, etc).

[easuter]

The minus:
- xorg packages .... damn, it is as modular as the sources.
  The slackware/x folder contains 289 packages !

Yikes!

That is overkill alright... I'm not a big fan using non-slack built packages for xorg though. Perhaps we could merge them into less packages. That should keep /var/log/packages a little cleaner while still using Slacks packages . Trouble with this approach is, that things start getting really weird when a security update for one of those 289 packages is issued. We'd have to get that 'module' from Slack, and then make a completely new Xorg package just for that one update.

Yeah, making a combined package would be much easier to manage than 289. Plus, might we use a Xorg 7.3 build of our own?
There are lots of reports on other forums that it contains many new drivers, especially for the newer range ATi cards.

The plus:
+ It uses the newest kernel 2.6.21.5

Thats nice to know, because 2.6.18 was the initial kernel chosen for Slackware 12.

[The Headacher]

might we use a Xorg 7.3 build of our own?

No !! . seriously, I'm opposed to using a non-Slack xorg. We didn't do it before, why would we do it now? Of course I'm not the one to give the go or not, that's up to vec.

I just found an interesting problem with my previous suggestion:
you can bet your ass some of those 289 packages will show up as dependencies in packages from slacky.eu and other sites that might use dependency info. If you're going to use slacky.eu ( I know this isn't a usual practice YET ) in slapt-get, you'll get either dependency failures or you'll download and install those packages after all (even though they're already there, there just isn't an entry in /var/log/packages).

[Kocil]

Are you honestly suggesting using another base than Slack? I sure hope not. Let's look at slack some more:

NOOOOOOOO (big one).

Stick with slack, drop the unnecessary, then add some good things from the others.
They have been improving slack, just like we do, so use it if we can.
That's the open source spirit, right ?

[Kocil]

That's what I figured. I hate polling demons like hal, and it's a reported resource hog on lower-powered boxes... . That's the main reasoning behind vl-hot (besides configurable flexibility).

Well, I got to test it on another machine then.
I love VL, but my compy is always the best I can get (currently P4 3,2 GHz, 1 MB RAM) 

[bigpaws]

I am running current and have been for awhile. It has been stable for me.

KDE is compiled with HAL enabled, adding HAL is all that is needed.
Compiz is installed as well. The changes in Slackware 12 RC1 are geared
more for a Desktop, a change that surprised me. Using any of the other other
distributions as a base IMHO will create problems down the road. The reason
that Slack is great to use as a base is that it is vanilla. No hidden gotchas that no
one thought of.

Bigpaws

[lagagnon]

NOTE TO ALL READERS:

I split off the other posts to this thread to a seperate thread entitled "Graphical versus Text Installer" as it was off topic but very relevant.

your friendly moderator...Larry

[JohnB316]

Since Xorg 7 is designed to be built in a modular fashion, it is an advantage to have 289 packages for the different modules. Think about it this way - if only one module needs to be updated because of a security update, it's a lot easier to build a smaller module than it is to have to rebuild 289 modules in a monolithic build for the sake of one module being updated.

Again, don't let the fact that the Slack repo for xorg 7 has 289 packages daunt you. There's a method to that seeming madness. ;-)

Cheers,
John

[exeterdad]

Your exactly right JohnB316