Slashdot Mirror
Replies from Slackware Founder Patrick Volkerding
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.
upgradeability (Score:5, Interesting)
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.
Download/Sales? (Score:5, Interesting)
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.
Some of you might have noticed that our home site moved from ftp.cdrom.com to ftp.freesoftware.com (also reachable as ftp.slackware.com). This machine just had an $80K overhaul, adding 500 GB of RAID storage and gigabit ethernet, and should make downloading Slackware faster and more reliable. This machine, BTW, is expected to handle more free software downloads than any other machine on the net. Now if I can only get them to switch it to Linux. ;^)
Boxers or briefs? (Score:5, Funny)
by Anonymous Coward
C'mon... lets see if moderation REALLY decides what gets asked of Patrick... or if Roblimo just does it himself...
Patrick:
Boxers. With Grateful Dead skeletons.
The Magic Wand questions (Score:5, Interesting)
by Anonymous Coward
If you could wave a magic wand and change any one technical aspect of Linux, with no negative side effects on the OS or its users, what would you change?
Patrick:
I wish that limit on kernel size would go away. Or, if I really wanted to go overboard on this one, I suppose it would be nice to be able to use hardware drivers designed for Windows or NT, even if it were unreliable. Just to be able to play around with it.
AC:
If you had one wave of the wand and could change only one thing about the Linux community (in the traditional and/or the new, more business-oriented sense), what would it be?
Patrick:
Suddenly they would all want to run Slackware. ;^)
No, I think I'd just like to see the community base its decisions on good technical reasons rather than profit motive, and for the people who are marketing and advertising Linux products to represent the products honestly. If they don't, then we all look bad.
How powerful is this magic wand? Maybe the IPO funds raised by all of the Linux companies should appear in a giant pile, and then K&R will decide how to divide them up among all the various Linux projects. I think they'd be fair about it.
Slackware's Direction as a Linux Distribution
(Score:5, Insightful)
by dee^lOts
I've always viewed Slackware as the all purpose workhorse of the Linux distributions. It's always done things better and faster in the server role. Now as everyone is pushing to get Linux on the desktop, I'd like to know what Slackware's Direction in this area. Will it remain focused on playing the server role, or will the distribution splinter into different job roles, or will it follow the crowd and push for the desktop?
Patrick:
While we're not really trying to be one-size-fits-all, it seems like by not focusing on some niche that we've ended up being the most flexible.
One of the fortune quotes I like is "A successful tool is one that was used to do something undreamed of by its author. -- S. C. Johnson"
Anyway, I think the more you try to second guess the user, the more you put up barriers. So we like to keep things uncomplicated as much as possible. I think this leads to a system that makes a good server (where you aren't even required to install X if you don't want it), or a good desktop workstation if you do a full installation with KDE or Gnome. It all depends on what you install, and we like to keep that open-ended, and give you the options for whatever you might have in mind at install time. We are talking about making a higher priced retail version that would bundle some commercial tools and office applications, since we're asked about that quite a lot. This will probably also take the swiss-army-knife approach, as some of the add-ons will probably be server oriented, and some will be for the desktop.
Installation options -- FTP install (Score:5,
Interesting)
by kjj
I was wondering if Slackware would include an ftp install method in some future version similar to FreeBSD, NetBSD, Redhat. I realize ftp has some serious drawbacks compared to NFS or CD install but I found it quite handy when I wanted to give FreeBSD and NetBSD a try. If not ftp, what about the possibility of opening up a public NFS server that will export the latest stable version of Slackware since many of us may not have an extra machine to set up NFS on. It could just run off the same machine as the ftp server for Slackware, right? Just a couple of thoughts.
Patrick:
Well, I don't think there's much possibility that ftp.freesoftware.com will run a public NFS server, and slackware.com doesn't really have the bandwidth for it. And sure, NFS is supposed to be secure now, but as recently as last fall there were holes fixed that you could get a root shell through, so I don't think I want to run NFS daemons that are exposed to the net at large. :)
An FTP install would be a good thing, though, and there has been a test version of color.gz with support for an FTP installation floating around among the Slackware developers. I'd like to see it added to the standard installation disk, but the rootdisks as they exist now are running out of extra space. So, to add FTP capability we will have to either have a dedicated FTP rootdisk, or the other option would be to add a second install disk. This would give us the extra room needed to merge together the existing color, text, and umsdos installation disks, and add FTP support as well. I'd rather not have to require 3 installation disks, but it's getting harder to fit all of the tools needed to install Linux onto a single floppy anyway, and at some point the change will have to happen.
Closed Development (Score:5, Interesting)
by nullspace
I have been a loyal user of Slackware for many years. I have always wondered why isn't the development process more open. For example, Debian has a very open process in which volunteers can contribute to the packaging of the distribution. Slackware does not seem to allow for that, that is, you seem to be in complete control of what goes out the door. Do you plan to allow for users to assist in development or do you wish for things to remain the same?
Patrick:
There's a trade-off there. Being pretty much the Slackware czar, I can make sure that there's a high level of quality and consistency. Keeping the source open is one thing, because then people will help find bugs and send in patches, but having people making changes directly is a lot harder to manage. That said, we have added more developers to the team over the past year, but so far everything still goes through me so I can check it over, and I still do most of the development myself. I'm hoping to start distributing tasks more once I'm satisfied that the quality will stay the same or improve.
Porting Slackware (Score:5, Interesting)
by Vladinator
With the formation of your company, will this give you the resources to port Slackware to the PPC and Alpha? Are there any plans for this?
Patrick:
I can tell you that everyone working on Slackware is interested in other platforms. Besides a load of x86 machines, we have two Alphas, two G3s, and a couple of Sparcs floating around. I actually got Slackware running on my Alpha, but never got as far as building an installer for it. There is work going on for Alpha and Sparc, but I don't know when any of it will be ready for public consumption. David Cantrell just picked up a new Sparc today, in fact. Chris Lumens has been working with a dual processor Alpha loaned to us by Alpha Processor, and has a basic Slackware system up and running on it. And Logan Johnson just got a shiny new iMac DV the other day, but he told me not to tell you. :)
Corporate Structure? (Score:5, Insightful)
by Spud Zeppelin
Now that "Slackware Linux Inc." is being spun off, are there any plans to honor J. Robert "Bob" Dobbs by designating him Chairman Emeritus? What kind of poison-pill-defenses are going to be included in the corporate bylaws to prevent being taken over by X-ists, or for that matter, anyone from Cupermond or Redtino?
Patrick:
Sure, why not? I doubt he'll spend much time in the office, though. :)
On the serious end of the question, since we're not publically held and don't have outside investors we don't have to be concerned with a hostile takeover. Someone could offer to buy us, but if it's not in the best interests of Slackware's users we'll tell them to go away.
(Non) Participation in the LSB. (Score:5,
Informative)
by gharikumar
Hi, Partick,
I understand that you have chosen not to participate in the LSB. The reasons mentioned were:
a) That you prefer the old "unix" way of doing things.
b) You feel that these ways should be THE standard.
There must be good technical and marketing reasons behind your preferences. Could you please elaborate on both? Thanks.
Patrick:
Did I say that? Well, I suppose I must have, but my main reason for not participating in the LSB was simply a lack of spare time. It wasn't like I was boycotting it or anything. That said, I do like the more traditional ways of doing things in most cases, and I'm reluctant to move things around for no reason. So, it'll have to go through a little bit of Darwinism first -- if it succeeds, and compatibility improves among LSB compliant distributions, then I'll definitely adopt it, at least to the degree needed to get those benefits. I am hoping that the LSB succeeds to that degree at least. Given the current state of divergence, I think Dan Quinlan has his work cut out for him. But, the Linux Filesystem Standard and the File Hierarchy Standard were both extremely beneficial to Linux (where would we be without those?), so I'm sure this will be another step in the right direction.
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.
>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.
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.
--
see shy jo
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.
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
--Chouser
"To stay young requires unceasing cultivation of the ability to unlearn old falsehoods." -LL
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 :-)
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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."
The Linux filesystem standard states that nothing the distro installs should go in /usr/local. Makes sense if you think about it.
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
this sig limit is too small to put anything good h
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.
**>>BELCH
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
'Advanced Systems Development' group!
\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...)
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
--
Infuriate left and right
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.
/etc/rc and delete all the init scripts (at least with solaris's init). I thought unix was about orthogonality tho?
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
I've finally had it: until slashdot gets article moderation, I am not coming back.
I usually hate this kind of messages, but:
:)
I agree!!
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
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.
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
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!
So now that Slackware is a marketable company, where can I pick up a pair of Slackware logo-emblazoned boxers? :)
.sig Instructions .sig here
_____________________
step one: place
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.
Why wait - the appropriate garment already exists
here
Send lawyers, drugs, and money. Dad get me out of this. -- Warren Zevon
Tab completion!
Bash has it, so use it.
installpkg work^T
-> installpkg workbone-x86-4.2.1.tgz
:-)
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
How hard is it to download those packages to your harddrive before hand?
;) Source tarballs? They're great, and the ones I always use.
:-)
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
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*
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
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
two, im have an old 486 that i want to put linux on. would slackware be my bet bet?
(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
"False modesty is the refuge of the incompetent." - The Stainless Steel Rat
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
this sig limit is too small to put anything good h
I recently set up one of those graphical Linux systems just to see how it worked. I tried Best Linux. 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).
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!
now we need to go OSS in diesel cars
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
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.