Skip to main content
Welcome guest. | Register | Login | Post

Considering switching distribution, but to which?

21 replies [Last post]
tbuitenh's picture
Joined: 2005-12-21

I'm considering switching to a different distribution. The reason is that I'm not happy about my recent experiences with archlinux.

- some time ago I had some spare time and decided to see if I could help someone in the #archlinux irc channel. I found some arch fans talking about ideas for trolling in #centos - and executing those ideas.

- a few kernel upgrades ago, shutdown -h became equivalent to shutdown -r . Not a big problem, solved by downgrading, and permanently solved in the next upgrade, but this kind of thing is not supposed to happen. Kernels should be tested before letting normal users get them in the upgrade. Since then I don't upgrade the kernel automatically anymore, and don't install kernel packages with low version numbers.

- today, another kernel upgrade. Somehow /sbin is not in my path (it is even for normal users, I haven't been able to reproduce the issue yet), causing the script that builds the initial ramdisk to fail. If I had upgraded the kernel separately, the errors would have been hidden by hundreds of lines from other packages and I would have ended up with an unbootable system.
Anyway, at first the cause of the error isn't clear, so I copy it to the search box of the archlinux forum. Nothing. I downgrade the kernel to the previous version - same problem of course. I'm getting a little nervous. I go to #archlinux, and ask "while upgrading the kernel, I get [the error]. Is this a problem or can I safely reboot?". Answer: you'll find out soon enough. I'm not amused. I search the forums again, this time with only one word from the error. I find others have had the same problem, and it does indeed make the kernel unbootable. The solution: make sure /sbin is in the path, and install the kernel upgrade again. Really... code run as root, and especially upgrade scripts for vital packages should not make assumptions. Assuming the PATH environment variable is sensible is an assumption. And how did it end up being not sensible anyway?

So those are my issues with archlinux: bad kernel upgrades, and a not nice / unhelpful community.

I don't have time to switch distros now, but if things continue like this I think I will when I have time again. I'm considering the following:

RubixOS: mixture of arch and slackware. Seems good, but does anyone have experience with it?

Debian stable, with recent versions of a few packages compiled myself: no more problems, ever. But configuration is done through tools instead of directly editing the files, and I don't like that.

Slackware: good, but no automatic dependency thing. I could try slapt-get, though.

Any better ideas?

libervisco's picture
Joined: 2006-05-04
Looks like some prominent

Looks like some prominent people in the Arch community are getting infected by a disease known as elititis. The usual symptoms are treating the way of the particular software project one is associated with as superior and more important than any others (hence the trolling of other distro channels) or disregard for questions one finds unimportant to ones important self.

Or roughly so.

In any case, it's sad to see this.

But.. I would recommend sidux if you're already willing to give debian a shot. Sidux is a Debian sid distribution and is hence pretty cutting edge while sufficiently stable for desktop use (it really is) and likely more stable than Arch is these days (judging from your problems and similar issues I had before on Arch too actually with kernel upgrades). I use sidux right now and am so far quite satisfied. It fits the bill; lots of newest packages, great support community, sufficiently stable and flexible (unlike Ubuntu it doesn't really force its way much). So.. that's my recommendation, based on my own current experience. Smiling

Best of luck!

tbuitenh's picture
Joined: 2005-12-21
Oh, and I forgot about the

Oh, and I forgot about the old problem of the package manager nearly insisting on replacing sun java with gcj still not being fixed. I encountered that one again today too :/ .

tbuitenh's picture
Joined: 2005-12-21
sidux looks interesting, it

sidux looks interesting, it will be considered. Still, I'd prefer a distro more similar to arch (one using the Keep It Simple, Stupid approach)

Maybe I'll try building something myself, starting with EasyLFS Smiling . We'll see.

Joined: 2006-03-28
I'm happy to hear you take

I'm happy to hear you take my project into consideration. And I guess you'd be happy with the fact that you'll be configuring everything in text-files and nothing with some tool. But since it's all from the source you'll have to take care of dependencies yourself, though of course you can also install RPM or DPKG. ;-)

