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.
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...
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.
Agreed. I jerk off to ASCII art on Usenet too. Damn kids today.. all they want is fancy colorful moving pictures in high resolution. In my day we printed out porno on dot matrix printers and retired to the bathroom for the afternoon.
Yeah... GCC 3.0 is included in /contrib... it's not the main compiler.... it would have been insane to do so....
Not the kinda thing I'd expect from Pat....
BTW stop slashdotting store.slackware.com if ya ain't gonna buy it.... some people really want to buy the whole thing fast !
Just yesterday, I was looking at the devel tree, and saying to myself, "Hrmm... to I want to take 7.1 and try to bring it up to date, or use the devel one, and worry about problems. The development tree was refered to in a few of the files as 7.2.
/.? Does it have anything to do with staying ahead of Redhat? Or maybe it's just because a lot of major new packages have come out since 7.1 (not sure what's in it, but we've had big releases for X, the kernel, KDE and Gnome since 7.1 came out)?
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
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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."
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
--
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. :)
--
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.
--
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.
--
You are absolutely correct. Debian supports this in a primitive way with the "provides" field.
--
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. :)
--
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.
--
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. 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.
--
I fall under the same category as CmdrTaco and about half of all the people who posted in starting out on slackware. That would make a good poll, is finding out what distro people started out on, or tried first.
Inconceivable!
Even better, it's both!
/var/adm
/var/adm -> log/
logan@mojo:~$ ls -l
lrwxrwxrwx 1 root root 3 Feb 16 22:06
Ah yes, I remember installing Linux for the first time. It was Slackware 3.4 if I am not mistaken. That was a nice distribution. But I feel that today's distributions like Debian and RedHat are superior thanks to their excellent package management systems. Can someone tell me, what solutions are there for easy package management in Slackware?
Uhh... Slackware has included KDE and GNOME (contributed) since version 4.0. Seems like those two graphical desktops are modern, but maybe I am just a plain-old UNIX nostalgic...
"You're gonna need a bigger boat." - Chief Brody
Okay, sure. And what about for computers not connected to the Internet?
Uh, so why not just compile all the extras you need yourself? And in a horrible twist of fate, I had just downloaded 7.1 yesterday... Doh.
Exactly right. My first Linux experience was with Slack 3.4 on a 486 with limited disk space. I spent a lot of time scouring the system to free up space, and learned an awful lot about Linux and Unix in the process.
Amen. One of my family duties is turning old 486 and pentium boxes into cheap internet boxes. Usually I have little disk space and ram to work with, so I stick Zipslack on and compile anything else that machine needs.
:)
I've gotten really good at optimizing binaries for speed and size, too.
Just this weekend I made of LAN of three 486s so my parents, little brother and little sister can all get DSL from their respective bedrooms. Minimal X with Windowmaker, Opera, and a few other things, and they're good to go. And I've had far fewer problems securing Slack than some other horrificly-insecure Lindows distros, such as Mandrake.
I tried the link (ftp://ftp.slackware.com) but all I got is a login prompt.
Since I don't have the password, I can't get through that prompt, and that means, I can't even get to see the changelog !
So... how to access the changelog ?!
Muchas Gracias, Señor Edward Snowden !
True, but not all distributions use the same versions or even flavours of package. Dillon's cron, Vixie's cron, etcetera.
> > Dependencies should be up to the administrator, not up to the maintainers, because the maintainers will eventually get something wrong.
> Eh? This makes no sense at all.
This makes *perfect* sense. The maintainers *do* get it wrong. For example, both Ximian Gnome and the Red Hat Netscape RPM's provide a Netscape Icon, thus producing a conflict and breaking up2date. Why can't *I* choose which icon I wanna use? Do I look like some kind of windows user who can't figure out for myself what kind of Icon I want?
The underlying problem with Windows (and MacOS) is that it is condecending to the user. "There there, poor, stupid user, don't worry, we'll just install this crap and you don't have to think..." One of the major goodneses of Free software and Linux is that it does not condecend. The user has the right to be responsible for their own computer!
My friends with Red Hat call me saying they updated an RPM and now the config's different and they can't find the config file and the dependancies won't resolve and so on... It's the same calls they made to me years ago about Windows.
USE THE SOURCE, People! This is not a black box... It's good to know and care what's happening on your hard drive.
>YOUR SYSTEM, THOUGH LACKING A PACKAGE MANAGER, STILL HAS DEPENDENCIES!!!
Yes, and Real World Dependencies != package manager dependencies, unfortunately.
>> For example, both Ximian Gnome and the Red Hat Netscape RPM's provide a Netscape Icon, thus producing a conflict and breaking up2date.
>The problem there is mixing packages from two independent, non-cooperating vendors, not packaging per se.
Exactly the point. Two different maintainers. One or the other got the dependencies wrong. And the user is screwed for it. Not all RPM's come from Red-Hat.
The problem is a packaging system that enforces the maintainers idea of dependencies. Yes, the maintainer may have built his RPM on a system with libfoo-1.1, but I have libfoo-1.0.8, because I've found libfoo-1.0.9 to be broken for me. And after I rip open the RPM and hand install the thing, I find it works perfectly fine with libfoo-1.0.8...
You are right, this is not a problem with packaging per se. It's a problem with a package maintainer trying to enforce his idea of how a computer is set up on you.
And this problem is not limited to packaging or software installation. How many times have you gone to a web page with a perfectly modern browser, only to be greeted with a "this site requires a modern browser" message, just because you were not on Win/MacOS? Shockwave.com will break in in the middle of a perfectly playing flash movie to tell me I can't watch flash with my browser!
A package maintainer cannot foresee all things. Yes, it's true, if I install a binary package with different libs, etc, than the maintainer intended, it may not work. But then, maybe it will. The maintainer has no way of knowing if his package will work on my computer, so he says (through the facilities of the package manager) "Do No Try." I say, "Go Ahead, try it... maybe it will work!"
(Blah blah supporting my users blah support nightmare. There are many valid places for a homogenised computer. My desktop is not one of them.)
That would be really cool, especially if the *user* gets to make the choice.
I wouldn't be suprised if there is a way to do that (optional dependencies) as it seems like an obviously good extension. But what does the user do if the package maintainer doesn't use it?
It would be cool if the *user* could permanently mark a dependancy as "optional", and that would survive package updates.
If I could say, at package install or update time, "libfoo-1.08 is every bit as good as libfoo-1.09" and forevermore libfoo-1.08==libfoo-1.09 as far as the package manager is concerned, why that would just rule...
Unfortunately Debian is starting to annoy me with all its dependencies. In particular, I strongly dislike it wanting to install things like esd and gnome which I would always consider to be optional. Or how about cdrdao requiring gtk? That's just crazy. Debian's package management has gone too far.
After reading everyone's comments here, I am strongly considering moving over to Slackware. It sounds like exactly what I want. I wonder if it's possible to slowly migrate my system over without having to reinstall from scratch. That would be sweet.
--
Harsh But Fair: you know it makes sense
harshbutfair: you know it makes sense
www.harshbutfair.org
I don't know of any mac software that properly burns iso images. On another topic though, you should note that tomsrtbt is _not_ for burning onto CDs. It is meant to be copied onto a single floppy, from what I understand.
Over the years slackware has remained the best distro (imho, and I am sure there are many many people who are out there who would just love to get in an argument about it but I wont). Slack brought me in to using linux when a friend handed me the 3.5cds he bought and said I should try it. And its remained stable for me over multiple servers and workstations. There is nothing like being able to get a clean box up and running with slack and X if I have to in under 30 minutes. So Congrats to Patrick and everyone involved in getting the best distro avalible out. Now if my download would only hurry up and finish.
Uh? Nothing stops you from compiling apache, bind, or even perl on Debian or RedHat, so this particular argument is irrelevant.
And so why don't you use *BSD, then?
% uname -a
:-)
Linux endor 2.2.14 #1 Tue Apr 4 20:51:38 EDT 2000 i686 unknown
% uptime
12:26pm up 440 days, 18:46, 4 users, load average: 1.00, 1.00, 1.00
Runing Slackware 7.
It would be cool if the *user* could permanently mark a dependancy as "optional", and that would survive package updates.
m l
Obviously this doesn't apply for all distros, but you should have a look at Debian's equivs package -- for a while, I used it to provide a fake libgl1 package while using NVidia's video drivers, so I could install things like xscreensaver-gl. (Of course, then a more elegant solution emerged, but it's useful as a stopgap...)
http://packages.debian.org/stable/admin/equivs.ht
deus does not exist but if he does
Better. Stonger. Faster.
Stonger?
deus does not exist but if he does
Sup wit dat, yo.
Hooray for one line posts.
Holy Cow, now there's a blast from the past. Never thought I'd see the day when someone would mention SLS on /. :)
SLS was the first distribution I ever tried (pre 1.0 kernel) and I hated to see it die, but then I discovered Slackware and all was well with the world again
I've tried other distributions but I always end up coming back to Slackware for it's stability, security and because it doesn't get in the way when you're admining a box unlike some other distributions.
I've tried em all. Debian (stable, unstable), Mandrake (7.0, 7.1, 7.2), Redhat (5.2, 6.0, 6.1, 7.0), StormLinux 2000, and SUSe (7.0). Installed and uninstall all of them. I've never used a better distro than slackware. Everything else was bloatware and obtuse (well debian was good, but I just have issues with a distro that wont allow me to do a 'make menuconfig' after a full install). I'll continue to use slack, and I'll continue to try other distros, but I don't think I'll be swayed to leave.
"I have great faith in fools: Self confidence my friends call it." ~Edgar Allan Poe
modern gui: XFree86 4.1.0, KDE 2.2.1, GNOME 1.4
9 84.html
modern os: Linux kernels 2.2.19 and 2.4.5, glibc 2.2.3, and all the usual utilities
package system: http://www.slackware.com/book/index.php?source=c3
dunno about the device config in Mandrake v. Slackware...
wow .. thank ... 90k/s .. that's more like it !
Somebody marked that post as informative?
I've had slakware based systems up for excess of
6 months, and the only reason they have come down
is due to power failure (someday I'll get an UPS).
'the distribution that just wont die has been released. I'm sure many people here started w/ Slackware back in the day'
/. is sickening.
Lets translate to what you really meant:
'the distribution that really should die once
again has cheated death. I'm sure many people
when they were kids used Slackware before there
was something better like Redhat'
Why not just be a man and say you think there is
no place for slackware and that it sucks (which it
doesn't)? Sometimes the PCness on
Another decent channel is #linuxhelp on undernet.
I'm not feeling that clever this morning.
I do X configuration by hand all the time. And I always compile my own kernels.
You seem lazy. All these things are fun.
Interested in weather forecasting?
I mean, this place is run by people who can't manage their own installations of Linux themselves, they have to have packages for every little thing. Hooray for Slackware! If you want Linux done right, this is the distro for you.
Interested in weather forecasting?
There's a certian amount of ignorance that most people who use Linux have about Slackware. I wouldn't call Linux "not modern", but it certianly isn't bleeding edge. Just because it's stable doesn't mean it's outdated, people.
Interested in weather forecasting?
Slackware is a great distro if you need to do a custom setup for a server. It's really easy to strip an install of Slack down to the bare essentials and secure it. It's great for older hardware too... Less daemons to worry about, less system resources taken.
Keep up the good work, Patrick V. and developers of Slackware!
Interested in weather forecasting?
Interested in weather forecasting?
RedHat is impossible for me to use. Nothing makes sense to me when it comes to why everything has dependancies on the most obscure stuff. It's just annoying to have to deal with all the linking and the horrible arrangement of configuration files.
Slackware, for me, is much easier to deal with. I don't need X running to configure my system. I don't need GTK for every application. Hell, on my servers, I don't even have X installed.
RedHat is too much. If I wanted that much bloat, I'd just run Windows 2000.
Interested in weather forecasting?
Slack jumped from 4 to 7 at about the time RH was going to 6.x. There was an interview with Volkerding around that time. The 4 to 7 version number change also marked the adoption of glibc, which Slack was slow to adopt for hopefully obvious reasons, but, when it was adopted it was very painless and the disclaimers were right in your face to warn you during installation.
Boy I'm glad I rsynched my mirror over here, yesterday. These people updating to =day must be stepping all over each other. >:)
Linux rocks!!! www.dedserius.com
www.dedserius.com
VB != VisualBasic
9:00am up 342 days, 43 min, 14 users, load average: 0.00, 0.00, 0.00
That's from the main server at where I work, which runs our company's accounting system and is the PDC for our NT domain. It's running Slackware 4.0, and frankly, the only times this machine has gone down is thanks to instabilities with third-party serial multiport card drivers. (It took me a week or two to work around those... heh.)
Just my $.02...
I'm still running Slackware 3.4 on my main desktop---haven't seen the need to upgrade it. Sure, I have installed new packages and libraries, but it is essentially the same system I installed years ago. Slackware Rocks!
If you would notice the dates next to each posting on the Freshmeat page, you would notice that those comments are from 1999, and the very last comment stated that as well.
tourettes
So, what you're saying is, you want Windows? I thought part of the point of Linux was to do things for yourself, like setting up stuff, installing/uninstalling, etc. If I want to put in a CD and see pretty graphics during the install, I'll use Windows. If I want a command line to do stuff, I'll use UNIX or Slackware.
I've used Slackware 7.0 which I had to install using floppies and I don't have a big problem with doing that coz you should keep a bootable floppy lying around anyway. But seriously, is making a bootable cd-rom ISO too much of an ask?
Slackware is the best distribution in regards to having the most stable set of apps. It is as raw as FreeBSD.
ever tried ./configure ?
though this relies upon the developer, it will warn you and not generate the correct makefile if you don't have the right libraries.
it doesn't give the same level of warning and protection that dpkg gives you, but it simply gives the admin more power - assuming he's actually up for the task.
i slacked for a long time. i'm currently a bit into debian, though i'm thinking about returning to slackland. it's THE best server distrobution. it's a fine desktop distrobution. look at the stats for security problems on Security Focus. which one would YOU like to use for a server?
Stop the brainwash
mandrake 8.0 and suse 7.x - just as high a version number as slack, but they're 1/3 as old.
What you are looking for is LCDProc .
"Prefiero morir de pie que vivir siempre arrodillado!"
Debian already has this Mike
heh, and I thought my 48 days (between power outages) was a nice uptime. Still, In about the 3 months that I've had that little firewall running it hasn't crashed, it's gone down 3 times because of power outages, but that's it. Oh, and it's running slack 4 :)
Want some indy electronic (and other) music?
This sig intentionally left blank.
There's an answer to this: RSYNC!!
Know it, use it, love it.
Heh, main reason I noticed Slack 8 was out is because my daily rsync update of Slack-current failed this morning.
When you live in a sick society, just about everything you do is wrong.
GCC 3.0 is in /contrib. It comes with a 2.9.x version as default.
It's /var/log/packages, not /var/adm/packages.
-- My comment is above.
That's exactly what I love most about Slackware; it allows you to have complete control over everything instead of trying to do it for you. I hate waiting for a binary package of something when I can configure and compile it myself.
Kudos to the Slackware team for making such a great distro!
I found Taco's posting a little depressing myself. Now I feel I must defend my favorite distribution :)
Actually, the most interesting aspect that I find in Slackware is how easy it is to create your own packages.
I usually have to do this when I want to install brand new software (when XF86 4.0 came out, my friends with Debian in their machines wouldn't touch it because they couldn't do aptget on it!) I like the independence.
I guess that's the spirit with Slackware. Do it yourself, I think. The distro doesn't get in the way. The package management system will probably be improved some of this days, I just hope they keep it as easy to interact with as it is now.
Oh, well...
I'm a slackware advocate. Sure sure, I recomend it. If someone is a newbie, I usually say something along the lines of "Well, I use slackware which is of course supposed to be the hardest to deal with. Most beginners try Mandrake or Redhat..." The thing is that recently some of my friends have started using linux. Two of them started with Mandrake and couldn't get stuff working and didn't like it too much. I had them try slackware, both of them love it. I have another friend who, like I did, is starting to learn on slackware.
There are some ease of use issues, but it does work. It gets out of your way and lets you change as much as you want to. As for all the crys of "But there is no package managment!!!" There are a few options. First, you can directly install RPMs if you want. (Why?) or you can get native slack packages. They are called package.tgz, and no, they are not source. You type installpkg package.tgz and it installs. removepkg package and it goes away. If you need the binary package and it's only in tgz format, then you can use rpm2tgz. Also there will soon be autoslack which is akin to apt-get. It automaticly downloads, promps for downloads, or informs you of new packages. I haven't checked if it's in Slack8.0 yet or not. It's at http://zuul.slackware.com/. There is also going to be a program (who's name escapes me ATM) that will let you get a source tarball and will do a package install for you.
I'm very excited about the new version, and will be installing promptly.
--Josh
There are exactly 42,935,718 letter sized sheets in a square mile.
From what I can remember, since Slack 3.2, telneting in as root was explicitly disallowed. You could only log in as root via tty1-6. Either your friend explictly *ALLOWED* remote root login, or you are...mistaken.
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
Yes, the *most* stupid parts of /usr/doc are (in order of uselessness):
PPP-Howto
Net*Howto
NFS-Howto
dhcp*/
Ethernet-Howto
This documentation *especially* should be web-only, like you say.
End Sarcasm.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Can someone recommend a place that will press slack 8 to a CD for a decent price? An ISO is just too much for a dialup user.
I've been using Slackware from pretty early on as well. It's always been my distribution of choice, mostly because I'm not into RPMs and love to compile stuff on my own -- and what better than to have a distribution that FORCES you to compile your own kernel because they don't have your Ethernet driver compiled in by default, or have it available as a loadable module? ;-) [By the way, this changed only at Slackware 7.1 where the 3com and other network drivers were insmod available from the initial kernel on the CD]
Damn, I wish I would have known about this release earlier -- I just installed 7.1 on three new servers which are now lacking the glibc-2.2.3.
But back to why I dig Slackware -- every article I've read that compares distributions always pegs Slackware as the one to choose if you don't mind compiling things on your own -- and well, I guess that's me. I also like it because of its consistency. The installation process has remained consistently simple, non-GUI, and I can install faster than any Solaris/Redhat/Mandrake GUI installer.
Long live Slackware. Now its on to tips on upgrading, or is it still recommended to just dust the old installation and install anew? I mean, what are the REAL advantages of upgrading past 1.2.13? :-)
The problem there is mixing packages from two independent, non-cooperating vendors, not packaging per se.
It's actually a namespace problem with packaging schemes per se. If you can't mix packages reliably, throw "free software" out the window because you're bordering on single-vendor lock-in.
There should be a way for the Netscape package to say "I optionally need an icon package associated with Netscape, doesn't matter what it's called" without the whole thing blowing up. (Maybe there is, and this is an issue that can easily be resolved.)
When I hear the word 'innovation', I reach for my pistol.
That's why I said it's a namespace issue.
A package should require or optionally use some abstract key such as "Netscape Icon" or "libfoo > 1.08". Then you, the SA can decide that "MyCoolNutscrapeIcon" or "mydistro_libfoo1.09_1a_beta" meets those abstract requirements.
But maybe it already works that way, I dunno because for what little I bother, I follow the single vendor route. It just seems that people bitch about specific version requirements and naming issues.
When I hear the word 'innovation', I reach for my pistol.
> 9:00am up 342 days, 43 min, 14 users, load average: 0.00, 0.00
;-)
Not too bad, although this looks better:
8:26pm up 448 days, 7:30, 19 users, load average: 1.45, 1.54, 1.44
This (Slackware) box is running Linux 2.2.13 because upgrading would of course kill the uptime.
Could everyone stop thier multi-hour downloads of the iso, and take thier slackware 7.0 dist tree and rsync it to 8.0? Should save sourceforge.net a little bandwidth.
Spring is here. Don't believe me, look outside!
If Slack works for you, great. It may not in the future and it certainly doesn't for many Linux users.
Wow. You've left a bit of FUD on your chin. Would you like a napkin?
If some time in the future you become tired of manually configuring and building packages[...]
This shows a deep misunderstanding of how Slack and Slack packages work.
[acknowledge] that changes come through time how open-minded and forward-thinking you are.
Hmmmm. If hiding information from the administrator is open-minded and forward-thinking, give me unreceptive and reactionary any day. The concept that Linux must be easy to use for any clueless git on the planet is seriously flawed. The requirement of study and attention to detail to run a *nix system is a Good Thing. I'd prefer that people who aren't willing to put in the time and effort stay out of the pool rather than pissing in it.
--
If only I could order W/O a creditcard...
It wasn't me! | MySQL rulez!
[blockquote]That is assuming of course that Slackware doesnt already have a Slackware package for that dependent package. And if it did, and you decide to install that instead of compiling the source, how would that be any different from using an RPM or DEB? [/blockquote] For starters, I can at least get things to compile on Slackware! some people find that a plus.
I don't know if it's totally secure - but traditionally Slackware 'out of the box' has been a lot more secure than other distributions like RedHat 'out of the box', simply because where RedHat wants to be user friendly and comes with all the options turned on, Slackware is aimed at a more experienced audience and it is expected that they will turn the same options on if and when they need them.
Don't pull a Microsoft and group all the Linux distributions together. 'Linux out of the box' indeed. =)
Some said that there was an easy to use package system for slackware, I've used slackware for 2+years now. I will admit, the dialog's based bash scripts are really slow in terms of installing packages. But I compile everything I download. It's easier that way.
--
Sakui
Package management is a wonderful thing, but it does have some drawbacks.
Package management is used to ensure that the rights libraries needed for your app (server) to work. If you think that the package you are using is bloated, does not provide the functionality that you need or even does not exist in your distribution. You should create the package yourself.
Unfortunally very fewer distributions can satisfy every kind of user, so if you knows how to create a package for your distro, you can fill the gap.
Just to note RPM has been made the official LSB packaging tool,
And the Slackware store page takes (took) about 120kB to load.
...a fact which for the sake of a quiet life most people tend to ignore ~H2G2
Read the Changelog:
/ Ch angeLog.txt
ftp://ftp.slackware.com/pub/slackware/slackware
--
Yes, I suspect Patrick has been viewing the ftp logs to wait until the most amount of people had just downloaded the latest release before going live. Some kind of humour I guess!
Unimpressive, we just turned this box off shortly after recording it's uptime, because the hardware is now obsolete, so it's wasting rackspace!
4:47pm up 1026 days, 21:07, 2 users, load average: 0.01, 0.00, 0.00
http://store.slackware.com is slashdotted. I think it's becuase that part of the website is being run off an ADSL line (63.206.96.212). See for yourself.
Ha! Sorry...
"unattended install"
Though unintended might be interesting...
STOP . AMERICA . NOW
But if you're not going to use it, what's the point of having it? And what might you break installing stuff outside of it?
CEE5210S The signal SIGHUP was received.
Slackware: old school feel, new school gear.
What a great motto. I'd like to have that on a T-shirt.
Damn Sourceforge, sometimes they suck sooooo badly!!!
Currently getting 5.6k per second on the download from them, and I am on an OC-3.
Anyone know of a good, fast mirror?
Ron Gage - Westland, MI
this is what you do:
add a deb-src for unstable or testing line in your sources.list file and then compile and install perl, ssl, and then apache. or you might as well go to testing and apt-get dist-upgrade from there to get to get the latest/greatest stuff.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
Slackware's package management system will do that. cp and tar will not.
As I said, Slackware's PMS (!) isn't as advanced as RPM or Debian's. Those two do not solve every interdependency issues either, though they do a good job of catering for most issues.
Actually, IMO that's ridiculous. It's rare that a package is dependent on something rare and undocumented, and it is fair that if a sysadmin wants to install something, they should have some idea of what they're installing and its requirements.In any case, at the very least, all a packaging system that supports dependency checking does is move the time an installer is informed about what dependencies are required by an app from being when the administrator is reading the README to when they're trying to get the damned thing to install. Neither are perfect, and while it's useful for an app to fail to install without the correct dependencies loaded for a novice, it's also something that, in my experience, can get in the way for more advanced and esoteric applications.
Either way, saying that something is no better than tar or cp because while it automatically installs software, including running automated installation scripts if necessary, keeps track of the files it uses, and allows them to be automatically, easily, and safely uninstalled, because it forces the administrator to read a README file rather that write instructions to the screen (or automatically download packages over a network link if available), seems to me to be lacking proportion.
--
You are not alone. This is not normal. None of this is normal.
And as has been said, they use different daemons in some cases and tend towards the more stable side of software. (hence slow uptake on glibc, no pam, etc)
A diplomat is someone who can tell you to go to hell in such a way that you will look forward to the trip. (355/113)
vi Makefile
what happened to us? *grin* - ./ configure does make it a bit easier, but, tweaking Makefiles to match your system configuration was definately more fun.
Does anyone know the md5sum of these iso images? extra.iso, install.iso and source.iso Would have been nice of Patrick to let us know what they where but I bet he was just tired.
Well, probably if everyone wasn't all downloading from ftp1.sourceforge.net at the same time, the mirrors could update more quickly, and we'd all be able to get our slack more quickly. For what it's worth, carroll.cac.psu.edu is qutie a good server, once it's done updating. I believe they have a 155Mb connection, so it's usually quite quick.
slackware is great for me, and it does have a simple package mgmt system (yes, simpler is better). i've installed slackware-current dozens of times, and only once had a problem with doing so. compiling and installing your own software with slack is a breeze. the only comparible alternatives to it are in the bsd world. thanks to all involved for keeping it current!
this was a few months ago, but Pat has said that, yes, debs ROCK, and will be implementing something along those lines a few releases from now.
Now, I can't speak for everyone, but personally, I like the fact that I can communicate directly to Pat, get a response, and sometimes get things changed. It's nice having one person who actually maintains the distro, and that person actually talks to us directly, asking us really what we want. For example, this release, the pre-compiled kernel has no multi-processor support built in, as a result of a vote he put up on the message board. We, the users, decided what we wanted. I can't say more.
C Pungent
Definitely...
What's the point in having advocating open-source systems when you don't even want to look at source code in the first place!
Do Not Taunt Happy Fun Ball...
I just don't understand this modern OS thing - I've used Slackware since the beginning, and I've also played with Red Hat 'Hedwig' and 'Guiness', did a rough install of Mandrake, but I keep finding reasons to go back to Slackware. I'm running a very new P4 with a lot of new hardware, and Slackware picked it up just fine... and the new Gnome packages are tasty ;)
Anyway, age old question, but how difficult would it be to create an RPM-based version of slackware? I'd like to give it a go, but admittedly, I know little about the internals of RPM and why RPM *allegedly* doesn't lend itself well to systems based on tarballs. Any ideas or references to get me started?
Do Not Taunt Happy Fun Ball...
Better. Stonger. Faster.
Who is modding this down?
I love Slackware, but he does make a valid point. Slack is NOT for newbies.
Most programs written for KDE start with the letter "K" (KWord, KBattleShip), whereas those written for Gnome mostly start with... "G" (e.g. GNumeric). Nothing to do with recursive acronyms, but I could be wrong.
Raymond
"There are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." - Blair Houghton
Slackware rules! I first got into Linux recently with Mandrake 7.2 At first, I thought it was easy to use, but then, i realized that it was actually TOO easy to use!! I wasnt learning anything about linux :(
So, i had my friend help me install slack 7.0 off his CD. (I realize now that i probably could have done it myself.) It is GREAT!!! It is challenging enough that i learn things, but not so hard to use that i give up. Also, it runs reasonably fast on a Pentium 100, unlike the bloated mandrake. NEWBIES: Do NOT get Mandrake!!! Its like riding a bike with permanent training wheels! Just get Slack 8.0! It is still easy to use, and you will actually learn something. Oh, and DONT use a WM that looks like Windoze95.
/usr/games/fortune
NOT secure??? The only thing i have had that is more secure than my linux box is my win98 box because it would undoubtedly crash before anyone could fsck with any of my files! I know linux is not secure out of the box, but it is more secure than most other os's and MUCH more reliable.
/usr/games/fortune
Yep.
;-). Easy CD creator automatically recognised the .iso extension (depends on the setup though) - all I has to do was double click that little icon and Easy CD creator new what to do! yipeee: bootable slack cd {you see... windows does have its uses ;-)}
I downloaded slack to windows 98 (now uninstalled
p.s. make sure your friends computer can boot from cd (may need to be enabled in BIOS), otherwise bootable floppy is straightfoward enough.
p.p.s slack isnt that difficult for newbies: I started with it 6 months back and am getting along just fine.
p.p.p.s Mac's dont deal with iso or rockbridge or whatever. Only there own proprietry format. which sucks.
p.p.p.p.s i'll shut up now
ACK! both the primary and secondary luon.net nameservers are down... Galileo is still reachable on galileo.tte.ele.tue.nl
----
Hey,
:-D
Yes, Slackware has a simple package management system, but had you - 'non-Slackers' - looked at the packages sources?
I'm subscribed to the main free software packages "*-announce" lists, and when a new release comes up, I just create a tarball for each of my servers and install them.
To me, this is care for your work. I like to optimize and secure at most my servers, not only because I'm being paid for this, but because this is my life, being a UNIX-admin and programmer makes me happy, is my very great love!
Congratulations, Pat!!! Go, Slack, go!
Blind_Bard
--
Blind_Bard
--
The degree to which life sucks is directly proportional to your blood/caffeine ratio.
It's not extreemly "advanced", but it's great. It's been shown time and time again that RPM packaging is a chore that gets as little time as needed. (ie. post install script requires bash, but did you put bash in the requirements?)
Slackware has README files for packages that require other packages (like for 7.1's 3dfx stuff). Read the README and install stuff rather than try to rpm it and have rpm tell you.
Not that big of a difference.
-EvilMonkeyNinja
a.k.a. Joseph Nicholas Yarbrough
Security Grunt by Day
Programmer by Night
-EvilMonkeyNinja
Mild Mannered Host by Day
Wild Hammered Programmer by Night
very good grasshopper, but no cookie!
I meant it was a tradition *like* recursive acronyms. kde/gnome wern't the first and only things to spark a naming convention. (like java, qt, etc, etc)
-EvilMonkeyNinja
a.k.a. Joseph Nicholas Yarbrough
Security Grunt by Day
Programmer by Night
-EvilMonkeyNinja
Mild Mannered Host by Day
Wild Hammered Programmer by Night
> They've consistently offered the most complete and versatile distribution.
Wow... by complete you mean netscape, pine, and some 15 IRC clients? Mandrake and Suse have far more available programs (that are *ALL* in the menus... thats "userland")
> with terms like "konsole"
Wow... it's a play on words like 90% of the rest of free software. Bet you hate Mozilla for being like Godzilla too right?
> I respect everyones choice regarding the distro they use
As do I, but I doubt anyone spells console "konsole" when they aren't talking about *the* "konsole". It's not fruit-cake-frenchies that named it Konsole... it's sorta a free software tradition (think recursive acronyms)
-EvilMonkeyNinja
a.k.a. Joseph Nicholas Yarbrough
Security Grunt by Day
Programmer by Night
-EvilMonkeyNinja
Mild Mannered Host by Day
Wild Hammered Programmer by Night
> Before everyone comes down on me, I do think
> Slackware has one very important role.
Every distribution has an important role just by existing. Different minds will find different ways to accomplish something and that's precisely the power of the GNU/Linux/xBSD/OpenSource-"movement". It provides the chance for mindshare cross-pollination between the projects and distributions, accelerating overall development. May the best solutions prevail and come about through diversity, thus giving the equally diverse users various means to fulfil their individual needs and wants based on their free conscious choice over their computing environment. The names do not matter...the principle does.
Harka
Hey, have you ever contributed to FreeSoftware/OpenSource comunity? If you have, great, I think you know what to do!
If you haven't, that's great too. It's a wonderful way to start. You probably use slack at home, so, I think that if you know a way to implement SVr4-style-init-script everybody in comunity will be very happy, and so you will to.
And if you don't know how to implement it, it's a wonderful opportunity to learn how to do it. I don't know, and if I have some free time, I promisse I'll learn.
So, good luck. (no offense, pal. Just a friendly chat :O)
Don't worry, I'm too busy [to|every]day
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
On the other hand, I use Linux for "productivity" work too. Therefore I chose to use Red Hat a long time ago. They've consistently offered the most complete and versatile distribution. They are also English language oriented, which off course is not a surprise for an American company. The product of their greatest competitor gives me itches, though, with terms like "konsole", etc.
I respect everyones choice regarding the distro they use, just wanted to let you know what my preference is, and why. I don't have any shares in any Linux distributor, just fyi. :)
Regards
Actually the ports model on FreeBSD is pretty nice, it may automatically find dependencies, download and install them, and it can keep track of installed ports for later deinstall.
burn a non-bootable CD-ROM, create boot floppies.
After he installs Slackware 7.2, he will be able to create bootable CDs (assuming he can't do it with what he already has).
I've been creating bootable CDs with 7.1, no problem.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Tough to do. I went to the website, and nowhere is the product advertised for order.
(And idiots wonder why they can't make money on open source products...)
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
...SuSE's based on Slakware ;-)
> The only options I have are to try forcing the
/usr/local tree though. Its for locally installed software, which in the presence of a vendor specified package manager, means software which doesn't come prepackaged in a rpm/deb (imho).
/usr/local statement is a non-issue because no package thats been installed outside of the /usr/local tree should depend on any thing inside the /usr/local tree.
/usr/local doesn't exist. Its up to you to manage the software in /usr/local. Let the package manager handle the rest of the system.
> 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.
Thats the whole purpose of the
Your "leads to inconsistencies in the RPM data" with regard to installing software to
As far as the package manager is concerned, anything installed to
And what pray tell is to stop you from compiling the latest Perl and dropping it under /usr/local and then compile the SSL module and tell it to use the Perl in /usr/local???
Christ, you people seem to think that just because a system has a package management system that you have no choice but to make use of it!
The package management system is for managing the various components of the system. You would maintain the /usr/local tree (or where ever it is you install local packages) independent of the rest of the system. Some people opt to use third party package management systems (such as epkg or stow) to mangage this local software tree. Personally, I make my own debs for my /usr/local tree for my Debian systems.
And no, you don't break anything.
> If you want to push Linux, you should introduce
..... not.
> people to an Operating System that requires
> people to think for themselves
Oh yes. Computers shouldn't be made easier to use. What a stupid idea. I long for the days when "programming a computer" actually meant rewiring the thing
> Shit, I can't even get anything to compile on
> RH7.1 without some gay RPM to throw at it.
Yes, instead you'll need to go download some gay source distribution of a dependent package, compile it in true gay fashion, and then install it in some gay location such as "/usr/local".
That is assuming of course that Slackware doesnt already have a Slackware package for that dependent package. And if it did, and you decide to install that instead of compiling the source, how would that be any different from using an RPM or DEB?
> No good. No good. Every time I've used Debian > or an RPM-based system, I end up with EVERY > LAST DAMN THING in the system in the /usr/local
> tree because I've compiled it myself as way to
> get around the versioning and dependencies in
> package management.
Hmm ... wouldn't you be doing this ANYWAY in the absence of a package management system?? That is, you grab the source for a package and install it yourself somewhere under /usr/local or where ever it is you like to stick local software packages?
The only people who I see bitch about package managers are the ones who like to fight them rather than work with them. If you're in need of a particular software package, you first check to see if it already exists in rpm/deb form. If it does, you use that. If it does, but you happen to not like the compiled-in defaults you grab the source rpm/deb, rebuild it, then install it. Failing all that, you then grab the source and go ahead and compile/install to /usr/local.
> Package management gets in the way of a
> competent system administrator's day.
Only if said "competent" system administrator is a lazy fuck who doesn't want to learn how to use the particular system he or she is administering.
> We're talking about computers here, people, not
.. the one by atheos. Here, let me repeat what he said so as to not make it too difficult for you ("you .. you mean you were responding to someone else's post???"):
/usr/local or something (i.e. the Hard Way). In the presence of a package management system you have the choice of either doing it the Easy Way or doing it the Hard Way. In the absence of one though you have no choice but to do it the Hard Way.
.. well, thats what I get for trying to use sarcasm in a forum where the bulk of the target audience is made up of people who aren't sharp enough to tell when it is being used. Again, read what atheos said. Then re-read what I said. Repeat until it starts to sink in.
> a toaster or curling iron. There are people
> running RedHat who have VCRs flashing 12:00! If
> you want to turn a PC into an internet
> appliance, that's just fine and dandy with me.
> Those machines SHOULD be
Perhaps you should try reading the post I was responding to. You know
atheos> So, in order to push Linux, you think we
atheos> need "Windoes" looking clones? Or gay RPM
atheos> packages? If you want to push Linux, you
atheos> should introduce people to an Operating
atheos> System that requires people to think for
atheos> themselves.
What I think atheos is trying to say here is that Linux ought to remain the difficult-to-use OS it started out as. Do you really believe Linux would be where it is today if it remained the difficult-to-use OS it started out as? If so, then I have a bridge I'd like to sell you. Or perhaps you're one of those 3l33+ h4xx0rz d00dz who draw self-esteem from using obscure OSes that no one has ever heard about? Which is why you'd object to Linux going mainstream because then you can't brag about being the 1 out of 4 people in the entire world that knows how to use it.
> What's GAY about source? Where do you think
> your RPMs come from, you idiot? Again, it all
> comes down to getting what you need to do what
> you need to do, and doing it your way. If you
> need to feel homophobic about source code,
> that's your problem.
YOU DUMB FUCK. Now I KNOW you didn't read atheos's post (the one I was replying to in case you forgot already). Again, I'll repeat what he said here just to help you out:
atheos> they don't rank anywhere near Slackware.
atheos> Shit, I can't even get anything to
atheos> compile on RH7.1 without some gay RPM to
atheos> throw at it.
Here, atheos is bitching about how he can't get shit to compile because obviously he neglected to install some dependent RPM (for example, he might be trying to compile a program which uses Gtk but he didn't install the gtk-devel rpm). Now, the problem here isn't due to RPM or the idea of package management in general. The problem is he's missing some dependencies. Now he can fulfill these dependencies by either installing the necessary RPMs (i.e. the Easy Way) or go and download the source, compile it, and install it to
All clear? Probably not. But you can't say I didn't try.
And as for the alleged homophobic remarks
thats just great ...
You can also get Slackware8.0 geeze, you would think I would at least get the distro right :-) Between Mandrake 8.0, Slackware 8.0 I think I'll going nuts.
anyhow you can get it here at http://www.lsl.com
Dave
Here I thought I was updated with 7.1. Oh well, I don't see a reason to upgrade. I just installed xfree86 4.1 last week. Everything seems to work fine, so why upgrade?
Slackware baby yea !!! I started using Slackware at version 3.3. And am now using 7.0 w/updates from slackware-current. This is a great time. Thanks Slackware team. Keep up the good work !!!
1. Chinese food. No soul food here.
1. I'm no punk bitch !!!
2. I'm no punk bitch neither !!!
I'm no punk bitch !!!
Nothing like taking several boxes for floppies into the lab at college, and spending several hours ftpingthe latest release of SLS (Soft Landing Software). Several hours not due to connection speed nor too many users downloading, it just took a long dealing with 30+ disks)
For the longest time, X configuration was not a problem since X was not supported yet. That was such a happy day when X actually worked with Linux...
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
I am only pulling 958 bytes/s from ftp1.sourceforge.net. While this could be attributed to my polack connection, I was wondering if there are any mirrors besides those listed under the Get Slack page on slackware.com (none of these seem to be updated with ISOs).
Thank you
--
>> From the time a woman is seven years old till she dies of old age, she is ready for action, and competent. -- M
I've used slack since 3.2 and its the most versatile distro if you know what you are doing. I think the simplicity lends itself to more security as well. A couple years ago, I ran the addicts.org shell server loaded with the kiddies and there was never a security issue with slackware. It seems like the newer distros are very uncomprimising when someone wants to 'do' something to their box that is outside the realm of your average newbie.
very stable, very good.
RPMs: 1) Ridiculous dependencies chain packages between themselves and some are not even related. 2) Can't recognized tarballs installation. 3) Difficult to build. 4) Efficient system check. 5) Efficient upgrades. TGZ and COMPILATION: 1) Loads of time to compile (Eg. KDE install) 2) You can choose any dir to install 3) If do above, you have to set LIBDIRS and PATHS environments correctly. 4) Works with just about anything. 5) Takes lots of space when compiling or storing. 6) Hard coletive upgrading. 7) Difficult system check. I just wanted all linux pre-compiled to be just like an .exe that you run and install like in Windows.
PS: YOU IDIOT, take note that I said "pre-compiled" and not source above.
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?
-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
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
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;
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.
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.
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!
----
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. :-)
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.
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