Slackware 14.0 released
slackware.com
slackware.com
It's true that it might seem like an anachronistic distribution in 2012. It was actually the first distro I ever used back in the day when I started running Linux full time and increasingly had to interact with it professionally, and while I've long since moved on to other distros for a myriad of reasons, I wouldn't trade the years I spent running Slack for anything in the world,for a very simple reason, and that is that the old adage is absolutely true: when you run Distro X, you learn Distro X. When you run Slackware you learn Linux.
The whole distro, from the package manager to the init scripts is built around the KISS principle. Take the init scripts for example, they're nowhere near as powerful as, say, Upstart, but they're orders of magnitude easier to troubleshoot, and if you take the time to read through them (and yes, they're actually readable and very well commented) you gain a great working knowledge of how Linux actually boots and gets everything up and running.
The same philosophy applies to every other corner of the distro. Want to learn how to compile stuff on Linux? Take a look at a Slackbuild script, everything is in there. Want to know exactly what goes on during a distro upgrade, like what packages have precendence and so on? Read UPGRADE.TXT (http://ftp.slackware.com/pub/slackware/slackware-current/UPG...). I can only dream that even a small percentage of so-called enterprise software I've come across had release notes and upgrade guides this clear and well written.
Another great thing is that they maintain a policy of minimal interference with upstream code. If you come across a bug, you can be fairly sure it's from upstream and not Slackware, instead of having to examine the gazillion patches other distros like Debian and its derivatives introduce into the package.
I could continue to wax poetic about it, but I think I've given you an idea. It's not an exaggeration to say that I probably wouldn't be working in IT today if I hadn't come across Slackware in the before time. It's fun, and if nothing else it's a great learning experience.
The problem, however, is that no other Linux distribution looks like Slackware anymore. Everyone has moved to Sys V init first and then some to Upstart, systemd, and others. Other distributions have sophisticated package managers and source package formats. Other distributions use PAM for authentication.
So, effectively, when you learn Slackware, you learn Slackware. If you have to use Linux in the real world, you might as well learn a widely-used distribution such as a Debian derivative. Or Red Hat if you like suits.
Frugalware may do a better job for that (if you love Arch Linux, but don't want to use it on production you should give it a look!), but still isn't Slackware.
Personally if someone would have put LFS in front of me when I was just starting out with Linux, I would have freaked out. It's just too complex (although not complicated) to get up and running. But it's a good learning experience once you're comfortable with the basics.
As for Arch, it was one of my stops when I migrated away from Slackware, and while it's very similar in some aspects, I feel it has an added layer of fat that's missing from plain Slack and its one man vision of what a distro should be.
YMMV and all that, but IMHO Slackware is a Goldilocks distro. It maximizes learning without the pain of being overly onerous.
I have CentOS 6.3 on my 'must just work' PC, and play around on the laptop, which currently has Debian on.
Dont you mean, "when you run slackware you learn slackware"? Otherwise the old adage is not true.
With the exception of the ssh keys I can not remember running into a problem that debian introduced into a package. Which packages have you had trouble with in debian?
No he means what he said. There are no distro specific tools for Slackware. You don't `system-config-network` or `system-config-services`, you edit the config files. You don't run a tool to update which Java runtime is your default, you edit config files, or write a wrapper script for what ever applications need a specific version. Or do both, if you as the admin determine that is the right way to go.
You don't have a tool coming back and undoing your changes because you edited the file instead of using the tool. You're not reliant on a tool to enable or disable an Apache module.
You, as the admin, are the be all and end all. The distro is not second guessing you. There are no special tools to learn in running the system, just vi. That is why it was said when you learn Slackware you learn Linux.
There's a time and a place for both. Simple upgrade mechanisms and scripted/UIed management tools make the OS more accessible to the less hardcore Linux enthusiast; but these benefits come at a price - larger distros, somewhat higher system requirements, some abstraction between what the user wants the system to do and what the system actually needs in order to do it.
I see Slackware used now in very small embedded Linux systems in a few places, and I think I would be hard pressed to come up with a better choice of distro for a limited resource environment (no distro wars argument here, I know there are others that'd fit, I just my opinion from using it).
Yes, there's no official "apt" but when managing servers, I view apt as the devil. Automatic upgrades and trusting someone else's install recipes are a great way to open security vulnerabilities. I'm of the camp that everything in production is best built from source and packaged internally.
A dependency-resolving package manager is an excellent tool, but I think it's most useful application is in the desktop world. People who want software generally don't want to sit around resolving dependencies all day. People who run production servers might be better off if they knew exactly what was happening under the hood. Not to mention, once you do get your base packages set up along with Puppet, you hardly have to think about dependencies at all. Apt is great for setting a box up initially, but after that the luster wears off in my experience. Either your package manager is on the bleeding edge and unstable/insecure or it only has outdated (although probably stable/secure) packages. Slackware forces you to build and package just about everything from source, but the base system is an incredibly stable foundation.
I know quite a few people disagree with me, and that's fine. I'm not saying my way is right, I'm saying for me, this is the benefit of using Slackware in 2012 (which I do). Also, like I mentioned, once you get your base packages and something like Puppet set up, the package manager you use fades into the background.
KISS leads to a lightweight and fast system and moves much responsibility back to the user, which means that the user has to learn how the system works. I wouldn't be, were i am, without using stuff like Arch and FreeBSD.
Know your system, especially in 2012.
I've decided that the answer (for me) is that Slackware is the craft microbrew of Linux distros. Painstakingly created, tended, and bottled by one man (with some diligent helpers). No, it doesn't have the flashy ad campaigns of the majors, or the ease of (X), but you can tell someone has taken their time with this distro, and crafted it with care and love. Pat V. has a vision, and this is it. That appeals to me in intangible ways that a simple list of the technical 'advantages' of Ubuntu/Arch/etc does not. It's not to everyone's taste, but I don't think it was ever meant to be.
I'm extremely biased because I've only ever used Slackware seriously (for servers and desktop) but trying my best to put that aside, I think it's a masterpiece.
There's a cred to it too, which is no reason to use something, but it's the icing on the cake. In some of my support jobs, I had to interact with other techs, and once in a while you get a BSD snob who says "Oh pff, you're into linux? What distro do you use?" and after hearing "Slackware" the tune usually changes: "Oh! You probably know what you're doing then." I think it's true, though: if you can manage a Slack server, you can probably manage any server. The reverse is probably not so true.
So, in a sense, it has the advantage of keeping it simple and, thus, being a better platform for learning how Linux works.
It also offers an environment that resembles more a BSD system. So, if you like those systems, but cannot run those, maybe it is a better alternative than, say, Ubunto or Redhat (from a user perspective of course).
update: typo
To be specific about Slackware I think people who enjoy it like its lack of branding, conservatism in package management and configuration tools and the focus on package stability (users are assumed to dislike new features, unless they consent explicitly to them.). People who dislike it probably do for the same reasons.
Also the community is important - tastes and convenience are acquired through friends and the environment you are in.
However, with a stable distro one often finds themselves hankering for an update for a specific package or adding source-based packages. Rolling your own packages with Slackware is extremely transparent and using its tools to do so is dead simple.
Some people might say it's old and unnecesary, I say there are still people who love this distro, and maybe you will love it if you try it.
with ubuntu, there is too much majic, i dont run a server, but for example i dont think anyone should install Postgresql sql on running production server by running
sudo apt-get install postgresql
that would definitely be a nice book to read, someone should write it
It seems the most sensible way to install software, since it will automatically be upgraded with everything else.
To use the GP's example of Postgres: I care a whole lot more about my data than anyone at Canonical does. It would be a firing offense to trust that Canonical handles a database software and data upgrade correctly.
It's also why you can easily set up your own repo in two stages: one that updates from upstream automatically, so you can test changes, and one that never updates except when you specifically update a package: that's the one that your production runs on.
With proper due diligence on our part I trust the package maintainers to make less mistakes than if I have to do it all by hand :)
I've mainly used mysql and never lost data due to an upgrade (we backup before an upgrade anyway), YMMV of course.
Are you talking about minor-version upgrades, security patches, etc? Or any kind of upgrade? I think there's a big difference.
In the case of minor-version upgrades or security patches, what exactly is apt-get taking away from you?
The only thing holding you back is your own fear.
If you don't want to commit a full machine, try it out in a VirtualBox instance.
Keep in mind it's also possible to run your own apt repositories and have your machines source from those, allowing you to define what specific software runs on your farm, down to the smallest detail.
All in all apt can give you a very flexible setup :)
Btw using Slackware on one server in production and i must admit that small specific systems are perfect match for Slackware (VoIP, routers, ...). And ofc non-production systems (laptops, testing and development environments, etc).
<Insert obligatory comment about how all code is translated to something else before execution>
I wonder who's still using that in some deep dark corner of their infrastructure.