Slashdot Mirror
Is Slackware Fading Away?
A reader writes "I just read over on userlocal.com about how David Cantrell announced he is no longer actively developing protopkg and autoslack (these are 2 apps that could have brought slack out of the stoneage but still kept to slacks philosophy of K.I.S.S.). So is it almost "game over" for the first commercial linux distribution which used to be the heavyweight champ?"
I don't think Slackware is quite dead. I switched to Slackware 7.0 after Red Hat screwed up my partition tables. I now use Slackware 8.0 and haven't looked back since or regretted my dicision. Sure Slackware takes a little more time to maintain, but the people who use Slakware aren't above using ./configure; make; make install to get the programs they need/want.
I've never had a problem with the stability of a Slackware distro because Patrick Volkerding puts out a quality distro with out a ot of bloat.
Thanks for such a good distro Patrick.
Adam
Patrick Volkerding is a very resourceful man. Besides... To some people, Slackware is the only real Linux distribution. I seriously doubt that this will cause any major problems for Slackware.
Stable out of the box.
Easy to configure (for the average Unix guy).
Rarely has software which contains security holes.
BSD style init scripts
No RPM locking dependancy. If there's an issue, you can upgrade from source quickly.
There's an article here explaining why one site runs Slackware, which you might find interesting.
If you'd grown up on it, or come from another Unix-alike (such as OpenBSD, etc), you'd probably find Slackware quite friendly... most Slackware-heads would find Red Hat or even Debian restrictive and unfriendly.
To each their own.
Even if they stopped developing it, made it illegal in the lower 48 states, systematically jailed or impounded Slackware users or fed us to ravenous wolves, I'd not stop using this distro. It has everything I want on the CD, plenty of office suites and window managers, no shortage of development tools, and a small/fast enough footprint to still work on an i386 with 16 megs of RAM. That's not half bad for software I started using six years ago.
Lacking really ultra-advanced package management has never been much of a problem either. While the setup programs weren't quite as "saleable" as the pretty GUI frontends, they were colorful, used an easy-to-follow menu system, and gave a very detailed description of what they were doing, when, at all times. Compare that to, say, the Corel setup wizard, which kept crapping out on even slightly non-standard hardware.
"Look at me, I invented the stove!" -- Ben Franklin
This is a common misconception. pkgtool makes it very easy to add, update, and remove packages, and the simple package format makes it easy to make your own. In combination with installwatch and install2slack, maintaining multiple machines is a no-brainer.
If you want pre-built packages for slackware, you might try linuxmafia, where you can find contributed packages for a wide variety of software.
Now, if you mean that slackware's package management system doesn't check dependancies, you'd be right. It's not as if it doesn't exist, though.
>If there's an update in one of the packages you
>use, you can publish that onto an ftp server,
>and then have the debian boxes patch themselves.
>Slackware can't do that, to the best of my
>knowledge. I used slackware intensively up to
>and including 7.1. It is a GREAT distrobution.
>Really. You're on your own, and if you fuck up
>it's usually you fucking up, not some
>inconsistent package management system. Use it
>if you want to learn Linux the hardcore way.
It seems to me that, if one needs to distribute software to many machines at once, there are easy ways to do it besides relying on a particular distribution's packaging tools. For instance, the unix labs at UT Austin use Debian, but most software (as far as I can tell) is actually stored on a central NFS server and run directly from that machine. It works great.
I administer several Slackware servers for our UT's student union. When I need to add a new piece of software or make an upgrade, I do it on a test server first (either compile a new package, or find it on Linuxmafia.) Once I ensure that it works, I run rsync on the other servers and viola!, they 'patch' themselves! Sometimes I have to run lilo if I upgrade the kernel on the other machines, but that's it.
"Redhat, Mandrake, and SuSE have been pissing me off lately with installs that take 1800 MB of disk space, and 10,000 background daemons that eat up 80% of the available RAM. If I want to install a useful system with X and FVWM to do Web browsing, check e-mail and log into remote UNIX boxen, all on a Pentium-90 with 16 MB RAM and a 600 GB hard drive, the ONLY current distribution good for the job is Slackware."
;-).
Oh come on. Have you tried a custom install lately on any of the other big linux distros lately? Or are you just going with a stripped down distro because you are to lazy to do so or want to be elitest? The window manager you mentioned ships with all three of the distros you seem to despise. The whole daemon bit is hyperbole. To go the other way, at least the other distros are shipping with newer more secure daemons and have facilities built in to keep them current and notify the user from one centralized spot about updates. For instance an outdated WUFTPD that ships with slack versus a current PROftpd anyone?
Hell how much time do you save with pre compiled i586 optimized binaries in compiling on that P90? Quite a bit in my experience. I like how you need a "600 GB" hard drive as well for a slackware install
"Slackware is for folks like me, who remember when Linux was *Linux*, and not a Windows wannabe."
Or maybe it's for people that remeber when a distro was bare bones and you had to practically roll your own to make it work the way you wanted, if that was possible at all. Linux has gotten better over time. Maybe just maybe you need to get with the times OR better yet be a developer/tester that brings the improvements of other distros to Slackware. One major programmer left, if you love your distro perhaps you need to play a greater role now that it is by most measures on the rocks.
Personally I like the modern linux distros because they give you more than Windows out of the box.
All things said I too remeber installing slack off of disks in in the mid 90's, but nostalgia just doesn't cut it when I have to get real work done. It's sad if slackware goes the way of the dodo, but personally it's not as relavent to me as it once was.
(with apologies to Barry White)
Slackware was the first Linux distro I installed, more than 6 years ago. Since then, I've flirted with the GUI-package-oriented distros (Red Hat and Mandrake in particular), acquired disks of several others (tradeshow giveaways and the like), been exposed to Debian on servers someone else installed, but I've come back to Slack, to stay.
Why? Several reasons really:
I think I'll go along with what others have said about this: even if Slackware, by name and/or business, were to go away, there are plenty of people in the Slackware community (myself included) who have the wherewithal, interest, and capability to "roll-our-own" Slack-like distros. I would expect, if it were to happen, to see all sorts of "children of the Slack" proliferate as a result, perhaps none with the singular momentum of the parent, but all with a specific niche to fill.
MOO;IANAL.
There used to be a picture linked here.
That story seems to just be trolling. i mean, the slackware forum at www.slackware.com is always buzzing. doesnt seem like its dieing to me. i use slackware 90% of the time on my workstation to do just about everything i want. it runs the apps i want, i can install them no problem. the slackware community has been going fine for years without a package manager and still keeps its userbase.
what does that tell you.
Just because some apps are no longer being actively developed by the lead maintainer doesnt mean the distro is dead. thats the beauty of open source. if alan cox or linus decided that they no longer had time to work on the kernel, would people shout that linux was dead?
i think not. as many people have said here, they are still using slackware, lots of people are. just because it isnt keeping up with the 'latest and greatest lindows distro' doesnt mean its dieing.
As another poster said, slackware's goal is not to ipo, make a huge amount of money (although im sure patrick wouldnt mind that, heh), and take over the world. its to have a linux distro based on KISS. and it works.
slackware lives on, and always will.
very well put -- I started off with Slackware in 1994. I tried Redhat for a while, but found myself spending most of my time trying to figure out what Redhat's scripts were failing to do correctly, and I moved back to slack. Last year, I tried Debian because I was getting sick of the lack of package support for slack, but I then spent most of my time learning how to use dpkg and trying to figure out what the hell got installed to my system on my last upgrade.
Now, I'm happily back to slack, and I'll stay here. No other distribution enables you to know as much about precisely what's installed on your system as slack, and for somebody learning linux, I think Slackware is the best learning tool out there. I find that most of the other distributions try to do too much for the user (making it a "windows-like" experience), which makes learning what it's doing that much more difficult.
I'm assuming userlocal.com is alluding to /usr/local. They're wrong. /usr is not "User", it's "Unix System Resources", and is pronounced "Yew Ess Ar"
Sorry, you are wrong. "Unix System Resources" is a retro-nym for /usr, much like "Packet InterNet Groper" is a retro-nym for ping; both are incorrect 'explanations' for for terms who's origin and meaning have been hidden by time.
In current Unices, /usr is where user-land programs and data (as opposed to 'system land' programs and data) hang out. The name hasn't changed, but it's meaning has narrowed and lengthened from "everything user related" to "user usable programs and data".
So, you are wrong. Deal with it.
"values of beta will give rise to dom!"
Yup, one can really trim down an install of Slackware to run on pretty much anything with a couple megs of RAM and about 40megs of HDD space.
I installed Slackware on a 486DX-33 w/12Megs of RAM and a 100meg hard drive to act as a print spool for an old laser printer on our network. Shut down all services except what was needed for printing, installed SSH for remote admin, and let it loose.
You can pretty much shape Slackware for whatever job you need a Linux machine to do, and you can do it easily.
You must be talking about their menu based front end (deselect?) to apt... Nobody really uses that, just get out of it as fast as you can and use apt. It's got no menus and is the best apckage amnagement program I've ever seen.
If the submitter had bothered to even glance at the slackware forum, he would have seen that David Cantrell and Chris Lumens have gone back to school now that Windriver dropped slack. Pat (who has always been the main man) has been busy shipping slack 8 and other business details he didn't have to worry about when wccdrom/bsdi was doing the publishing. He still updates -current occationally, and other than the latest fancy kernel, it's still one of the most up to date distros out there right now.
I'm going to have to disagree on the "lack of package management holds it back" argument.
Current package management systems in use (rpm, deb, etc.) rely heavily on the package maintainers. You're trusting them on several issues that seem kind of hairy in a large production environment.
1) The binary package does what it's supposed to (read: trojan free)
2) The software within was compiled to an architecture that you can handle (Nothing like finding -i386 meant to your package maintainer that 686 optimizations were included (not so good on some chips, like the AMD k6-2's))
3) Everything was built with reasonable options
4) The package plays nice and doesn't replace files from other packages on your system.
Personally, I'm more than happy compiling everything from source, especially now that a "./configure ; make ; make install" describes the build instructions on a huge number of available applications.
Want to roll it out on your large production system? Build the package on your test machine, use makepkg to build a slackware package, and then install it all over your network. Slack's concept of packages may be a bit simple (yes, they're basically gzipped tarballs with a manifest), but installpkg, removepkg and makepkg have been enough for me. (If you're using the makepkg angle, it's quite a bit easier removing things, especially if you're generally bad at keeping track where all the stuff is landing to begin with)
I won't bother with all my other anti-package arguments (dependencies, etc.)
As long as there are people that enjoy slackware, it will keep going. My question to the poster of the article (not that comment I'm replying to) is "When did commercial acceptance become the _only_ thing we care about?"
-transiit
That's baloney. I did this, as an experiment, with 6.2 and the install ended up around 200MB. Still too big, mind you, but 1G is a little too much hyperbole to let stand.
"I have a good idea why it's hard to verify programs. They're usually wrong." --Manuel Blum, FOCS 94
Similiar here, but for me it's:
./configure --prefix=/usr/local/encap/foo-x.y ; make ; make install
/usr/local/encap
5)
6) cd
7) epkg foo-x.y
Take a look at http://www.encap.org/epkg/ . It gets rid of the single valid complaint that packaging nuts have against Slackware.
Just want to recommend that all RH users (and slackware too) check out checkinstall.
It's a utility that automagically changes tarball installs into RPM or slackware package installs.
I run it like this:
./configure
make
make test (if necessary)
checkinstall
Checkinstall first installs the build into a temp directory, builds the RPM or slackware package, and then installs the package.
I've been using it for the past 8 months and it's saved me many times from giving up on the RPM database. The developer is working on getting Debian pkgs going too.
It's available here.
By almost veryone's definition these are methods of installing software but not packaging systems, Packaging systems (that is EVERY one I know of with the exception of Slackaware's) are designed to manage software in small chunks with some kind of metadata describing how packages relate to eachother - i.e. dependencies.
I've been sold the slackware `packagaing system' doesn't have dependencies. If that's true, it isn't a packaging system. Nothing wrong with that, but less call a software install method a software install method.
How can any distro that dosn't even include pico be considered 'unix-like' ???
If you want pico, you might try nano. It's a GNU clone of pico. Debian doesn't include pine because it's license violates the Debian Free Software Guidelines (DFSG).