“I have very mixed feelings about this release of Slackware. I do not think that the underlying philosophy of Slackware is obsolete. The concept of a system that can be configured and molded to the n’th degree is still in my opinion very much a good idea. However, this release of Slackware is not without its problems in execution.” Read the review here.
I wonder if the reviewer even bothered to download the installers for XFCE 4.2 to determine if it was actually an XFCE bug or Slack bug.
I use XFCE 4.2 pretty much exclusively and have never run into that bug. On suse, fedora, or mandriva.. Though I do download and install the desktop with the Oscillator installer packages. I never use the packages provided by the distro.
hail slack… praise bob!
I have since moved on to other things (I really enjoy package management), but Slackware will always be dear to my heart. I wish there was a distro with full package management that somehow still tried to keep the system as pure and simple as possible. Having the BSD init system, for instance, is something that I miss.
Wow, I could not disagree more. I have used Slack 10.1 since its release and I have found it to be exceptionally well-done, as is the usual case. I have upgraded to KDE 3.4, XFCE 4.2.1, kernel 2.6.11.8 and, using Gware (http://www.gware.org) GNOME 2.10. I ususally use XFCE and I have not encountered the problem the reviewer mentioned.
For me, Slackware is, and always will be, the best Linux distribution. Rock on, Patrick.
You might want to take a look at http://www.rubix-os.org then. It strives to be a slackware drop-in replacement, but with a powerfull packagemanager (pacman).
Thanks for the heads-up. Looks like an interesting project.
I have moved to Arch Linux. It’s a lot like Slackware in most ways, but more bleeding edge. It’s not as stable as Slackware though. If this gets worked out as well some speed up of pacman, Arch would be a better solution to the kinda-neglected Slackware today. It’s only so much that a single person can do supporting and maintaining all these packages and their increasing complexity.
My distro of choice. Rock solid and fast. If you want package managers for this distro, Slack’s gottem to: slackpkg is one that’s official.
I left Ubuntu for this distribution because I wanted to learn, and have fun. I have done both and continue to do so.
You might want to check out ArchLinux. It sounds like it has all that you are looking for.
Why does every GNU/Linux review talk about boot time. GNU/Linux was designed to be ON all the time. The Linux kernel is stabel enough to allow the system to run for Months on end. Services can be started and stopped with out a reboot. Unless your changing the actual Kernel, once a system is booted theres no reason to shut it down.
I’ve played with Arch and found that many of the init scripts were buggy and wireless support is very poor. I have read many posts in the forums that say the same thing (search for “wireless”). Also, some of the packages are not that stable and the GNOME install is totally borked.
But, other than that, it’s pretty cool. Arch people, don’t get all riled up. I’m partially joking here. Arch is nice, and has really great potential, but for me, the stability, time-tested maturity, and excellent init scripts make Slackware the top choice.
I wonder why many refer to Arch when talking about Slackware (whenever comparison comes out)
Anyway, I gather Crux is much nearer the original motto of Slackware ( “KISS” ) and *BSD init than any other distro.
I guess many should give it a try ( at least on PPC).
I find Crux is not much talked about on Osnews, when we get regular reviews/info about Ubuntu, Slack and others.
(btw, I’m a Slack fan, only Crux is very appealing I find)
I wonder why many refer to Arch when talking about Slackware (whenever comparison comes out)
Anyway, I gather Crux is much nearer the original motto of Slackware ( “KISS” ) and *BSD init than any other distro.
Since it’s already getting off-topic somewhat.. you do realize that Arch is based on Crux right?
“What is Arch Linux?
Arch Linux is an i686-optimized linux distribution that was originally based on ideas from CRUX…”
—http://www.archlinux.org/docs/en/guide/install/arch-install-guide.h…
Slackware: BSD-style init scripts, KISS philosophy
Arch: i686-optimized, up-to-date packages, pacman
Frugalware: i686-optimized, up-to-date packages, Slackware’s init scripts, Slackware’s philosophy, Arch’s pacman with a GUI frontend
No proprietary software is included in the installation media.
This is simply not true. For instance, J2RE, J2SDK and XV are propietary software. Some other distributions also regard Pine as non-free.
The only thing I will mention at this point is this: why, oh why, is LILO still the sole option for a bootloader Slackware? There should at least be an option to use GRUB.
GRUB is available from the extra/ directory.
Unfortunately, this did not go too well. The kernel panicked on the first attempt at booting. It was related to APIC (Advanced Programmable Interrupt Controller). It’s probably not Linux’s fault – it’s more likely related to a flakey BIOS.
In most cases it is, I suspect that the author booted with the bareacpi.i kernel.
Still, most distros don’t have a problem with it, so I suspect it’s related to some particular patch.
Slackware uses a vanilla kernel.
So, I added “noapic” to the boot prompt, and tried again. While the system was booting the second time, I received another kernel panic apparently related to the hotplug system. This ticked me off, because no other distribution has this particular problem with my system, and as my wireless USB adapter requires the hotplug system, the only workable solution was to recompile the kernel. This was the case with Slackware 9.1 as well.
Send a bug report to the maintainer of the subsystem that crashes. This is no Slackware issue, Slackware uses the vanilla kernel.
Slackware 10.1 includes fairly generic installations of KDE, GNOME, Xfce, and WindowMaker. However, they have placed an emphasis on KDE, and it shows. The included KDE 3.3.2 is very nicely done.
It is just plain off-the-shell KDE.
GNOME is just GNOME – don’t expect any surprises here.
No difference here, it is just plain off-the-shelf GNOME.
While boot time is not the greatest on the planet, it is perfectly acceptable.
Hotplug causes most the most delay.
My only complaint is that valgrind is missing. This is probably my favorite developer utility of all time. Words cannot describe how much this accelerates bug-hunting. It’s only a small piece of software – it really ought to be included.
I agree, Valgrind is a gem . Maybe you should send a suggestion to volkerdi@.
However, the working version of Apache is still 1.33. Correct me if I’m wrong, but I see no reason why the transition to Apache 2.x cannot proceed at full throttle.
Possibly the same reason for kernel 2.6 not being the default. Patrick Volkerding has always been conservative in switching to new software, in my humble opinion this is an asset to Slackware.
It has made the management of my system much easier and less painful. Udev is in my opinion one of the most important developments in the Linux community in the past few years.
It is nice, but the added layer of complexity seems a bit unnecessary to me.
Specifically, permissions simply do not work as they are supposed to, and I need this functionality for properly handling permissions for the DRI interfaces.
It should be no problem setting them in /etc/udev/rules.d/udev.rules
Udev is a very important component that should be important and functioning in every modern Linux distribution.
Is it? It is still under quite heavy development, e.g. the configuration of permissions even changed very recently. Besides that it adds an extra layer of complexity. It can be nice on desktop systems, but what is wrong with device nodes?
Its borkage counts against Slackware. These are the types of headaches that make Linux in general a pain to use.
I think Slackware doesn’t address a general Linux public. Most Slackware users are able to create device nodes, edit fstab and mount devices themselves.
but I should not have to fix bugs like this. That is the job of the QA guys prior to release. To my knowledge, this issue has still not been corrected.
How is your misunderstanding of setting up udev permissions a bug in Slackware?
I don’t mean to be rude, but with a bit more digging this could have been a more useful review.
Arch would be a better solution to the kinda-neglected Slackware today.
Eugenia: in what way is Slackware neglected? Patrick has been absent for a while during his illness, but security issues were handled very well by SlackSec and GUS-BR. The last few months the development of Slackware has continued in pretty much the same pace as before.
I’ve started to use Slackware since 9.1 after moving away from RedHat, although could not escape it at work .
I really like the simplicity and so far have not found a compelling reason to switch to something else…
As for package management, the standard tools are just fine, but there is also slapt-get
It’s very unfortunate about Pat’s illness, but the reality remains that packages were not updating in the same speed as it was happening before. Pat is one person, as I said, and a single person can’t take into such a big job. The whole Slackware experience does not fit in 5 floppies anymore, it requires more work and Pat is not able to do so as fast, and he doesn’t want to share the burden with anyone else. That’s bad for business IMHO, and that’s why I moved to a faster-maintained distro. Security updates is the not everything.
As I said, Arch is not as stable or reliable as Slackware is, but it’s a trade off that I am willing to do.
Pat is one person, as I said, and a single person can’t take into such a big job. The whole Slackware experience does not fit in 5 floppies anymore, it requires more work and Pat is not able to do so as fast, and he doesn’t want to share the burden with anyone else. That’s bad for business IMHO, and that’s why I moved to a faster-maintained distro. Security updates is the not everything.
I would agree if Slackware maintainance slowed down heavily, but these days it is moving as it did for years. But that might be a difference in perception.
As I said, Arch is not as stable or reliable as Slackware is, but it’s a trade off that I am willing to do.
Yeah, it is good to have freedom om choice.
on slack 10.1 I noticed something strange that popped up on the two (very different) machines I installed it on. After I finished installing and rebooted, I could not log in. No keyboard response, or mouse for that matter. Turns out the ‘solution’ was to swap the usb ports that the mouse and keyboard were plugged in. (Once I got X started up, I also noticed the the mouse speed was all out of wack.) Doing that once, though odd, is one thing, having to do it most times I reboot, that just sucks. I’ve only seen that in slackware 10.1 from what I can recall, and have played around with lots-o-distros.
I’ve been using slackware since ditching redhat 9. Other then redhat I’ve only tried debian and gentoo but didn’t stay there very long. I personally don’t like automated package managers and slackware just “feels” clean. With slackcurrent and checkinstall it’s the perfect distro, I feel like I have complete control. I can’t imagine using anything else.
Slackware business has never been to follow the latest x.y.z package, it makes its work and it’s one of the best out there.
Reality is that people leave slackware because they want another package manager (well…people love to have a program say them “hey you need this library”), and people love and stay with slackware because they love its package manager and because like Pat philosophy/choices.
It’s not because “hey latest foobar is 1.2.3 but slack has 1.2.2!”, come on…
Mandrake (8.2 – 10.0) had a problem with USB ports where I had to make sure the keyboard was in the first USB slot or Mandrake would not detect it at boot.
I run Slackware-current and the only USB oddity I have is that when I have a USB mouse plugged into my laptop, the system does not see one of my usb-drives. (The other USB drive has no problems). I have to unplug my USB mouse, plug in the usb-drive, then re-plug in my USB mouse. Then everything works fine.
Wow, you really know your stuff when it comes to Slackware. I found your comments more interesting than the review itself. And that’s why I like this site. Well done.
Agreed, and as another long time slack user the things Zyx mentioned are known by most slack users. The reviewer said he reviewed 9.1 but clearly neither time did he dig very deep.
@eugenia: I disagree with your assessment with Slackware’s current status. Folks I know have traded emails with PV and he is doing much better and is back in business.
Slackware has always been about stability first and will always be that way. However, if someone needs the latest and greatest, it’s easy to do. I am using the latest kernel, the latest kde packages, the latest gnome, the latest xfce, the latest firefox, the latest xorg… what else is there? all of these were available in -current except the kernel of course and except gnome but that’s easy to install with gware.
Slackware ain’t going anywhere. There are many, many dedicated slackware users who, like myself, will never try another distro. I have no urge to. Slack gives me everything I need and makes it easy to upgrade from version to version. I have a friend that has upgraded from 8.0 > 8.1… all the way up to 10.1 without a single problem. He hasn’t downloaded an iso in years (although he has a slackware subscription like I do to support PV).
Slack is it.
When I was a newby, I was told to start with Slackware because..
..It was the oldest
..It was the closest to UNIX
..I would have to learn the guts of the system
..It was the leanest
..It was the best on old hardware
What no one told me about was the open hostility I would receive from the Slackware “experts”. The people in the newsgroups would not allow any question to be asked unless it was purely Slackware-specific, meanwhile they wrote hundreds of posts about eachother and themselves. They loved it. They thought they were in a private club, but it was more like a kindergarden classroom. And God help you if you talked back to them (notice this message will say ‘Comment Pending Review’).
I don’t know how many more years Slackware will survive, but one thing is for sure – when Slackware dies, I am going to have the last laugh.
Hey, sorry to hear about your experience. I have a totally opposite experience. I have posted about in various slackware forums and on slackware mailing lists and I have never received the hostility you speak of. I have not seen it, either. (But I’m not saying it doesn’t exist).
However, I *did* receive some of that kind of treatment on debian mailing lists. But, hey, whatever.
I think that sort of behaviour is seen all over the place in Linux land, unfortunately. Still, the poor behaviour of some users does not mean that all users act that way and it should not reflect negatively on the distribution itself (especially in the case of Slackware since Patrick has been very vocal about how that sort of behaviour upsets him).
Anyway, hope you have found your distro of choice. Cheers!
1) Eugenia, have you ever thought that what you think is a reason not to use Slackware, that is, the fact that it is mainly a one man show, it is also the reason why a lot of us like the distro? Not being a community driven project the maintainer doesn’t have to compromise with anyone else when he chooses what to package, that’s why Slackware’s goal of simplicity has never been sacrificed. The other reason why people appreciate Slackware is because they trust Patrick himself. The fact that Slackware is Patrick Volkerding (I’d be tempted to write “and vice-versa” 🙂 is IMO Slack’s strongest selling point.
2) You say: “Pat is not able to do so as fast” . Whether this is bad or good is debatable.
3) You also say “That’s bad for business IMHO, and that’s why I moved to a faster-maintained distro.” and
“Security updates is the not everything. ” . Yep, security updates are not everything, but most businesses would be happy to trade features for overall more secure systems.
“””
Why does every GNU/Linux review talk about boot time.
GNU/Linux was designed to be ON all the time. The Linux
kernel is stabel enough to allow the system to run for
Months on end. Services can be started and stopped with
out a reboot. Unless your changing the actual Kernel, once a system is booted theres no reason to shut it down.
“””
I would think this follows naturally from the increasing use of Linux on laptops (where I find myself annoyed over slow startup, can’t use ACPI sleep-functions; it doesn’t work) and as a desktop-OS in general. Not everyone likes to have their computers on and humming 24/7. Also, today’s computers consume a lot more power than in the old days. Leaving your computer turned on for absolutely no reason (you don’t need it online, you’re not at home, you use a DE with session management, etc, etc.), is a waste, the way I see it. I hope there will be general improvements in the init-system, to speed things up a bit (like doing some form of safe parallelization of startup scripts). Btw. today’s best distro when it comes to startup performance has to be Gentoo (too bad I got tired of all the compiling and switched=).
The Xfce bug is forgivable. While it is annoying, it is entirely possible that the developers never encountered it, or if they did, they mistook it for a minor fluke.
Stuff like this drives me mad. This guys writes a nice report which is very positive, but then decides to switch to fluxbox because his monitor dies, or he chose the wrong display frequency, put his subwoofer on top of it … you get the idea.
People who cannot stay objective should not write articles like this. This way no-one will get a fair idea about anything.
Loved (in fact I still love) Slack. However , as a Gnome fanatic I was quite dissapointed by the decision of quiting Gnome altogether from the future Slack releases. Of course, there’s Dropline,GWare,you name it, but it just don’t cut for various reasons I won’t say them here.
Since I don’t have much time anymore to play with Slack, I’ve opted for another distro recently.I put that to test.It may be that I will come back to Slack,but I don’t think so.
It’s all in the choice. What I loved to Slack is that you keep fine tuning,change the bits and stuffs, you customize it until is no more a Linux distro. It becomes … you. Really , that’s my feeling about it after 3 years of non stop usage.
Yeah, that’s right. I used to play with Slack a lot in the past, but when I discovered Arch Linux <www.archlinux.org> [thanks Eugenia ] i’m no looking back. Arch is everything you would want to have in the modern Linux distro designed with the KISS philosophy in mind: speed (i686 optimized), excellent package management (pacman) which is MUCH better than pkgtool, swaret, slapt-get all together, stability (yeah, that’s right, i’ve been using Arch on a few production servers for a few months now and encountered no problems so far), init scripts? what’s wrong with them – they are BSD style and IMHO much better and even simpler than in Slack. You got only ONE (rc.conf) file where you can change basically everything.
Arch, it is the GNU/Linux distro for the new generation.
but when I discovered Arch Linux i’m no looking back.
Good for you .
excellent package management (pacman) which is MUCH better than pkgtool, swaret, slapt-get all together
That’s a matter of personal taste. For me pacman adds complication that is avoidable. pkgtools are just a bunch of shell scripts, that can easily be modified if you want. Besides that the simplicity of Slackware packages is very comfortable, in the end it is just a tarball that sometimes contains one additional post-install script. I don’t have to worry about what the package manager or maintainer thinks that I want.
In my opinion Slackware has the perfect balance: packages are comfortable, but nothing is done out of my control.
But different users have different needs, and some other users just want something that does everything of them.
what’s wrong with them – they are BSD style and IMHO much better and even simpler than in Slack. You got only ONE (rc.conf) file where you can change basically everything.
They are different. Toggling a service by editing rc.conf is no simpler than flipping an executable permission. I’d say parsing a configuration file is even a bit more complex (depending on how it is implemented).
But tell me, how can Slackware be a distro of the past, just because your preferences differ? FYI: alternative package managers and init systems have been around for years. Did Slackware Linux fade away?
Slackware *is* the distro of the past, that is why it is so good. There is no other (GNU/Linux) distro I would rather put on a server.
Slack is, without doubt, a fantastic distro for some. Not for me. I do not, have the time any longer to sink into manually configing everything, and compiling nearly everything (including the kernel ay time you make a change to your system). Lightweight, flexible and stable, sure – absolutely, but also more of a pita than I want to deal with these days.
“[Arch] init scripts? what’s wrong with them – they are BSD style and IMHO much better and even simpler than in Slack. You got only ONE (rc.conf) file where you can change basically everything. ”
Barf. I’m sorry – I know that many people prefer this single flat file way of doing things. I can’t stand it – it’s the one thing I hate about dealing with BSD boxen. Certainly several people manage to turn their rc.local files into the same sort of abomination, but a 2k line init file you need to grep through to see how a particular service is started or stopped is not my idea of elegance or simplicity.
@Zyx
Besides that the simplicity of Slackware packages is very comfortable, in the end it is just a tarball that sometimes contains one additional post-install script
Have you ever tried Arch Linux? The same situation is with Arch packages. They are just tarballs that sometimes contain one additional post-install script. Basically it’s the same KISS philosophy as in Slackware, BUT pacman manage wisely dependencies. and if you really do not want to install dependencies it’s as simpe as adding –nodeps to pacman command. NOONE will tell me that Slackware package management system is better than Arch’s pacman. Basically pacman is “pkgtool improved”. And package database is kept in simple text files, as in Slack. Some of you guys are just funny, you keep preaching to yourself that candle is still the best light source out there, when some people improved on it and discovered a light bulb.
@Father Baker
Let me tell you something. Try Arch first and then speak, all right?
this is a part of rc.conf
#
# Daemons to start at boot-up (in this order)
# (prefix a daemon with a ! to disable it)
#
DAEMONS=(syslog-ng !hotplug !pcmcia network netfs crond gpm)
How is this difficult to enable or disable a particular daemon?
You tell me this.
ex-slacker typed:
Arch, it is the GNU/Linux distro for the new generation.
Yip, I agree. Add though that diet cola is the drink for
the new generation. Ol’ men prefer beer and … Slack. 😉
Bravo, great postings! More cognitive and educational than the review by itself. Could you please consider a possibility of writing an article for The Slack World <http://slackworld.berlios.de/> to share your experience with the other Slackers.
Have you ever tried Arch Linux?
Yes, I have had a quick look at it a while ago to see where all the fuzz is about. To be honest, it didn’t really impress me.
The same situation is with Arch packages. They are just tarballs that sometimes contain one additional post-install script. Basically it’s the same KISS philosophy as in Slackware, BUT pacman manage wisely dependencies.
Most other package formats also use an ar or other kind of archive. Most other package managers also provide a –nodep option. Why should I use another package manager when I will be typing –nodep all day. In the end I will throw out all cruft, and it will end up being some sort of Slack. Slack consists of just vanilla versions of all software, packaged by someone I trust and buy a CD set from twice a year. It must be hard to believe, so I will reiterate once again. I need no dependency checking, I need no update tool that automatically fetches packages from the internet, I need no hand holding, I need no automatic compilation infrastructure, I need no gazillion bleeding-edge packages.
Yes, if Slackware would ever go the path of adding such things (which most likely won’t happen, since it hasn’t happened in over 10 years), I would take the latest “traditional” release of Slack and update it myself with the SlackBuild scripts until some other group continues the KISS tradition.
Some of you guys are just funny, you keep preaching to yourself that candle is still the best light source out there, when some people improved on it and discovered a light bulb.
No, tastes differ. What you see as an improvement for you would be a step back for me. That’s why it is great that there are different distributions. But Arch obsoleted Slack in no way. It just has a slightly different target group.
Why should I use another package manager when I will be typing –nodep all day
Nah pal, you can just type -d or even put an alias in your /etc/profile. Personally i don’t even type “pacman”, just “pac”
In the end I will throw out all cruft, and it will end up being some sort of Slack
In the end I will throw out all cruft and it will all be just GNU utilities based on Linux kernel. What’s your point here?
Slack consists of just vanilla versions of all software, packaged by someone I trust and buy a CD set from twice a year
Why would i bother to buy some cd’s twice a year and doing a fresh reinstall when i can just type “pacman -Syu” once a day and keep my system constantly up-to-date. I don’t even know what a system reinstall is no more.
I need no dependency checking, I need no update tool that automatically fetches packages from the internet, I need no hand holding, I need no automatic compilation infrastructure, I need no gazillion bleeding-edge packages
It’s good you let us know that. Like i written previously, nothing really hold you back from using –nodep option in pacman. But
dependency handling in pacman is really an improvement, trust me or not. It ain’t no old Red Hat’s rpm tool.
end note: Why not build your own distro in “linux from scratch” fashion then?
Why would i bother to buy some cd’s twice a year and doing a fresh reinstall when i can just type “pacman -Syu” once a day and keep my system constantly up-to-date. I don’t even know what a system reinstall is no more.
Why? I don’t know why you were asking this.
Certainly to support slackware. You can use pacman to keep your system up-to-date. I can use rsync to keep my system uptodate daily. I haven’t done reinstall since slackware 7.1. Even I did full release upgrade from 10.0 to 10.1 by using pkgtool for my workstations.
So, why buying? To support maintainer ofcourse.
This is a serious question.
Don’t you love how the Arch fanboys always have to post and tell you how much better their distro is? And if you look back at the comments to this review, you will see that none of the Slackers brought up Arch – it was Eugenia, who certainly qualifies as an Arch “fanboy” (or is it “fangirl”?) these days since she takes every opportunity to tell you how much better Arch is. And then “ex-slacker” picks it up and runs with it. It used to be the Gentoo fanboys, then the Yoper fanboys (remember them?), and how it’s the Ubuntu and Arch fanboys. You never see Slackware users post in a thread about Ubuntu, for example, how Slackware is better. That’s because we don’t need to go around telling everyone how much our distro is better than your distro.
These Distros Of The Week come and go but Slackware just keeps on truckin’.
You never see Slackware users post in a thread about Ubuntu, for example, how Slackware is better.
Because Slackware and Ubuntu has a different target group, when Slackware and Arch have more or less the same. I know many, many people who switched from Slack to Arch and never seen one who afterwards went back to Slack.
These Distros Of The Week come and go but Slackware just keeps on truckin’.
I would say Arch is similar to the snow ball effect. Once is starts rolling it only can gets bigger and bigger, with more people contributing to the project, taking the active part in development. Slack is still maintained basically by ONE person. Linux IS the community, you can’t really stay up-to-date with
one person maintaining the whole distro. Personally i don’t have nothing against Slack, I just wanna show people who still
don’t know what distribution to choose that there are other
alternatives based on Slackware philosophy out there, but more matured and improved in a positive sense of this word.
So next time you will start trolling around with your “fanboys” phrases, first think about what constructive arguments your post will add to the discussion.
People like ex-slacker just kill me. It’s not his fault really. We live in a time where everything has to be new and improved. Got an IPod yesterday but a new one came out today, got to have the new one, the old one wont do anymore.
Same goes for computers. This need to update the computer every 2 seconds is just not needed. People got this idea, IMO, from Windows, since there seemed to always be something to update. Then it trickled down to every piece of software that they had installed. Their current thinking is, if its not the latest and greatest, its broke and must be discarded as soon as possible regardless if the latest is stable or not.
These people finally learn enough on Windows and wanted to try out Linux. They, unforunately, brought their endless need to update everything with them. They try out several distro’s and if it doesnt keep them on the bleeding edge of everything, they consider it ancient and move on. You will be hard pressed to change their mind on any distro that doesn’t keep them 100% up to date.
You could try telling them that all they need to do is update the software that has security issues but its just not the same. You could try telling them that the old software has all the functions that they said they needed but they will want the newer software with the functions that they will never use. Oh well, we Slackers know better and thats enough for our piece of mind.
I’m the troll? You have to be kidding me. I’m the one posting here about Slackware — the subject at hand. You, my friend, are the one who popped in to give us your two cents about Arch. You said it yourself:
I just wanna show people who still
don’t know what distribution to choose that there are other
alternatives based on Slackware philosophy out there, but more matured and improved in a positive sense of this word.
So, in other words, you feel the need to pipe in during a discussion of Slackware and a review of the same and tell the world how much better your distro is. That’s basically what you are saying, right? That makes YOU the troll!
You kill me, ex-slacker. LOL.
a few &s in /etc/rc.d/rc.M can do wonders (carefull with hotplug though, you should probably just let that one sit) had to do this for my laptop (slow, used a transmeta chip, which is, i suspect, the main reason)
background for those confused: rc.M is a startup script, which runs each startup command one at a time, showing you its output, so if anything goes wrong, youll see it. no one cares any more (at least till something goes wrong) so background those starting tasks and it will move on to the next one, effectively doing them in parallel.
anyway, the above applys to slackware, apperantly uniquely to slackware, as all the other distros have complex start up procedures that take even longer.
I’m the one posting here about Slackware — the subject at hand.
Oh really? I didn’t notice it. All you did was flaming, that’s why i said do not post if you don’t have nothing constructive to add.
Calling me troll because i just express my thoughts on Slackware and Arch is just immature and stupid. I can’t understand why Slackware zealots are starting to get too emotional when they learn that there are other distros which aim at a similar target group as theirs. Jealously?
In the end I will throw out all cruft and it will all be just GNU utilities based on Linux kernel. What’s your point here?
What you are pointing out. Slackware is just the kernel, a bunch of GNU utilities, X.org and some other software. And there is some good guy that packages it for us. He only added some small scripts to make it a bit easier to install/upgrade/remove software. And voila, that is Slack.
Why would i bother to buy some cd’s twice a year
To support somebody who does a job that I and many other value very much.
and doing a fresh reinstall when i can just type “pacman -Syu” once a day and keep my system constantly up-to-date. I don’t even know what a system reinstall is no more.
FYI: I don’t do a fresh install, I actually don’t use the CDs for my own systems. My own computers track Slackware current. Do I need a complicated package manager for that? No, just some standard *nix tools and pkgtools. My server rsyncs with one of the Slack mirrors, and shares the slack-current over NFS. I just keep the CD sets handy, just in case (occasionally somebody else wants to give Slack a try too).
It’s good you let us know that. Like i written previously, nothing really hold you back from using –nodep option in pacman. But dependency handling in pacman is really an improvement, trust me or not. It ain’t no old Red Hat’s rpm tool.
You sure like to run in circles, don’t you? I don’t think it is of any use. It seems that you have made up your mind, and Arch is the one and only thing. Have fun with Arch, it is good that there is choice, just don’t spread misinformation or FUD. It is not a professional way to promote your distribution.
🙄 Ok, whatever. I’m movin’ on, brother.
just don’t spread misinformation
Actually it is YOU who spread misinformation about Arch, that’s why i stepped in. Calling pacman a “complicated package manager” is one of your misnomers.
Maybe I should make a wiki but for now here it goes.
Don’t get me wrong, I love Slacware and have it running on all my computers (workstation, server, and a laptop).
But Slackware has more than enough faults.
First of all, Slackware as an enduser system (home computer) is a major pain.
A regular user can’t do squat in default Slack install.
It’s basicaly a server configuration. That maybe great for servers but it’s a pain for home computers.
The permissions are such that as a regular user you can’t even dial out to connect to the Internet. You can’t mount drives, you can’t sync your Palmpilot etc. the list goes on.
Jail like security sounds good but it’s not very usefull if you can’t do anything with your system other than stare at command prompt.
The installer should ask a simple question during install if it’s a server or home computer install and set some sane permissions and group memberships so home users can mount their cdroms and floopies and connect to the Internet.
In this day and age where just about every home has a computer there is no reason not to do that other than PV being backward and lazy.
The purpouse fo a Linux distro should not be to teach end users the inner workings of a *nix OS but to provide a usable OS install out of the box.
I’m sure there can be a solution to provide both security and a usable system at the same time (and no, Windows is not it).
Also the installer is far from perfect. If you choose not to install Gnome from the second CD then you’ll be missing libs that are needed by major apps like Gimp for example (libsrvg comes to mind) and it’ll complain about it.
Those libs have to be installed later manualy.
And why the f*** does the installer insist on a domain during network configuration?! How many home computers have their own domain?
The 2.4 kernel shipped with Slack is fine for older computer s but on newer hardware you loose a lot of performance compared to the new 2.6 kernel compiled with SMP (if you have a Pentium 4 with hyperthreading) and also may not be able to boot at all if you run SATA hard drives.
HT and SATA is pretty standard on systems sold this year.
Basicaly to get a realy fast and smooth Slack install on a new system (like P4 with HT or AMD64) you have to compile your own 2.6 kernel, fix the broken udev, blacklist a bunch of “stuff” in hotplug and only then you have a modern, fast, very responsive, and stable OS install.
I think the reason Slackware users are so loyal and devoted to Slackware is because once they go through the initial tortures and very painfull configuration of Slack install they are terified and scared shitless that they would have to go through the same ordeal if they switched to another distro.
Slackware is like the mob, once you’re in you’re in for life, there is no way out :>(
And if someone says Ubuntu is the “witness protection program” for Slackers, you know how it goes, you can run but you can’t hide, Slackware will find you anywhere (and then you’ll get your rc.S in the back of your head when you least expect it) :<o)
…I’m not running GNU/Linux anymore. However, for any future x86 projects (I have a couple in mind, both revolving around a mini-ITX board), I will most certainly use Slackware, as it is the distro I know the most about. I ran it as my main OS for nearly three years, and I am very comfortable with every aspect of setting up and configuring it to do what I need. My favorite feature by far is the vanilla 2.4 kernel; I can modify it to my heart’s content without worrying about breaking some obscure, unnecessary patch. I also am very familiar with LILO, so unlike the reviewer I never have problems with booting a modified kernel.
As for desktop use, well, as I said I used it for almost three years, and other than a couple of minor applications, it was a great desktop. The only thing that could lure me away in that area was Ubuntu/Kubuntu. I don’t think “Desktop Linux” gets any better than that. In fact, Kubuntu was the first distro that made me like KDE! The reason I switched to Ubuntu originally was because of Patrick’s announcement that he was going to drop GNOME support. I didn’t care for Dropline, and I don’t have the patience to use Garnome, so Ubuntu seemed a perfect fit. For the most part, it was, but on my dated 1GHz system it was very slow. A friend and recent Linux convert convinced me to try Kubuntu, despite my loathing of KDE. I did, and I was blown away! Kubuntu had what I liked about KDE (speed), but severely cut down on the feature bloat, which was what made me dislike it so. Other than a few general Hoary bugs present in both distros, I was satisfied. Of course, a few weeks later my (2-month-old) hard drive died, and a week after that my Mac arrived. I am very happy so far with my decision to switch to PPC/OSX as a desktop, but I am still planning to tinker with Linux/x86 in the future.
As far as I am concerned there are only two Linux distro’s.
Slackware and the rest.
I have used about a dozen or more distro’s in the last four years and I always end up going back to Slackware.
Yep, I have even tried the “new” ones.
I like KDE more than Gnome.
I like Slackware more than the others.
I like Beer more than Pepsi.
I like Slackware, you may like something else… but to start calling people names and such is just childish.
Use what you like and like what you use.
Celebrate diversity, and let’s just be excellent to one another.
I’m glad to see that there are is still a hand full of users that perfer a OS without the use of system configuration wizards.
http://www.slackware.com/announce/10.1.php
– As an alternate choice, Slackware 10.1 includes Linux 2.6.10
source, kernel modules, and binary packages, along with the
mkinitrd tool and instructions on using it to install the
new kernel (see /boot/README.initrd). When running a 2.6
kernel, Slackware supports udev. This is a system for
creating devices in /dev dynamically, greatly reducing device
clutter and making it easy to see what devices are actually
present in the system.
——-
I agree, Udev is a necessity, but Slack is not blind
I wrote a big long post but didn’t like it, so I’m starting over.
I’ve found that Slackware users can usually be grouped into one of 3 camps; those who have been around the block and just feel most comfortable with the degree of control they get with Slackware, those who have *not* but either started with slackware or found it better than the few distributions they briefly experimented with and have grown accustomed to it, and those who used to use Slackware a lot but have since moved on to using other distributions on their machines.
As a disclaimer I’m in the 3rd group.
As an ardent coder and a lover of politics, I noticed a few things that started to concern me about Slackware. The first was that the community which was always touted as mean spirited, the community which I never really found as such, *started* to become more hostile (or to simply ignore) questions about the merits of the Slackware system of organization and others.
Why is it easier to view text files in /etc/rc.d/ as opposed to run ‘rc-update -s’ and ‘rc-update add _runlevel_ _service_’? Why is rsynching -current better than “apt-get dist-upgrade”? Usually the answers you get are laughable; most hinge on some paranoid delusion that distribution-common software like rsync are inherantly better and less likely to bite you than distribution-specific software like apt, disregarding the differences in their purposes and how they fit the problem at hand: that rsync is designed for the synchronization of files and apt is designed (in part) for the synchronization of packages.
I started to fall out of love with the type of simplicity that Slackware pushes to the forefront and with the simplicity of other distributions with more lush package management. Slackware’s simplicity is with its components and their organization (both of which are sparse: a good thing), but when it comes to keeping the whole system “in your head”, things get out of hand quickly. Slackware offers you *no* sort of system-level abstraction, no tools that can abstract away questions you will always have. You want to know what packages you have? `ls /var/log/packages`; Other than that, you’re stuck grepping around in there for what you’re looking for or worse not finding it at all.
After using other distributions with large package repositories, I found that the number of times I had to go outside the repository was extremely small, even though at first this led to some trepidation. Going outside the repository but staying within the package management system in slackware is trivial, and in more managed distributions its complex, but if you never have to do it, why settle for hand-done triviality?
Finally, the recent decision to not include Gnome was somewhat of an epiphany: I want my linux experience to be as freeform as possible, with me feeling as though I am making decisions on what software I run. In slackware I mostly kept with what was in -current (or the most recent stable in some cases), but that shaped in many ways my experience, and not always for the better.
Grub was the first piece of software I encountered that made me realize this, but as time went on I realized that much of the things I was previously building was there in the new distro’s repository. Slackware also does not ship with python bindings for Qt or Gtk, so say goodbye to experimentation with oh about half of the up and coming applications written with those toolkits. It probably won’t ever ship Mono, so there basically goes the other half.
Looking to the future, I found that more and more software is being developed using tools and libraries that I do not get (officially) running slackware. As time goes on there are two possible solutions: Slackware occupies a smaller and smaller niche meeting the needs of users who don’t care for the software they can’t run (or don’t mind building it themselves or using 3rd party packages), or Slackware inevitably increases in its own complexity in order to abstract away complexity in lower levels of system management. If you take a look at the trend of major open source software development and then try to affix those efforts to a simple disjoint loose collection of individual packages, you’ll see that the trend of slackware development is divergent. Libraries are good, Bindings are good, interoperability is good, and this stuff is complex to manage with the philosophy that “simple is best” and “unconfigured vanilla” is good enough for the user.
well, different tastes for different people.
What I want from Slack is a solid, stable and secure platform that I can build almost anything on top of it. I don’t mind compiling from source, and don’t mind living without bleeding edge apps.
What I want is just a core and solid platform. Just that. The rest is my bussines.
The talk of Slackware 10.1 not having the latest greatest packages from install is a totally moot point.
I’m running slackware 10.1 with KDE 3.4, 2.6.10 kernel and other more recent packages than slackware 10.1 shipped with.
KDE 3.4 compiled from source in 3 hours without a hitch – I wrote a little shell script to go in and out of the source folders and compile and just left it running while I did other things.
Bing – 3 hours later, a fully functional KDE 3.4.
That’s the beauty of Slackware for me – everything I’ve wanted to compile has worked pretty much “out of the box” – it’s very seldom I’ll need to fetch additional libraries or tools in order to compile an application successfully.
Actually it is YOU who spread misinformation about Arch, that’s why i stepped in. Calling pacman a “complicated package manager” is one of your misnomers.
It is easy to twist words. I said that pacman adds a layer of complexity that is not of my taste. Others may find it useful.
Interesting post jonas…
The first was that the community which was always touted as mean spirited, the community which I never really found as such, *started* to become more hostile (or to simply ignore) questions about the merits of the Slackware system of organization and others.
Maybe, but it is probably caused by a cultural difference. To the outside world it may seem to be a rude community (or at least some facets of the community), but when you have an interesting problem it is a very helpful and kind community. A lot of Slackers found their own way in Linux and UNIX, and are not very interested in too obvious questions for which the answers are documented at various places. “Pointing out the obvious” (though it may be less obvious for new users) may often be felt as a waste of time, or the unwillingness of a user to try to find an answer him/herself.
Why is it easier to view text files in /etc/rc.d/ as opposed to run ‘rc-update -s’ and ‘rc-update add _runlevel_ _service_’? Why is rsynching -current better than “apt-get dist-upgrade”? Usually the answers you get are laughable; most hinge on some paranoid delusion that distribution-common software like rsync are inherantly better and less likely to bite you than distribution-specific software like apt, disregarding the differences in their purposes and how they fit the problem at hand: that rsync is designed for the synchronization of files and apt is designed (in part) for the synchronization of packages.
I think that there is more than one reason. Some of which are captured in older (or newer) UNIX philosophies:
“There are many people who use UNIX or Linux who IMHO do not understand UNIX. UNIX is not just an operating system, it is a way of doing things, and the shell plays a key role by providing the glue that makes it work. The UNIX methodology relies heavily on reuse of a set of tools rather than on building monolithic applications. Even perl programmers often miss the point, writing the heart and soul of the application as perl script without making use of the UNIX toolkit.” –David Korn
“This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.” –Doug McIlroy
The traditional power of UNIX is the fact that it is a whole bunch of very small utilities that are connectable via very simple means (mostly text streams via pipes). Using these simple building blocks, a creative mind can solve very complex problems. Though there is no clear-cut line, the fear some people have with APT or complexer configuration and package tools is that it loses the kind of flexibility that UNIX offers, and it does harm to the universality of UNIX tools.
To give one, more clear-cut example, most (traditional) UNIX users are allergic for word processors. Why? First, a word processor is a monolithic program that can’t be expanded as easily as a pipeline, second, it does not use a plain text format when you add formatting. The horror of not being able to sed or awk your data is scary for this category of users.
Looking to the future, I found that more and more software is being developed using tools and libraries that I do not get (officially) running slackware. As time goes on there are two possible solutions: Slackware occupies a smaller and smaller niche meeting the needs of users who don’t care for the software they can’t run (or don’t mind building it themselves or using 3rd party packages),
Time has known its toolkits and languages. In the end it seems only a few things have sticked: the UNIX toolbox, C, X, Perl, LaTeX, and maybe a handful of other tools. In my experience I can do most work with these tools that have been available for ages.
Not having PyQT or other bindings can be painful if you have to develop applications for other target groups. But this can be another discussion on its own: are graphical user interaces that much better than using a shell, except for very obvious applications, like non-batch image manipulation?
Some people may find it interesting to read this article:
http://www.rap.ucar.edu/staff/tres/elements.html
It may give some insights why some people work in a completely different way, and are not so much interested in the latest desktop environments, GUI toolkits, etc.
I’m already very familiar with this philosophy and UNIX history as a whole, so I’ll skip some of the more informative parts of the reply.
The traditional power of UNIX is the fact that it is a whole bunch of very small utilities that are connectable via very simple means (mostly text streams via pipes). Using these simple building blocks, a creative mind can solve very complex problems. Though there is no clear-cut line, the fear some people have with APT or complexer configuration and package tools is that it loses the kind of flexibility that UNIX offers, and it does harm to the universality of UNIX tools.
This is the real heart of what I was trying to get at; that we must develop levels of abstraction to understand complex systems, and as time goes on we must develop new methods of abstraction or else be faced with an overly complex system with no way to abstract away any of it and thus no way to keep it all under control.
The “slackware way” is to follow the Unix way as much as possible; that this toolkit (pipes + cat,set,awk,grep,sh,ls,cp,mv) is a good level at which to provide your base system abstraction. I hugely agree for file management and for dealing in matters of text, where expertise in this toolkit can lead to the power to quickly do all sorts of complex operations. It’s for this reason the console won’t lose its importance any time soon; users who know this toolkit are aware that nothing better has been developed in 30 years and until its enormously apparent that something better has been developed, these users will not abandon that paradigm.
But as time goes on systems grow in scope, complexity, breadth; we now manage many types of devices, we deal with more and more data not represented (or representable) textually, and we deal with systems that have much more breadth because more and more libraries are necessary to interoperate with the rest of the world.
One place where it’s specifically obvious and thus easy to bring up is package management. Its a necessity common to distributions, and thus is abstracted away in each (serious one at least); even slackware does it by creating a set of tools based on the unix toolkit. There were 245 packages in slackware 3.3, and in 10.1 there are 552. Keeping track of this is a task that will only get tougher, and as time goes on its just foolish not to take a look at the provided tools and do *serious* introspection.
The example of the word processor is an interesting one because I personally like to publish most often in either HTML or LaTeX; but to do this you need deep knowledge of markup and most importantly the semantics of presentation. I don’t know if these are valid requirements to place on all users, or even that placing these requirements gets you towards a better resulting set of tools; i think eliminating requirements for deep knowledge is beneficial to productivity and if done correctly ultimately beneficial to the final result. The word processor is an example where you are *still* dealing with text, though; so using text in this case is still desireable.
But it extends beyond this; interoperability in visual environments is becoming more and more important for productivity and interoperability with other systems (by and large all exclusively visual), and this takes time and work. The GNOME community has realized to a large extent that trying to do everything in C is limited (because it’s not abstract enough for the problem at hand; creating visual applications!). The growing pains that the GNOME project is experiencing now are exactly what I think Slackware *needs* but is not getting due to its BDFL structure; why else would there be so many slackware based distributions?
I think that Slackware’s level of abstraction is one that is slowly becoming obsolete as almost all other distributions are finding it necessary to provide a higher one… it’s an opinion and a personal preference, but I do think that there is enough evidence behind it for me to stand strongly by it. Attempts to try to graft features onto the existing framework in ways that are not destructive (Jason Woodward’s proposal for some optional dependency info) are met with disapproval straight from the top and are doomed to never be included, and while conservativism in software maintainence is good there are times when it just slaps the face of better judgement (debian sticking with xfree86, to provide a nonslackware example, and there are plenty for each distribution).
In the end, I can answer one of my own “questions”; the reason I always feel compelled to write a package manager for Slackware when I use it is that it’s extremely easy to visualize how to do so because the package system is so simple and built upon such strong components, but also because the omission of a richer (or at least more convenient) package management system is a *glaring* defect that I can’t readily ignore.
Time has known its toolkits and languages. In the end it seems only a few things have sticked: the UNIX toolbox, C, X, Perl, LaTeX, and maybe a handful of other tools. In my experience I can do most work with these tools that have been available for ages.
I have my own biases against Perl, but I think that the much of the future successful GNU/Linux development is centered around abstractions off of this toolbox and no longer the toolbox itself: abstractions that I feel go hand in hand with the unix philosophy. We are beginning to move beyond this toolbox to developing on or with the next atomic set of abstractions. This set is not yet well defined, but it is roughly: python/ruby/mono/java/some high level language with C interoperability, gtk/qt/fltk/fox/some toolkit with convenient abstractions above Xlib (which hardly any projects that have active development use anymore), and a host of scripting languages that aim at a niche between quick kludges (which perl exceeds at beyond all others) and large scale applications.
Interesting read. IMHO, abstaction is one os the strategies to manage complexity. Devide and conquer is another one. That’s is slack way.
Hope to welcome you someday in debian;-)
Does anyone know why Patrick Volkerding prefers to publish his own code under the BSD license?