I know very little about the reasons why sidux became aptosid and why team members left , but I have to say that as much as I was excited when I first discovered sidux I can't resist the feeling that it's not going well. I find it ironic that they are perfectly OK with using kernel compiled by one of the users who is not a team member (towo) but even mentioning Liquorix is tabu. What is the difference,it's still third party, right ? And if using damentz kernel saves people the headache why don't just use it ? If damentz quits the Liquorix I'll ditch aptosid altogether , I don't want to spend the rest of my life staring at the black monitor with a blinking cursor (aka aptosid kernel upgrade )
Edit: I didn't know squat about that, but then I read Damentz blog :-)
Back to top

slh's kernels are configured using some rather bad assumptions and that's what users been running into when trying to configure nvidia or fglrx blobs.

Liquorix kernels are well configured and they worked when slh's kernels failed.

The aptosid team doesn't want to admit that damentz has gotten it right.
Back to top

I wish someone could explain it to me, I don't have all that technical knowledge, but beginning with 2.6.38 slh and now the recent 2.6.39 slh strange things happen when I boot my machine. Half-way through the boot process the fonts change to very tiny and I get a message 'can't set fonts,path has been deleted' or something of that sort, then I get log-in prompt.And of course 'failed to load nvidia kernel module, kernel specific error' . When I installed Damentz kernel I was near 100% sure it will do the same thing,I was quite surprised when it boot into x with no problems whatsoever , it complains about ipv6 being unknown key when setting kernel variables but that's little worry I guess.Asking the forum for help yielded no results , my gut feeling is that slh kernel has certain parameters embedded in it which conflicts with something I'm not sure exactly.
Back to top

I see that they have introduced special aptosid versions of udev, libudev and libgudev which people say has fixed the problem. I'm always a bit worried when something which looks like a kludge is needed to keep a system working.
Back to top

welcome to Debian Sid, that's what it is. Sid is NOT meant for average users, it is meant to find and detect and debug and fix issues so the fixed packages can move on to Testing, currently Wheezy, which is the preparation for the next debian stable.

The key to understanding Sid is to listen to what Debian says, not Aptosid. Debian wants users who want rolling release to use Testing, they don't want to support Sid for average users in general, and they do want more advanced users to run sid so they can find and help fix failures and bugs.

Like the udev thing, for example. I kick myself for having ignored what Debian said before diving into that sidux/kanotix project blindly listening to those fanboys, I should have studied up on that more before I got so into the idea of doing something that really isn't a very good idea.

smxi and its users continue to support anyone who wants to run sid, and if the warning people are active with their holds and warnings, then you can often but not always count on smxi to help you out in terms of running sid, but it's just an aid, it can't guarantee anything.
Back to top

techadmin:
Agreed. Thankfully I don't see myself as an average user. I've been using Linux since 2001. In fact, years before, I dabbled with it in the pre kernel 1.0 days on an Atari Falcon. All CL and buggy as hell back then with daily postings promising stability and crashing with the next post. Amazing to think how far it's come.

As regards sid I like the challenge of living on the edge and hey, somebody's got to find the bugs. Also perhaps I have a different notion of what unstable means in the Debian context. For my part I don't consider sid to be a distro that has flaky software but rather a distro that changes very rapidly. Where updated versions of software arrive almost on top of each other eg a new udev the middle of last week and another update today. (If I remember correctly I once read a Debian maintainer say that was what he thought unstable meant.) The software may crash more often but fixes do arrive very quickly.

Of course seismic changes like the recent introduction of the /run directory can catch one unawares but I have the fun(?) of fixing it with or without help.

Because of this daily challenge places like aptosid will always be of use to me however unappealing the devs are. So I shall stay there as long as I feel comfortable with Debian sid or if another sid based distro arrives on the scene. Even then I expect I'll stay with them both.
Back to top

Lucky me, since I can't use slh kernel anyways for the reasons I still can't understand this most recent udev vs 2.6.39 slh kernel conflict doesn't affect me at all ! I'll stick with dmz kernel for as long as I can. I have posted the boot log clearly showing nvidia driver problem on aptosid forum paste.pocoo.org/show/388453/
and nvidia driver in /usr/lib/xorg/modules/drivers
usr/lib/xorg/modules/drivers/nvidia_drv.so
My question was why Liquorix kernel has no problems loading nvidia driver and aptosid will not, but the reply was we don't discuss unsupported software
Back to top

Not quite clearly:



The log asks us to look at the system kernel log (dmesg). I mentioned that once before but you still haven't uploaded your dmesg log anywhere. If you really want to get to the root of the problem, paste it somewhere for us to look at it.
Back to top

I'm sorry most likely I missed something as I haven't seen the dmesg request, I would greatly appreciate your help. What I'm not sure of is since I purged slh kernel it wouldn't be of any use the dmesg with your kernel running.Should I reinstall aptosid kernel and then get dmesg ?
Back to top

Each boot saves the log of dmesg to /var/log. Then they rotate - you'll want to look at each one and find the instance that you were running the aptosid kernel.
Back to top