Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Linux Software

Slackware 8.0 Released 256

cyberkreiger was among many to submit that Slackware 8.0, the distribution that just won't die, has just been released. I'm sure many people here started w/ Slackware back in the day and I'm glad to see it keep moving. You can read the Changelog or the Freshmeat project page. It'll probably be awhile before enough mirrors have caught up to settle demand, so please be patient. And congrats to Patrick and the rest. If it wasn't for your work back in the day, I may never have started using Linux.
This discussion has been archived. No new comments can be posted.

Slackware 8.0 Released

Comments Filter:

  • SuSe was also based on Slackware. They switched from pkgtool to rpm around version 5 or 6 though. Yast (1) still has the feel for the slackware installer.

    SuSe has morphed alot with package managment, startup scripts (changed to system v), amount of software included, config tools, etc... It is an rpm based system, but not a "slackware rpm system" due to it's morphing.

    Not saying it is bad or good, just saying...
  • by Anonymous Coward

    I have tried Slackware back when it was like 3.something and did not like it. But now since 7.x it has changed a lot and has all up to date stuff.

    Installing packages is easy with "installpkg packagename.tgz" and "removepkg packagename.tgz". I also use Redhat and other RPMs with Slackware. I just run "rpm2tgz redhatpackagename.rpm" and there I got myself a tarball that I can install with installpkg! rpm2tgz works fast, I got the file changed to tgz almost as soon as I hit ENTER.

  • by Anonymous Coward
    Agreed. I jerk off to ASCII art on Usenet too. Damn kids today.. all they want is fancy colorful moving pictures in high resolution. In my day we printed out porno on dot matrix printers and retired to the bathroom for the afternoon.
  • by Anonymous Coward
    Yeah... GCC 3.0 is included in /contrib... it's not the main compiler.... it would have been insane to do so....

    Not the kinda thing I'd expect from Pat....

    BTW stop slashdotting store.slackware.com if ya ain't gonna buy it.... some people really want to buy the whole thing fast !
  • by Anonymous Coward
    Just yesterday, I was looking at the devel tree, and saying to myself, "Hrmm... to I want to take 7.1 and try to bring it up to date, or use the devel one, and worry about problems. The development tree was refered to in a few of the files as 7.2.

    What I have to wonder about is the reason why they caleed it 8.0 instead of 7.2. Was it because the the false release announcement on /.? Does it have anything to do with staying ahead of Redhat? Or maybe it's just because a lot of major new packages have come out since 7.1 (not sure what's in it, but we've had big releases for X, the kernel, KDE and Gnome since 7.1 came out)?
  • by Anonymous Coward
    Actually, Slackware has ALWAYS (at least since 1994) had a package management system. I didn't start to use Linux until 1994, and it was Slackware. I haven't changed yet :) There is pkgtool (dialog based), installpkg/removepkg/upgradepkg/explodepkg (console based). If you didn't know about those, then you obviously haven't really used Slackware. Then for creating packages, there is checkinstall (3rd party) and makepkg (native Slack).
  • I made sure to check that before submitting an article about it, which was rejected (possibly because my submission didn't downplay Slackware as being a historical distro that didn't die when it was supposed to, or something). It's really out, and I've ordered my copy (and a polo shirt and a bumper sticker) from store.slackware.com [slackware.com]. It's a good thing I did; at the rate this ISO is downloading off Sourceforge's server (and I began the download before it was Slashdotted), the CD may arrive first.

    --

  • This pales in comparison, but my friend's NFS box on his LAN:

    1:54pm up 122 days, 12:55, 2 users, load average: 0.00, 0.00, 0.00

    I won't have decent uptime on any of my systems for awhile; I keep moving hardware around.

    --

  • I love Slackware, but he does make a valid point. Slack is NOT for newbies.

    You couldn't be more wrong. Slackware is not for stupid people. Slackware 3.5 was the first Linux distro I installed, and was the distro of choice when many of us were newbies. If you don't know how to read, or simply refuse to, then Slackware is not for you. If you can RTFM, you can install and set up Slackware, and it will be a very valuable experience.

    And if you're talking about using a system that's already set up, Slackware's not that much different from anything else, from a user perspective. A friend of mine who's a Windows users and had never seen Linux before sat down in front of my Slackware 7 box, and was surfing the Web and chatting on IRC within minutes, with not much more help from me than "log in, and type startx."

    --

  • Living in the past is certainly fun and educational but it also has a tendency to close our minds to new ideas.
    As a postscript, realize that the reverse is also true: ignoring the past leads us to reinvention and downright hostility to those keeping it alive. Witness the "30 year old technology" rants of Bill and Steve and the blackballing of those not on "the cutting edge" in most fields.

    --

  • No, _I_ dont think the cli is hard or unfriendly to use at all. Though this seems to be the opinion of all my friends who arent big fans of linux / BSDs (one of my friends beleives EVERYTHING should be done on OS9 macs).

    Note that I mentioned vendors leaving the CLI as the sole user experience. I do not underestimate the power and user-friendliness of the CLI. It's an absolutely crucial element of a user interface.

    My response was more to the point of some UNIX advocates thinking that to be a real UNIX Guru one has to work solely at the CLI, or configure Sendmail by hand or some other ridiculous notion. The hostility toward graphical mailers/editors/wizards is a perfect example. Not all of these things are right for me because I am more familiar with other tools. But that doesn't mean the ideas are wrong.

    I agree that it's fun to rummage around a system, find out how things work, etc. It's part of the learning process. Forcing this process on people who aren't interested is a bad idea.

    If Slack works for you, great. It may not in the future and it certainly doesn't for many Linux users. If some time in the future you become tired of manually configuring and building packages, you won't be "giving up" or "sacrificing your UNIX-ness" by moving to another distribution. You'll just be ackowledging that changes come through time how open-minded and forward-thinking you are. :)

    --

  • For example, both Ximian Gnome and the Red Hat Netscape RPM's provide a Netscape Icon, thus producing a conflict and breaking up2date.

    The problem there is mixing packages from two independent, non-cooperating vendors, not packaging per se.

    The underlying problem with Windows (and MacOS) is that it is condecending to the user. "There there, poor, stupid user, don't worry, we'll just install this crap and you don't have to think..."

    No, the problem is that these systems hide what is going on and make it impossible to fix when problems occur. I don't want to think when doing something as mundane as upgrading software. Gads, I have too many other thing to think about!

    One of the major goodneses of Free software and Linux is that it does not condecend. The user has the right to be responsible for their own computer!

    Packaging systems in no way prevent that.

    My friends with Red Hat call me saying they updated an RPM and now the config's different and they can't find the config file and the dependancies won't resolve and so on... It's the same calls they made to me years ago about Windows.

    They're making the call because it's not convenient to RTFM. One of the really nice things about Debian is /usr[/share]/doc. Nothing in Slackware would prevent these sorts of call. You'll just get them about configuring X or running ./configure && make && make install.

    USE THE SOURCE, People! This is not a black box... It's good to know and care what's happening on your hard drive.

    Of course its good to know this. It's even better if it can be automated and the knowledge kept in a nicely-organized system.

    --

  • anymore than cp and tar are 'package management tools'.

    Exactly right.

    of course, deb doesn't really have alternate distros, so i assume it would have a similar drift problem were it in the same circumstance.

    Corel and Progeny are both based on Debian, use the .deb package format and have no problems interacting with "official" Debian packages. I think this is a testament to the design of the distribution. I'm not sure how cross-polination between Progeny and Corel works. I doubt they include dependecies or conflicts between each other.

    The iPAQ Familiar distribution uses the .ipkg format which is .deb repackaged using tar instead of ar so that ar doesn't have to be installed. So Debian-proper packages are out.

    The Intimate iPAQ distribution is Familiar using full-blown .debs. Adding Debian-proper packages is no problem.

    Finally, there's emdebian, another ARM-based handheld distribution. It's not too far along, though.

    So Debian does indeed have several derivatives, most using the original package format and having no problem mixing Debian packages and its own repackaged software.

    --

  • It's actually a namespace problem with packaging schemes per se.

    There should be a way for the Netscape package to say "I optionally need an icon package associated with Netscape, doesn't matter what it's called" without the whole thing blowing up.

    You are absolutely correct. Debian supports this in a primitive way with the "provides" field.

    --

  • Ok, that's a good point. However, with Debian (don't know about others) it is trivial to grab the source of a package, tweak it, automatically build a new package and have it play nice with the packaging system.

    For kernels, this is pretty much the standard practice in Debian. In fact there's a nice make-kpkg tool that converts a generic kernel source tree into a Debian package, configured to your liking and ready to install. It even runs LILO for you so you don't forget. :)

    --

  • If Slack works for you, great. It may not in the future and it certainly doesn't for many Linux users.

    Wow. You've left a bit of FUD on your chin. Would you like a napkin?

    Where's the FUD? Many Linux users don't use Slack. That's not in debate. It's obviously not right for them. Or are you objecting to the colloquial use of "works?"

    If some time in the future you become tired of manually configuring and building packages[...]

    This shows a deep misunderstanding of how Slack and Slack packages work.

    I know how Slack packages work. Used 'em for many years. I was responding directly to a comment that having to manually configure packages (X in this case) is good and indirectly to a (common, IME) belief among Slackware users that compiling from source is a necessary task for good system maintenance. You're right, I was a little sloppy with my wording.

    [acknowledge] that changes come through time how open-minded and forward-thinking you are.

    Hmmmm. If hiding information from the administrator is open-minded and forward-thinking, give me unreceptive and reactionary any day.

    Well, I was being a bit facetious there, but only a little. It takes some insight and courage to realize that sometimes the easy way is not a cop-out. It's the same reason that NIH is so looked down upon.

    How, presently, do package managers hide information? I agree they can, but I can't think of a single instance where they do. Note that I'm coming from a Debian perspective and YMMV for other distributions or operating systems.

    The concept that Linux must be easy to use for any clueless git on the planet is seriously flawed.

    First off, no one is a "clueless git." They may not be interested or may not have the background you and I do, but they almost certainly have a clue in areas where you and I will be lost. Sorry, this sort of talk really grates on me.

    The requirement of study and attention to detail to run a *nix system is a Good Thing. I'd prefer that people who aren't willing to put in the time and effort stay out of the pool rather than pissing in it.

    Now how could someone new to Linux/UNIX possibly ruin it for you? At worst a nice hacker writes a useful interface for that person. No reason you have to use it. Yes, you could argue about open relays or some such thing, but that sort of thing has been going forever, even before UNIX became less macho. Either it happens in closed/unfixable Windows or it happens in Linux. I'd rather it happened in Linux, and making Linux friendly is the only way to accomplish that.

    --

  • Slackware was originally created because Patrick Volkerding couldn't get 386BSD working on his computer. So he took the time and created the basis of a truely UNIX based linux distrobution. It's a damn shame no one else seems to have followed his lead.

    I don't follow you. What's not UNIX-like about Red Hat, Debian or any other server/workstation distribution of Linux? Perhaps you meant "BSD based?"

    Slackware tarballs are still cross platform compatable to other unixes, or windows. Or at least far more than RPMs or DEBs.

    One can examine and unpack .debs with standard tools. Please see here [kitenet.net]. Yes, .deb is missing some functionality. But it does more and is more "cross platform" than most people realize.

    Slackware is a sourcefriendly distrobution that is rock solid from the bottom up.

    I'd argue that Debian is more source-friendly than Slackware because source packages are an integrated part of the distribution. That's a big part of what makes Debian Debian. Source is available for anything and it is trivial to download, build and install any package from source. The "build depends" field in .deb means that there shouldn't ever be a problem getting all the tools necessary to build it. Those complaining that Debian releases too slowly (they do, but it's for a good reason) can always build unstable source packages for their stable distribution. I don't think it's guaranteed to always work due to build-depends (tools from unstable may be needed), but it should work most of the time.

    With alien, I've had no trouble installing RPMs. I've never tried a .tgz, but I can't imagine it would be all that much different.

    It is not a wonder that it doesn't die, It is only a wonder that people don't take the time to think about seriously using it.

    No it isn't a wonder that more people don't use it. I'll agree with you that it's not a wonder it hasn't died. It will be around as long as it's useful to someone and with millions of people using Linux, the odds are pretty high that this will be the case for some time.

    Many people don't use it because they've realized that Debian provides everything Slackware does plus a lot more. I consider it the modern version of the great Slackware that saved us from SLS back in its heyday.

    Other people don't use it because they just don't care about building from source and use Red Hat or some other binary-focused distribution. Honestly, what's the difference between downloading source, compiling and installing and installing a binary package? It certainly isn't any more secure. It's only more work and takes time people could use to actually get something useful done.

    --

  • I fall under the same category as CmdrTaco and about half of all the people who posted in starting out on slackware. That would make a good poll, is finding out what distro people started out on, or tried first.
  • Eek! And I'm sitting here running it, too. How embarrassing.
  • he's not talking about an autoconf/automake system. Maybe you should pull your head out of your ass and . [slackware.com]
  • Even better, it's both!

    logan@mojo:~$ ls -l /var/adm
    lrwxrwxrwx 1 root root 3 Feb 16 22:06 /var/adm -> log/
  • by Anonymous Coward
    ... but certainly not for all newbies. Don't forget: the real glory of Free Software is that we're not stuck in someone's idea of one-size-fits-all.

    Newbie-friendly features of Slackware:

    • Setup is simple. Don't tell me that a point-and-click install routine is any easier than Slackware's. Everybody has a keyboard, and keyboards are far more standard than any kind of pointing device. They're not significantly more difficult to use, either.

      Slackware's setup walks you through it, step by step. But you can return to the main menu any time and redo earlier steps if you need to. (Advanced users can switch to tty2 or tty3 to run system commands, or to tty4 to see the syslogd output.)
    • Hardware problems are less likely to stop you. Chances are over 99% that there is a precompiled Slackware kernel which will work on your hardware. If you have a kernel which can access the Slackware CD, you can manually load modules from it to gain access to your target media.

      GUI install routines are pretty to look at, but they are much less likely to work. Any VGA-compatible system can run Slackware's setup.
    • Documentation is clear and readily available. There are many pages at the Slackware web site, most notably the Slackware Linux Essentials book, which present comprehensive information, in concise language which does not presume any prior knowledge of UNIX or GNU/Linux.
    • Fast, competent support is there for anyone with a Web browser. The Web-based Slackware Forums are a superb resource even for the completely clueless newbie. Even if you don't know how to formulate a coherent question, you will probably find help there. (Look me up there; I am a forum participant. I have had the satisfaction of having helped quite a number of beginners in using Slackware.)
    I began on Slackware 3.6 after a failed attempt at RedHat 5.0. RH failed because of a hardware problem, which I as a newbie could not figure out. I later used Mandrake 7.0 and have dabbled a bit with RH 7.0 too. But I remain with Slackware, because it better meets my needs. I am planning to install 8.0 ASAP.

    I don't have anything against the other distros. On the contrary, they are mostly fine products. Sometimes I recommend to certain beginners on the Forum that they try one of them instead of Slackware. If all you want is to get up and running with a GUI and typical user software without any trouble, other distros are more likely to meet your needs.

    Slackware is for techies, geeks. If you want to know how and why it works, and if you don't mind getting your virtual hands dirty editing configuration files, you might find Slackware to your liking. Slackware won't get in your way or try to force you to conform to a certain way of doing things. If there's any part of Slackware you don't like, it's easy to change it.

    Note that many GNU/Linux beginners are technical people! By learning Slackware you will have skills which are applicable in any distro. You are not wasting your time learning distro-specific tools.

    /dev/rob0

    (I'm posting as an A.C. because I don't have a /. account; I seldom even read here. Come see me at the Slackware Forum [slackware.com].)

  • The problem is a packaging system that enforces the maintainers idea of dependencies. Yes, the maintainer may have built his RPM on a system with libfoo-1.1, but I have libfoo-1.0.8, because I've found libfoo-1.0.9 to be broken for me. And after I rip open the RPM and hand install the thing, I find it works perfectly fine with libfoo-1.0.8...

    True, this is a maintainer problem. The package in this case is buggy and needs to be fixed. Packages should only specify the bare minumum of dependecies. That's why we have dependencies like "glibc >= 2.0."

    Making every administrator specify dependencies is not the answer, though. Perhaps some way of incrementally modifying the dependecy structure of a package would be useful. Think "free software" for packages, but in a more automated fashion. As people learn what additional versions of things the package works with, they can be added to the specification.

    --

  • Before everyone comes down on me, I do think Slackware has one very important role. It is an excellent teaching tool. I'd encourage everyone new to Linux to try out Slackware in some way, either on a space machine, partition or before installing a more advanced distribution. Maintaining a Slack system really helps one to understand the UNIX Way and why things are they way they are. You'll also appreciate all the hard work packagers do to make your life simple.

    Don't underestimate the importance of Slackware in this role. I view it as critical.

    --

  • I then went to slackware, which i LOVE, because it is pure unix and not afraid of saying it.

    There's nothing "UNIX" about "hard to use!" Does no one remember why UNIX came about? It was a simplification of MULTICS, both in the kernel and in user space. The "everything is a file" paradigm was developed for the user. UNIX != unfriendly and there is no reason something has to be held back in the Dark Ages of the CLI to be UNIX. UNIX system vedors left the CLI as the sole interface years ago.

    UNIX == user friendly. Unfortunately, most of us still haven't realized it and cling to some overblown nostalgic view of the "good old days."

    As for your unfortunate Red Hat experience, it was my experience around Red Hat 5.0 that the packages just weren't well-maintained. I switched to Debian and never looked back. Don't judge a concept by its implementation.

    Also its good because its default setup of X never works properly (in my experience), so it almost FORCES the new user to figure out the command line before getting lazy with X.

    You can't be serious. The only thing worse would be a non-working sendmail.

    I agree that Slack is a great way to get under the hood and learn a few things. I'd encourage anyone interested in Linux beyond day-to-day use to install Slack and have a go at maintaining it. But to get work done, go with a package-managed distribution.

    --

  • Dependencies should be up to the administrator, not up to the maintainers, because the maintainers will eventually get something wrong.

    Eh? This makes no sense at all. Why reproduce very hard work millions of times. Let one person intimately familiar with the software do it and validate the results. Yes, there will be bugs. That's why we do testing. With your strategy those bugs will be repeated millions of times and will be more frequent because there's no way an administration team can keep track of the dependecies of an entire system.

    I tried both Debian 2.0 and Debian 2.2 and the complexity level and rigidness level are on part with that of RPM-based distributions, only not as polished.

    What did you find rigid about Debian?

    Maybe it's better said like this: Slackware is the old-school sysadmin's distro!

    Ah, now I understand your viewpoint. I vigorously disagree with it, but I understand it. :)

    Living in the past is certainly fun and educational but it also has a tendency to close our minds to new ideas. This is not a personal criticism. I've heard this view expressed too many times in too many different contexts to be able to ignore it. Hell, I'm guilty of it myself (check the .sig).

    --

  • If RPM is so *gay* (what's wrong with being gay by the way?), why does:

    • Slackware include rpm
    • Slackware also include rpm2tgz (to convert rpms to tgz packages)

    Maybe it's because the slackware team recognizes the need to play well with other package formats on occasion?

  • Is a RPM version of Slackware even feasible?

    Sure...it's called Red Hat :P

    (For those interested in a history lesson, the original Red Hat was based on an early version of Slackware...could someone please post a URL with details about this?)

  • Maybe if you wait until it gets unslashdotted, you will have better luck.

    -E

  • FreeBSD doesn't do bleeding edge hardware very well, and while it runs *most* commercial Linux software programs, it by no means runs *all* commercial Linux software programs.

    I'll be evaluating Slackware 8.0 shortly. My current employer does a Linux-based product and right now we're based on Red Hat 6.2. RH62, though, is getting rather long of tooth. We need the stable 2.2 kernel (let the morons shoot themselves in the foot with 2.4, it'll still be a few months before 2.4 is stable enough for commercial use), so upgrading to Red Hat 7.1 is not an option.

    -E

  • Then you would discover that disk 29 out of 30 is bad.
  • by pedro ( 1613 )
    I've tried the others, but slack is *it* for me!<br>
    If I wanted to be a point and click monkey and use buggy, insecure software (cough! Redhat! Cough!) I'd be running windoze.<br>
    I'm starting to somewhat understand where all those *BSD bigots are coming from, having surveyed slack's competition. bleh.
  • Whatever happened to the MCC distribution? That was another old-time (i.e. pre-RedHat) distribution. I started with MCC, then went to Slackware, then to RedHat and then to Debian.
  • Let me first say that I LOVE SLACKWARE. I have never been able to set up another Linux box that I've been nearly as happy with as an "out of the box" Slack install. (Plus, you have to love the pipe smoking slack penguin; hail Bob.)

    For those of you fellow Slak people, I strongly reccommend that you check out FreeBSD.

    No, wait! Don't go! I'm not trolling.

    Slackware is, by far, the most BSD like Linux distro out there, and you will find many things to be very similar.

    For example, both are incredibly stable (degrees better than anything I can think of commercial or Free). Both are very stable development and "source friendly" systems. Both have an absolutely marvelous selected group of packages.

    Why try FreeBSD if both are so similar? Well, there are a couple of places where I think that FreeBSD outshines.

    Slackware's package management (yes, it does exist, and it works) is not as comprehensive as FreeBSD's. FreeBSD has a mechanism for automatically downloading source, compiling it, installing it, and registering it in the package db with one command(this is called the ports collection). For binary people, /stand/sysinstall with your installation source set to any official FreeBSD mirror is BRAINLESS to install new binary software packs, and it gets registered in the same place as the ports do.

    I guess it boils down to ease of use. FreeBSD is the easiest free Unix clone that I can think of. They made the system easy by design, not by abstraction with a gui installer.

    I'm teaching a short course for UNIX newbies at my university through our IT department. What am I using? FreeBSD. It's that easy, and it's got all the stability of really great distros like Slackware.


    -Peter

  • I don't claim to be a debian expert. All I know is that I went into the #debian IRC channel and asked, and people reacted very badly when I talked about upgrading my perl. They said it would break Potato up and down the block. I didn't try it, because I figured they knew what they were talking about.

    Slackware was easier, and it works, so that's what I did.
  • What are the new features? etc.....

    I guess we will have no bandwidth on the dsl line tommarrow with me downloading it....
  • Again, I think that you don't understand the way that package managers (or binary loaders) work.

    Package managers build the vast majority of their dependency information automatically. That is, if you download a package for mini-commander, and your package manager it depends on 12 things that you haven't got, it's not because the human packaging the software said so, it's because the package management software examined the binaries that were compiled and found those libraries to be required. And it will be *correct*. Forcing the install will not work because you will be missing libraries or symbols that are required, and the application will either crash "randomly" or not start up at all.

    The "options" you list are incorrect. You should never consider a forced install to be an option unless you understand *why* the dependency exists and are *sure* you don't need it. This is unlikely to be the case unless you are a developer yourself. You have an option that will both provide you a working package and maintain the accuracy of your package database. It's a source package. If, for instance, you had an i386.rpm file that wouldn't install because of missing dependencies, then you can get the src.rpm from the distributor of the i386.rpm file and rebuild it like this:
    rpm --rebuild mini-commander-0.4.2.src.rpm

    The package will be built, and an i386.rpm file will result. Having been built on your system, all of the dependencies will match what you have on your system, and you will be able to install it without forcing the install.

    The same things are true in reverse. That is, packagers can't compile against a "lowest version available", because in unstable packages the API changes. Compiling against an old version of a library would create a dependency on an old library, and objects or symbols may be missing on newer systems. Only when library interfaces are *stable* can you expect not to have this problem. Unfortunately, some of the libraries that GNOME applications (and it sure seems like you're talking about GNOME) don't have a stable API. Until they do, they will continue to be a headache for users. Don't blame the package managers. They aren't the problem. Distribution developers aren't doing this intentionally.
  • The only time I've ever had syskripple is when I was using Redhat during a year of insanity back in 1999. Since coming "back to Slack" the problems went away. Things do tend to work better in Slack even if the versions are a little mismatched. And I don't have to do battle with the package manager to get stuff updated the way I want. RPM tends to end up with a rigid web of package dependencies. Perhaps a lot of that is due to improperly built packages. In my last days of Redhat, I was just doing the force option on every install or upgrade to get things to work. And that made me realize that all RPM was giving me was the ability to quickly install lamely built packages without thinking about what I was doing. So I went "back to Slack".

  • I don't know about Debian because I never managed to get it installed (I hear they have a whole new installer now, so maybe it will work for me now). But I did try Redhat. Installing things from outside the package manager into /usr/local was not always an option. For one thing, you end up filling the system up with redundancies. And then all my truly local stuff gets buried on all the installed stuff and now I have to worry about my local development colliding with installed stuff. LHS needs to define yet another place for things like this. What I ended up having to do with RPM on Redhat was forcing the install. Things did work despite the force, but at that point I realized that the whole idea of having enforced dependecies, at least the way RPM was doing it with the way packages were made, wasn't really working right.

    So I am "back to Slack".

  • If upgrading OpenSSL breaks some other package, then something is wrong with the other package. In practice I found that package builders were making their dependencies too tight, and the end result was often an unsolvable equation because in many cases a newer package was even available. And as soon as you start installing from original source code, you end up with dangling dependecies in your RPM database. That's what happened with Redhat for me (I actually used Redhat for a little over a year). I used Slackware before then with no troubles, and after I went "back to Slack" my problems went away.

    I think the problem is more a case of badly built packages. RPM certainly helps you to deal with those to a point. But it also serves to hide the real problem in that packages built to depend to tightly on specific versions is bad. Sure, if package A depends on package B and you have a buggy version of package B you want to upgrade package B. But if that requires also upgrading package A, or some other package C that is dependent on a specific version of package B, then there is definitely something wrong with the other package. It might be in the packaging (too specific a dependency) or in the coding (author depends on bugs in the other package).

    If upgrading a package breaks another package that depends on it, I want to know what is wrong with the other package before I upgrade that one. I certainly do not want to be going around upgrading half my system just because I notched up the 2nd or even 3rd digit on a library. I shouldn't have to upgrade anything on account of that if the other packages were done right.

    But that's not the biggest reason I switched "back to Slack". That reason will be revealed later.

  • Slackware isn't for everyone. It is for me, but apparently not for you, whoever you are. I'm glad you found what you like. At least you aren't doing what some people do and ask "what distro should I use?".

  • One's choice of package management also depends on what they want to do. Clearly none of the choices is perfect for everyone.

    For my desktop machines, I could perhaps go either way. For my servers, I install all exposed services and other critical functions from original source code anyway. I script up the compile config and any modifications I make so if I need to quickly upgrade to keep SKs out of BOs I'm prepared. And if the BO isn't fixed in a new version, I can go fix it myself (done that before). Besides that, I prefer to keep servers as stable as possible. My "upgrades" are more a case of migrating services from an older server to a newer server. That's done to get the least disruption in service (a few seconds to cut over instead of a few hours to upgrade the same box, leaving time to fallback in the event something might not work in the new versions).

    Being as my servers are Slackware, I might as well just make my desktops the same.

  • Easy CD Creator probably installed an association with .ISO files; your friend should be able to just double click the image files.

    Alternative approach: Start Easy CD Creator; from the File menu, select Build CD From CD Image; change the image type from .CIF to .ISO (the least intuitive step); navigate until you find the image file.

    I've burned Red Hat 7.0 and 7.1 CD sets, and a SuSE 7.0 CD, this way. I think they were bootable.

    I've also burned CDs this way based on my own ISO images (created with mkisofs; Joliet, autorun on NT, plus Solaris package format), for versions 2.0 and 3.0 of the product I work on.

    This list of functions for Nero (Burning Rom) [ahead.de] leads me to believe it can do the same thing.
  • Case in point. I just finished compiling FreeBSD 4.3 and all my favorite packages. It has a very *nice* ports/packages systems.

    But it's still a package manager deep down. And has all of the disadvantages of a package manager. I installed XFree86-4.1, which includes freetype-2. But that's not good enough for other ports that need freetype-2. They want the freetype-2 port, and not the XFree86-2 port. So I eventually ended up with 2 freetype-2 installations that are identical in everyway except that one is under /usr/X11R6 and the other under /usr/local.

    The useless dependencies are still there. Yes, they're useless. You get much, much fewer dependencies building my hand than building through a package manager.

    For instance, Dia requires GNOME... Huh? Since when? If I used GNOME then I would like it compiled with extra GNOME flash built in, but if I don't use GNOME, that's 3 digits of megabytes I don't need.

    And why does Qt need mng when I've never seen an mng file in my life?

    (okay, enough ranting...)

    Yes, like Debian, I can tweak the sources and makefiles before building. But I'm building the entire system. I don't have the time to tweak fifty packages and get this all done over the weekend. So I ended up building a few of them directly from source, bypassing the ports system.

    I use both Slack and FreeBSD. I like the ports system, but I still find lots going for Patrick's simple tarballs and build scripts.
  • Did you even *READ* the previous post?!? cp and tar are NOT package installers. They do NOT keep track of what's installed. They do NOT uninstall packages for you. The only think Slackware lacks in way of package management is dependency tracking.

    Do you really believe that installpkg is merely an alias for 'tar xvfz'? Go check again.
  • Please inform me as to how RedHat is less secure than Slackware?

    Compare the length of the Redhat-7.1 errata to the Slackware-7.1 errata. For a REAL eye opener, compare the Redhat-7.0 errata to the Slackware-7.0 errata.

    I dearly love Open Source, but there's two major bad habits most Open Source developers have. First, they treat their customer base as their own personal SQA department. Second, they think that an entry in an errata counts as security.
  • Wow! It looks like you haven't seen Slackware for a very long time then!

    modern graphical interfaces

    KDE-2.1.2, GNOME-1.4, XFree86-4.1.0. How much more modern can you get than that?

    an easy way to install

    The second easiest install I have ever done was Slackware-7.1. The first was DOS-3.3. The worst was Corel LinuxOS-1.0. Second worst was Mandrake-7.0.

    An easy install is much, much more than pretty pictures and icons to click on. An easy install is organized, minimal, fast and error free. If all you can do is one-finger hunt-and-peck typing, and on a mouse at that, then perhaps you should simply stay away from any variety of Unix.

    and configure devices

    Okay, configuring ISA-PNP soundcards on Slackware requires a few brain cells to do.

    I'll grant you this one. But may I suggest, at least, that you learn how to configure those devices by hand anyway? A little bit of knowledge never hurt anyone, but saved quite a few butts along the way.

    a package system to install/uninstall softwares

    installpkg, removepkg, pkgtool. And if you want a GUI, use kpackage.
  • For those of you fellow Slak people, I strongly reccommend that you check out FreeBSD.

    Yeah, I checked it out. And that's what I'm using now!

    But I still have Slackware around. And when 8.0 comes in on the autoship, I'll be upgrading to that. I dual boot, but I don't dual boot Windows.
  • Please inform me as to how RedHat is less secure than Slackware? RedHat has a nice "errata" section where you can download all the RPMS for bugfixes on assorted non-RedHat daemons such as lpd, bind, apache, etc...

    Just because RedHat post all the security advisories and offer patches doesn't mean they are less secure than another distro who uses the same daemons but yet does not post security any advisories.

  • I'm not trying to start anything, I swear. Slack is my favorite Linux distro; I have it on 3 boxes at home and a monitoring box at work. I've been rsyncing to slackware-current for the last few months. I love it.

    .. but one thing I wish (and i know; if you want it write it your damn self) is it had the option of doing BSD-style or SVR4-style init scripts. I use 'real' Unices in my day job (HP-UX in the last one, Tru64 & IRIX in the current one) and all three used a SVr4-style init script structure. You know 'service '. A control system such as this simplifies life for tasks such as service restarting, service starts at boot, etc. NFS is a prime example; it gets old SIGTERMing mountd & nfsd for /etc/export changes (and despite what the docs or anyone says, you're hit-or-miss if you simply try SIGHUP). My point; while pretty much every Unix has both BSD & SVr4 conventions in it, the SVR4 seems to win out in daemon control and some other basic operation.

    .. and yes, I know Slack can fake it with an /etc/rc.d/rc.(initlevel)-type directory structure. Maybe some simply prefer the kill-level control of mucking with each daemon. It would just be more handy for me if Slack has some type of support for this out of the box.

    (ok, I'll just shut up write my scripts, lazy bastard that I am. Just my $0.02).

  • Honestly, what's the difference between downloading source, compiling and installing and installing a binary package?

    Here's a biggie: it lets one optimise the code for one's chip. A lot of stuff is still be compiled for the 386. I've an Athlon--why not compile my stuff for something used in this millenium? I just set my CFLAGS in my .bash_profile, and everything's fine from there on out.

  • GUI install routines are pretty to look at, but they are much less likely to work. Any VGA-compatible system can run Slackware's setup.


    First time I installed slackware on one of my computers, I didn't even have VGA. All the equipment I had to spare was a 386-40 and a CGA card with an EGA monitor. Needless to say, I wasn't running X. But I was able to install slack 3.0 on it without a fuss and promptly purchased some newer hardware to take advantage of the OS. This was early 1998.

    -Restil
  • Well, I still use some old 486's with 8 meg of ram around here, mostly for controllers. Since I don't even have a monitor on these systems, let alone X, I don't require a significant portion of the distribution. I've gotten a functional 3.6 slackware installation on one of these systems with an 85 meg HD, and I still have enough room left over for some small programs and to do a kernel compile.

    Of course, since that release meets my needs in that case 100%, I've never even considered installing anything later. I've got 7.0 installed on my main box though.

    -Restil
  • When I first decided to try SuSE, that's what I thought. That's in fact why I tried it. I had tried Red Hat and Debian, and both were lacking *something* that I couldn't actually put my finger on.

    I later learned the somewhat full history:

    - They packaged a German SLS
    - They moved to German Slackware
    - They hired Florian LaRoche, who had a distro called Jurix, which used tgz for packages
    - They made a new distro from, essentially, scratch and decided to use RPM for the package format but still supported tgz (they do to this day). Interestingly enough, this new, "SuSE" distro (first version: 4.2) had quite a resemblance, in some respects, to HPUX. I found this out when a couple of HPUX guys were hired at my work and took to SuSE like fish to water.

    Nowadays, SuSE also supports deb and apt as well. There were a couple of threads on the suse-linux-e list about going totally deb, but I doubt that will happen, especially where RPM is required for the LSB.

    Another interesting tidbit: The first version of YaST (Yet another Setup Tool) was 0.42. The installer for 7.2 has an easter egg as a tribute to the late Douglas Adams.

    To get back to the Slackware thing... Yes, a lot of SuSE users are ex-Slackware freaks, myself included, that hated Red Hat. Nowadays though, more people convert from Red Hat
  • Find an rsync mirror, rsync your ISO to the latest. Can save a loooooooooooooot of bandwidth.
    --
    mysql> DELETE FROM world.human_race WHERE iq < 100;
  • It's pretty likely that his 486 had a non-functional Turbo button. I think he brought it up because do-nothing Turbo buttons and little LEDs that told you the CPU speed are classic bits of old skool PC cheeze.
    There was even a computer I ran across once that had a "MIPS meter" on it...instead of the two- or three-digit clock-speed display, it counted instruction fetches (usually available from a pin on the processor) and displayed that information. With most processors carrying a significant amount of cache today, though, you probably couldn't do this now.

    I don't remember who did this, though. I don't think it was one of the major manufacturers...certainly not an IBM or Compaq. I don't think it was something you'd find at the average screwdriver shop, however.

  • I started with MCC, went to SLS, because all the docs seemed to assume you were running SLS. When SLS died I moved to Slackware. I think I cut over to RedHat around version 4, and jumped to Debian when RH broke the compiler. Somewhere in the middle of that I played with SuSE a little.

    I started with SLS eons ago...probably stuck with it longer than most, well into the "Slackware era." I even had a BBS (with some gateway software between smail, cnews, and the local Fidonet) running on it for a time, on a 386SX-25 with 4 megs of RAM and 120 megs of disk. Eventually I moved to Slackware, then to SuSE when a somewhat long-running Slackware setup got eaten by some code I'd written which tried to malloc() way too much memory (hosed the filesystem somehow...maybe the swap was misconfigured). I run LFS on my home server nowadays, but I keep SuSE on other people's systems.

    I used to have a bunch of 5.25" floppies with SLS in a three-ring binder (the thing that kept me away from Slackware for a long time was that it was only installable from 3.5" floppies, which my machine didn't accept). I suspect they were tossed out before the last move, though.

  • You are referring to SuSE. Sorry, no URLs, but I guess googling might help.
    Search here [google.com]
  • Excuse me, I should re-iterate, a more potent graphical package tool is in development. There is a package tool out there, and it is incredibly easy to use, and efficient. Its 10:30 after a very very late coding run.

    these mistakes can happen :-p

    Long Live Slackware!
  • Hmmm... I can't view the changelog right now because the ftp server is full, however I read the other day that 8.0 is using GCC 2.95.3 and GNU Libc 2.2.3. I hope this isn't correct, because there is a serious incompatibility with these two where the libc_nonshared.a library does not get compiled into programs in some situations.

    This breaks all sorts of things and you will have a hell of a time getting things working when you build them. I think there may be patches that fix this, but I dunno. GCC 3.0 doesn't have this problem.

    If I'm right about that, I'd seriously doubt that the slack guys haven't done something to correct it, as every version of slack I've ever used has been extremely well put together.


  • Someone else mentioned that it's got GCC 3.0. Alas, I can't verify this anymore than you can at the moment, what with the entire /.ed slackware domain...

    On a side note, I thought I read that GCC 3.0 actually can't compile glibc... if this is true, how did the Slackware folks do it? :P

  • My main complaint about modern package management systems and dependencies is the fact that modern distributions always want the latest and greatest software, regardless of whether the older stuff still works fine or not.

    As a fictitious but relevant example, let's say it's 2003 and I have Mandrake 7.2 on my desktop. There's a new version of Mini-Commander that has a feature I can't live without, so I get the RPM. When I go to install it, the RPM cites about 12 packages that need updating. And then *those* packages have their own set of things that need newer version.

    Mini-Commander would probably compile and/or run just fine with any old version of those packages, but the people who built the distribution picked the newest versions versions available and listed them as dependencies in the .spec file.

    The only options I have are to try forcing the install (which might work and which *will* result in broken dependencies in the RPM database) or to compile from source. Both options lead to inconsistencies in the RPM data relative to what's actually on my disk.

    Now, if the person who *created* the package would have simply compiled Mini-Commander against the lowest versions of dependency packages possible (while still retaining all functionality), then there would be no problem such as this. I have actually come to the conclusion that distribution developers do this intentionally to keep people buying every new release.

    It's enough to make me want to switch to FreeBSD.

  • Would someone mirror at least the ANNOUNCE and ChangeLog? The entire slackware domain is now officially /.ed.
  • A friend in another country wants to try Linux. I pointed him to where he could download the ISO's for SlackWare and Mandrake (shipping would take a long time for him, but he has a good net connection).

    He doesn't have an existing Linux installation yet so he can't use cdrecord to make his bootable ISO9660 CD's. Are either Easy CD Creator or Nero for Windows capable of burning the bootable Linux iso images correctly?

    The reason I'm concerned is that when Win98 scragged my laptop I got the ISO for tomsrtbt [toms.net] and tried to burn it with Toast on a Macintosh, and it wouldn't boot. Toast didn't seem to understand the ISO format tomsrtbt's image used.


    Mike [goingware.com]

  • This can be taken as either a cut or a compliment, depending on your own partisan tendencies, but I love Slackware precisely _because_ of its simpler package handling and its closeness to a BSD-style system. I've run Slackware boxen when requiring Linux boxen amidst *BSD boxen, and the admins have lots easier time adjusting to its ways of doing things.
  • I don't think Taco meant that Slackware was worthless and should be put out to pasture. I think he was referring to the fact that its still around, despite others (RedHat, Debian, etc) that have exploded in popularity. If anything I think Taco was praising the fact that Slackware has been able to survive for as long as it has.
  • Did you know "turbo" buttons on computers actually do the opposite of what you might think they do? Yes, "turbo" buttons are meant to slow down your computer! In all honesty. Infact, here's a reference regarding it: http://www.pcguide.com/ref/case/switchTurbo-c.html [pcguide.com]
  • Toast burns bootable Slackware .iso files just fine. I've burned 7.1 with it and it boots on any BIOS that supports El Torito (?) booting.

  • Slackware Package Management [slackware.com]

    I find it works pretty well actually.

  • I just love the tarball package system !

    Four simple steps :
    tar xzf file.tgz
    ./configure
    make
    make install

    Done. Could it be any easier ? ;)

  • you really want to push Linux... send new users to a user-friendly distro. Not Slackware.
    So, in order to push Linux, you think we need "Windoes" looking clones? Or gay RPM packages? If you want to push Linux, you should introduce people to an Operating System that requires people to think for themselves. Slackware is where I started, and from there moved to BSD and Solaris. I doubt I would know HALF what I know now, if I was dumbed down by Redhat or Mandrake. Not that these are good Operating Systems, but they don't rank anywhere near Slackware. Shit, I can't even get anything to compile on RH7.1 without some gay RPM to throw at it.
    Fuck them if they can't take a joke - J.R. "Bob" Dobbs
  • Slackware is what Debian should have been.

    Debian is the Red Hat of source-friendly distributions, if you will. Too much cruft. Dependencies should be up to the administrator, not up to the maintainers, because the maintainers will eventually get something wrong. All of the source is included with Slackware as well, only as nice vanilla .tgz files like they ought to be, butt naked like when they were born.

    I tried both Debian 2.0 and Debian 2.2 and the complexity level and rigidness level are on part with that of RPM-based distributions, only not as polished.

    Maybe it's better said like this: Slackware is the old-school sysadmin's distro!
  • YOUR SYSTEM, THOUGH LACKING A PACKAGE MANAGER, STILL HAS DEPENDENCIES!!!


    Yes, and when you don't have a package manager to f*ck with you can resolve them YOURSELF, using HUMAN intelligence! You can install MULTIPLE VERSIONS of software in MULTIPLE LOCATIONS and then using the shell/scripting/administrative capabilities that made Unix so great to begin with, you can automatically select between them on a per-application, as-needed basis.

    With so-called "package management" if you install a new version, the old one's got to go. No good. No good. Every time I've used Debian or an RPM-based system, I end up with EVERY LAST DAMN THING in the system in the /usr/local tree because I've compiled it myself as way to get around the versioning and dependencies in package management.

    Of course then you're screwed because eventually your package database doesn't match what you're really using on a day-to-day basis. Then you buy a commercial application, it detects that you're using a package-based system, and installs something based on what it sees in your package database -- which then doesn't work because you gave up on keeping a current package database long ago.

    Package management gets in the way of a competent system administrator's day.
  • ...I like modern OSes, with modern graphical interfaces...more like Mandrake 8.0 than Slackware 8.0...


    Um, Slackware 8 comes with KDE 2.1.2, Gnome 1.4 and XFree86 4.1.0. Whose GUI is modern, now?
  • I have to recognize that Slackware has actually a particular status in my hearth because it's the Linux distro that made me discover Linux. Back in '95, it was already a full Linux distro, with most of the tools a Unix user could expect to program in C/C++, use LaTeX and so on. Anyway, times have changed and I wouldn't use Slackware anymore because I like modern OSes, with modern graphical interfaces, an easy way to install and configure devices and also a package system to install/uninstall softwares. That's the reason why I think a modern Linux distro looks more like Mandrake 8.0 than Slackware 8.0. Anyway, keep on the good work, there will always be some plain-old-Unix nostalgics to use Slack! :-)
  • Using Easy CD creator (3.5c), when you get click the burn CD button you get a Setup dialog. Click the Advanced tab, change the option to Disk-at-Once. Almost always makes a bootable CD from an ISO with that kind of setup.
  • Of course Slackware is for newbies. I, like probably the majority of people here, started out on Slackware, on a veritable s***box of a PC (486SX/4Mb RAM/120Mb HDD/14.4k modem) downloading floppy sets off the net. That was my first experience with *nix, and damn I liked it! Slackware has probably done more for getting people into Linux than anything else (including all this media hype of the last few years). --Chris
  • Try here [sourceforge.net] for the changelog since the one up top seems to be overused. I was going to include the changes in the post but "Lameness filter encountered. Post aborted."

    now they tell me that "Easy does it! This comment has been submitted already, 276111 hours , 11 minutes ago. No need to try again.

  • The md5sums for the ISOs are as follows: 363b762630bc95a1b5d8e330585679f0 install.iso 8ba63550935c9e64e45b6a84ec0b5528 extra.iso These were verified by another user on the Slackware forum, so they should be correct. I haven't completed my download of source.iso, so I can't say for that one. Good luck.
  • I mirrored install.iso on ftp://galileo.luon.net/pub/install.iso . It's a mirror in the Netherlands, so it's probably only useful for europeans. The server has a 100mbit inet connection, so: do your worst!

    ----
  • Ditto. My first Linux was a Slackware, too. A co-worker did the gruntwork of downloading the floppy images, and after he was don with them, I borrowed the floppies and installed slackware on my 486DX 66, with a turbo button. I think I had a 340 MB hard drive, and I used 140 for Win3.1 and 200 for Linux. Those were the days.
  • If you had bothered to read the Changelog, you would know that Slackware _IS_ glibc based.

    a1/glibcso.tgz: Upgraded to glibc-2.2.3.

    --
  • Slackware is a sourcefriendly distrobution that is rock solid from the bottom up.

    Amen. Could not have said it better myself.

    I also like Pat Volkerding's attitude. He gives "it works and it works damn good" a higher priority than "everyone else is doing it, so should we".

    While each distribution has its own flavour, Slackware is really another category of food all by itself.

    And indeed, source friendly. Truly amazing how many open source zealots critizise Slackware because the preferred way of doing things is compiling source instead of copying binaries. :-)

  • by MentlFlos ( 7345 ) on Sunday July 01, 2001 @06:32AM (#116940)
    I'm work'n on grabb'n the isos

    then I'll mount the isos so people can pick thru them and grab individual files

    ftp over to hedwig.meatbarn.com (anonymous)

    I just threw a quick dir structure in there so as I add files it won't get too ugly.

    The only thing is I'm still downloading myself, so when the file size gets to 670138368 bytes, I'm done.

    I will then test and make an md5. I wonder if I can be an official slack mirror... hmmm :)

    -paul
    -------------------------------------
    The art of flying is throwing yourself at the ground...
  • by astrashe ( 7452 ) on Sunday July 01, 2001 @06:16AM (#116941) Journal
    I've wondered that myself. That's certainly a big name from the past. I used to install it from floppies on a 386sx with a 20MB hard disk. I'm pretty sure it was from Manchester, in the UK, and that a prof rolled his own distro to roll out machines for a class he was teaching.

    I started with MCC, went to SLS, because all the docs seemed to assume you were running SLS. When SLS died I moved to Slackware. I think I cut over to RedHat around version 4, and jumped to Debian when RH broke the compiler. Somewhere in the middle of that I played with SuSE a little.

    I think it was more fun in those days. There was something cool about having to roll a new kernel just to get your ethernet card working. Although there wasn't anything cool about having to do X configuration by hand.
  • by mihalis ( 28146 ) on Sunday July 01, 2001 @07:16AM (#116942) Homepage
    If that's what you like, then you'll love Slackware 8.0, however it sounds like you'll never know since you're acting as if it hadn't changed in six years.
  • by Restil ( 31903 ) on Sunday July 01, 2001 @08:44AM (#116943) Homepage
    Ok... was it REALLY released this time or is this just another overreaction to a directory name on an ftp server? :)

    -Restil
  • by be-fan ( 61476 ) on Sunday July 01, 2001 @07:09AM (#116944)
    Apparently nobody has looked at the latest packages listings. Slackware used to stay behind the curve before 4.0, but ever since then, its kept right up. 8.0 even includes GCC 3.0!

  • Once you save your tagfiles, it's an unintended install

    An unintended install? Whoops, I didn't mean to installed Slackware 8.0, it just happened! Honest!

    But.. hmmm... hey, this operating system ain't so bad....
  • by goingware ( 85213 ) on Sunday July 01, 2001 @09:10AM (#116946) Homepage
    I've been using SlackWare continuously for years. Unlike many people who started out with it and moved on, I started with Yggdrasil and moved to slackware at the recommendation of a friend, using it since 3.2 or so on a 33 Mhz 386.

    Now I use it on my laptop [goingware.com] and on my desktop PC [goingware.com].

    I tried out Debian PPC on my Macintosh, and while it was nice to be able to run an install over the Internet, Debian was much harder to install than SlackWare. One thing that turned me off of debian was that after installing the full X11 package, debian enabled XDM - but this was before X actually was gotten to work on my system (the ADB mouse was frozen) so doing an apt-get made it impossible for me to actually log in to my computer. It really sucked undoing the damage that Debian's X11 maintainer did to my PPC system.

    If you're running Slack 7.1 or earlier, a real good reason to update is that 7.1 comes with GCC 2.91.66. This version of GCC has a bug in the C++ parser that makes it emit an error for a certain piece of legitimate C++ code a friend wrote. I was able to FTP several packages off of ftp.slackware.com [slackware.com] out of SlackWare-current and get gcc 2.95.3, which fixed the bug.

    As for Slack not having package management, I don't know what you're talking about, I use pkgtool, installpkg and removepkg all the time to manage packages on my systems. If you have a bug, you can always try getting the pre-release packages for later versions of the software from slackware-current.

    One nice thing you can do is download the source to a package off of the Slackware FTP site (or get it off the source CD), then get a later version of the source from the project's home FTP or CVS server, and use the scripts provided by Patrick to make a slackware package of some hot-off-the-presses code.

    One project I have in mind is to build my own Slackware distribution, using the sources provided on a CD, except that I'd select Pentium III optimization in all the GCC command lines. If you do this with everything but the static libs that go into the distribution library directories, your system should run faster.

    Note that I'm not a complete Slackware zealot. I can run through a Slackware install or upgrade pretty quickly, but it took me a while to figure out how to do it right. Recently when a colleague said he wanted to try Linux, I recommended he use Mandrake, but encouraged him to use Slackware for production systems.


    Mike [goingware.com]

  • by frknfrk ( 127417 ) on Sunday July 01, 2001 @07:42AM (#116947) Homepage
    the thing i have been loving about slackware-current is the nice 2.4.5 kernels with reiserfs already built in. this means i could install a 2.4.5 kernel and all reiserfs-only on my machine and go from there. way to go pat! where's my 'order this CD' button? oh yeah, it's at store.slackware.com [slackware.com].
  • by small_dick ( 127697 ) on Sunday July 01, 2001 @08:19AM (#116948)
    ...anymore than cp and tar are 'package management tools'.

    whether anyone 'likes it' or not, the foremost package manager out there is debian's 'apt' and deb packaging system. it just plain works, keeping track of interdependencies and not leaving your system in a corrupt, useless state.

    next in line is rpm, but as everyone knows, redhat has done a horrific job managing the s/w (rpm versions of package and rpm itself) that has really degraded the quality of the system. even worse, the 'rpm drift' between mandrake and redhat at rpmfind.net has made looking for anything but official packages useless. of course, deb doesn't really have alternate distros, so i assume it would have a similar drift problem were it in the same circumstance.

    people need update capability that don't kill their machine. your 'package management system' does not meet that criteria, so I can only conclude that slack is a 3rd tier distro, unless you simply hold it stable between releases.

    i've seen apt and rpm blow up and leave a system unable to launch X. nothing is perfect. but this is due to a fault of the pacakges or the code, not the user (unless they are 'forcing' installs).

    with the setup or installpkg, the error domain goes right back out to root space. you better know what you are doing, and with thousands of packages available, it is unthinkable and ridiculous to expect an admin to know all the interdependencies of the libs/scripts/bins.




    Treatment, not tyranny. End the drug war and free our American POWs.
  • by BetaJim ( 140649 ) on Sunday July 01, 2001 @06:15AM (#116949)
    I use slackware and compile most things from source. I have found a very helpful tool which will manage versioning of programs compiled from source: encap [uiuc.edu]

    To use it create a directory, say /usr/local/encap/, and when you run ./configure set the prefix to /usr/local/encap/packagename-1.2.3. After running make install go to /usr/local/encap/ and run epkg to install sym-links under /usr/local to your program.

    Check it out, it is a very good system. It becomes very easy to uninstall a package and also see what packages are installed. I highly recommend it!

  • by afinlay ( 225703 ) on Sunday July 01, 2001 @07:03AM (#116950)
    Here's the list of new features:

    ftp://ftp.slackware.com/pub/slackware/slackware-8. 0/ANNOUNCE.txt [slackware.com]

    Those are the release notes, easier to read then the ChangeLog.
  • by account_deleted ( 4530225 ) on Sunday July 01, 2001 @06:35AM (#116951)
    Comment removed based on user account deletion
  • by fredlwm ( 146021 ) on Sunday July 01, 2001 @05:47AM (#116952) Homepage
    http://store.slackware.com/ [slackware.com] and support the Slackware project.
  • by astrashe ( 7452 ) on Sunday July 01, 2001 @06:07AM (#116953) Journal
    Taco's comments make it seem as if Slackware is a kind of museum piece, relevant only as a historical artifact.

    But in my opinion if you want a distro to run a specific kind of server (like a name server, or even a data driven web server), and you want to build your own software and not depend on someone else's packages, Slackware is still hard to beat.

    Let's say you're running Potato, and you need SSL and Apache. The latest Apache needs a certain version of the SSL module. The SSL module needs the latest Perl to compile. But you can't upgrade your Perl because it's tied into everything Potato in your distro. Sure, you can install debs with Apache/SSL, but what if you need other stuff too?

    Package management is a wonderful thing, but it does have some drawbacks. It's not the best way to go in every circumstance. Luckily, we have Slackware for those times.

  • by MSG ( 12810 ) on Sunday July 01, 2001 @09:27AM (#116954)
    But you can't upgrade your Perl because it's tied into everything Potato in your distro.

    Comments like this display a serious lack of understanding about package management.

    Perl isn't a good example for this one, because the only thing that's *really* going to depend on a specific version of Perl is Perl modules, but we know where you're going with this.

    Lets say instead that you needed to upgrade to a newer version of OpenSSL, because... oh, I dunno, maybe mod_ssl complains that yours is buggy. With a package manager, you would get the packages for apache, mod_ssl, and the newer OpenSSL, and tell it to update everything. If anything depended on that specific version of OpenSSL, the package manager would tell you so that you could update those packages as well, and avoid breaking your sytem. If your system lacks package management, then you would probably go right ahead and compile and update apache, mod_ssl, and OpenSSL. But, guess what?

    YOUR SYSTEM, THOUGH LACKING A PACKAGE MANAGER, STILL HAS DEPENDENCIES!!!

    That's right. The system with a package manager warned you what you were going to break to stop you from breaking them. The system without the package manager let you break them without any warning, and now all of the same packages that you would have been warned about are totally FUCKED. The lack of a package manager hasn't saved you any work. You STILL have to update every one of them. The difference is that you won't *know* that you need to update them until you see them break. That can be a serious problem. How do you fix a server in a remote location when you just upgraded openssl and SCREWED ssh?

    There may be times when package management seems like a pain in the ass, but the alternative is *so* much worse.
  • If there is one thing I do not understand, is the neverending wave of criticism often dealt out to slackware linux. Either it is attacked for its lack of a package management system, or it is attacked for not being a modern OS, or whathave you.

    First and foremost, Slackware linux was never intended to be a 'modern' operating system. It was not intended to follow the broken precident that Microsoft established for operating systems, which is that of bleeding edge dysfunctionality due to attempts at convenience. It was intended to follow the UNIX model of an operating system, more specifically the BSD model. Slackware was originally created because Patrick Volkerding couldn't get 386BSD working on his computer. So he took the time and created the basis of a truely UNIX based linux distrobution. It's a damn shame no one else seems to have followed his lead.

    Also, another point: does anyone remember the early glibc nightmares, when redhat would break half the time? I never had that problem on my personal box, because the people at slackware waited until a more stable release came out. I have yet to use a more stable release of linux, having used a good 5 different distros since I have started my linux career back in 94. I never, and repeat -never- have had to deal with any eath shattering flaw out of a stable release of slackware. And it is considerably more secure out of the box than most other distrobutions I have useds.

    To address the issue of packages; there is a package tool in development. And development is taking its time, to make sure a stable product is publicly released to the masses. And when it comes down to it, there is still no easier way to deal with source code than the tarbal. It is the one step short of having a CVS tree. Since source is the fundamental element of the GNU revolution,
    it must be payed attention to, and Slackware certainly does. Sources are apart of every distrobution. And do you know something? Slackware tarballs are still cross platform compatable to other unixes, or windows. Or at least far more than RPMs or DEBs.

    Slackware is a sourcefriendly distrobution that is rock solid from the bottom up. It is not a wonder that it doesn't die, It is only a wonder that people don't take the time to think about seriously using it.
  • I used Slackware for the first time around '93 because it was the simplest to download and install at the time (using a whole stack of floppies). Red Hat hadn't happened yet and X was very cool just being X, no need for integrated API's like KDE and Gnome.

    I left Slackware around 4.0 because I wanted the new "glibc" goodness and I couldn't figure out why Patrick wasn't including it. Unfortunately, I soon found out as I fought Red Hat 5.0 for several months. Since then on my personal box I've used Red Hat 5.1, OpenLinux 1.3 (gave up on "glibc" for a while thanks to Red Hat), Debian 2.0, OpenLinux 2.4, Debian 2.2 and Red Hat 7.1. Last night I downloaded Slack 8.0 (the hard way, ISOs weren't out yet) and re-installed it again to replace Red Hat 7.1.

    Slackware is as great as EVER! Very stable, nice BSD-like setup with lovely non-spaghetti init scripts, a *working* KDE 2.1.x/Gnome 1.4 setup, X 4.1.0 without having to kludge it in by hand (what's with Red Hat mixing 4.x with the 3.x servers in the same installation?!), and all of the great stuff that nobody else seems to bother to include (Netatalk! XView! fortune!)

    And it doesn't try to configure EVERY LAST DAMN THING during the install process. Red Hat 7.1 takes six years to install because it tries to configure things in "anaconda" -- but it's wasted time because you just have to go back and "fix" all of those automatic configs anyway to get them like you like them. Slackware installs it and then leaves it alone so that you can get it right the first time. For example I get to run "X -configure" or "xf86config" myself rather than having to fight some default setup that didn't really work anyway.

    And even the installer itself is sheer heaven -- same simple stuff. Boot in, run fdisk then setup, where you make your own tagfiles to select on a package-by-package basis what goes in and what doesn't. Then, you start it off and it runs, no graphics, no having to click-click-click... In short, no shit. Once you save your tagfiles, it's an unintended install, and on as many machines as you want, even on machines without XFree86 or VGA-compatible graphics hardware.

    Way to go, Patrick! Slackware still is and will always be the Linux for Unix users. No showstoppers, packages without the strictness of .rpm or .deb, "technical" purity and simplicity! I don't know why I ever left, and I won't leave again as long as it's available. I'm going to go and buy the CD now to support the effort.

    Slackware: old school feel, new school gear.

The means-and-ends moralists, or non-doers, always end up on their ends without any means. -- Saul Alinsky

Working...