tbuitenh's picture
Joined: 2005-12-21
If one is careful not to

If one is careful not to use software with many dependencies, I guess automated (un)installation of dependencies isn't really needed.

I think it may be interesting to try to build a distro consisting of only one monolithic package. Include only one program for each task, and use binary patches for updates. Choice? Who needs choice? If someone needs a different set of programs than I do, they can use a different distro Laughing out loud .

free-zombie's picture
Joined: 2006-03-08

just package the vanilla GNU system with a kernel of your choice ;-)

tbuitenh's picture
Joined: 2005-12-21
I think I need a little

I think I need a little more than just vanilla GNU, unless you have a very broad definition of GNU. A list of things I need to be comfortable:

xfce (trying matchbox instead may be interesting)
xfce terminal
tar, gzip, bzip2, zip

hardware support:

gcc, g++, bison, flex
autoconf, automake
cvs, svn, darcs
sun java, jython

photography / graphics / documents:
panotools & friends
various postscript and pdf utilities
antiword & catdoc
some character picking thing (currently abusing openoffice just for that)

mplayer & vlc
sox, ogg*, lame

paper I/O:
cups / gtklp
sane / xsane


If someone recognizes this list as (nearly) the same as their own favourite tools, we may have a future project Smiling .

Joined: 2006-03-28
Well, most of the general

Well, most of the general software (except for GPG) is there in EasyLFS, and of course most development-stuff like the autotools and GCC (complete or only C/C++) (at the moment Python will only be installed when you want SELinux).
Well, all the other software of course is not there, but some could be an option for future versions, like GPG for example. For the next version I already implemented cryptsetup-luks, so why not also add GPG, some libs of it are there already anyway for something else.

tbuitenh's picture
Joined: 2005-12-21
GPG is nice for verifying

GPG is nice for verifying signatures of source tarballs, if they have them. I think EasyLFS should have GPG.

Have you considered the possibilities of an encrypted filesystem and encrypted swap?

Joined: 2006-03-28
I have considered it, but

I have considered it, but so far I haven't looked into encrypting swap yet and since for encrypted /-fs you need an initrd I'll also have to suck up the necessary information for that first.
For encrypted filesysystem, other than /, EasyLFS will bring cryptsetup-luks, which I consider pretty good.

GPG really would be a good addition for EasyLFS, I guess I will add it to my current working-set so that it will be in the next version.

tbuitenh's picture
Joined: 2005-12-21
I wouldn't recommend

I wouldn't recommend encrypting all filesystems anyway: you lose performance and gain nothing, unless you want to hide what software you have installed. The following should be encrypted:

