- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Course: Choosing A Top Linux Distro
|
|
|
Comments (42)
22 earlier comments in the full thread.
> I suppose I could figure out Slackbuilds...
As bigg says, sbopkg: http://www.sbopkg.org/
Give it a try.
> There is currently no GNOME for Slackware 12.2.
http://www.slacky.eu/index.php?option=com_content&task=view&... http://www.gware.org/ http://gnomeslackbuild.org/
All have versions for 12.2 now. Of course, with 13.0 due out any time... :(
> My next review of Slackware (and one is coming) will be no less strident about making this point than my last one.
As I recall, that wasn't your only point, and the disagreements were mostly about more nebulous terms, such as "user friendly", "ease of use", an such.
> Actually, on LXer.com the conversation was respectful all around and mainly stuck with the pros and cons from technical perspectives. That issue only occurred in other forums. That is one of the reasons I have such a high level of respect for the LXer regulars.
Fortunately, Bob's not a Slackware user, and Slackware conversations seldom involve gun ownership. :)
Now, when you do your next Debain review, all bets are off. :)
As bigg says, sbopkg: http://www.sbopkg.org/
Give it a try.
> There is currently no GNOME for Slackware 12.2.
http://www.slacky.eu/index.php?option=com_content&task=view&... http://www.gware.org/ http://gnomeslackbuild.org/
All have versions for 12.2 now. Of course, with 13.0 due out any time... :(
> My next review of Slackware (and one is coming) will be no less strident about making this point than my last one.
As I recall, that wasn't your only point, and the disagreements were mostly about more nebulous terms, such as "user friendly", "ease of use", an such.
> Actually, on LXer.com the conversation was respectful all around and mainly stuck with the pros and cons from technical perspectives. That issue only occurred in other forums. That is one of the reasons I have such a high level of respect for the LXer regulars.
Fortunately, Bob's not a Slackware user, and Slackware conversations seldom involve gun ownership. :)
Now, when you do your next Debain review, all bets are off. :)
> All have versions for 12.2 now.
Okay, I guess I haven't checked in a while. After all that time had passed, I sort of gave up and expected them to skip 12.2.
Okay, I guess I haven't checked in a while. After all that time had passed, I sort of gave up and expected them to skip 12.2.
Quoting:As I recall, that wasn't your only point, and the disagreements were mostly about more nebulous terms, such as "user friendly", "ease of use", an such.
Again, that was true on LXer.com. Not necessarily on other forums.
I intend to be a lot more specific in describing those terms this time around. I don't think it will stop me from being flamed. Fans or critics of distros always flame reviewers. It's par for the course :) It may, however, help smooth things over with the more reasonable Slackware fans who agree that Slackware isn't for everyone.
> Again, that was true on LXer.com. Not necessarily on other forums.
OK. I'd normally only read LXer, and occasionally Linux Today for specific articles.
> I intend to be a lot more specific in describing those terms this time around.
Assuming the definitions are considered reasonable, that should help quite a bit, at least here. Given your previous articles, I have no reason to think they won't be.
OK. I'd normally only read LXer, and occasionally Linux Today for specific articles.
> I intend to be a lot more specific in describing those terms this time around.
Assuming the definitions are considered reasonable, that should help quite a bit, at least here. Given your previous articles, I have no reason to think they won't be.
@bigg
> Criticism of Slackware typically amounts to stating the disadvantages, and then leaving the impression that there are no advantages, that you could only possibly be interested in using Slackware if you have lots of time to waste or you like to do things of absolutely no value.<
Well, one disadvantage I've found with Slackware is its irritating adherence to BSD-style file layout for its system initialization files. Never mind even, the old discussion of LILO vs grub here. (Yes, I know this has been discussed before.... just repeating this, as I couldn't find mention of this point in the posted Course article.) For those of us with some Linux experience, e.g., readers of LXer, it's less of a bigg deal :). Yet anyone past a _real_ n00B kinda sorta HAS TO spend lots of time using Pat V's documentation figuring out some of the text files with all these scripts scattered around the place. Not only user UNFRIENDLY, but also doesn't conform to other distros stndard SysV system initialization with clear runlevels. Even Ubuntu has something similar to a SysV startup. I recall having to hunt down much of PatV's documentation on setting up Slack startup as close as possible to that of Debian Sarge in dual-boot Linux-WInblow$ systems, at a time when I could spend the necessary time then to play around with both.
Although I WILL say here that one advantage for Slack past and present is that finding its minimal HW reqs for installation has always been straightforward, this going way back to Slackware 7 probably close to ten years or so ago. Might have been before kudzu, do not remember clearly on this.
Well, one disadvantage I've found with Slackware is its irritating adherence to BSD-style file layout for its system initialization files. Never mind even, the old discussion of LILO vs grub here. (Yes, I know this has been discussed before.... just repeating this, as I couldn't find mention of this point in the posted Course article.) For those of us with some Linux experience, e.g., readers of LXer, it's less of a bigg deal :). Yet anyone past a _real_ n00B kinda sorta HAS TO spend lots of time using Pat V's documentation figuring out some of the text files with all these scripts scattered around the place. Not only user UNFRIENDLY, but also doesn't conform to other distros stndard SysV system initialization with clear runlevels. Even Ubuntu has something similar to a SysV startup. I recall having to hunt down much of PatV's documentation on setting up Slack startup as close as possible to that of Debian Sarge in dual-boot Linux-WInblow$ systems, at a time when I could spend the necessary time then to play around with both.
Although I WILL say here that one advantage for Slack past and present is that finding its minimal HW reqs for installation has always been straightforward, this going way back to Slackware 7 probably close to ten years or so ago. Might have been before kudzu, do not remember clearly on this.
> Well, one disadvantage I've found with Slackware is its irritating adherence to BSD-style file layout for its system initialization files.
Strangely, I consider that one of its advantages. I find Slackware's startup scripts a lot easier to understand than the sysv version everyone else uses. I've heard other folks say the same.
Strangely, I consider that one of its advantages. I find Slackware's startup scripts a lot easier to understand than the sysv version everyone else uses. I've heard other folks say the same.
I've used Robby Workman's Slackware packages in the past, and I vouch for their quality.
I haven't used sbopkg, but that sounds like something that would help immensely. My feelings toward Slackbuilds (even though I had trouble getting them to work) are much more favorable then they are toward any number of 3rd-party repositories for Slackware binary packages.
I understand some users wanting the choice to be theirs of exactly how a package is built from source. For me, I prefer to delegate those choices to the maintainers of that package for the given distro, be it Ubuntu, Debian, OpenBSD or what have you.
That's why when seeking an OS I look for the packages I want, I prefer them to be part of the distro's own repositories, to be maintained in a timely and rational manner, and not to break my system.
It's a lot to ask from something I'm getting for free. But there are plenty of choices that meet these criteria, and for that I'm thankful.
Observation: Slackware pushed out Firefox 3.0.11 on June 16, 2009. I just updated my Debian Lenny install this morning, and I still have Iceweasel (aka unbranded FF) 3.0.6 http://packages.debian.org/lenny/iceweasel. I'm sure there's a good reason, or a reason at any rate, as to why Debian has such an old FF package in its Stable tree, and I await that reason.
So from a security standpoint, Debian might be saying that FF 3.0.11 has to wend its way through Volatile, Sid and Squeeze to make sure the package doesn't break anything.
But if there is a security problem with FF/Iceweasel 3.0.6 (or the past FIVE releases of the browser), Debian users have been seemingly left in the lurch.
Slackware users, not at all. And Ubuntu is also up to date as far as FF goes (3.0.11).
Debian Squeeze (Testing) is at Iceweasel 3.0.9 http://packages.debian.org/squeeze/iceweasel. Debian Sid (Unstable) has 3.0.11: http://packages.debian.org/sid/iceweasel
So see, people, these things aren't at all clear-cut. And there's a big philosophical divide in how security updates are delivered to users of a stable Slackware distribution and a stable Debian distribution.
Point of order: Slackware pushed out FF 3.0.6 on Feb. 5, 2009. For users of Debian Stable and Testing, we don't have it more than four months later.
I've run Debian Testing, and in my experience it wasn't as "stable" as some make it out to be. That means I had a lot of problems.
I'm enjoying the sheer speed of my customized Debian Lenny install (I built it up from the "standard" installation), but I wonder if I'd be better off elsewhere (even Slackware) from a security standpoint.
The proper equation for me might just be: Slackware minus KDE (but + Xfce) + OO + Geany (+ Flash + Java + slapt-get + Gslapt + sbopkg)
Point of further order: Here's what Mozilla has fixed in its various FF3 updates: http://www.mozilla.org/security/known-vulnerabilities/firefo...
I haven't used sbopkg, but that sounds like something that would help immensely. My feelings toward Slackbuilds (even though I had trouble getting them to work) are much more favorable then they are toward any number of 3rd-party repositories for Slackware binary packages.
I understand some users wanting the choice to be theirs of exactly how a package is built from source. For me, I prefer to delegate those choices to the maintainers of that package for the given distro, be it Ubuntu, Debian, OpenBSD or what have you.
That's why when seeking an OS I look for the packages I want, I prefer them to be part of the distro's own repositories, to be maintained in a timely and rational manner, and not to break my system.
It's a lot to ask from something I'm getting for free. But there are plenty of choices that meet these criteria, and for that I'm thankful.
Observation: Slackware pushed out Firefox 3.0.11 on June 16, 2009. I just updated my Debian Lenny install this morning, and I still have Iceweasel (aka unbranded FF) 3.0.6 http://packages.debian.org/lenny/iceweasel. I'm sure there's a good reason, or a reason at any rate, as to why Debian has such an old FF package in its Stable tree, and I await that reason.
So from a security standpoint, Debian might be saying that FF 3.0.11 has to wend its way through Volatile, Sid and Squeeze to make sure the package doesn't break anything.
But if there is a security problem with FF/Iceweasel 3.0.6 (or the past FIVE releases of the browser), Debian users have been seemingly left in the lurch.
Slackware users, not at all. And Ubuntu is also up to date as far as FF goes (3.0.11).
Debian Squeeze (Testing) is at Iceweasel 3.0.9 http://packages.debian.org/squeeze/iceweasel. Debian Sid (Unstable) has 3.0.11: http://packages.debian.org/sid/iceweasel
So see, people, these things aren't at all clear-cut. And there's a big philosophical divide in how security updates are delivered to users of a stable Slackware distribution and a stable Debian distribution.
Point of order: Slackware pushed out FF 3.0.6 on Feb. 5, 2009. For users of Debian Stable and Testing, we don't have it more than four months later.
I've run Debian Testing, and in my experience it wasn't as "stable" as some make it out to be. That means I had a lot of problems.
I'm enjoying the sheer speed of my customized Debian Lenny install (I built it up from the "standard" installation), but I wonder if I'd be better off elsewhere (even Slackware) from a security standpoint.
The proper equation for me might just be: Slackware minus KDE (but + Xfce) + OO + Geany (+ Flash + Java + slapt-get + Gslapt + sbopkg)
Point of further order: Here's what Mozilla has fixed in its various FF3 updates: http://www.mozilla.org/security/known-vulnerabilities/firefo...
@jdixon
> I find Slackware's startup scripts a lot easier to understand than the sysv version everyone else uses. I've heard other folks say the same.
I've also heard the same thing from a select group of other users, that Slack's startup scripts are easier to use than SysV's version. AFAICT, the common denominator in all these person's views on this is their hands-on experience with OS's that have text-based configuration. Most of these persons had experience going way back with M$'s 16 and 16/32-bit config files autoexec.bat, config.sys, system.ini, win.ini, system.dat and user.dat files, so these persons have a good idea of where to start looking for script files of various sorts even without prior exposure to Linux. Those who did not have extended experience with M$'s Winblow$ here, came from backgrounds that used other OSs, such as other types of Unix and Novell's NetWare. AAMOF, NetWare also required startup scripts in a DOS partition before loading the native Netware filesystem, so some basic knowledge of scripts was needed here too, easing a transition to the BSD-style. And without question ALL of these users certainly had enough experience that they'd never be considered PC n00b's.
I still think that for even these computer users as well as those with even less experience, detailed knowledge of runtime scripts is much less necessary with SysV than with the BSD-style of Slackware. For SysV, just grasp the concept of the runlevel, change a line in inittab, rename or hide away some S & K scriptnames within your default runlevels and presto 1-2-3 you can start your system with less of a chance of messing things. Slightly more advanced as far as knowledge of scripts go, is to then maximize your SysV system and user bashrc and profile files.
I've also heard the same thing from a select group of other users, that Slack's startup scripts are easier to use than SysV's version. AFAICT, the common denominator in all these person's views on this is their hands-on experience with OS's that have text-based configuration. Most of these persons had experience going way back with M$'s 16 and 16/32-bit config files autoexec.bat, config.sys, system.ini, win.ini, system.dat and user.dat files, so these persons have a good idea of where to start looking for script files of various sorts even without prior exposure to Linux. Those who did not have extended experience with M$'s Winblow$ here, came from backgrounds that used other OSs, such as other types of Unix and Novell's NetWare. AAMOF, NetWare also required startup scripts in a DOS partition before loading the native Netware filesystem, so some basic knowledge of scripts was needed here too, easing a transition to the BSD-style. And without question ALL of these users certainly had enough experience that they'd never be considered PC n00b's.
I still think that for even these computer users as well as those with even less experience, detailed knowledge of runtime scripts is much less necessary with SysV than with the BSD-style of Slackware. For SysV, just grasp the concept of the runlevel, change a line in inittab, rename or hide away some S & K scriptnames within your default runlevels and presto 1-2-3 you can start your system with less of a chance of messing things. Slightly more advanced as far as knowledge of scripts go, is to then maximize your SysV system and user bashrc and profile files.
I have a whole lot more mastery over the startup scripts in OpenBSD only because the average user needs to know about them in order to manage the OS. And the project's excellent FAQ and man pages make it very clear as to how things work.
I'd love to be at the same level in Linux now that I'm back to using it every day.
I'd love to be at the same level in Linux now that I'm back to using it every day.
If you're talking about startup scripts, I love Arch. I'm not the kind of guy who likes using them, but you do all that stuff (not just startup) in rc.conf.
> ...AFAICT, the common denominator in all these person's views on this is their hands-on experience with OS's that have text-based configuration.
Well, that's true for me, so I can't contradict your assessment.
> I still think that for even these computer users as well as those with even less experience, detailed knowledge of runtime scripts is much less necessary with SysV than with the BSD-style of Slackware.
I didn't find that to be the case, but obviously YMMV.
Well, that's true for me, so I can't contradict your assessment.
> I still think that for even these computer users as well as those with even less experience, detailed knowledge of runtime scripts is much less necessary with SysV than with the BSD-style of Slackware.
I didn't find that to be the case, but obviously YMMV.
Quoting:I have a whole lot more mastery over the startup scripts in OpenBSD only because the average user needs to know about them in order to manage the OS.
Can't remember that. AFAIK you don't have to know what's going on in the scripts, you just comment out the things you don't want and put in the things you want. It's exactly the same as in Linux, though in Linux instead of commenting things out you make / delete 'softlinks', or you use a script to do so.
@jdixon
At the same time, another thing I didn't mention above were some of my own experiences with older Slack versions. Mind you, these experiences were not just limited to Slackware, although just like you, YMMV.
But at least there WERE decent books available on past RedHat versions to get someone started with RedHat in particular.
The installation order for the Slackwares though, was and still is :
1. You had to figure out what partitioning you needed in order to use disk space wisely with a coexisting Windblow$ OS already installed just fine. IIRC, RedHat's disk druid was okay for doing all this, but not Slackware's fdisk. Together with this was the question of Yes fips or No fips on that large fat16 or fat32 Windblow$ partition.
2. You then had to figure out what level of package installation you needed to do, without the level of help as someone can regularly find today. For instance, I could never find this in the Linux Documentation Project of days gone by. Should I do a full Install, a newbie install, or a menu install ? At what level of experience could you do a manageably fast expert install ?
3. You then had to figure out what software sets A through Y you would like to have, and then eventually decide by viewing each package's short-description and space requirements what you actually should or shouldn't install.
4. AND THEN you had to go through a whole bunch of p.i.t.a. steps to choose an xserver and maybe find & edit that daunting XF86Config file for X11R6 (by using vi? using emacs?), correctly set up ppp, and _hopefully_ get your sound card recognized fine the first time around.
These Slack 1-4 steps were all quite intimidating at first, and all before the helpful linuxquestions.org and user-friendly guides & tutorials became more widespread. Though again, I'll have to say that once Slackware gets running okay even in CLI text mode, PatV's documentation for his distro remains good.
These Slack 1-4 steps were all quite intimidating at first, and all before the helpful linuxquestions.org and user-friendly guides & tutorials became more widespread. Though again, I'll have to say that once Slackware gets running okay even in CLI text mode, PatV's documentation for his distro remains good.
Very off-topic: Had a few problems with YouTube and other things, so I coulkdn't respond for a while. Now with the 1980's Pop King Michael Jackson death, I was seeing some related network server issues.
@Steven_Rosenber Back on-topic: Slackware isnt't the only one with a confusing initial package installation issues. IIRC, old versions of Debian s8uch as Woody were a real hassle to install even more than Slack. The old Debian installer used a whole ncurses-type package install, called tasksel I think. Now THIS was a very confusing package-installation front-end. Something like six or seven CD's, a bunch of confusing lists of packages to be dependency-resolved, and little info to know what should be best left out. I was glad to have some good help using this pkg-install thing when I did, otherwise I might have just given up! Red Hat versions 6.2 - 8 were all much more convenient to install than the old Debians. The Debian Etch and Lenny installs are all so much better now, with good behind-the-scenes apt-get's to quickly get a desktop Linux OS up and running okay. Just saying..
@Steven_Rosenber Back on-topic: Slackware isnt't the only one with a confusing initial package installation issues. IIRC, old versions of Debian s8uch as Woody were a real hassle to install even more than Slack. The old Debian installer used a whole ncurses-type package install, called tasksel I think. Now THIS was a very confusing package-installation front-end. Something like six or seven CD's, a bunch of confusing lists of packages to be dependency-resolved, and little info to know what should be best left out. I was glad to have some good help using this pkg-install thing when I did, otherwise I might have just given up! Red Hat versions 6.2 - 8 were all much more convenient to install than the old Debians. The Debian Etch and Lenny installs are all so much better now, with good behind-the-scenes apt-get's to quickly get a desktop Linux OS up and running okay. Just saying..
@fluffbeer: tasksel still exists and is still used in the Debian installer. It's nothing more than a coule of sets of meta packages. I.e. the "Desktop" tasks depends on Gnome, IceWeasel, OpenOffice and a bunch of other software. The "Webserver" task depends on Apache, PHP, MySQL, Perl, Python, etcetera.
@Sander
Yes, maybe this labyrinthine old Debian front-end was called by some other name than tasksel.
I recall many categories of packages to be expanded or reduced, with a whole menu of editing and status +/-/i keys to use for the sets of meta packages. These sets of meta packages were not identified by single or double alphabet letters like Slack's.
I certainly remember that after each package with unselected dependencies was selected, I HAD to choose the bottom-listed dependent packages, which then led me to FURTHER mandatory selection of MORE dependencies, on and on, until I reached the point when the list of other Required (as opposed to Optional) packages finally disappeared.
Exploring the old and dusty tomes of Debian past [1] I think you're referring to the "dbootstrap" program (not to be confused with "debootstrap" which you can use to quickly install a chrooted Debian in a subdirectory).
[1] http://www.debian.org/releases/3.0/i386/ch-install-system.en...
[1] http://www.debian.org/releases/3.0/i386/ch-install-system.en...
> 1. You had to figure out what partitioning you needed...
You still do. And with NTFS, there's not even an easy tool like fips to repartition for you. You have to get a gparted disk or some such to do it before you start. Of course, if you're using Slackware at this point, you probably don't have a Windows partition to worry about.
> 2. You then had to figure out what level of package installation you needed to do...
Again, still the case, though with the large hard drives available today it's simplest just to install everything and be done with it.
> 3. You then had to figure out what software sets A through Y you would like to have,
Again, that's still an option, but see 2 above.
> 4. AND THEN you had to go through a whole bunch of p.i.t.a. steps to choose an xserver and maybe find & edit that daunting XF86Config file for X11R6 (by using vi? using emacs?), correctly set up ppp, and _hopefully_ get your sound card recognized fine the first time around.
That's a lot better today. The vesa default works on most chipsets, and modern Xorg's pretty much identify everything for you, so at most you have to run one setup script. With most people having broadband, ppp isn't the problem it used to be, and most sound cards are detected and installed by the kernel. All you have to do is unmute your outputs with alsamixer.
> ..old versions of Debian s8uch as Woody were a real hassle to install even more than Slack.
Very old versions were. I'm not sure that was true by the time Woody came out. I'm thinking things had already improved quite a bit by then, but you know how memory is. Bob could tell us, he's a Debian person.
You still do. And with NTFS, there's not even an easy tool like fips to repartition for you. You have to get a gparted disk or some such to do it before you start. Of course, if you're using Slackware at this point, you probably don't have a Windows partition to worry about.
> 2. You then had to figure out what level of package installation you needed to do...
Again, still the case, though with the large hard drives available today it's simplest just to install everything and be done with it.
> 3. You then had to figure out what software sets A through Y you would like to have,
Again, that's still an option, but see 2 above.
> 4. AND THEN you had to go through a whole bunch of p.i.t.a. steps to choose an xserver and maybe find & edit that daunting XF86Config file for X11R6 (by using vi? using emacs?), correctly set up ppp, and _hopefully_ get your sound card recognized fine the first time around.
That's a lot better today. The vesa default works on most chipsets, and modern Xorg's pretty much identify everything for you, so at most you have to run one setup script. With most people having broadband, ppp isn't the problem it used to be, and most sound cards are detected and installed by the kernel. All you have to do is unmute your outputs with alsamixer.
> ..old versions of Debian s8uch as Woody were a real hassle to install even more than Slack.
Very old versions were. I'm not sure that was true by the time Woody came out. I'm thinking things had already improved quite a bit by then, but you know how memory is. Bob could tell us, he's a Debian person.
And I thought this thread was dead ...
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
Actually, on LXer.com the conversation was respectful all around and mainly stuck with the pros and cons from technical perspectives. That issue only occurred in other forums. That is one of the reasons I have such a high level of respect for the LXer regulars.
Yes, it matters. When something goes wrong someone (or some organization) has to be responsible for correcting that. Normally it's the distro developer. With Slacky.eu it's whomever contributes. That is a huge difference. The depth of the repos is good but it doesn't compare with other major distros.
Your "if" is the key word. The dependency checking part does NOT work with the official Slackware repos. If I enable more than one third party repo (a must to get a decent selection of packages) I end up with conflicts and dependency problems. These are not issues with other major distros with a centralized repos.
FWIW, I don't hold up Ubuntu or Debian as model distros. I've been pretty critical of both.
You want a distro that, at least recently, has done repos the right way: Mandriva would be it.