@allend: I realize that GRUB exists in /extra but i really believe that it should be an option during the install process. When you say: I find that pretty funny. GRUB has been the standard for years now. Slackware is the only distro I know of that not only uses LILO as it's default bootloader but doesn't offer the option of using GRUB during the install. The future of disk partitioning and GPT aside, LILO is just too damn inflexible. GRUB shell has saved my bacon both at work and at home countless times. I just have never understood my Slackware has to be so resistant to using a better boot loader. I understand the "if it ain't broke don't fix it" philosophy but when it comes to LILO it does work but it is seriously lacking in features that are extremely useful. Having to boot off of a live CD and reinstall LILO just because your boot loader configuration is messed up is inexcusable. There is a reason why every other distro in the world uses GRUB and not LILO as it's default bootloader. What surprises me is that there is not more Slackware users that agree with me on this one. Why is it that Slackware users get so defensive when anybody criticizes their distro? In their eyes Patrick V can do no wrong. On this one I think he is wrong and has been for sometime. Don't get me wrong, Slackware is my favorite distro but this has always bugged me.

@fancylad - Feel free to get busy modifying the installer to include the option and submit your improvement to Patrick V. who has often stated his commitment to choice in FOSS.
Perhaps the lack of support from other Slackware users arises from the thought that it is inexcusable to mess up your boot loader, so that booting from the install CD is the price you pay?

Grub could be in a future release.
http://slackware.osuosl.org/slackwar...ADME_FIRST.TXT

Slackware is also about the only distro whose package manager doesn't do dependencies. That argument won't work on that characteristic, or this, either.

I prefer to have features appear after I boot into the system. I want the loader to just Just Work.

Messing up your loader config is inexcusable. LILO is just encouraging you to do it right.

Probably the reason you don't get more support is that probably most of us use LILO without any problems. On your last point, it may be that some Slackers feel Pat can do no wrong and get defensive at criticism but, to speak for myself, it's not defensiveness at the criticism - it's defensiveness for Slackware. You can criticize Slack all you want where it could be made more transparent, simple, and work even more reliably, and generally be as Slack as possible. Slack is becoming more and more unique as more and more distros homogenize on the Wrong Principles. Some of us cherish real issues like our dependency-free system and also our symbols (which still reflect real issues like simplicity and durability) like LILO which make Slack Slack. If people want a dep pm or grub, almost every other distro is out there for them to use and all kinds of addons and /extras even for/in Slack. For people who want pkgtools and LILO, there's just about only Slack. If you don't want Slack as is, but want some Slack, you're supposed to be able to customize it to your tastes. But don't take other peoples' Slack or at least don't expect a lot of enthusiasm from them when you do.

But I respect your point-of-view and, as others have said, and I just did, install grub from /extra and you're set.

Oh, and to be on topic: 13.1 is working great here. Shocked, I tell you. Shocked!

Slackware 13.1 Released :: An Unfortunate Choice of Kernel

Finally got around to put into writing some musings on the stability of 13.1 and its kernel. In general I write with the tone of a harsh critic, so I warn you I by no means intend to sound harsh but it might come across that way. I'm just a little saddened by the troubles I and others have had with the stability of 13.1.

I still have absolutely no idea what a boot loader is. Just hit enter. That's my motto during install. Install LILO to my master boot record? Sure, setup. Whatever you say. It's not like I know what a master boot record is anyway.

Now that's Slackware criticism. I don't use DRBD/LVM and haven't experienced any problems but data-loss is inexcusable. If that is indeed an issue, hopefully it can be addressed in some way even on 13.1.

One of the 13.0 patches was for a new kernel; I don't see why that cannot be the case here.

True enough.

I wonder if people are sending these concerns to Pat directly. I hope so.

I basically have one observation. Slackware 13.1 is apparently buggier than Slackware 13.0. Slackware 13.0 was as close to excellence as any Slackware distribution released since I've started using Slackware 3.4.
Slackware 13.1 was released TOO early. After code freeze, at LEAST one month should transpire before releasing any distribution so most bugs can be found and removed. Slackware 13.0 apparently went through a longer testing phase after the code freeze and the results spoke for themselves ... excellence except for gcc 4.3.3. Personally, I like Slackware's use of newer versions of software as each upgrade's viability lasts longer, i.e. Slackware 13.0 is still very usable. However, the use of more current software demands a longer testing phase to identify and remove bugs; again, at LEAST one month AFTER freezing updates.



For example, I use multiple video cameras and the pwc driver has been crashing the video subsystem at the (apparently) kernel level. I'll have to continue to research this issue. I just upgraded my kernel to 2.6.34 and the problem remains. Slackware 13.0 runs the same hardware perfectly.

