typodupeerror

## Replies from Slackware Founder Patrick Volkerding185

Well, here are Patrick Volkerding's answers to your questions, "Just in time for St. Patrick's Day. :)" as Mr. Volkerding himself put it. Read and enjoy!

Looking to the future? (Score:5, Interesting)
by phrawzty

Most (all?) of the other "major" distributions have gone the way of commercial and public acceptance (meaning ease of installation, and ease of use). Slackware, on the other hand, is still very much geared towards the linux user that already knows what they're doing. Do you plan on making Slackware "pretty", like the others, or do you plan on honing it into a development environment for power users? Or perhaps something else entirely?

Patrick:

But Slackware *is* easy! Trae McCombs even said he was very impressed with the ease of installation. And I think we set up the desktop (at least on KDE) with the nicest set of defaults. But I understand what you're saying -- many of the other distributions now provide a fully graphical installation. But, then you end up raising the hardware requirements, so it's a trade off. I do think keeping things primarily text based is the most flexible, then you can do things like installing with a serial console, and maintaining the machine remotely is more straightforward. Of course, I've been accused of being one of those "command line" kind of people...

Slackware, Inc. (Score:5, Interesting)
by mircea

Now that you are a separate company (spinning merrily off...), what will your distribution channel be? Will it still be handled by Walnut Creek? What about the Slackware-by-subscription option?

Patrick:

The retail distribution channel for Slackware will continue to be managed by the same people -- we're distributed through Ingram Micro and Frank Kasper and Associates (who were recently acquired by LinuxMall) so you should be able to find the retail version of Slackware at CompUSA, MicroCenter, Fry's, and a lot of other big computer stores.

We're definitely continuing with the discount subscription program. Our loyal subscribers have helped fund the project for many years now, and other than downloads that's where most of the copies go. For now the subscription signup remains on the Walnut Creek CDROM site, but we'll probably be moving that over to slackware.com fairly soon.

The name (Score:5, Funny)
by sanityimp

How did you come to the name Slackware? DId it hit you during a long nights of smoking from the holy frop with bob? Did stang climb in your window and wisper it in your ear while you were asleep? Was it the Xists?

Patrick:

Yeah, ok, I'll admit that it was SubGenius inspired. In fact, back in the 2.0 through 3.0 days we used to print a dobbshead on each CD. The name didn't come from Stang... I ran into him last summer and he asked me if that Red Hat organization was my company. I still think it's a pretty good name. I've been trying to put an ease-of-use spin on it, but it doesn't quite work. I think I'll just start telling people all the good names were taken to get them off the subject.

by SpaFF

I've been a Slackware user since 3.4 and absolutly love it. I don't like most package management systems out there and am glad that Slack doesn't use one (well, if you don't count pkgtool). Unfortunately this seems to be a bit of a problem when it comes to upgrading, seeing as you usually have to just reinstall from scratch and hope you have a good backup of your config files. How do you plan on addressing the issue of upgradability in future releases of Slackware, and do you think a better solution can be achieved through the install scripts without having to revert to an rpm-style package management system.

Patrick:

Although pkgtool is mentioned most often, there are also installpkg, removepkg, makepkg, and upgradepkg tools. The current system does install, track, remove, and upgrade packages, but lacks many of the extra features found in other packaging systems. Still, it *is* a real packaging system. We have used cleanly installable and removable packages since the start.

We're looking at ways to improve upgradability. One thing I've been discussing with the core team is changing the package naming format to be packagename-version-build-arch.tgz, similar to other distributions. The 8.3 filename length policy probably doesn't need to continue anymore, and having that extra information right in the filename will help people (or scripts) spot upgrades. I quit restricting package name lengths in the /contrib directory quite a while back and haven't gotten any complaints, so perhaps the time is right for that change.

David Cantrell is working on an experimental packaging system that would have a lot of advantages over our current system (or any other). It would track the user's config files and make it easy to transfer packages and configuration between their own systems. But, we're still evaluating it. It looks like the LSB is going to want everyone to use RPM, so we have to take that into account.

by iCEBaLM

I've been using slackware for years now, it was my first distribution back in the 2.x era and other then my little stint with debian for about a month I've been running it ever since.

It's been my observation that slackware has been the most "download friendly" distribution, by that I mean it's segmented into disk sets and you only need to download the ones you want to install it. Other distributions seem to obfuscate this process (redhat complains during install if it cannot absolutely find every package, as do many others).

The reason behind this I think is that they want people to buy it, so they obfuscate and make it difficult to download the distribution.

Now with Slackware apparently getting spun off into a seperate company, will there be more pressure to sell more units, and will this "download friendliness" change?

Patrick:

If anything, you're going to see a much stronger commitment to download friendliness. After all, a lot of our users are more technical and prefer to download. Sure, we like to ship paid copies as this helps support the project, but our first priority has always been to make things as good as we can, and then give it away on the net. We will never try to sell more copies at the expense of our user community. We've even been known to give free support to people who download.

• #### Another fine point (Score:1)

A lot of newer distros, including the one I use, tend to use the Windows "magic hardware" approach: if the hardware works, we have good magic; if it doesn't work, there's some bad magic at work, and we shake our heads and fire off emails saying "my sound card don't work." :^)

Quite frankly, this can be a bit annoying. A prime example is my personal system. I just did a clean install of Linux-Mandrake 7.0. I have a Voodoo3 2000. I received no messages regarding what card I had (strange) what kind of mouse I had (I know what it is, but this is also strange), but, despite the lack of messages, gee, it just kinda magically worked.

Problem: Linux-Mandrake 7.0 installs some X server I've never heard of: XF86_3dfx. If you get the RPMs (boo, hiss) off of linux.3dfx.com, this is essentially the SVGA X server with V3/Banshee support. On top of that, the XF86_3dfx server doesn't support the Microsoft IntelliMouse (strange; the darn things are so common now on newer machines.) I didn't get to test 3D libs on it, because I replaced the X server too quickly. :^) (NOTE: The regular 3dfx X server needs to be running in order for Glide to work. Again, boo, hiss.)

Quite frankly, I was a bit of an idiot about hardware when I installed Slackware. I stuck with it out of a genuine desire for a more stable, more configurable operating system. If all these folks need a brain-dead installer and no fussing with hardware settings, then I suggest these folks invest in Apple hardware. I believe that, thanks to their monopoly on the Mac market, that hardware support is a relatively low issue.
• #### Re:what's the diff? (Score:1)

Actually, if something doesn't respond to killing nicely, I doubt if a script is much more efficient than I would be on my own.

My personal feeling is that daemons *should* be written in such a way that one can simply kill them. Simply writing a script to get around this is just a sloppy hack to fix a problem.
• #### Re:Old School (Score:1)

Uh...I think he meant control==oldschool :^)
• #### my "most minimal" system... (Score:1)