/tmp (if it isn't a ramdisk)

That should be enough to hide all user data, right?

Joined: 2006-03-28
Yes, that should be

Yes, that should be enough.
But since EasyLFS at this time is only using one partition for everything this would have to be implemented by the user.
Later I might add the possibility to have different partitions make up the fs-tree, even with encryption and different filesystems, but so far this isn't possible.

BTW, you got a quick link about encrypted swap?
And what is commonly used for encrypted filesystems? As said, so far I've been playing with cryptsetup-luks, which uses the device-mapper. But I'm not sure if this is suitable to have the fs mounted during boot-time, though it should be possible.
Would be great if you also had a link for that.

tbuitenh's picture
Joined: 2005-12-21
I currently don't use any

I currently don't use any encryption, so I'm afraid I can't provide a lot of useful links. After googling around a bit it seems encrypting swap is the same as encrypting any other partition, except that one could use a random key for it.

page from archlinux wiki

Second thought about my previous post: / should be encrypted after all, otherwise someone with physical access could still install spyware. OTOH, even if you do encrypt /, they could still mess with /boot . I guess the only solution to that is to put /boot on a CD-R with your signature written on it. I guess I'll have to buy a new cd/dvd drive sometime then, cause letting my whole system depend on a drive that is becoming unreliable doesn't seem like a great idea.

libervisco's picture
Joined: 2006-05-04
Some other choices you

Some other choices you might want to consider, that we haven't mentioned, are pure Slackware, Zenwalk or maybe CRUX. Since you're considering going with your own combination anyway I doubt any of those would be too hardcore for you. Smiling

On the other hand... we've been talking about doing an EasyLFS based livecd distro and you've now taken some interest in something EasyLFS based, so there's a possibly fruitful connection. Smiling

This also reminds me of discussions we had about perfect ideal OS. Maybe we could try doing some of those ideas somehow.. Smiling

Just some thoughts.

tbuitenh's picture
Joined: 2005-12-21
Slackware and Zenwalk would

Slackware and Zenwalk would work. CRUX deletes documentation, just like arch does. It's not a huge problem, but I prefer a distribution that doesn't do that.

My thoughts about the ideal OS have changed, I would like one that manages software this way:

compile it yourself, with help from some scripts such as ketchup, or rsync binaries

core (maybe based on EasyLFS):
compile it yourself, or rsync binaries.

these are named after their developers, and contain all software those developers use that isn't in core. For example there could be an add-on named "tbuitenh" and one named "libervisco" and... etc. You can get binaries through rsync again, or you can get (or write!) some build scripts yourself. It is recommended that you start with an existing add-on, adapt it to your needs, then become an add-on developer yourself. Developers are of course free to share build scripts with each other, but they are not required to make sure their scripts stay compatible with those made by others.
The add-ons will be contained in their own directories, and mixed with the rest of the system using unionfs (if necessary because of hardcoded or standard paths. /opt/name-of-add-on can be used if all software in an add-on allows it). Add-ons may depend on each other, but not so much that anyone would want automatic dependency stuff. There will be a few special ones for widely used software, such as "kde" and "lsb/desktop", but any add-on developer who wants to can ignore those.

Why do things this way?

Binary distributions that use package managers and have many optional packages cannot be as fine-tuned as the single developer add-ons can be. Also, for many binary package formats making packages is a pain. And of course dependencies sometimes cause trouble.

Source based distributions can be fine-tuned, but have their own inflexibilities *cough*useflags*cough*, and take a long time before you can start using them.

LFS takes even more time, and most people fail the first time they try it.

My approach is to try to combine the best of binary distros and LFS, while keeping things simple.

Joined: 2006-03-28
I like this idea. Since

I like this idea.
Since EasyLFS, just like Slax, uses the Linux Live Scripts it can easily be supplied with new modules.
These can just be added to the image-file and will be available at boot.

Anybody played with Slax or the Linux Live Scripts before? It's really cool.
Just have a look at the Slax-site, you download the basic image and then any extra module you like.
The same is possible with the EasyLFS LiveCD, so it should be pretty easy for us to create something from that idea.

tbuitenh's picture
Joined: 2005-12-21
Every add-on developer gets

Every add-on developer gets the ability to create a livecd of his super-tweaked environment? Neat.

Joined: 2006-03-28
Well, I was thinking of the

Well, I was thinking of the principle Slax is using. Having one basic LiveCD, but every developer can offer modules that can easily be added to it.
This would also make it easier to try different things since you don't need to download a bunch of LiveCDs, but just one CD and then stock it up with different modules.

Joined: 2006-03-28
During the last few days I

During the last few days I did some testing and made the decision that EasyLFS 0.3 will contain GPG.
For now I'll go with the GPG1. After I did some testing I might switch to GPG2.
If you got some good reasons why I shouldn't use GPG1 and go for GPG2 rightaway, I'm all ears.

tbuitenh's picture
Joined: 2005-12-21
I have GPG1 here, wasn't

I have GPG1 here, wasn't even aware of the existence of GPG2...

Joined: 2006-03-28
GPG2 is the "new, modular

GPG2 is the "new, modular version".
On the download-page GPG1 is still on top, so I guess it's still the recommended version.

Also it says wrote:

GnuPG comes in two flavours: 1.4.7 is the well known and portable standalone version, whereas 2.0.3 is the enhanced and somewhat harder to build version.

Comment viewing options