With the aforementioned criticism of too short a testing phase, Slackware remains my favorite distribution of Linux. Overall, my limited experience with Slackware 13.1 has been quite nice so far. Again, thanks to everyone working on Slackware.

From a general desktop/home server standpoint I would say the exact opposite. Slackware 13 needed patching immediately, but I've had zero issues with 13.1. I also think that if KDE is going to be part of slackware it was ABSOLUTELY right to include 4.4.3 with 13.1. What came before it was super unstable. The testing branches of kde from Eric were stable from the get go and only got better. I can actually USE konqueror now to browse directories with 1000's of files. Previously it would just crash after hanging.

Each user will likely have somewhat different experiences. Personally, I have no use for KDE. Thankfully, Slackware's appeal doesn't rest solely on KDE. Even I had to upgrade the stock kernel of 13.0 because some of the drivers for my hardware were crashing. However, kernel updates solved the problem. So far, the same pattern isn't true with 13.1...

Regardless, the need for a longer testing period after freezing updates remains IMO. If I were releasing software, I'd use the -rc method approximately every week for one month. For example, -rc1 would mark the beginning of the official release of the software. (-rc1, -rc2, -rc3, -rc4, final) Only patches would be accepted for one month. -rc2 would follow the next week with each -rc following the previous -rc by one week. Granted, many users would simply wait until the official release and not help in debugging the -rc. I don't see the latter situation as much of a problem. Enough people would have difficulty waiting for a month for the final release to participate in the debugging the -rc.

To each his own. I keep a base kernel-config file for my machines and tend to upgrade kernels at about rc3 of each kernel cycle so I really wouldn't notice too much of what's going on in the official kernel after installation anyway.

Hey guys,

Long time slacker here. I started with 7.0 way back in 1999, and used every version through to 12.0, which I've been using for approximately 3 years now. In the past 3 years, we've had our first child, sold a house, built a house, moved twice and I changed jobs... so to say I've been too busy to find the time for further upgrades would be an understatement. Slackware 12.0 has been rock solid for me, so I never really had reason to upgrade, but now it's getting a bit long in the tooth... and I have a little more time on my hands...

So, I downloaded 13.1 (the 32 bit version), put it onto DVD and installed it onto a spare partition. I prefer to do this instead of upgrading, because you get a clean installation and have no chance of old configs ruining things.

My findings were as follows:

The first problem I encountered was no response from the keyboard at the password prompt. I've no idea what caused it, but switching from the "huge" kernel to the "generic" kernel fixed it.

The second problem was that the module for my it87 sensor chip refused to load. It said something about the resource being busy. A bit of Googling told me that this was a known issue, and was in fact the preferred behaviour since everyone should be using acpi drivers anyway. I had a cursory glance, and couldn't find one for my Gigabyte mobo, so I used the "hack" method of passing the following option to the kernel at bootup: "acpi_enforce_resources=lax". This enabled the it87 module to be loaded and work as previously.

My other problems were encountered within X, and are probably not entirely unrelated to this:

KDE4 doesn't remember any of my settings. Not a one. I like to have a slightly larger panel, date on the clock, etc, etc... And KDE restores everything to its default settings every time I logout and then login again. Its as if I'm logging in for the first time, everytime.

A minor thing I've noticed is that there are lots of random 'artifacts' left on my screen from prior actions. There are a few graphical glitches, e.g: the panel decorations don't load properly upon startup, but correct themselves when I click on the 'cashew' to bring up the panel settings configurator. Not a big deal, but not very professional, IMO.

The final thing may be related to the NVidia driver or KDE4, I'm not 100% sure. When I log out, X crashes. It won't even let me switch to another terminal. I'll have to try an alternate DE to try and figure out what's going on.

What with all of these 'minor' problems, I feel like I've chosen to test drive an Edsel... And I've not yet had it for 24 hours, so there may well be other things which crop up.

For the time being, 12.0 will remain my 'daily use' desktop... at least until I can get 13.1 to the same level of functionality.

Will the 'unsupported' KDE 3.5 packages from Slackware.com work with 13.1?

Cheers,


Rob

I think there was a notice somewhere in the CHANGES_AND_HINTS file about KDE settings, or at least it got mentioned in the forum.

I had a similar case on one computer with the nvidia driver (173 series), screen going blank after logout (when using kdm), blocking the terminals, too. I was able to work around it by setting TerminateServer=true in /etc/kde/kdm/kdmrc.

1 members found this post helpful.