...is an amd 386sx40 running an ancient(so old that I don't remember anymore) edition of slack with 16MB of ram, no cache, an equally ancient 80MB ide drive, 2x ide cdrom, 1MB isa svga card, isa nic, isa serial/parallel/ide-i/o card, motherboard, power supply, keyboard, mouse, and monitor. It works just fine as an x-terminal for surfing, emailing or whatever while the rest of the family hogs the rest of the (newer/better) nodes on the home network.

There's 20MB of swap included in there on that 80MB disk and when I chose to add x, the kernel source and development tools had to go. The last time I tried a kernel build took ~9 hours. ;-) What else would you expect from 6 b-mips!?!? Its current configuration has been stable for years, though since there's no ups and it's not on all the time, it doesn't have the uptime to match.

My daughter and her friends think it's cute with that little 14 inch display...

• #### Re:yes!! (Score:1)

My web server/mail server/home router is a 386DX-25 with 16megs of RAM running slack7. It has 2 10megabit cards and a wireless lan card in it and it does a fine job at routing. The only thing that taks a wile is kernel upgrades :)
• #### Re:Slackware (Score:1)

If I can't afford an ethernet card, I can't afford a CDROM either. If you want, you can email one to me.
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
• #### Re:Slackware (Score:1)

If you cannot afford either then you don't need a computer...break out a pen and paper and do your calculations that way. Consider a job
• #### Slackintosh (Score:1)

Check this out: slackintosh.exploits.org [exploits.org]. Slackintosh is (to be) Slackware for PowerMacs. As I understand it, installation can be done but Your Mileage May Vary. Unfortunately I only have one of these early PowerMacs with NuBus, which isn't supported by vanilla kernels, so I didn't yet have the chance to try it myself.
• #### Re:why I don't use Slackware (Score:1)

I won't defend Redhat, but Debian's "APT" ROCKS AND RULES, and I've never used a GUI to install a package. I apt-get update' and then apt-get install justaboutanything' and I'm done.

APT isn't itself a packaging system--it's Another Package Tool, which obviates the need to go searching for the right package. It keeps a database of packages and their locations (based on the source sites you provide), and grabs them (and all their dependencies) when you want them.

It is the most wonderful system I've used. If you're going to use packages, I strongly suggest using Debian/APT.

If you're not, well, go ahead and compile and use /usr/local/stow or whatever. It's invaluable to know /how/ to compile a package from scratch, but it's a nuisance to do it all the time.

--
• #### Re:_slightly_ O.T.: Favourite editor (Score:1)

There never was such a kernel, nor such a Slackware at the time.

Oops, you're absolutely right. My first kernel was 0.99 (not 59) and I seem to recall we used to refer to it as 0.0.99

The first version of Slackware I remember using was 1.2, but I don't remember what kernel came with it. Also, I know I used Linux before that, and I _thought_ I was on Slack already.

Oh, well. That was some years ago, so I'll have to blame my memory again. Now I'll just sit and watch the pretty colors and see if anything else comes back to me ;-)

BTW: joe is _THE_ editor.
• #### _slightly_ O.T.: Favourite editor (Score:1)

Ouch! I missed my chance to ask a question, but I'll do just in case P.V. is still around and would care to answer: Which is your favourite text editor? My intention is not to start a holly war, but I'd really like to know.

-alf
(Slackware user since kernel 0.0.59)
• #### Re:Package Managment (Score:1)

*ahem*

No one easily upgrades their libc. For that matter, upgrading libc is something that affects the entire system, so it shouldn't be done "casually" by any measure. That's just madness.

In any case, minor revision jumps aren't nearly as dependency-hostile as the jump from libc5 to glibc (v6), and when you make that jump, you might as well just reinstall a glibc-built version of your distribution, since you're going to be upgrading just about everything on the system at one time.

• #### Tab expansion is your friend (Score:1)

...and that about covers it ;-)
• #### Re:why I don't use Slackware (Score:1)

RPMs? rpm2tgz; installpkg works great.

Where do you find rpm2tgz? I have searched forever trying to find that, and ended up with nothing... except "rpm2cpio", but cpio is, IMNSHO, brain-dead.

• #### In defence of RPM (Score:1)

You keep fighting with RPM, overriding dependencies, installing packages directly from source and generally using it against the way it was designed and then you wonder why it's not working for you?

The dependencies are there for a reason. Sure, they can sometimes be a pain, but so are seat belts and type checking. Overriding dependencies is possibly, but I rarely find it necessary.

RPM works just great if you work with it instead of against it. Learn how to build RPMs. It's easy. You can pick it up in a few hours just by looking at .spec file. When I get a package with no RPM I make one myself and upload it to contrib.redhat.com. Updating an RPM to a newer version of the package is even easier.

----
• #### Re:SlackPPC (Score:1)

It's not slackware, but Debian also runs on powerpc [debian.org]. It's even going to be part of the next official release.

The BSD that runs on MacPPC is NetBSD OFPPC. [netbsd.org]

And SUSE has a page [suse.com] on installing SUSE for ppc.

For laptop installation hints, look at the archives for the LinuxPPC Mailing List [linuxppc.org]. If your laptop is a pismo (the ones with firewire) support might not be 100% there yet; best bet is to post to the mailing list, several of the LinuxPPC kernel developers subscribe, as well as the author of the LinuxPPC booters (miBoot, yaboot, and BootX).

The same kernel and booter(s) are used for all LinuxPPC distros, so questions about booting and installing are appropriate on that list, because many list members have experience with those issues.

• #### LSB and darwin (Score:1)

I agree with him on the LSB stance I would like to see XML used alot and that wont be in LSB for a while the reason we are here today is because of diversity regards john
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
• #### Re:what's the diff? (Score:1)

Doesn't handle switching between runlevels well? How do you figure? There's an rc file for each runlevel, and switching between them causes the appropriate file to get run.

Probably the most common thing is going from multiuser to singleuser. Doing so will cause various services to be killed off, leaving only what is necissary running. When you jump back into multiuser mode, the rc.M file will get run, bringing all the network daemons and such back up.

Everything that needs starting and stopping is listed in the runlevel scripts. How is this not handling things well?

• #### Re:why I don't use Slackware (Score:1)

as a recent born-again slacker (the last time I used it was, i think late 2's early 3's-i strayed from the true path and have repented) i found rpm2tgz came in real handy in converting some of my rpm's of my favorite proggys on other CDs so i could use em. rpm2tgz and installpkg rule!
• #### Re:Are FTP installs practical? (Score:1)

Besides, even back in 1995 I installed Slackware on my trusty 386 by downloading it via ftp. I forget what the release it was with kernel before even 1.2.13.

All I ever needed was A, AP, D, K, N packages. One or two overnight downloads over 14.4k modem :-)

Allow me to explain, in the USA today we have an exploding growth of very high bandwidth service providers. We also have no usage charges like you do in the UK.

