Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Interview w/Slackware Developer David Cantrell 85

Posted by Hemos from the interesting-stuff-to-read dept.
keskoy writes: "David Cantrell is a core team member for the Slackware [?] Linux Project. In this interview you will learn how David got his start working on Slackware linux, what his role as a Slackware developer is, he will explain to us about his two new applications protopkg and autoslack, plus other various topics of interest are touched on."
This discussion has been archived. No new comments can be posted.

Interview w/Slackware Developer David Cantrell More

Interview w/Slackware Developer David Cantrell

Comments Filter:
  • at some point it would be nice to have keywords (something like what "apropos/man -k" is to man pages) for packaging systems. I don't like having to go on the net to find commands/packages to get when I need a program to do "whatever".
    This may not be a cure-all, but I've gotten some joy out of the following:
    grep (keyword) /cdrom/slakware/*/disk*
  • "Difficult" would be more clearly stated as "unfamiliar"... If you are accustomed to more pure SysV systems, such as Solaris or AIX, Slack is quite different and unfamiliar. However, if you come from a BSD environment, Slackware feels like FreeBSD (or OpenBSD if you like to keep Slack clean) with pretty directory colors. The reason why you say "difficult" is because it is unfamiliar due to its architectural difference in this respect.

    I felt the same way when I was spontaneously stuck fixing a RedHat machine for the first time, or when I first ran Debian. I didn't end up becoming accustomed to the SysV way of handling things until running Solaris. Now, I have no problem with those design differences when using RedHat or Debian, and although I prefer using Slack (Praise Bob!), it's due to other reasons other than unfamiliarity.

    Lack of personal knowledge of a system does not make a system difficult - it makes the user uninformed. Don't be afraid to RTFM :)
  • It's not a production system...yet...:) Anyways, thanks for the info. I appreciate it.
  • But that's forcing the linux newbie to skip linux-user status and go straight to linux-admin status. I think that's one reason more people don't use linux. Most people don't want to be an administrator; they want to be a user and get their work done. Should we stop using automatic transmissions so that drivers better understand how the car works? ( I know it's not a perfect analogy; just making an illustration. Let's not start a flame war )
    • Perhaps the "best feature" of Red Hat is their tendancy to aggressively pursue the most bleeding edge experimental stuff out there, whether that be ELF, GLIBC2.0, GNOME, or GCC 2.96...
    • SuSE's "best feature" is that they have built vast quantities of RPM packages for all sorts of stuff, with considerable numbers of "engineering hours" tweaking the packages.

      Note that these tweaks are to make the packages work with the SuSE "layout," and may not work with other distributions...

    • Debian's "best" features are three, namely that they have built vast quantities of DEB packages, with a huge group of package managers (that are people) that tweak those packages, that they have built tools to validate those DEB package to ensure conformance with their standards, and, thirdly, that they have a sophisticated package dependancy manager, APT, which will automatically install the dependancies called for by what you want to install.

      The stable release, as typically released on CDs, takes the conservative approach of only releasing what they know already works well.

    • Slackware takes the approach of requiring that packages be managed as "tarballs," with somewhat more limited dependancy checking, and with the expectation that you, the sysadmin, will be installing and configuring the services that you want, as opposed to GUIing it all.

    Note that none of this has anything to do with licenses, only with the respective design choices. And some of those choices are downright incompatible.

    I would argue that the notion of the "best uberdistribution" is a contradiction in terms and thus an inherent impossibility.

    As for the "licensing thing," one part of constructing a distribution is indeed in assessing the respective licenses of the components and how that fits with what you plan to release. If you can't cope with the legalities there, you're probably not legally prepared to release any kind of collection of this sort of thing...

  • apt-cache search stuff check it out

    /*
    *Not a Sermon, Just a Thought
    */

  • Re:Slackware packages (Score:3)

    by Arandir ( 19206 ) on Monday December 18, 2000 @10:59AM (#551245) Homepage Journal
    So what's the alternative? Surely not Debian, Redhat or SuSE. Using common defaults works well for the user who fits those defaults, but screws up everyone else. And throwing a flashy GUI over the adminstration doesn't make it any easier.

    I have found, like the other poster, that Slackware is TRULY easier than the other distributions I have tried. The installation is a snap. Administration is easy. That's because Slackware is laid out sensibly. It does require that you be willing to learn, however.

    Taking the car analogy, everyone who can drive a stick can drive an auto, but the reverse is not true. Once you know Slackware you know Linux, but once you know Redhat all you know is Redhat.

  • GPL is protection, BSD is slavery! (Score:1)

    by Anonymous Coward
    What's with all that whining about GPL not beeing free?
    In fact, the BSD license is even less free than GPL is!

    The so-called "restrictions" in the GPL are made to ensure freedom instead of take it away.
    Is it really that hard to DISTRIBUTE SOURCE CODE WITH THE BINARIES?
    Is it really that hard to release the source code of decended work?

    The BSD license is *more viral* than the GPL is!
    Look at it: you can do whatever you want.
    That's right, you can even relicense the software with GPL!
    Now, if you think the GPL is not free, how come a license that allows you to take away others' freedom IS free?

    [RANT]
    GPL stands for protection of freedom!
    BSD stands for slavery, because "you have the freedom to make slaves"!
    <B>AND IF YOU DON'T MAKE OTHERS INTO YOUR SLAVERS, OTHERS WILL!</B>
    [/RANT]
  • I must agree. I had messed briefly with Slackware ages and ages ago, but never really gotten into linux per se. Recently I acquired a laptop at the best cost (free) and decided to install linux on it. I snagged Debian, having heard lots of good things about it, and proceeded to be amazed by how much linux had changed. More than this, though, I discovered (being a newbie) that a lot of stuff was moved around, and that dselect made it hard to find stuff that I installed. So I remembered good 'ole slackware, got it, never went back. I learned an incredible amount about Linux in a very short timeframe. I credit this 100% to slackware's do-it-yourself mindset.

    Of course, I think everyone who wants to understand Windows should spend 2+ years working in DOS first, too.
  • Why do you think Slackware has to be reinstalled all the time?

    Slackware rarely has to be reinstalled. You can upgrade packages for a long time without reinstalling. Occasionally (due to shared library upgrades) you might have to boot a minimal system from boot/rescue floppy to fix up some things, but a complete reinstall is not needed.

    FreeBSD, having the same tradition like Slackware in taking a simple but solid approach, is even better. I have gradually upgraded my FreeBSD system since 1994, without a single reinstall (only upgrades via cvsup/ctm and then a 'make world' in /usr/src).

    FreeBSD is more conservative, and everyhing in /sbin and /bin (not /usr/bin) is statically linked, greatly diminishing the chance for disasters when playing with your shared libraries.

    Btw, the FreeBSD ports collection has precisely what you want: in /usr/ports there is an index file (an overall, plus also one per category of ported software) containing one line descriptions of all 4000 ports, in a fixed format so tools can read it. Example

    inn-2.3.0|/usr/ports/news/inn|/usr/local|InterNetN ews -- the Internet meets Netnews|/usr/ports/news/inn/pkg-descr|des@FreeBSD. org|news|gettext-0.10.35 gmake-3.79.1||http://www.isc.org/products/INN/

  • Err, How about some facts [slackware.com] to back up your assertions?

    Contrary to popular mis-information, Slackware packages are not just archives. They do contain rules for installation, version information, and meta-information. This is why Slackware users know that you just cannot 'unzip and untar' a Slackware package -- you need to run 'installpkg' to install something correctly. (BTW - You can use installpkg to install 'simple tarballs', but these do not contain the additional package information used by the Slackware package system).

    In the UserLocal interview, they discuss that 'autopkg' and 'protopkg' are the next generation of tools for the Slackware packaging system. For example, here's what the UserLocal interviewer wrote about 'protopkg':

    I've recently made a package with protopkg, I was completely amazed at how simple it was to use (I actually just modified an existing prototype found on ftp.slackware.com in the /unsupported dir). This system seems almost revolutionary in the fact that essentially it allows users to trade binaries just by exchanging these prototype text files.

    I don't know whether protopkg is revolutionary, but it is certainly not primative.

    Later

    "Fat, drunk, and stupid is no way to go through life."

  • Err, How about some facts to back up your assertions?

    How about reading the post you're responding to?

    In which I maintain that dependencies are an integral part of any packaging system. Your link doesn't refute that. Yes, Slackware archives have some meta information, but do not meet the other requirements listed above to be classified as a package management system.

  • I like Slackware. There, I admitted it :)

    AFAIK it is the only distro that uses a BSD-style /etc/rc.d rather than the SysV-style mess'o'symlinks. Easy to reconfigure with `vi`, and very similar to Slowlaris and FreeBSD boxen. No need for linuxconf.

  • My two points (mangled the HTML) 1. There is more than one way to define a package system. 2. There is more than one way to define a dependancy.

    "Fat, drunk, and stupid is no way to go through life."
  • Now, Slackware is finally coming out with platform ports just as everyone else is dumping support on other platforms. I don't get the logic.

    I don't care what the logic is, I just want to keep using Slack when I move over to Alpha hardware!

    Seriously, what are the motivating factors for Open Source developers? Many times, it's just scratching an itch of thier own that gets people started. Seeing that there's others who need/want/will help with packages, and....

    Anonymous Cowards need not reply.

  • How do you define what is in a package system?
    How do you define what is/should be flagged as a 'dependancy'?

    I define it differently from you. That's fair enough, but my main point is that every other system which labels itself as a package management system defines it similarly to my definition, and Slackware users are generally the only persons who share the other view.

    It would seem that this means Slackware's package system is at least effective enough for me to do such things as upgrade a major part of my system, no?

    Just because you can upgrade a major chunk of your system with a tool does not prove that tool is a packaging system. I just upgraded some major components of a Windows 2000 machine using Windows Update [yes, I use and prefer Linux]. That doesn't mean Windows Update is a package management system.

    Clearly, you would not want your package system to remove all dependancies. In this example, your system would be useless without the glibc libraries.

    When you remove a package, a packaging system may prompt to remove all packages dependent on that package. Not all packages that package is dependent on. You seem a little confused about this.

    My point is that there is more than one way to define a package and its uses. Slackware is slightly different,


    Agreed on both points. Slackware's definition of a packaging system is a very rare and unusual one. It doesn't match the definition of `packaging systems' that AFAIK all other packaging systems use. That's Sun's, Red Hat's, Debian's, Microsoft SMS's, and others.

    Finally, if packages were so simple and definable, why are there so many package systems available?

    I agree. Just because soemthing is a packaging system, it doesn't mean its god. Many OSs get along fine without packaging systems. Slackware might be a great OS, it just doesn't have a packaging system but any defiition of `packaging system' other than that of Slackware users.
  • I totally agree with you. Slackware was the first real linux distribution I started using and everything I know I can attribute to that. Slackware forces you to know all the nitty gritty things that other distributions just GUI and package off to be easily point and click configured by the user. I'm well aware that they're a lot of people who don't care about the nitty gritty... but for anyone who's even remotely like me... they want total immersion into what they're doing. Thats what Slackware offered me and I'm glad I started off my linux days with it. These days I use Debian.. but only cause it saves me a little bit of time and cause I tended to make things a bit messy back in the Slackware days.. but it was all worth it.. there's nothing better than that feeling you get after making a fresh slackware install seem so robust. Just the way you like it.
  • Nice to see Slackware on /. Of course, CmdrTaco didn't post it, because he uses Debian...
  • Actually you can get a port of slack for the power PC, Slackentosh, MacOS is for dummies
  • I love this distro! I get so much work done with it, and I always know what is happening and where. >I think Slackware is very easy to look "under the >hood" of, a very simple distro, and yet very >useful. Simple , stable and useable . >Unfortunately, I am probably the only Slackware >user in Nokia. That sucks. Fight it, :-) Our company only develops in Slack. ,but we have to test in redh*t :-(
  • Debian has file-rc, which converts those SysV init scripts into more BSD type ones. It also supports the standard Debian rc.d management tools, so it automatically gets updated when you install new packages.
  • Whenever I see a Slashdot story about David Cantrell, I think about Jerry Cantrell, the guitarist from Alice in Chains. Then I wonder, "What the fuck is Slashdot interviewing Jerry about? Did he figure that with his long hair and grungy clothes, he can easily make the transition from metal guitarist to GNU hacker?" Then I reread the headline, and notice that it says "David", not "Jerry". And then I sigh, and say, "Ahhhh... my mistake."

    And that's all I have to say about that.


    See you in hell,
    Bill Fuckin' Gates®.

  • As far as I know, Debian will continue to support all platforms...

  • Slackware Developers (Score:3)

    by tiny69 ( 34486 ) on Monday December 18, 2000 @09:46AM (#551262) Homepage Journal
    David, Chris, and Logan are three of the friendliest and most helpfull developers I've ever met. They regularly answer questions and post information on the web forums on www.slackware.com [slackware.com]. They can also be found at #slackware on irc.openprojects.net. I've seen them help more people on irc then I can count, from newbies to gurus alike.

    All three need to be recognized and applauded for their efforts and commitment to the community.

  • Of course, debian doesn't have dselect anymore...the new pool thing has broken it. It no longer workes for me, and I am sad. Of course, I am lying. I won't miss dselect. Aptitude is dselect for apt, and on crack.

    -------------
  • If you want to make an uber-distro like this, it would certainly make sense to start with Debian and add in the features from Slackware as you see fit (The .tgz packages are too easy to install [cd /;tar -zxf path/to/file.tgz])... You can use the Debian or slackware RPM package as a core for adding your redhat-supported features without a whole helluva lot of trouble.

    As far as retaining a safe package base that interacts properly with most administrative programs, Debian would certainly be the best. RedHat makes many major modifications to administrative tools that makes their tools a bit sketchy. Slackware deviates from the GNU core quite a bit too, to retain the BSD-like feel.

    If you're feeling lazy and brave all at once, you could look at taking VectorLinux (sorry, I'm too lazy to find their URL), which is a stripped-down and all-in-one version of Slack and use that for a base. I definitely wouldn't put this choice above going with Debian base plus outside packages, though.
  • Here Here.

    I talked with them at ALS and the were really nice , let me play with their VAIO a bit and gave me some CDs. Cool and nice guys (Kinda like CmdrTaco).

  • Re:The best of both worlds (Score:1)

    by Anonymous Coward
    Wait a minute... that's not a Slackware module. THAT'S NOT A SLACKWARE MODULE!!!!!!!!!
  • Ditto! I started teaching myself UNIX administration on a Slackware Box. The fact that "I" had to do everything on my own taught me more than reading the man pages and HOWTO's. The Slackware approach leads you to the Linux "Do it yourself" philosophy.
  • Isn't chroot used for this sort of thing all the time?

    --

  • But that's forcing the linux newbie to skip linux-user status and go straight to linux-admin status.

    Indeed, and rightly so. Like it or not, but Linux still isn't far enough to be run by a pure "user" without having an expert at hand.

    b.t.w., neither is windows; superficially it may look like it, but the problems simple users get with windows "administration" are even worse.

    The only things that come close for non-experts without any external help are (IMO) machines with operating system in ROM (such as the old home computers, gameconsoles, palmpilots) and maybe the Macintosh (closed hardware and strict software certification diminishes the chance for conflicts and driver problems).

  • I love this distro! I get so much work done with it, and I always know what is happening and where.
    I think Slackware is very easy to look "under the hood" of, a very simple distro, and yet very useful.

    Unfortunately, I am probably the only Slackware user in Nokia. That sucks.

  • Thats the one! I really would like my own distro, flabdabix or hubbardix, or something, but then, I have nothing to add to it. No unique selling point. It would be cool to have my own distro though....

  • Worth every hour of effort to a newbie.
    LFS [linuxfromscratch.org]


  • I'm not sure. What I was referring to was the kind of environment where if you run ls in the bsd env you get /usr/ucb/ls and if you run it in systemV universe you get /usr/5bin/ls (in Solaris terms, all off the top of my head).
    The cool thing with vmware/plex86 would be that you could run multiple kernels, and fork processes on whichever one was most appropriate for the task at hand. Kind of like "kernel mode" user-mode linux :-)
  • Stampede is also BSD-style.

    Slackwares config-system (do it yourself in BSD-style) is one of the main reasons I use Slackware on all our servers.
  • HA! You are so dumb! MacOS has to be the most dumbed down OS ever!

    MacOS Developer #1: "Damn! Our users are having trouble with this feature."
    MacOS Developer #2: "Okay, let's take away that icon. See, no more problem."

    MacOS is for pusses!
  • A agree. To tell the truth, Slack is probably the best way to go, because the newbie distros actually make things harder. For example, Mandrake 7.2 includes an asnine set of wrapper scripts over the normal SysV scripts. Since these things are only documented in the Mandrake docs (which are fairly sparse) it makes it more confusing for the new user that is reading from a HOWTO that assumes SysV. In comparison, Slack uses the BSD scripts, which are quite well documented. I found that Slack tends to have much fewer idiocies than other distros of Linux. Rarely as I used Slack did the HOWTO I was following differ from what was going on. When I used RedHat, I could never follow the HOWTOs because RH messed around with things and put them in different places. And I recently deleted the stupid linkes that Mandrake put in the /etc directory (to the rc.d directories) and the system would't boot anymore!
  • I was looking for something to put on my mac other than Debian.

    Although they really ought to call it iSlack...
  • I think you could do this with virtual terminals and chroot. You just run the program in the required terminal.

    --

  • I'd like to also say that I've seen very few major-distribution developers that are as personable with their users as David is, even in some less-than-fortunate circumstances. I just wanted to thank David publicly for being such a great example of a community-friendly Linux Distribution developer. It's good to see him get a well-deserved interview!
  • boy was my life hell ;-)

  • No, I meant the binary TGZ packages. They're never up to date. The only thing in the /tgz directory is source code.
  • Let me clear that up again. I'm not talking about the Slackware tgz's, but the general, distro-independent Linux i386 binaries.
  • Hi Brian!
  • And further complicated again by the fact that I (david@cantrell.org.uk) am a Slack advocate. Oh dear.

  • Slackware packages (Score:4)

    by Jeppe Salvesen ( 101622 ) on Monday December 18, 2000 @09:24AM (#551285)
    If you are a control-freak, Slackware is definitely the way to go. The administration tools are kept to a minimum. If you want to make things fancy, you need to set that up yourself. The result is that you slowly move towards gurudom.

    However, if you are making money, slackware packages are fairly primitive. To the best of my knowledge, they don't support dependencies. You don't have a neat dselect type app. But you have the direct power. And that is the price of power - efficiency. I used to compile all my stuff on slackware. However, I must admit that I love apt-get and dselect. It has cut my workload severely.

    That being said, I still use slackware on my production server. But my workstation is a debian woody.
  • There was a time when Patrick ran Slackware on the Alpha (couple of years back). I saw him at Comdex and asked when Slack was to be released for Alpha (we had Red Hat on one Alpha). He said that he ran Red Hat, he just Slacked it out. So, I asked about the release of slack.rpm.

    Now, Slackware is finally coming out with platform ports just as everyone else is dumping support on other platforms. I don't get the logic.

  • "autoslack will look at your machine and a distribution tree of your choice and tell you what packages can be removed, upgrade, or new ones that can be installed. Optionally it can download those packages and/or perform the actual package operation."

    I remember when slack was one of the most difficult distributions to setup and maintain, I think it was a very good idea for them to become a more accessible distribution and appeal to more people, without losing their original customer-base. AutoSlack will help in that process but is not necessary to run Slack.
  • If you are a control-freak, Slackware is definitely the way to go. The administration tools are kept to a minimum. If you want to make things fancy, you need to set that up yourself. The result is that you slowly move towards gurudom.

    NOT intending to start a distro war or anything, but for the reason above, is exactally why I think linux newbies should use Slackware, it helps them to more fully learn the basics, without pretty wrappers and guis, that can sometimes hide what some administrative processes are accomplishing.

    Not a flamebait, just a thought
  • it sure would be nice if there was a bit more uniformity amongst the tools for the various Distro's. I suppose that they are all variations on a theme but they *do* work differently (especially from end-user perspective). From a hobbiest point of view I guess it isn't a big deal but from a commercial perspective it might be. I've been using RH on my intel boxes and a friend gave me a Sparc 10 to fool around with. No RH7 distro for that so off to debian or some other....files located in different places, apt-get and other oddities when compared to RH distro. It drives me nuts.

  • Doppelganger (Score:4)

    by babbage ( 61057 ) <cdeversNO@SPAMcis.usouthal.edu> on Monday December 18, 2000 @09:58AM (#551290) Homepage Journal
    Every time I see this name, I assume people are talking about British Perl Monger David Cantrell, instead of American Linux Hacker David Cantrell. Obviously the open source world needs better naming conventions... :)



  • Q. How have you contributed to confusing the masses of people that have no clue as to what Slackware is?

    A. Well, I would think that explicating the derivative mechanisms for the kernel's command-line implementation could render my speech patterns to emulate the errors received when booting our prototype distribution on a Pentium 4! [laughs] But really, I've written my framework prototype file. The variables in my speech are exemplified in the brain.cortex.left functions I will try to hash out and personify using prontofkdfd.

    I extract the source jargon from the perl makefile, as ironically I simplify the misunderstanding process by avoiding the use of Fortran-esque statements. Now I take that makefile and go dylexify my prototype file. Like this:

    IGNOREPATH=/mnt:/home:/dev:/opt:/root:/export
    PATER@SLASHDOT.ORG=CowboyNeal
    STRIPLIB=yNot
    STRIPBIN=y?b/cWeLikeU

    VERSION=2.04x10^-34
    PROGNAME=Yfixelsyd
    DESC="Yfixelsyd confuses the hell out of those JonKatz advocating, Windows novices."

    BUILD=1
    ARCH=i386
    WASH=rinse
    MAINTAINER="David Cantrell "
    SOURCE=http://poocs.net/babbling/53/
    PKGNAME=confusification-$VERSION-$ARCH-$BUILD

    compile() {
    tar xvzf $CWD/confusification-2.04x10^-
    34.tar.gz
    cd confusification-2.04x10^-34
    perl Makefile.PL
    make
    }

    install() {
    make install
    repeat() {
    if WASH=rinse {
    repeat();
    }
    }

    But that's just the current version. Wait till our implementation and compilation of the abusifcation confusification installation parameters.

    install() { make install
    mkdir -p /usr/doc/confusification-2.04x10^-34
    cp COPYING ChangeLog INSTALL MANIFESTATION README ToDoLaterOn *.html \
    /usr/doc/confusification-2.04x10^-34
    }

    But then we take the Eggdacator indacator, wait until Easter, and then, uh, and then, um...

    Where was I?

  • Perhaps a distro which popped up a drop down menu box with 'bleeding edge', 'mostly stable' and 'rock solid stable' options would be cool. Then the user could choose whether they wanted to be the 31337 |-|4 By making it a point and click choice, we would de-problemetize the choice of distribution for newbies, and thus convert more people to our cause.

    Another alternative would be for plex86 [plex86.org] or vmware [vmware.com] to become part of the kernel. Then you could have a kind of 'switch personality command like on the old Sequent systems (you could choose bsd universe or system V). In this case you could say something like 'redhat ls -l' and the process would get forked in a redhat environment.

  • I saw a link once which shows you how to make your own distro...

    Do you mean Linux From Scratch [linuxfromscratch.org]?

    This is a project on installing Linux literally from scratch. Probably no better/simpler way of forcing yourself to learn the nitty gritty details, than having to install binutils, fileutils et al yourself... :-)

    -Andy
  • Thats compleate, and utter crap.

    In any enviroment where performance and reliability are as importating as bleeding edge features, you always want some kind of nice package system.

    Get a .rpm from redhat - it works. Get a patch from Sun it works.

    Sure your going to have to compile stuff eventualy, but unless there is some r00t exploit, wait for the vendors package. Making things intentionaly hard is just crap.

  • You are of course correct about the 'best' distro. I guess what I really wanted to do would be to eliminate all the (seemingly extraneous) choices for the newbie, but then hey, there's always winblows ME right ? ;-)
  • slackware packages are fairly primitive. To the best of my knowledge, they don't support dependencies.

    Then in my opinion, and from poular definition, they're not packages. They're software archives. A packaging system is a set of rules for software installation, with not only the archived software, but instructions to install it, versioning information, and meta information about how packages relate to each other. These are all key elements of every other popular package management system, and though there's no dictionary definition of software package [or is there?], they form the basis for the current popular definition.

    It seems Slackware is just renaming their current technology to be competitive with DEB and RPM based distributions. As more polished, easier to operate Debian versions arise, and APT for RPM grows in popularity, there's going to be a huge difference in software management techniques and installation ease between other distributions and slackware. Linux needs packages - an Open Source system is fairly compartmentalized and even regular user apps may consist of many other applications brought together. If there's no centralized management then things fall apart very quickly.

  • Because it sames you time? I don't know about you, but my time IS worth money. I installed the XFree-4.0.1 package on Slackware in approx three minutes. Top that using gcc...

    Of course, some things I do compile. I rebuilt Qt and KDE for K6 optimization and sped up performance on my destkop about 150%.
  • Question. Why don't the KDE developers have the decency to keep the binary releases up to date? By the time flat .tgz packages get out, the next release of KDE is already available. Second, why aren't optimizations compiled in to begin with? Everybody and their mother already has a PII, and releasing versions optimized for the most common chips (PII/PII, Athlon, and straight-Pentium) would make much more sense. Seriously, i386 builds should be the unusual ones, and i686 (maybe i586) should be the default ones. I want to see KDE compiled for i686 by default, with an obsolete/ folder from which I can get i386 builds.

  • Flip-side: BSD Ports (Score:3)

    by Christopher B. Brown ( 1267 ) <cbbrowne@gmail.com> on Monday December 18, 2000 @10:49AM (#551299) Homepage
    The other interesting alternative would be to take some variation on the BSD Ports [freebsd.org] and build that as the "user space" with Linux as the underlying kernel.

    Note that the Debian folk once had the (arguably deranged!) counter-idea of doing the opposite, namely using FreeBSD as kernel for Gnu/Debian/FreeBSD.

    I'd contend that neither approach is the least bit "deranged;" I'm actually quite surprised that, with all the BSD connections, Slackware has never headed to using Ports as its package management system...

  • Answer. Because the KDE developers don't *make* the packages. The individual OS maintainers are responsible for their packages - so if RedHat doesn't make RPMs, then nobody running RedHat gets RPMs. Pretty simple. If you want Slack packages, then bug Patrick or David and email them. Or even better, use something such as protopkg to build your own packages and submit them. More questions?
  • What do those '100% Official' comments mean on the redhat boxes ? Is this an endorsement from Linus himself or Alan Cox or some other kernel guru ? Otherwise what stops me from claiming my hypothetical distro (called FlabdabbHubbardux) is 100% official ?
  • Easy! Call one of them $Perl::Developer::David, and the other david.iso.

    This will distinguish between perl coders and distro developers quite handily.
  • Very true. I also think driver education should be conducted in top fuel dragsters. If they can't handle everything right away, it's their damn fault!
  • As far as I know solaris 2.x (SunOS 5.x) is SysV and not BSD. And I've been working on solaris for a while now. I also disagree with you which system is better, but that's me.
  • There's also a 'ls -slag'. ;o) A slag is the British equivalent of a trailerpark ho.
  • Why is it a bad thing to not want your server to be under control? In my personal experiance Slackware lends itself to be way more stable that other distros. One other thing I would like to point out. When I was starting out with linux I picked RedHat to install first. I slamed the disks in and BOOM it was install, X was working and I could even dialup to my ISP. But wait something was missing, I had learned nothing. ...So I dropped RedHat and started with Slackware. I dedicate everything I know about linux to Slackware in the beginning.
  • That is a very true thing to say. My suggestion is to use evildave when referring to the Brit Cantrell. Hi, evil!
  • I noticed the last name and was wondering if by any chance you are related to Alice in Chains guitarist Jerry Cantrell...of course, it's probably a dumb question.
  • "autoslack is pretty stable"

    This sounds cool as hell. Available for public domain?
  • Slackware rules, but I also like debian ( and sometimes even Re$hat) What would be really cool would be if someone combined all the best features of say redhat, debian, suse and slackware into one awesome uber-distro.

    That would kick ass.
    I saw a link once which shows you how to make your own distro, and I did think about maybe creating my own, but it seemed like a lot of work, and I wasn't really sure about which bits of Linux actually are free (as in beer) and which parts are merely free (as in speech). I've looked at linux.org [linux.org] and the various distro homepages, but apart from reading the individual licenses and then consulting a legal expert, there seems to be no clear way forward.
    Or am I just being dense ?

  • got this from Ultrasparc.org *note* that RedHat hasn't said that they won't be releasing a 7.1 or 7.2 for Sparc, just that they won't have a 7.0

    and why would you want a 7.0 release anyway on a production system? icky

    Red Hat has so far released the following versions for SPARC:

    Red Hat 3.0.4 (beta for 4.0) (Rembrandt)
    Red Hat 4.0 (Colgate)
    Red Hat 4.1 (Vanderbilt)
    Red Hat 4.2 (Biltmore)
    Red Hat 5.1 (Manhattan)
    Red Hat 5.2 (Apollo)
    Red Hat 6.1 (Cartman)
    Red Hat 6.2 (Zoot)

    As you can see, there is a sort of "tradition" in not releasing x.0 versions for SPARC.
  • I wholeheartedly agree! Understanding how and why is definitely part of attaining gurudom.

    However, if all that person needs is a workstation, debian would probably be better :)
  • at some point it would be nice to have keywords (something like what "apropos/man -k" is to man pages) for packaging systems. I don't like having to go on the net to find commands/packages to get when I need a program to do "whatever".

    In Debian, you can use apt-cache search anything which is probably what you're looking for..
    However, it will only search your listings, that are downloaded via apt-get update (I believe), but it works offline.
  • Okay. You maintain. Your opinion. Your requirements. Your classification.
  • Who made you the authority in determining the requirements for a "package management system"?

    Nothing does, and I'm not. As said in the original post, what most people [IMHO] define as packaging systems contains those criteria. And [for a something more concrete than opinion] that every other software installation method apart from Slackwares that describes itself as a packaging system contains these features.

    Draw your own conclusions from the latter, but mine is that the popular definition of a package management system includes dependencies as a base feature.

    There are conventions for RPM naming. They're usually stuck to, apart from the odd CVS extracted package, where there doesn't seem to be much of a standard [CVS packages are very rare though].

    To use your example, seach for libglade on RPMFind [rpmfind.net]. And see, out of the hundreds of results, which packages are misnamed.
  • As a common example, this happens because fooApp.rpm lists the "libglade" (version >= 1.2) package as its dependency and I have libglade-1.2" (version 1.2.4) installed.

    That package isn't actually misnamed. Its the standard way of naming RPMs.

    [packagename]-[version]-[packageversion and extra info]-[platform]

    libglade-0.14-1k-i586.rpm

    for example.

    I've installed around 150 non vendor produced packages on my Mandrake workstation. I've very rarely had to use --force - and mainly because I took the rather unusual setup of replacing glibc with hack-glibc, and other packages are dependent on the name.

    Conventions for package naming are also likely to improve on RPM based distros, as Debians excellent packagaing uidelines are used as a basic for RPM based APT repositories.

    Debian already has these features and goes quite far to eliminating many of the problems you've mentioned.
  • i didn't have an internet connection and would bring stuff back to my room on floppies or tapes.

    sometimes it would get to the point where much of the system would not boot or things would stop compiling or things would start coring.

    after a couple of hours of searching the green book, and not being able to fix the thing, with homework due in the morning...well, reinstall.

    i don't think it was that terrible of an option, considering how rapidly things were changing and the woeful state of dependency checking.

  • I think Slackware is by far the easiest to use and most sensibly packaged distro I have tried. I have been using it for about 1 year and I never even considered switching to any other distro. (Ok I tried SuSe when I first got my ata100 controller ;-)

    How long until the next release and will it include anything special like Reiserfs, ata100 or USB by default?

    If 2.4.0 were released tommorrow, how long would it be until we see it in a release?

    Thanks for all your hard work.

  • if you want to install them manually, all you have to do is gunzip and untar them.

    Ashes of Empires and bodies of kings,
  • apt/dpkg is still the best of breed

    ?

    I can understand apt, but I think that dpkg is on par with rpm. Does dpkg have signed packages yet?

    Anycase this whole distro crud will be tossed when connectiva finishes their apt port to rpm... and when redcarpet eliminates the competition ;)

    distro wars are lame...

  • Two points:

      1. How do you define what is in a package system?
      1. How do you define what is/should be flagged as a 'dependancy'?

    For example, the Slackware installpkg utility can warn you if you are going to over-write existing files. Some (presumably not you) would argue that this is a dependancy check.

    Similarly, the man page from the removepkg utility states:

    Removing a package (as well as installing one) can be a dangerous undertaking. For this reason, there is the -warn option available. When you use this, removepkg will not actually remove any files or links, but will output a detailed report of what it would do if you actually did remove the package.

    Personally, as a Slack user for the past 6 years, I have not had a need or desire to remove a package and all of its dependant libraries. Furthermore, I have been able to upgrade my system using only the package tools provided. For example, I removed KDE1 and installed KDE2 - without a hitch and only using the pkgtool utilities. It would seem that this means Slackware's package system is at least effective enough for me to do such things as upgrade a major part of my system, no?

    One could argue that if a package uses the System C libraries, then are not those libraries a dependancy? Clearly, you would not want your package system to remove all dependancies. In this example, your system would be useless without the glibc libraries.

    My point is that there is more than one way to define a package and its uses. Slackware is slightly different, but IMHO, the main functions are available for the Slackware user. Slackware is not about holding the user's hand. This is reflected in its package system. If you want hand-holding, use RHAT.

    Finally, if packages were so simple and definable, why are there so many package systems available? Food for thought, indeed.

    "Fat, drunk, and stupid is no way to go through life."

  • get slack (Score:3)

    by small_dick ( 127697 ) on Monday December 18, 2000 @09:33AM (#551323)
    wow...1996, and having to reinstall every three or four weeks due to library drift. really brings back memories.

    interesting about package management, but it appears apt/dpkg is still the best of breed.

    at some point it would be nice to have keywords (something like what "apropos/man -k" is to man pages) for packaging systems. I don't like having to go on the net to find commands/packages to get when I need a program to do "whatever".

    some of these news sites ("userlocal.com" in this case) are pretty cool. I prefer the articles that mix some tech background, review, and a bit of getting started all-in-one.

Slashdot Top Deals

You can be replaced by this computer.

Close