Slackware 14.0 released(slackware.com)
slackware.com
Slackware 14.0 released
http://www.slackware.com/announce/14.0.php
49 comments
Honest question: what is the advantage of using Slackware in 2012?
I was trying my hardest not to comment, but this is a pertinent question, maybe even THE question when discussing Slackware.
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.
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.
When you run Slackware you learn Linux.
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.
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.
Everyone had moved to sysvinit years ago. The point is not that Slackware did what the other distros did, minus the handholding utilities. The point is that Slackware requires you to figure it out yourself, read documentation, go to the IRC channel, and grep around /etc until you got something working the first time, a skill that will help you with any flavour of Linux--no matter which init system it uses.
I haven't used Slackware, but all of the points you mentioned are valid for Arch Linux as well.
Well, I think the biggest argument against Arch or Gentoo (even though I like both and actually am using Arch right now) is that you can't/don't want to use it for a production server.
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.
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.
And with Gentoo. Not trying to start a Distro flamewar, but if someone wants to learn distro independent Linux, then he or she should try his or her hands on LFS. The next best thing after LFS would be Gentoo.
Distro wars was why I was trying my hardest not to comment.
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.
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.
Thank you for the post and the comments. I am a new Arch user (having used it for about 6 months now), and while I am happy with it, your comments are making me want to try other bare distros like Slackware or Linux From Scratch.
" the old adage is absolutely true: when you run Distro X, you learn Distro X. When you run Slackware you learn Linux."
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?
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?
> Dont you mean, "when you run slackware you learn slackware"? Otherwise the old adage is not true.
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.
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.
I too ran Slackware in the Way Back When days, and I think it's simplicity helped admins to understand how Linux works, on a more general scale, than user-friendlier distros nowadays might not.
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).
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).
I am not using Slackware myself, and obviously can't speak for the GP, but I think the old adage means that Slackware is so low level and comes with only the bare minimum, that it forces its users to understand lots of things about linux, as opposite to, say, the package manager of a given distro.
I got tired of all hacking and came back to Ubuntu.
Interesting: Ubuntu 12.04 I suppose.
I have CentOS 6.3 on my 'must just work' PC, and play around on the laptop, which currently has Debian on.
I have CentOS 6.3 on my 'must just work' PC, and play around on the laptop, which currently has Debian on.
I have been using Slackware for ages. The advantage for me is this: prior knowledge (it's the distro I'm most efficient in), extreme stability, blazing fast, solid/secure as a rock.
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.
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. IMO.
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.
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.
KISS, "know your system."
I know the usual answers - stability, KISS, etc, but as a newbie(ish) to Linux in general and Slackware in particular, I almost think this question (which comes up repeatedly) is almost missing the entire point of Slackware.
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'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 think he's done an incredible job making a stable, secure, fast operating system that makes sense. I've tried really hard to use Debian/Ubuntu/others but always come back to Slackware after scratching my head for hours wondering "which file do I edit to this?" when the answer is actually "which distro-specific script do I run to do this?"
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.
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.
This question is subjective. Slackware is cool if you like to know how things work. It doesn't hide a lot of things that other distros automate for you.
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
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
As any distribution it depends on your taste and convenience. This is why there are so many - peoples tastes and circumstances of convenience vary greatly.
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.
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.
Also forgot to mention - Slackware is a traditionally KDE distro and KDE increasingly feels like a second-class citizen in many distributions.
A Slackware install is extremely stable. As in, there are not system upgrades every week. So it's unlike Arch in this respect, and more like the rest of the stable distros. (E.g. Debian, Ubuntu, etc...)
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.
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.
There is no single "advantage".
Some people just like it, I ran Slackware 13.37 in my laptop for some time: didn't really like it, but the community is nice and I like the "feel" of the distro, the package management wasn't that bad either (using SBOPkg).
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.
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.
Well, there are no advertisements on your desktop and nobody's replaced normal search with sponsored search, so that's two things.
i wish i am brave enough to use slackware, the idea of a rudimentary package manager seems plausible
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
that would definitely be a nice book to read, someone should write 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
What's wrong with apt-getting things?
It seems the most sensible way to install software, since it will automatically be upgraded with everything else.
It seems the most sensible way to install software, since it will automatically be upgraded with everything else.
One-line installers are fine. Automatic upgrades are not.
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.
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.
Which is why Debian doesn't do upgrades-for-the-sake-of-upgrades in Stable. Anything you get there is a security fix, and the notes will tell you if there's an unavoidable functionality or config change.
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.
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.
Sure; which is why you have an update process - the includes checking for potential issues, and involves several avenues of upgrade (apt, direct, etc.).
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 :)
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 :)
apt is pretty configurable though.
For example I get an automatic email every day notifying me of package upgrades that are available. Only security patches are installed automatically (you can even specify individual packages to be excluded altogether).
I've mainly used mysql and never lost data due to an upgrade (we backup before an upgrade anyway), YMMV of course.
I've mainly used mysql and never lost data due to an upgrade (we backup before an upgrade anyway), YMMV of course.
> One-line installers are fine. Automatic upgrades are not
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?
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?
> i wish i am brave enough to use slackware,
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.
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.
It's grokkable magic :) The Debian package format has nice functionality for deploying software such as the seed database, the script hooks and dependency checking via apt.
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 :)
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 :)
Slackware comes with slackpkg which is (in terms) similar to apt-get, but for non standard apps you need slackbuilds or compile code manually.
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).
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).
Pardon a trip down memory lane: Slackware was was my first distro. I spent several days (including a weekend) downloading the minimal bits to run over a 2400baud modem (in 1993?). My wife and kids almost killed me for hogging the telephone :-)
Slackware.com is currently overloaded. For more info, try Distrowatch:
http://distrowatch.com/table.php?distribution=slackware
http://distrowatch.com/?newsid=07475
http://distrowatch.com/table.php?distribution=slackware
http://distrowatch.com/?newsid=07475
Obviously, this is because PHP doesn't scale.
I just looked. Slackware still ships with UUCP. Quaint.
I wonder who's still using that in some deep dark corner of their infrastructure.
I wonder who's still using that in some deep dark corner of their infrastructure.
It looks like we 404'd the page.
Go Slackware!