Excite@home, for example, offers up to 3mbps (300kb/sec vs. 5.6kb/sec of a modem) download rates for only $40/month, unlimited connectivity time. I chose something a bit more interesting, an SDSL line which gives me 416kbps/416kbps burstable uplink/downlink via frame relay. Yes, I have a standard 19" rack cabinet in my computer room with all my extra equipment :-). SDSL a bit more expensive, at$235/month, but well worth it for my needs. Besides, I can tell you the T1 local loop and ISP charges and you won't want it.

I can not think of why you would want to download something for 30 hours, you clearly do not need all of those downloads. I had a development system with X11 deployed on 200mb partition. The less junk is installed, the more easy it is to secure the system.

Since you seem to know what you are doing, you may actually prefer Slackware's streamlined way of doing things. And if you mention at a job interview that you are a Slackware user instead of Redhat 6, you will occasionally get different looks, especially when not chatting with an HR drone but with a senior team member.

Yes, I know exactly what I am doing and what the files I install are for, and that's why I choose Slackware. :-) I use SuSE for some managed installations as well with custom automated installation scripts. By the way, I am one of those types who actually reads docs with more R* docs\R* Makefile docs\* src\c*h
--
Leonid S. Knyshov
• #### Re:what's the diff? (Score:1)

Expert mode new in 4.0?

I seem to recall I was able to customize my slackware installations 5 years ago :-)

I don't remember the vocabulary used, I am in NT environment for the past two years (I accept your condolences, and about to go back to CLI-friendly environment soon). I think it was related to custom tag files.

