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.
Re:Slackware and RPM (Was Re:Slackware position) (Score:1)
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...
Slackware (Score:1)
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.
Re:Bah. kids these days. (Score:1)
Re:Since when is Slackware old? (Score:1)
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 !
8.0? what about 7.2? (Score:1)
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
Re:Slackware (Score:1)
Re:Really this time? (Score:1)
--
Re:Yay! (Score:1)
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.
--
Re:I hate Slackware advocates (Score:1)
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."
--
Re:The Neverending wave of criticism of slackware. (Score:1)
--
Re:I hate Slackware advocates (Score:1)
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. :)
--
Re:The Neverending wave of criticism of slackware. (Score:1)
The problem there is mixing packages from two independent, non-cooperating vendors, not packaging per se.
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!
Packaging systems in no way prevent that.
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.
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.
--
Re:that's not package management (Score:1)
Exactly right.
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.
--
Re:The Neverending wave of criticism of slackware. (Score:1)
You are absolutely correct. Debian supports this in a primitive way with the "provides" field.
--
Re:The Neverending wave of criticism of slackware. (Score:1)
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. :)
--
Re:I hate Slackware advocates (Score:1)
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?"
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.
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.
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.
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.
--
Re:The Neverending wave of criticism of slackware. (Score:1)
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?"
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.
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.
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.
--
Slackware at heart (Score:1)
Re:8.0? what about 7.2? (Score:1)
Re:Slackware (Score:1)
Re:Minor correction (Score:1)
logan@mojo:~$ ls -l
lrwxrwxrwx 1 root root 3 Feb 16 22:06
Slackware is for newbies ... (Score:2)
Newbie-friendly features of Slackware:
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.)
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.
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.
(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].)
Re:The Neverending wave of criticism of slackware. (Score:2)
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.
--
Addendum (Score:2)
Don't underestimate the importance of Slackware in this role. I view it as critical.
--
Re:I hate Slackware advocates (Score:2)
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.
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.
--
Re:The Neverending wave of criticism of slackware. (Score:2)
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.
What did you find rigid about Debian?
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).
--
Re:I hate Slackware advocates (Score:2)
Maybe it's because the slackware team recognizes the need to play well with other package formats on occasion?
Re:Slackware and RPM (Was Re:Slackware position) (Score:2)
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?)
It's slashdotted, dude! (Score:2)
-E
Driver and software issues (Score:2)
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
Re:MCC anyone? (Score:2)
YES! (Score:2)
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.
MCC anyone? (Score:2)
For fans of Slak (I am) try FreeBSD too. (Score:2)
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,
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
Re:Back in the day? (Score:2)
Slackware was easier, and it works, so that's what I did.
New? (Score:2)
I guess we will have no bandwidth on the dsl line tommarrow with me downloading it....
Re:Back in the day? (Score:2)
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.
Re:Back in the day? (Score:2)
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".
Re:Back in the day? (Score:2)
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".
Re:Back in the day? (Score:2)
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.
Re:It's not my favorite distro (Score:2)
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?".
Re:Slackware's package management (Score:2)
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.
Re:Burning Slack ISO's on Windoze? (Score:2)
Alternative approach: Start Easy CD Creator; from the File menu, select Build CD From CD Image; change the image type from
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.
Re:Back in the day? (Score:2)
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
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.
Re:that's not package management (Score:2)
Do you really believe that installpkg is merely an alias for 'tar xvfz'? Go check again.
Re:YES! (Score:2)
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.
Re:Slackware position (Score:2)
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.
Re:For fans of Slak (I am) try FreeBSD too. (Score:2)
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.
Re:YES! (Score:2)
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.
Semi-OT; Why is everyone so pro-BSD? (Score:2)
(ok, I'll just shut up write my scripts, lazy bastard that I am. Just my $0.02).
Re:The Neverending wave of criticism of slackware. (Score:2)
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.
Re:Slackware is for newbies ... (Score:2)
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
Re:Slackware on old hardware (Score:2)
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
Re:As far as I know... (Score:2)
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
Use rsync (Score:2)
--
mysql> DELETE FROM world.human_race WHERE iq < 100;
Re:Slackware (Score:2)
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.
Re:MCC anyone? (Score:2)
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.
Re:Slackware and RPM (Was Re:Slackware position) (Score:2)
Search here [google.com]
Re:The Neverending wave of criticism of slackware. (Score:2)
these mistakes can happen
Long Live Slackware!
gcc and libc??? (Score:2)
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.
Re:gcc and libc??? (Score:2)
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
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?
Re:Back in the day? (Score:2)
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
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.
Re:changes (Score:2)
Would someone mirror at least the ANNOUNCE and ChangeLog? The entire slackware domain is now officially
Burning Slack ISO's on Windoze? (Score:2)
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]
Slackware: The FreeBSD of Linuxen (Score:2)
Woah, Calm Down! (Score:2)
Re:Slackware (Score:2)
Re:Burning Slack ISO's on Windoze? (Score:2)
Re:Slackware (Score:2)
Slackware Package Management [slackware.com]
I find it works pretty well actually.
Re:Slackware (Score:2)
Four simple steps :
./configure
tar xzf file.tgz
make
make install
Done. Could it be any easier ? ;)
Re:I hate Slackware advocates (Score:2)
Re:The Neverending wave of criticism of slackware. (Score:2)
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
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!
Re:Back in the day? (Score:2)
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
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.
Re:Slackware position (Score:2)
Um, Slackware 8 comes with KDE 2.1.2, Gnome 1.4 and XFree86 4.1.0. Whose GUI is modern, now?
Slackware position (Score:2)
Re:Burning Slack ISO's on Windoze? (Score:2)
Re:Slackware is for newbies ... (Score:2)
changes (Score:2)
now they tell me that "Easy does it! This comment has been submitted already, 276111 hours , 11 minutes ago. No need to try again.
Re:md5sum??? (Score:2)
european mirror (Score:2)
----
Re:Slackware (Score:2)
Re:And Another Fucked Distro Limps Out (Score:2)
a1/glibcso.tgz: Upgraded to glibc-2.2.3.
--
Re:The Neverending wave of criticism of slackware. (Score:3)
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. :-)
Re:Fast Mirror wanted (Score:3)
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...
Re:MCC anyone? (Score:3)
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.
Re:Slackware position (Score:3)
Really this time? (Score:3)
-Restil
Since when is Slackware old? (Score:3)
Re:Slackware is the best Linux distribution. Perio (Score:3)
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....
SlackWare ROCKS! (Score:3)
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]
2.4.5 and reiserfs (Score:3)
that's not package management (Score:3)
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.
Re:Slackware (Score:3)
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!
Re:New? (Score:3)
ftp://ftp.slackware.com/pub/slackware/slackware-8. 0/ANNOUNCE.txt [slackware.com]
Those are the release notes, easier to read then the ChangeLog.Comment removed (Score:3)
Order your copy. Now ! (Score:4)
Back in the day? (Score:5)
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.
Re:Back in the day? (Score:5)
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.
The Neverending wave of criticism of slackware.... (Score:5)
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.
Slackware is the best Linux distribution. Period. (Score:5)
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
Slackware: old school feel, new school gear.