Slashdot Mirror
Slackware 8.0 Released
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.
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.
- 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.
- 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.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 .)
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.
--
Don't underestimate the importance of Slackware in this role. I view it as critical.
--
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.
--
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).
--
Maybe it's because the slackware team recognizes the need to play well with other package formats on occasion?
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?)
-E
Send mail here if you want to reach me.
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
Send mail here if you want to reach me.
Then you would discover that disk 29 out of 30 is bad.
I've tried the others, but slack is *it* for me!
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.
Brak: What's THAT?
Thundercleese: A light switch.. of TOTAL DEVASTATION!
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.
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
. Penguins Surely Ca
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".
now we need to go OSS in diesel cars
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".
now we need to go OSS in diesel cars
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.
now we need to go OSS in diesel cars
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?".
now we need to go OSS in diesel cars
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.
now we need to go OSS in diesel cars
Easy CD Creator probably installed an association with .ISO files; your friend should be able to just double click the image files.
.CIF to .ISO (the least intuitive step); navigate until you find the image file.
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) leads me to believe it can do the same thing.
Stupid job ads, weird spam, occasional insight at
Case in point. I just finished compiling FreeBSD 4.3 and all my favorite packages. It has a very *nice* ports/packages systems.
/usr/X11R6 and the other under /usr/local.
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
(ok, I'll just shut up write my scripts, lazy bastard that I am. Just my $0.02).
-'fester
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.
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
Play with my webcams and lights here
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;
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.
20 January 2017: the End of an Error.
You are referring to SuSE. Sorry, no URLs, but I guess googling might help.
Search here
I can throw myself at the ground, and miss.
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.
:-p
these mistakes can happen
Long Live Slackware!
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s: a-- C++ UL+++ P+ L+++ E--- W+ N+ o K- w-- O M V PS+ PE Y+ PG
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.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
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.
Would someone mirror at least the ANNOUNCE and ChangeLog? The entire slackware domain is now officially
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 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
-- Could you use my software consulting serv
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.
Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
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
Slackware Package Management
I find it works pretty well actually.
Four simple steps :
./configure
tar xzf file.tgz
make
make install
Done. Could it be any easier ? ;)
Probable impossibilities are to be preferred to improbable possibilities.
Aristotele
Slackware is what Debian should have been.
.tgz files like they ought to be, butt naked like when they were born.
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!
STOP . AMERICA . NOW
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.
STOP . AMERICA . NOW
Um, Slackware 8 comes with KDE 2.1.2, Gnome 1.4 and XFree86 4.1.0. Whose GUI is modern, now?
STOP . AMERICA . 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! :-)
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.
-- Another senseless waste of fine bytes.
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.
--
>> From the time a woman is seven years old till she dies of old age, she is ready for action, and competent. -- M
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. :-)
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...
Ok... was it REALLY released this time or is this just another overreaction to a directory name on an ftp server? :)
-Restil
Play with my webcams and lights here
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!
A deep unwavering belief is a sure sign you're missing something...
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....
Now I use it on my laptop and on my desktop PC.
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 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
-- Could you use my software consulting serv
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.
The REAL sam_at_caveman_dot_org is user ID 13833.
...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.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
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!
"Drug related crime" is a misnomer, "prohibition related crime" is the more accurate and correct phrase.
It's very simple, maintaining one file per package in /var/adm/packages, and using tar files. Installpkg untars the file at / (you can override that, and it's actually slightly more complicated to cater for library management and stuff), optionally running a post install script, and placing a list of the files in a text file in /var/adm/packages. Removepkg makes a list of the files in the package you wants to remove, strikes from the list those that are shared with other packages still installed, and then deletes the files left on the list.
Slack supplies a "rpm2tgz" script that will turn a .rpm into a tgz, so you can install an RPM - and manage it - by converting it and then using installpkg in the usual way.
So could someone explain why most posters, even those who profess to like Slackware, think it doesn't have a packaging system? If the complaint is that it's not an advanced packaging system like RPM, I'd agree. It lacks (built in) dependency checking - the ability exists to include it in the post install scripts - and a few other nice features, but arguing that it's not advanced therefore not a packaging system seems excessive. And the way I'm reading it, most of posters are of the opinion it doesn't have one at all.
I'm not saying it's perfect, it'd be nice if the post install scripts could report dependencies for example, but it generally works well and its simplicity makes it easy to maintain, especially when you're having to work with a variety of packages from different sources and platforms. I can happily get an RPM to work with a subsystem I compiled from source without feeling like the packaging system is getting in the way.
Slackware has package management. It's not as "do everything" as RPM or DEB. But it's still pretty useful. You can remove an application you installed with a single command (or do it by dropping into the setup menu.) I personally prefer it to RPM, but YMMV.
--
You are not alone. This is not normal. None of this is normal.
http://store.slackware.com/ and support the Slackware project.
How to contact me - http://www.pervalidus.net/contact.html
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.
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.
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s: a-- C++ UL+++ P+ L+++ E--- W+ N+ o K- w-- O M V PS+ PE Y+ PG
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.
.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.
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.
STOP . AMERICA . NOW