Yes, I really dislike using high-level all-in-one administration tools such as the dreaded linuxconf or Sun's admintool. I am not a newbie, so don't treat me to the pretty X11 interface that I do not need to have even a trace of presence on my servers. rm -fr /usr/*/X11 is capable of doing that job with great success :-)

Now I see companies deploying Redhat 6 all over the place. Well, it is their choice, but if I am called in to consult, I advise them of advantages of switching distributions if they are open to that. I have yet to have a customer that wanted to go back :-)

Besides, how hard is it to create your shell script-based high level admin tool? Just make sure not to skip on the su step :-)

Used to help out in #linpeople before linpeople.org :-)
--
Leonid S. Knyshov
• #### Re:Getting rid of 8.3 package names? (Score:1)

ksh - the official shell of Korn music fans!!!

Seriously though, it happens to be my favorite shell and if I don't have it on a box I happen to be working on, I deploy it very fast.
--
Leonid S. Knyshov
• #### Why you don't use Slackware is why I DO use it. (Score:1)

Having used Redhat and RPM for 3 versions, and now back to Slackware, I'll let you know that the packaging system was one of the major reasons I came back.

Still, people are different just as you and I are obviously different in what we want in a system. The ideal system is one where we both can do it the way each of us prefers.
• #### Re:LSB and darwin (Score:1)

I'm not sure if I will like LSB or not. But if it adopts XML for the config file formats, you can be sure that I will not like it at all, and not use it at all.

What would be best is to provide for diversity. XML seems fine for programmatically generated data, such as from GUI config programs (which I don't use), although HDF doesn't seem to detract from any of the capabilities, although it is a lot easier to manually type in for those of us that prefer to configure our systems with vi/pico/jed/emacs or such. The existing config files also work reasonably well.

IIABDFI.
• #### Re:Slackware as the foundation (Score:1)

That probably will happen. Right now it's all experimental. I'm running it on production servers only because I can be right there to monitor it. There is just a little bit of conversion to be done to the daemon scripts but that means they have to be tested. Since I don't run all the services that come in most distributions I'm not the best person to test them. I guess it would help to have a few more people trying it out who could add more scripts and test things out to make sure its not goofed up somewhere. I'm just not sure where is the place to post something that's technically still in development. Any ideas? Would freshmeat.net be right for that?
• #### Re:package management and slackware (Score:1)

Hopefully I can get my questions answered without starting a flamewar. I guess we'll see...

Well, hopefully one doesn't start and spoil an interesting discussion that we could have

Then Debian and RedHat arrived, and I realized how out-of-control things had been under Slackware (and also Solaris and SunOS). The ability to have a tool justify the existance of every file installed on my system was amazing from a sysadmin's viewpoint. And more than that, I could find out what other programs depended on it. This was wonderful, especially for shared libraries.

Do you want that tool to require you to be in front of, or connect to, each and every machine individually, just to configure your network? While having the tools is great when administering one machine, as long as the tools work well and let you do everything you want to do (something I found lacking), what about administering a whole network? The solution I have found is that I need to build a lot of my own scripts. I want things to take care of themselves as much as possible so my script tend towards automating. Fortunately I can just ignore the GUI tools. However, I do have to measure a system I might choose on the basis of how easy it will be to make those scripts work (among other things). Slackware's simplicity makes it the winner more often (though not always).

Because of this experience, I've never really looked back at Slackware. But is it true that Slaskware now has some sort of package management? I must admit I don't really like the convolutions built into the RedHat configuration files -- does Slackware still do this better? Will Slackware warn me if I try to uninstall some part of the system that some other part depends on? Can I tell Slackware that it isn't allowed to install over a particular file (because I've done something special with it?)

What I have always advocated is that as many packages as possible (and I believe that to be most, including all end user applications) should be entirely installable by putting all their files into a directory somewhere (/opt seems appropriate) named according to the package. Deleting a package would be a matter of doing rm -fr on that directory. Everything else should be designed and implemented to be smart enough to figure out how to deal with dependent packages in context. That means, if it can do something better if the other package is present, check to see if it is present and do so, else do the same old thing. If it absolutely has to have it, check to see if it is there and give a clear explanation if not. I really don't see that much need for package management if things are organized right (which they have not been throughout the history of computers).

No, Slackware will not warn you about uninstalling dependency resources. One of the things I have learned through years of supporting mainframes and UNIX, and dealt with MS Windows, is that when you start uninstalling things, reinstalling things, upgrading new versions, and the like, what you end up with is a messed up computer. Sure, package management attempts to address this. But why uninstall it in the first place? Disk space is cheap. Buy a bigger harddrive.

With one exception, I've always installed everything when I install any Linux system, and for the most part have done so with BSD/OS, IRIX, and Solaris. I did once upgrade an Redhat 5.1 system with 5.2. Although there were no dependency or other package problems, the machine just never did run right afterwards. I backed up my own files, wiped off the drives, and reinstalled Redhat 5.2 from scratch (everything) and then it worked fine.

My recommendation is to do planning. Decide what you do need and what you don't need in a new system. Install everything you do need. Do not uninstall anything you don't need. When it's time to upgrade, install the new version from scratch. If this machine needs to be up all the time, do that on a different machine and let them trade places when ready, or perhaps one service at a time (giving each service its own IP address in advance makes that easier to do). Of course not everyone has spare machines around to do this, so it can't be a universal solution. But the more it becomes an accepted practice, the more such machines can become available (if you can sell management on the idea of 99.99% uptime during the transition).

• #### Re:No RPMs == why I use Slackware (Score:1)

That's the fault of the applications. People who write software should learn that just putting files everywhere is a pain for the system administrator. Then they want us to make every system look identical.
• #### Re:Slackware as the foundation (Score:1)

Part of the process of making an RPM from the tarball is to compile and install it anyway, then identify what got installed so that can be integrated into the package.

Oh look what I get when I "install" a SRPM ... a source tarball.

I've done these things and made the investors in Advil more money.
• #### Re:In defence of RPM (Score:1)

I'm just not the kind of person who is oriented to doing things that way. Interesting that you mention type checking as I prefer programming languages with as little as possible. I put up with what is in C, despise Pascal, avoid C++, grumble at Perl, and find PHP and Pike more fun. I guess maybe this comes down to a difference in personality types?
• #### Re:why I don't use Slackware (Score:1)

Yes, but it's that failing to work which keeps me from liking it. If it were reliable...
• #### Thanks (Score:1)

Thanks Patrick for answering my question and I'm glad to know that the install and package manager programs are getting revamped. Keep up the good work!

-Lee

• #### Re:Alternative suggestion... (Score:1)

Sorry, I have to bite here.

RPM's depend based on libraries and pretty much libraries alone. Thinking about it, it's not that bad an idea. With a little luck you should get proper versioning through good source code. That luck rarely exists though, a lot of webpages that provide RPM's for download say 'if all else fails, install with --nodeps'.

Debian's packages (.deb) is quite amazing though. You can either blatantly depend on one package or depend on a metapackage. Metapackages work better for things that aren't libraries. Say you have someprogram and someprogram needs run time data to go. But someprogram has a few different types of run time data, only some can be installed. So instead of having someprogram depend on run-time-a or run-time-b or run-time-c just have it depend on someprogram-runtime and have each run time package provide this metapackage. An example of this lies in the vim package where there are a lot of different vim executables (plain vim, vim w/ python bindings, vim w/ perl bindings, etc) that all provide 'vim'. Any other program requiring any version of vim can rest easily :-)

In the end, debs with their excellent dependencies and apt (a program that installs packages in a Wise Way in relation to these dependencies) make keeping a Debian system updated very easy. Disclaimer: I love Debian. I have made .deb's. It was all good.
• #### Re:my "most minimal" system... (Score:1)

Kernel 2.2.8? Are you sure that somehow the kernel didn't travel back in time and lodge itself in place on your slack2.3 cd?
• #### Re:Slackware as the foundation (Score:1)

SourceForge [sourceforge.net] perhaps?

FreshMeat is for application records and announcements, SourceForge is for projects in development.

• #### Re:what's the diff? (Score:1)

SysV-style init makes it easier for automated installers to modify the scripts. OTOH, I prefer BSD-style init, since it makes far more sense for the human eye.
• #### Re:yes!! (Score:1)

Absolutely, if Linux is what you want to run.

I recently refurbished an old 486 box for a friend. In the interest of experimentation, I tried all the major Linux distros as well as FreeBSD on it before settling on the final choice. Of all the Linux distributions, I found Slackware was by far the easiest to get running and configured and it was also, interestingly enough, by far the best-performing Linux on the old 486. I eventually decided to but BSD on it, but only because BSD included some packages I needed that Slackware didn't have on the CD.

Slackware is my favorite Linux. How about a port to PowerPC? ;-)
• #### Re:why I don't use Slackware (Score:1)

The packaging system may not be quite as good as that of BSD, but it's quite a lot better than RPM. :-)
• #### Re:SlackPPC (Score:1)

PPC specialists? It's another RedHat-knockoff, only it's a knockoff of LinuxPPC, which is a RedHat knockoff, ad nauseam.

As always, I applaud the LinuxPPC folks for their hard work on porting the kernel, but unless what you want in a distribution is last year's RedHat, their distro leaves a great deal to be desired.

Debian for PPC, sure, but it's not available in a stable release, you can't (officially) get a CD, and all the other problems one associates with Debian, such as packages that are 2^20 version increments from being current, thanks to the glacial QA cycle. FWIW, even the ultra-conservative BSD releases usually have newer packages than Debian-stable at any given point in time. It's amazing how good Debian is, given how chaotic the development cycle is beneath the veneer of seriousness ("Outer Space, powered by Debian").
• #### Great news and thanks to Patrick! (Score:1)

Well, I was kind of expecting a "no" on the part of my question about public NFS, but I am very glad to hear that FTP install is in development and will be out eventually. I am also glad to here that packages will have more descriptive names for better upgradability and installation. Slackware seems to be getting better and better.

Again, thanks to Patrick V. for an excellent distribution and for taking the time to answer these questions.
• #### Re:Slackware as the foundation (Score:1)

RPM basically came across to me as a lock-in feature. That means, once I start using it, I have to keep using it to get any benefit from it. That also means, I have to wait for updates to come out in RPM format before I can upgrade something if I want to keep my RPM DB consistent. I would really much prefer that the presence or absence of a package be predicated on whether the package actually is installed, not whether some DB entry says it must be. I really dislike it when a DB that claims things is out-of-sync with reality, and that is a problem I encountered with the Redhat Package Management system.

I generally consider it a bad idea to compile and install from source on a rpm based system. I prefer to take the new source tarballs and make an updated rpm from them. It's an extra step in the compile / install process, but it's well worth it. Especially when you start looking at having to keep multiple machines updated. And if you don't like some of the options that redhat choose when compiling your favorite source, install the srpms make the changes and create a new rpm.

• #### Re:yes!! (Score:1)

bah you disk space hogs. ive installed slackware on 14 386 machines with 8 mb of ram and 40mb hard drives with 8 megs to spare on each running as print servers. this was slackware 3.5 and 4.0 (although 4.0 hogs one to two megs more..)
• #### Re:why I don't use Slackware (Score:1)

tar.gz is better than the various implementations of rpm...
• #### Re:Slackware (Score:1)

If I can't afford an ethernet card, I can't afford a CDROM either. If you want, you can email one to me.

You can't afford $5 to$10 for a used NE2000 clone from your local PC Parts shop?

Dang, do sell some plasma or something.

Seriously, used NIC's are dirt cheap.

George
• #### Re:Boxers?? (Score:1)

Boxers??? Don't the sides of your scrotum get sweaty?? And doesn't your penis tend to fall out? Sheesh, give me briefs any day.

Actuallly, the sweaty and falling out feeling I tend to find with briefs. Not to mention the binding.

With boxers, everything just hangs loose, like god intended to. Plus, they come in silk.

George
• #### Re:Getting rid of 8.3 package names? (Score:1)

Tab completion!

Bash has it, so use it.

Yes, bash has it but <holywar>why aren't you using tcsh, which has autocompletion plus all that C-shell goodness, yum yum.</holywar> B->
• #### Re:Getting rid of 8.3 package names? (Score:1)

I actually pretty much agree, and don't use (t)csh for "real" scripting. (For "do this, then that, then the other", it doesn't matter.) But for my typical command line, I prefer (t)csh; love that "foreach x (*.txt) mv $x$x:r.html end", that "setenv" rather than "export", and so on. Of course, that prefererence might be largely inertia.
• #### Re:SlackPPC (Score:1)

Most of the PPC Linux distros run on G3s and G4s. There was some trouble with Sawtooth G4s at first but that too has been conquered; see http://www.linuxppc.org/docs/sawtooth-install.shtm l [linuxppc.org]. I don't know what export issues you are talking about; to my knowledge there are none. Of course, iBooks and iMacs are G3 based, and they boot linux fine (see http://imaclinux.net [imaclinux.net] for details). Also keep updated on linuxppc news at penguinppc.org [penguinppc.org], a cool site.

Personally I can't wait for SlackPPC or Slackintosh to be usable. I installed the beta of SuSE and found it more intuitive and easier to use than LinuxPPC (which can be messy), but both are RPM based and I almost always screw up the RPM database after a few weeks of use (sigh - yeah I know, this is my fault, but it isn't a problem with slackware). I haven't messed with Debian yet but that might be a good interim alternative.

DrBen

• #### Re:yes!! (Score:1)

Absolutely!!!! I installed slackware on a friend of mine's 486, and while it can't run X, it still runs beautifully!
-Paul
• #### Why I LOVE slackware (Score:1)

Dude, I used mandrake for a week or so, and it corrupted my RPM database twice. I couldn't install new packages because the database was hosed. FORGET RPM, and all it's variants. Give me tgz any day of the week!!!!!!!
• #### Re:what's the diff? (Score:1)

Most of your complaints come from a lack of understanding any other distro. I have tried RedHat, Mandrake, and Debian, and I work on Slack boxen rather often.

I prefer RedHat. Contrary to other people's comments, RedHat doesn't care if you install from tar.gz's. Almost all of my apps are compiled and installed from source.

I let RPM manage glib, gtk, gnome, kde, X, and other such things with heavy dependencies. This is the main reason why I have a working installation of enlightenment 0.16.2 with eSound and Gnome and support for all my KDE apps.

As for init scripts, that is a matter of opinion and circumstance. Sure, BSD-style uses less files and no symlinks. But how many times have you tried to shut down just one service? How easy is it to turn a single service on and off? You might not think that that is a common task. I haven't had much use for it, but I have had some. I have fetchmail running as a daemon, and at times (for procmail testing) I don't want it to botch my testing. So I turn it off. Maybe you would prefer dealing directly with fetchmail, I kinda like being able to say "stop" and "start".

I have installed RedHat on a 80MB hard drive also. On a 486. Oh wait. Thats what you just said too. Were you implying that only Slack could do that?

I've never had any dependency problems, besides silly things like me forgetting to update gtk before gnomeicu. Oh. Wait. That was from source. That's what dependencies are. Its better than just having it install and segfault.

I find the custom installs rather easy. I tell it what I want. It says "You forgot that PackageA requires PackageB", so I either add PackageB or remove PackageA. I haven't had any problems with them at all. I don't really have any problems with any of the install programs for any of the distros. They get the job done.

As for someones silly comment: Yes. RedHat lets me modify .conf files too. To say "Slack lets me modify .conf files easily" is a joke. Of course it does. Just take your favorite editor as root after the files in /etc. What makes you think anything is different for RedHat?

In the end, the distro is just where you got it. My system is far from being a RedHat 6.1 installation. I now run a SSL enabled version of Apache, ssh, ProFTPd, no inetd server, a newer XFree86, a new version of gnome, KDE, and elightenment, and netatalk.

In the meantime, all my Slack using friends can't get any sound to come from their speakers and are using enlightenment 0.15 because they cant get the update to gtk and enlightenment to work.

That, in the end, is the difference.

• #### Re:Public NFS Server (another in UK) (Score:1)

European users can note that there's also an NFS server [sunsite.org.uk] at sunsite.org.uk [sunsite.org.uk] - you can go to, say, 193.63.255.4:/public/packages/linux/slackware/slac kware-7.0/slakware
• #### SLS (Score:1)

Speaking of old school? Who else here remembers SLS, the first linux install I ever used?

Now there was control... I think I blew the thing up 5 times before I got it to install right.. of course I knew less then then I do know now :)

Minupla
----
Remove the rocks from my head to send email
• #### Old School (Score:1)

Not saying anything bad about Slackware at all, but just saying that he is from the old school, and I think Slackware will stay a traditional Linux distribution, unlike the big changes going on with Debian, RH, etc. So for all "command line" people, you needn't fear.

• #### Lets make this incredibly simple... (Score:1)

For the people who have complained about dependencies and matching them properly, consider one of the following files within your package for assistance:

INSTALL

These two files are included in basically any sane source package. It always contains compiling instructions (step by step) as well as all the necessary dependency information. Using your eyes and your choice of text editor will result in your accumulation of all the necessary information to deal with any given dependency issue.

NO installation system will replace literacy and common sense. PLEASE use your mind.

slack/sparc would give me a reason to dump OpenBSD and NetBSD on my sparcs!! oh, the joys of slack.
• #### Boxers?? (Score:2)

by Anonymous Coward
Boxers??? Don't the sides of your scrotum get sweaty?? And doesn't your penis tend to fall out? Sheesh, give me briefs any day. And no, this isn't any more off-topic than the question was in the first place.
• #### Re:yes!! (Score:2)

by Anonymous Coward
>two, im have an old 486 that i want to put linux on. would slackware be my bet bet?

IMHO, yes. Most other _popular_ distros are big on graphical installers (graphics are going to be dead slow on an old 486), have a billion unnecessary Daemons running at boot slowing performance (although Slackware is somewhat bad for this). Also, you can pare down Slackware to about an 80 MB install, and still have reasonable functionality.

Now, of course, there are distro's that fit on a disk (likt the linux router project), but if you want to actually use the box as a workstation, and not a server, these are of no interest.

They all the distributions on the machine though. I have a feeling that Slackware and possibly Debian are going to give an install that will run reasonably well on a 486.

All in all, just try a few distros until you find one that suits you. Something that really separates Slackware from the other distributions is it's init system. Slackware is smilar to BSD, others use the SYSV style.
• #### Re:SlackPPC (Score:2)

It's amazing how good Debian is, given how chaotic the development cycle is beneath the veneer of seriousness

One could say the same thing about the linux kernel, or any number of other free software projects.

--
• #### Re:why I don't use Slackware (Score:2)

Try alien (sorry, I don't have the URL handy); it converts between rpms, debs, tgzs and slps.

• #### TAB completion is evil (Score:2)

Lemma: If csh doesn't have it, then it is evil.
Proff: This old foggy started when csh was the best avaiable and can't be bothered to switch
csh doesn't have tab completion.
Tab completion is evil.
QED
excercise 1: Use lemma to prove tcsh is evil.
exercise 2: prove all sh dervitives are evil.
Exercise 3 (for advanced students) Prove that sh is evil but not as evil as any other shell

Seriously though, you can't assume that your favorite shell is the one I use. For that matter your favorite shell may not be avaiable on the computers I use, which include version of UNIX from when Unix was direct decendant of Bell Labs code, and not standard that could be applied to any OS.

Note that the converse is not true, as csh is very evil.

Besides the above, the unix way is not 8.3 filenames, but smaller ones. Unix would have only two letter filenames allowed, but the limit to uniqe two letter filenames is smaller then a typical /ur/lc/bn, and the early test to make sure the new longer filename filesystem would work changes that path to /usr/local/bin.

P.S. I have this nice swam^h^h^h^h parcel of land in Florida if anyone is interested.

• #### package management and slackware (Score:2)

Hopefully I can get my questions answered without starting a flamewar. I guess we'll see...

Slackware was the first Linux distribution that I ever used. I helped administrate a small- to medium-sized unix network that included a small pile of Slackware Linux machines (along with some Sparcs, some Sun 3/60s, some Alphas, etc.). It was fine. I had no complaints, and it's the distribution that got me hooked on Unix in general and Linux in particular.

Then Debian and RedHat arrived, and I realized how out-of-control things had been under Slackware (and also Solaris and SunOS). The ability to have a tool justify the existance of every file installed on my system was amazing from a sysadmin's viewpoint. And more than that, I could find out what other programs depended on it. This was wonderful, especially for shared libraries.

Because of this experience, I've never really looked back at Slackware. But is it true that Slaskware now has some sort of package management? I must admit I don't really like the convolutions built into the RedHat configuration files -- does Slackware still do this better? Will Slackware warn me if I try to uninstall some part of the system that some other part depends on? Can I tell Slackware that it isn't allowed to install over a particular file (because I've done something special with it?)

These are the reasons I stopped using Slackware. This in no way decreases how grateful I am to Patrick, or how glad I am that there is still a minimalistic, tgz based Linux distribution.

--Chouser

• #### Re:Alternative suggestion... (Score:2)

An example of this lies in the vim package where there are a lot of different vim executables (plain vim, vim w/ python bindings, vim w/ perl bindings, etc) that all provide 'vim'. Any other program requiring any version of vim can rest easily :-)

Yep, that sounds like a really nice feature. All those packages can provide "vim", on which other packages can depend. That way, it doesn't matter which vim you've got installed, so long as at least one of them is... which is why RPM provides exactly the same functionality (you'll need a version newer than 3.0.3, but that's nearly a year old now -- almost prehistoric in Linux terms :-)

• #### RPM in LSB? (Score:2)

It looks like the LSB is going to want everyone to use RPM, so we have to take that into account.

This isn't quite true. The idea is to have a standard LSB packaging format, which can be used for distribution-neutral packages. Each distribution will be responsible for providing suitable tools for converting LSB packages to their native package format, and handling their subsequent installation. It is true that the current plan is to use RPM as the basis for LSB packages, simply because it's so widely supported already. As the spec says: If you don't like this, then please propose an alternative.

• #### Re:Alternative suggestion... (Score:2)

You download a source package guaranteed to compile on your system so you get an optimized system

You're thinking too much like a home user. Corporate users don't want to have a software development kit on every machine. Also, if it needs compiling, it's going to be too slow for any moderately large app.

Of course the dependency checks of either blow the pants off RPMS. Care to give some examples? I've yet to see any real world examples where .deb dependencies are better than RPM. Yes, .deb can have more complex boolean expressions in dependency checking, but in real life, RPMs dependencies are sufficient to achieve everything that's needed.

• #### Re:Slackware in general (Score:2)

Not arguing that point, just sick of people saying "why can't everything get installed in /usr/local like it wants to be by default."
• #### Re:Slackware in general (Score:2)

The Linux filesystem standard states that nothing the distro installs should go in /usr/local. Makes sense if you think about it.
• #### Re:Slackware (Score:2)

I can't get a job. All I have is this dang MCSE.
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
• #### PLIP is your (laptop's) friend! (Score:2)

Also try PLIP to install through the parallel port. I share the cdrom drive on my desktop system via NFS, and install from there. I forget, tho', if SWare allows NFS installs. Nowadays it's even easier, actually, as I now do it through a pcmcia network card, which the install floppy can detect. I run SuSE, tho', so YMMV.
• #### Re:Getting rid of 8.3 package names? (Score:2)

easily solved by typing in "installpkg workbone[TAB KEY]"

:)

autocompletion is a wonderful thing

Sgt Pepper
Lame Sig Shamelessly Ripped from
Fortune:

Boy, I sure wish that I could be in the
• #### Re:Slackware as the foundation (Score:2)

\begin{rant}

I agree completely on the RPM stuff, my RPM database usually ends up in quite a mess in a very short time. I'm one of those people who thinks it is way easier to say "./configure ; make ; make install" than to search the net for an RPM which:
a) Probably don't exist yet
b) Probably wouldn't install anyway without tons of other dependencies, and
c) Is more difficult to find.

Now, someone will probably say something along the lines of "create your own rpms then". Maybe I would have, if it wasn't too much hassle, and if RedHat had actually given me any clue as to how it's done. The RH (5.1) manual just (barely) tells me how to install and remove packages, by example. It doesn't even summarize the switches in any kind of list. On the subject of source, there are exactly two example rpm commands, both of which assume that you already have an SRPM - "install from SRPM" (-iv) and "build an SRPM" (-bp). Nothing at all about how to transsubstantiate something to an srpm. That's not very useful when you're sitting with a nice .tar.gz.

It's a funny thing that most sources come with an INSTALL file which tells you how to build and install it, but I have never seen any INSTALL file which tells you how to create an rpm of it.

And you can't even get the files from an RPM without serious black magic, an "--extract" flag to RPM (working like good-ol' "tar xvzf") wouldn't hurt a bit. I always end up trying to work out the deep voodoo of cpio, which is not a trivial task (for example, it doesn't automatically create directories for me). Occasionally I find myself wanting the files without installing the package, and this bugs me every time.

So, the end result is that I use RPM for the initial install (which is not very often), and then gradually let the system migrate into a home-brewn setup, where a large percentage of the functionality lives in /usr/local/bin (and /usr/local/gimp, /usr/local/egcs-2000306, /usr/local/mpich, /usr/local/ssh, /usr/local/matlab, ...).

\end{rant} (and I didn't even get started on the init scripts...)

• #### No RPMs == why I use Slackware (Score:2)

I don't like those RPM managers. You start installing manually, you bodge up the package manager database. I really like Slackware NOT having RPMs.

Yes, I know I can install from source and bypass the package manager. But then the package manager falls on its face because it doesn't understand the libs I've added. So I'd rather just not have the danged thing to start with and do everything the source way. Besides, then I can set the options *I* want, and I don't have to whine about no packages for my particular machine :-)

--
• #### Re:TAB completion is evil (Score:2)

csh has file completion. Hit 'escape' instead of tab.

• #### Re:what's the diff? (Score:2)

I have so often wondered why debian, redhat, suse, et al have gone with Sys V style init scripts. BSD init is so much more concsise and easier to maintain it just seems the logical choice to go with.

Because with one script, you can bundle the stop, start, restart (and i tend to add "status" and "kill" as well) into ONE script. Then insert it anywhere in any init process without opening and modifying any existing files, requiring a script to puzzle out the format of the file. And only have to maintain one file.

If you hate SysV init so much, you can always just edit only /etc/rc and delete all the init scripts (at least with solaris's init). I thought unix was about orthogonality tho?
• #### Re:what's the diff? (Score:2)

I usually hate this kind of messages, but:

I agree!! :)

--
• #### Re:Slackware as the foundation (Score:2)

Just use rpm -tb sourcetarball-with-specfile.tar.gz and it'll build you a rpm in /usr/src/redhat/RPMS/i*86/ THen just install it. Easy.
• #### Re:what's the diff? (Score:2)

Slackware uses the BSD-tyle init scripts (/etc/rc.d/rc.M, rc.inet1, rc.inet2) which, IMO, is easier for newbie and guru alike to use.

I have so often wondered why debian, redhat, suse, et al have gone with Sys V style init scripts. BSD init is so much more concsise and easier to maintain it just seems the logical choice to go with.

-- iCEBaLM
• #### SlackPPC (Score:2)

I'd be in heaven! I'd also be willing to help. I've been using slackware a long while, and just got a new G3 notebook. I'm not excited about any of the RH-derived ppc distros, and even took a look at Suse and *BSD--both seemed to advertise ppc support, but I couldn't find the download, order a ppc CD, or locate installation hints for the G3 laptop anywhere.

Any pointers to slackware/ppc would be appreciated!
• #### Boxers or Briefs? (Score:2)

So now that Slackware is a marketable company, where can I pick up a pair of Slackware logo-emblazoned boxers? :)

_____________________
.sig Instructions
step one: place .sig here
• #### I say it before and I'll say it again, (Score:2)

I say,

Textmode install today,
Textmode install tomorrow,
and Textmode install FOREVER.

Thank you Patrick for the floppy friendly distro. otherwise my laptop wouldn't have made it.

• #### You ask - you get (Score:2)

Why wait - the appropriate garment already exists [bobwerks.com]
here

Send lawyers, drugs, and money. Dad get me out of this. -- Warren Zevon
• #### Re:Getting rid of 8.3 package names? (Score:2)

Tab completion!

Bash has it, so use it.

installpkg work^T
-> installpkg workbone-x86-4.2.1.tgz

:-)
---
• #### Re:why I don't use Slackware (Score:2)

Not too hard.

How hard is it to burn a CD from the ISO, or setup an NFS server on another machine?

Not too hard.

... Installing Slackware is not dependant on a method of retrieving packages. If you *really* wanted to try Slackware, you'd just download the packages to a dir, mount it, and choose install from a premounted dir.

As for packaging system.. I don't know why you say that. RPMs? rpm2tgz; installpkg works great. Debs? Well, people usually also have RPMs alongside those ;) Source tarballs? They're great, and the ones I always use.
You have many options when compiling a program. vim, for example, lets you use a lot of different widget sets for the gvim front end, which are compile-time options. And you can use a different compiler, perhaps pgcc or some such, as well as tweak the program at will, and submit patches to the maintainer. I love helping make programs better.

Again, it's all a matter of are you serious about running Slackware, or more of a "GUI all the way" guy who should stick with RedHat. I know what I *love* :-)
---
• #### Re:SlackPPC (Score:2)

Ever consider Yellowdog?? They are the PPC specialists... I've got a copy here waiting for a B50 that won't IPL..
• #### Re:Boxers or Briefs? (Score:2)

Hmm.. Real 'Slack wear'.. The marketing possibilities are endless! You could have SlackWear T's, socks, anything! A pair of boxers would be damn cool..
• #### Re:SlackPPC (Score:2)

They are specialists not because of the code in the distribution, nor their repackaging of it, but because of their support.. I spent two hours on with one of their techs fighting an UNSUPPORTED AS/400 through IPL of a D-tape, and another hour session helping me through an uncooperative network adapter in a 6000.. They have my vote as the third best support in the industry! (CTC and IBM being 1 and 2. CTC gleefully spent 50 manhours debugging an intermittant failure in a controller based on a vague suspicion, and IBM kicks ass for me every time I have a NON-IBM cmos question!)

Next??
• #### why I don't use Slackware (Score:2)

1. no ftp install
2. packaging system inferior
Pretty simple. It's unfortunate that we didn't get any commitment from P.V. to add either of the two things that most detract from Slackware's usefullness.

Warren Postma
• #### Re:why I don't use Slackware (Score:2)

1. no ftp install
2. packaging system inferior

So don't use it. For me, it was:

1. usable floppy install
2. lean, non-obfuscatory, packaging system

I can install a slackware system in well under half an hour in which I can have reasonable confidence that source tarballs from anywhere on the net will compile under it. With DeadRat, I end up pulling my hair out just trying to figure out which RPM contains the library I need, then installing the RPMs that it depends on in the right order.

Slackware is well named. It really does have more slack. I can feel it oozing slack every time I install it.
• #### Re:why I don't use Slackware (Score:2)

He did say it would become better.....
I just hope he doesn't stop using tar.gz files, I would stop using slackware if he did!

But most importantly: usefullness!=easy-to-install
To me Slackware is the most usefull because I can modify the config files very easy!

Grtz, Jeroen

• #### yes!! (Score:2)

one, it was a nice, funny topic

two, im have an old 486 that i want to put linux on. would slackware be my bet bet?

• #### Alternative suggestion... (Score:3)

on Friday March 17, 2000 @10:06AM (#1195523) Homepage
(Dons flame retardant undies)
Ok. I know this isn't the place to propose an alternative, but IMHO either Debian packages or the FreeBSD ports system is better than RPMs.

(This is the part where I start talking out my ass cause I don't know anything).
What I'd love to see is some sort of cross between the FreeBSD ports and Debian packages. You download a source package guaranteed to compile on your system so you get an optimized system (ala FreeBSD) and then a script runs that installs it and maybe does a little basic configuration for you (ala Debian packages). Of course the dependency checks of either blow the pants off RPMS.

If the ports collection does some script configuration please forgive me. I'm not a FreeBSD user. I tried it once (3.2) but the learning curve was a bit much for me at the time. I'm planning on trying again now that 4.0 is out.

Skippy
• #### Package managers, floppies, et al (Score:4)

<<moc.oohay> <ta> <kapimi>> on Friday March 17, 2000 @10:25AM (#1195524) Homepage Journal
First off, I dislike the existing package managers. They require the packages to be configured in such-and-such a way, and rely on different organisations using compatiable numbering systems.

What someone needs to develop is an auto manager, which tracks software installations, REGARDLESS of whether it's via tarball, or whatever. This should be easy enough - after all, it's fairly simple to see what changes are made, and it's usually possible to determine the version by using --version, -v, -V or something similar.

Automatic management would mean that upgrading from different sites, or different package formats would work fine. There wouldn't be any discrepency. It would also mean that manually deleting files would be automagically accounted for. (I =HATE= that /usr/doc directory!)

IMHO, distribution SHOULD be possible entirely off floppy, or any other medium. A GOOD distribution is a media-independent distribution. It isn't hard to do. After all, once you've packaged up the different applications into tarballs, RPMs, DEBs or whatever, it should just be a simple shell script to best-fit the files into collections which can fit onto a 5.25", 3.5" or CD, and/or provide images of said disks and CDs.

If you've a best-fit script for organising, YOU don't need to care what anyone wants. Indeed, why not have a web page for auto-arranging (using sym-links) collections of your choice for the media of your choice? Nothing intrinsically difficult about this.

• #### Slackware (Score:4)

on Friday March 17, 2000 @08:18AM (#1195525) Homepage
One of the things I used to like about Slackware was the fact that you could install *COMPLETELY* off of floppies. Now only the A [base] and N [networking] sets fit. What about us folks without ethernet?!?! HUH?!!? God, no one cares. Oh well, I'm going to dig out my old PLIP documentation.
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
• #### Slackware as the foundation (Score:5)

on Friday March 17, 2000 @10:19AM (#1195526) Homepage
But Slackware *is* easy! Trae McCombs even said he was very impressed with the ease of installation. And I think we set up the desktop (at least on KDE) with the nicest set of defaults. But I understand what you're saying -- many of the other distributions now provide a fully graphical installation. But, then you end up raising the hardware requirements, so it's a trade off. I do think keeping things primarily text based is the most flexible, then you can do things like installing with a serial console, and maintaining the machine remotely is more straightforward. Of course, I've been accused of being one of those "command line" kind of people...

I recently set up one of those graphical Linux systems just to see how it worked. I tried Best Linux [bestlinux.net]. One thing I noticed about it was that it was installing stuff in the background while I was going through the interactive Windows9X look-alike screens to give my configuration info. The install was pretty, but you can do all that in text mode as well. The only reason I see to do that is to ease the transition for people who have spent their entire computing life shackled to MS Windows.

What I ended up with, however, was mostly a Redhat look-alike. It appeared to have all the same problems of Redhat, although to be fair, I didn't have time to finish looking it over as I needed that hardware for some real work the next day (and installed Slackware for that).

David Cantrell is working on an experimental packaging system that would have a lot of advantages over our current system (or any other). It would track the user's config files and make it easy to transfer packages and configuration between their own systems. But, we're still evaluating it. It looks like the LSB is going to want everyone to use RPM, so we have to take that into account.

I've been using Slackware since around 2.0 or so. At around 3.4 I acquired a used Sun Sparc 5, and there being no Slackware for it, I gave Redhat 5.1 a try and it seemed OK. I then put Redhat 5.2 on a few machines. As I was getting more and more extensive in making system changes to automate more administrative processes, Redhat eventually became more and more of a pain and 6.0 was my last Redhat. I moved back to Slackware at 4.0 about 1 week before 7.0 came out, but quickly switched to 7.0. I still have 3 machines running Slackware 3.4 so I guess I never really abandoned it. OTOH, there's still 1 running Redhat 5.2 and 1 running Redhat 6.0.

One thing that I disliked greatly about Redhat was the RPM system. While it did allow a nice quick install of a package I did not have before, it really screwed me over with dependency stuff. I frequently update stuff, and on occaision, I was trying to update something a lot of other stuff depended on, and could not because of the dependencies. I was doing the updates from original sources, not RPMs, so the dependencies had to be forcibly removed and the old package deleted for the time being. Then future packages could not install because the dependencies were now screwed up.

RPM basically came across to me as a lock-in feature. That means, once I start using it, I have to keep using it to get any benefit from it. That also means, I have to wait for updates to come out in RPM format before I can upgrade something if I want to keep my RPM DB consistent. I would really much prefer that the presence or absence of a package be predicated on whether the package actually is installed, not whether some DB entry says it must be. I really dislike it when a DB that claims things is out-of-sync with reality, and that is a problem I encountered with the Redhat Package Management system.

I also found problems in making changes to the RC scripts in Redhat. In order to make some daemon scripts work right, I had to modify some of the core functions because they were in the way. Then other stuff broke. It became a nightmare. OTOH, I wasn't entirely happy with the BSD traditional RC scripts that Slackware uses, either. About a month and a half ago, someone on IRC challeneged me with "So just write your own rc scripts, then". So I decided to do so. It was Slackware that served as the foundation to do that because Slackware is still the easiest to change things in the system. What I ended up with was a daemon-script based system in the sense of separate files for each daemon, but with everything in a single subdirectory in /etc without the symlinks. Now the entire setup of what scripts run in what order in what runlevels are easily listed all at once. And now I don't get cut off from the machine when I change run levels from a remote connection.

I'm not saying that Slackware should become like that. What I am saying is that Slackware makes a great foundation for any of us to try out our own ideas on how things should be, especially if you, like me, prefer keeping things uncomplicated. BTW, I've been running my new RC script scheme on a few machines now and it works like a charm. It looks like I'll eventually be converting everything over to it.

Keep up the good work Patrick, David, and all the other folks at Slackware!

• #### Re:what's the diff? (Score:5)

on Friday March 17, 2000 @08:46AM (#1195527) Homepage
Slackware has a different directory hierachry than Redhat which, IMO, makes more sense.

Slackware uses the BSD-tyle init scripts (/etc/rc.d/rc.M, rc.inet1, rc.inet2) which, IMO, is easier for newbie and guru alike to use.

Slackware can be installed in 80mb as a firewall 486, or in a gb or so as a Workstation with Gnome and KDE with a lot of little apps for both.

Slackware's text-installer is slick, and easy to use. I personally love the "expert" mode added in Slackware 4.0 which lets you pick which pieces of each disk set you want before it installs that disk set.

That, and unlike RedHat, Slackware's packages are organised logically. I've never had an install of Slackware crap out because I'd not installed something important. RedHat custom installs are downright satanic in terms of how hard they are (IMO).. Slackware also has a cool support message board on slackware.com which I sometimes frequent :)
---

#### Related LinksTop of the: day, week, month.

"Confound these ancestors.... They've stolen our best ideas!" - Ben Jonson

Working...