Slackware 10-RC1 Released 346
Chaxid writes "According to the latest Slackware ChangeLog, release candidate one of the next iteration of Slack is upon us. I asked Patrick Volkerding via e-mail if the 2.6 series of the Linux kernel would be included in this version, and this was his response: 'To have support for using the 2.6 kernel in the installer might not be a good idea quite yet, and it would delay the release a lot. I'm planning to wait on that for the next one'. It's worth noting the Slackware 10 RC1 is fully 2.6 compliant however."
As TouchOfRed writes, though, "A test kernel 2.6.6 option is offered via the 'testing' tree. Slackware does not offer ISOs for the RCs (however there are some third party users that compile the RCs or the -Current tree regularly as ISOs), so if you are already running Slackware 9.1, you can use the excellent Swaret to upgrade to the latest packages (make sure you edit your /etc/swaret.conf prior of using swaret to allow for kernel upgrades and other options)." This release includes kernel 2.4.26 , Gnome 2.6.1+, KDE 3.2.3, GCC 3.4, XOrg 6.7 and more.
Slack (Score:2, Insightful)
Re:Can anyone say why they don't release... (Score:5, Insightful)
Re:Happiness :) (Score:4, Insightful)
Re:PAM? 2.6? (Score:4, Insightful)
This is one of the benefits of slackware. It's picky about new versions. Mature software is bound to be more stable. Like the article states, the new RC is 2.6 compliant but it's a Good Thing that it's not forced on users. It's not about elitism at all.
"Until Slackware has a solid PAM implementation, it will be delegated to my smaller, simpler tasks. And yes, I've read Patrick's rants about his dislike of PAM."
Why put in the work when there are some major problems with PAM? If you want it, you can either look for packages other people have made, or you can impliment it yourself. Yes, it's annoying not to have that option in the official distro, but then again, it's a whole lot of effort just for the sake of making a handful of people happy.
Re:PAM? 2.6? (Score:2, Insightful)
And if you don't want to roll your own colonel, then don't. Pat has built one for you. Otherwise, just do what the rest of the Slackware crowd has been doing for the last 10 years and roll your own. After all, ease of customisation is what Slackware is all about.
If you must have an out-of-the-box solution, you're probably better off with that *other* OS.
Mod this one a troll Re:Slack (Score:5, Insightful)
Slackware is not so much a cousin to Gentoo, as it is Gentoo's *mentor*. That said, any further comparison strains credulity.
Such silly, half-thought, cookie-cutter comparisons of the two distros only serve to further obscure the true nature and intent of Slackware.
Trolly, trolly, troll-troll
Re:Need some help... (Score:4, Insightful)
They are probably getting nostalgic from "back in the day" when Slack came on 2,545,645 floppies and you had to use a soldering iron, chewing gum, duct tape and copper wire to get the hardware to work with it.
That's no longer the case, but a lot of people started out with the "hard" Slackware, moved on to the "easy" distro's like Redhat, and still assume Slackware is still the same as it was in days of yore. The truth is, even though the appearance of the installer hasn't changed much (still ncurses), it is extremely easy to use, straightforward, and as flexible as can be.
Re:I started with Slackware... (Score:3, Insightful)
Re:A question... (Score:2, Insightful)
If you only use prebuilt binaries then I can see why this might be a problem. However, Slackware is designed with simplicity in mind for the user who is prepared to get his hands dirty compiling his own stuff (even if only from time to time). This almost by definition makes any package management system a la Debian or SillyHat redundant, since your database is out of date the first time you do this.
If you want to stay current with Slackware and stay with pre-built binaries, there's always swaret (and it really is current). However, you'll never appreciate the simplicity of Slackware if you never try playing with it.
Re:I started with Slackware... (Score:4, Insightful)
Slackware -- with its BSD-style init -- is easy to configure.
I would take issue with this. IMO SysV init is much simpler to use and administer one you understand what it is doing. Since each daemon has its own startup and shutdown script, and since the order they are being executed in can be determined by a glance. It is also very easy to re-order daemon startups, and to start / stop /restart individual processes while the system is running through /etc/init.d. BSD style init does not have this benefit, and since everying is all mismached together it is also often quite cumbersome to manage dependancies.
From my experience the people who prefer BSD init because it is "simpler" are just people who do not want to take the 5 mins to understand SysV and set it up properly. Investing a few mins setting up your SysV will save you hours of headaches you'd have later on with BSD style.
Re:Need some help... (Score:5, Insightful)
Slackware does not do automatic hardware detection and configuration. You need to know how to partition your disk(s) with fdisk or cfdisk before you even run the setup program. You need to know if you want to use CUPS or lprng or something else with your printer and how to set it up. You need to know the specs about your video card and monitor, and you need to configure X yourself.
I know all those things and can run thorugh Slackware's curses-based setup program as fast as I can use the keyboard.
Slackware has a little configuration tool called "pkgtool" that allows you to do some basic configuration (set up your mouse, decide what services will run, etc.). Beyond that, well...the beauty of Unix is that everything is configured with a text file.
I like Slackware because it doesn't get in my way with a big layer of poorly documented packaging and configured gizmos. Everything is visible. When I change something, I know exactly what has been changed. When I need to install software, I don't need to wait until someone releases it in the package format used by my distribution. I can download the source and install it myself. Case in point: When KDE 3.2.3 was released a few days ago, I might have downloaded the source and installed it myself as soon as KDE madeit available. As it was, the files were available on the Slack site within 48 hours.
Finally, Slackware does minimal tweaking of the packages it offers. What you install is pretyt much exactly as it was released by the developers. That's a great boon when something breaks. You don't need to worry about what SLackware has done to the code and not told you about.
Re:If not ISOs, .jigdo would be nice (Score:3, Insightful)
Ours might not be the most common circumstance, since most internet users aren't bound by HIPAA and other regulations to tightly control what leaves their networks. How many web programmers do you know that have (or should have) the official government Health Insurance Portability and Accountability Act home page [hhs.gov] bookmarked, for assistance in deciding what can and can not be displayed under what security circumstances? Probably not that many, but, for those of us who do, it means that certain popular distribution methods are not kosher at this point in time.
Jigdo is compliant, since it uses established protocols, and is inbound-only. Bittorrent may or may not be compliant, and I'm not in the mood to be the one who tries to get it approved.
If someone HAS the ISOs, they can make and post the .jigdo and .template files required. And the load on the servers now hosting the ISOs would be lowered significantly, since any mirror that has the basic files for the distribution can be a "jigdo ISO mirror", using either FTP or HTTP.
Re:Need some help... (Score:3, Insightful)
i for one don't know how debian's install has progressed. it was just different the first time through, and took some getting use to. Slack is pretty straight forward, more or less intuitive (to me).
Re:Slack (Score:3, Insightful)
Also, they both claim to be "BSD inspired" or somesuch.
Even so, I would never have thought of calling them cousins.
Re:I started with Slackware... (Score:2, Insightful)
in late 1993 or early 1994. I still have the CDs.
Okay, so I was already something of a "geek" at
the time, but it wasn't hard to do even then.
The installation tools are simple, and pretty
darn solid. No surprises, and no helpful "Bob"
or "Clippy" GUI that misconfigures the system.
And generally very stable. That tradition
continues to this day. I am running 9.1, with
the 2.6.6 kernel.
I haven't downloaded Slackware (even BitTorrent),
but buy the CDROM packaged distribution in order
to help support the project. While it would have
been nice to get the 2.6 kernel standard with the
10.0 release, I agree that it would not have been
in keeping with Slackware's reputation for solid
reliability.
IMHO, Slackware is the best linux distribution
going, and I have tried most of them.
Re:I started with Slackware... (Score:4, Insightful)
Why on earth would you do that? Use the tools your distro provides: RedHat/Fedora/Mandrake: chkconfig mysqld off Gentoo: rc-update del mysql default Debian: update-rc.d -f mysql remove Those things are much simpler IMHO than tracking down some filesystem permissions issue later. Suppose they change the behavior to not directly exec rc.whatever, but rather do something like /bin/sh /etc/rc.d/rc.whatever, now you're sunk. Your rc.whatever will be run even if +x isn't set..
Re:Slack (Score:3, Insightful)
Re:I started with Slackware... (Score:2, Insightful)
Because that is how it is defined to be done on Slackware. Simple and sweet.
Use the tools your distro provides
The checking for the +x during startup is provided by the slackware startup scripts. Thus, we are indirectly using the tools provided by the distro.
RedHat/Fedora/Mandrake: chkconfig mysqld off Gentoo: rc-update del mysql default Debian: update-rc.d -f mysql remove Those things are much simpler IMHO than tracking down some filesystem permissions issue later. /etc/rc.d/rc.someserver is much simpler than the commands you have provided. Since all of the scripts are in /etc/rc.d they are not hard to locate. chmod is also a very standard unix command and well documented.
I would content that chmod -x
Suppose they change the behavior to not directly exec rc.whatever, but rather do something like /bin/sh /etc/rc.d/rc.whatever, now you're sunk. Your rc.whatever will be run even if +x isn't set..
/etc/rc.d/whateverS. Your whatever will be run even if the link isn't set." Again, if any distro makes such a dramatic change then you will always have to change what you are doing. RedHat, Gentod, Debian, DistroX, have nothing special that can avoid this issue.
As the behavior of checking the executable bit is an integral part of the startup script processing, this would be a drastic change to the standard setup. You make a drastic change to any system's default behavior and you will always be sunk. It would be just as plausable to say "What if they changed 'chkconfig mysqld off' to return true if mysqld was configured to not run at startup?" Or perhaps you would prefer "Suppose they change the behavior to not indirectly exec rc.0/00whateverS and instead directly exec
Re:Need some help... (Score:3, Insightful)
It's all a matter of expectations: if you want an installer that looks and feels like that GUI shell [microsoft.com] they make for MS-DOS in Redmond, Slackware probably isn't for you.
I've always likened Slackware to a construction set for building Linux systems. RedHat et al are a Linux system in a can; open the can and pour out your system, ready to go. Slackware doesn't build system, but instead gives you the tools to build any kind of system you like.
My only non-Slackware system is a Sun Ultra 5 (bought on EBay), which runs Debian. That UltraSPARC hardware, y'know. Debian is different, but I can certainly see where they're coming from. Both are good approaches, maintaining that lightweight minimalist approach that Linux is in serious danger of losing.
...laura
Re:Terminology nit-pick (Score:1, Insightful)
Re:I started with Slackware... (Score:4, Insightful)
Slackware's init scripts haven't changed the way they call /etc/init.d/rc.* scripts since I've been using it (Slackware 3.x), and probably have always worked that way. That is how BSD style init scripts work. Just as the SXX, KXX, etc prefixes in the rc.X directories under SysV work a certain way since thats how they were designed.
Those of us who don't like hackish solutions like removing an +x bit prefer something manageable, like sysv.
I'd hardly call BSD inits hackish, rather I'd call it logical, and elegant in its simplicity. Take all the tools away and which one is easier? I believe one of the primary ideas behind slack is that anything should be fast and easy using only a text editor and the standard unix tools (chmod is one of those). In that vein it succeeds. If you look at SysV in this light, you are forced doing what others have pointed out (manual renaming/linking/removing/etc of scripts in several subdirectories).
Many of us Slack users have been around the block and had to fix things in a pinch. Doing things manually prepares you for these times and also teaches you a little more about how the underlying system works. If slack forced you to do it manually but used SysV no one would like slack. But slack makes it easy to do 'the hard way'. And this extends way beyond the BSD/SysV debate. Everything follows this notion, which is the reason why so many have brought up slackware's ease of administration. Everything is up front and there for the tweaking.
If you haven't given slackware more than a simple glance, I suggest running it for awhile to get the feel of it. I am not a blind-eyed zealot either, I have used redhat, mandrake, gentoo and sourcemage and run several distros regularly. I believe there is wisdom to be gained from most distros and that 'everything according to its purpose' is a good mantra here.
Re:Mod this one a troll Re:Slack (Score:1, Insightful)
I won't even bother trying to explain that/why Slackware is fast... it should be obvious to anyone that is at all cluefull.
Re:PAM? 2.6? (Score:2, Insightful)
#
# default; standard UN*X access
#
OTHER auth required
OTHER account required
OTHER password required
OTHER session required