Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Slackware 7.2 [Not] Released 235

Posted by michael from the slacking-off dept.
Pete Blackley writes: "The best Linux distro out there has just released a new version; check out the README. And it comes with kernel... 2.2.18! Some things never change, and I am glad it works that way. Don't forget to check the autoslack package in the unsupported dir: it means the imminent death of all the "Slack lacks apt-get" arguments. PS: If you browse the ftp.slackware.com/pub tree, you'll see that Slack currently runs on vanilla x86, SGI VisualWorkstations and SunSparcs; I'm just waiting for the PowerPC port! PPS: All the crap about Slackware's death really is an exaggeration." That's what I like: a distro that isn't afraid to say that its death is an exaggeration. Update: 01/13 01:47 PM by michael : Slackware says - rudely - that 7.2 isn't released yet. This situation - confusion about what is released and what is not - is one that most software developers avoid by utilizing new-fangled conventions such as "beta".
This discussion has been archived. No new comments can be posted.

Slackware 7.2 Released More

Slackware 7.2 Released

Comments Filter:
  • Whoa? What's up with your period key? All of them look like the copyright symbol on my system.
  • Two days ago...ftped slackware-current/slakware.

    TANJ TANJ TANJ TANJ TANJ TANJ TANJ TANJ TANJ!!!!

    But, as usual, Thank you for an excellent Distro!

    ttyl
    Farrell

  • Hey pinhead, the italics in a story are the words of the author (not a /. person). Thus, they are the author's opinion, not a statement or indication (necessarily) of fact.

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

  • With Slack, I download (ftp - mget) the packages to a non-system partition and install from there. Works great, no ISO images, no burning CDs, etc.

    "Fat, drunk, and stupid is no way to go through life."
  • I needed a laugh today... Get Slack!
  • Ummm buddy the newest Linux is 2.4.0, you are probably referring to Redhat Linux 7.0, which as I recall is the redhat Distro's most recent release, you see Linux is just a kernel, all the other stuff is distro stuff, oh yeah and my personal fav is Slackware, I love the flexibilty, and intelligent setup options and lack of dumbed-down interfaces, I respect Debian too, thank you guys for giving us Distro's for the Linux old-timers.
  • I certainly do, but as my posting stated, 2.2.18 isn't too different from an end-user POV. You're talking server.

    (For which I typically use FreeBSD)

    Oh, and for the record, I'm using 2.4.0 on my main workstation (a dual 466 celeron.) While the 2.4x kernels bench a bit faster when compiling, I really don't see an incredibly noticeable difference. (Apart from my APIC errors in 2.4.x, these have to do with heat and the notorious BP6.)

    Every OS (and OS distribution) has its place. For simple IPMASQ have you checked out Coyote Linux? Pretty sweet!

    Cheers,

    Ben
  • I don't know about benchmarks, but my dual 466 w/256MB RAM and a Voodoo 3 2000 has always been great with:

    - tux racer
    - UT (and UT demo)
    - Quake3
    - Sof demo
    - Sin demo
    - anything else I put it through.

    I'm running Debian unstable w X4.0.2 and 2.4.0, but it was also just as fast with 2.2.18 and the 2.4.0test kernels.

    The nVidia may be faster, but I challenge anyone to find a more supported video card than my Voodoo 3... (Linux, FreeBSD, BeOS, QNX, oh, and Win32 too..)

    I'd gladly send you my XF86Config file, if you'd like. Also, I've read that using fancy video modes in LILO can have an adverse impact on your card's speed. I'm not too sure about that though.

    Hmm, try disabling some unneeded services too, Mdk 7.2 throws in a _lot_ of stuff by default.

    Ben
  • I don't believe you have used it for 6 years without knowing that the option is "-lpthread", not "-pthread".
  • Comment removed based on user account deletion
  • Comment removed based on user account deletion
  • HAHAHAHAHA.... someone with a uid in the mid-200000 range is bitching about how Slashdot isn't what it used to be?!?
    Look around you... the cause of that deterioration is your fellow 5-digit buddies.

  • Re:SGI ? (Score:1)

    by BJH ( 11355 )
    The SGIs mentioned in the article are Visual Workstations, i.e. just Intel boxes with proprietary chipsets and bus controllers. What you're talking about is probably an SGI Indigo or one of its relatives; to use that, you'll probably have to go with NetBSD (although I'm not sure if their sgimips port will work on the older models).

  • Re:SGI ? (Score:1)

    by BJH ( 11355 )
    Erk, sorry... I just noticed that you mentioned that it's an SGI O2. If so, then yes, NetBSD/sgimips should run on it.

  • As a long time Windows user, I find that most Linux fans tend to think most Window's users are not technically inclined. This is rather annoying , to me, as I have found most things computer wise are related in many ways.

    When I started playing with Linux (2.5-3 years ago) Slack was my first distro. Some guy I worked with gave my a CD and just said "try this".... A day or so later, I was up on the network (in Linux) and using lynx, emacs, vi et al.

    Don't sell people short based on the OS they are currently using... Eveyone can learn a new trick or two


  • The evidence [slackware.com]?


  • True, multi-homed Windows machine can be a bit unruly. I've been lazy (about my sig) and I'm not that punny -- NT == Empty.


    What I find interesting is how long I was lurking on /. before I got an account. Being a Windows user [at the time], I really never wanted to say anything to make wave. Now, things are a bit more out-of-control here -- it fun for everyone!


  • Yeah I was thinking along those lines, but what TLA could I use? NFS is almost close enough...

    Cheers


  • Don't blame Debian if you're too stupid read the docs and learn how to use update-modules. And please, don't make up bogus strawmen, because apt-get in no way splits the kernel source and of couse does not prevent you from downloading said source yourself and mangling it as you see fit.

    Stick to Slackware, because you certainly lack the required number of brain cells to grow out of it.
    --

  • Just as keeping a central database of all configuration data (the Windows registry) is stupid, keeping a central database of all files (locate) is stupid, and keeping a central database of all packages (RPM) is stupid.

    Quick, hurry to the head of the HR department and tell them that maintaining a central database of all employees is stupid! Don't forget to tell the same to your account manager at the bank!
    --

  • Excuse me if I'm missing something, but exaclty why do you need to reboot?
    --
  • I'm about to upgrade my computer (next week, when the parts finally get here) to a setup that will be using a UDMA100 card for the hard drive. I'm gonna want to reinstall Linux from scratch on the thing. (old setup has a badly hacked up Mandrake 6.1 install on it) Is there any distro that will boot on my new hardware? Or do I have to first install differently, then build a new kernel, then swap hardware and hope it works?
  • Slackware has always had a packaging system. The addition of an (unsupported) automatic upgrading utility is NOT the addition of a packaging system. The automatic upgrader only works to determine what has changed within the distribution and download those changes for you. The package utilities handle manipulating the packages.

    Check out a Slackware system and look at installpkg, removepkg, and upgradepkg, among others.
  • Slackware has an open development model. Any changes Patrick makes to the distribution are uploaded to our primary ftp server into the -current tree. This tree is the developmental branch for what will eventually become the next release.

    If you walk through the changelog, you will note that -current is just about as open as it gets. We've made changes only to retract those changes days later because they didn't quite work. How many other distributions hang their development out in the open like that?

    Yes, Debian does too. But to imply that Slackware does not have an open development model is wrong.
  • Most of the time, ldconfig is automagically run for you. When you install new libraries onto a running system, the "make install" almost always runs ldconfig. When you install libraries from packages, the packaging system usually runs ldconfig for you.

    While none of those methods are really automatic from the viewpoint of the operating system handling it for you, the end result to the users is the same. Libraries are magically dealt with.

    The only times you ever really run ldconfig are if there's a broken "make install", you're doing something really complicated, or you are in exceedingly deep shit.

  • same (Score:1)

    by Sloppy ( 14984 )
    I just installed 7.1 on a new box last night, and I haven't even got to use it yet, because mkraid is still clearing devices.
    ---
  • The argument that SysV is easier than BSD setup is laughable at best. At my dayjob I'm the release manager for a large BSD based project. It's easy as pie, you edit rc.conf, reboot, and that's how the configuration program works.

    This isn't to say that SysV is harder, instead of editing one file, you create some symlinks. Slightly more convoluted than setting a variable to expand to YES or NO, but certainly feasible.

    To this point, there's another guy who takes care of the Linux portion of our product, and he has no troubles either. This with both of us having thousands servers 'round the world.

    The fact of the matter is, if you can't handle any given startup method, you probably shouldn't be working on the servers. Maybe you should consider making a powerpoint presentation, showing your expected decrease in defects/KLOC after all projects are written in Java, or something. I've heard rumours that directors are good at that kind of thing.

    --
    "Don't trolls get tired?"
  • Because I can either write code that detects that status change (instead of just forcing the new status into config), shuts down daemons appropriately, and reconfigures firewall rules, etc, then send that through system integration, then through QA, or I can reboot. Given that the former would probably cost about $100k/release, just rebooting saves around $400k/year, in exchange for (literally) about 10 CPU seconds. Given that the cost/CPU second is fractions of pennies, it's a pretty easy choice.

    --
    "Don't trolls get tired?"

  • There's even a response to michael's whiny, petulant updated message.

    THIS_IS_NOT_A_BETA_EITHER.TXT [slackware.com]


  • And it comes with kernel... 2.2.18! Some things never change, and I am glad it works that way.

    I for one would have lost respect for Slackware, or any other distribution, had it shipped with 2.4.0. Excepting "bleeding-edge" distributions, does anyone really expect distributions to ship a x.y.0 of any kernel? Do we always have to be so divisive?

    I'm still running test10 (or maybe 11) on my box, and I'm looking forward to having the time to try 2.4.0 out. But that doesn't mean I want it in any distros yet as part of the default installation.

  • Redhat 7.0 dosen't include the 2.4 kernel.
    Redhat 7.0 is 2.4 READY.
  • There is a lonely box sitting in the other room. This may be the perfect excuse for popping the top of a refreshing cold one.

    Saturday morning, Slack Linux and cold beer from a glass bottle. :)
  • if slackware is the best distrobution, macos is the best operating system!

    i think it's funny how slashdot can claim to be an unbiased news source when personal opinions are so freely interspersed with the stories!
    ------------
    a funny comment: 1 karma
    an insightful comment: 1 karma
    a good old-fashioned flame: priceless
  • unfortunatly for me (Voodoo3 3k, CL5446 dual heads) when I have the AGPPART and the DRI stuff compiled in, Netscape crashes just about constantly freezing the keyboard and forcing a reboot (either hard or from a remote session). I hear that this is fixed in 2.4.0 revisions but I haven't had the time or desire to download them... Maybe 2.2.18 doesn't include these problems but I know 2.4.0 does.
  • > you dont have the pthread library installed. Go get it, install it and try again. This is nothing like the trouble you have getting stuff to compile on *BSD.

    The original poster provided us a specific example. Perhaps you could be so kind as to do the same.


    --
  • > Also, somebody on here posted: "The thing that utterly frustrates me is that NOTHING COMPILES!" -- I've never had a problem compiling programs on Slackware. In fact, programs I could never get to compile correctly on Red Hat, Mandrake, etc. work just fine on Slack.

    In support circles this is called "WFM", stands for "works for me". It's a perfectly good state for a problem to be in, but problems in a "WFM" state are considered *open* (often closed as "Cannot Reproduce" when the user can't make the problem come back). If the Linux community really cares about support by and for its users, it might want to try solving problems that require a little investigation. In this case, the problem is caused by a missing pthreads dependency, the sort of thing which, incidentally, packaging systems were designed to solve. Even the .tgz should specify a pthread dependency somehow, and if it doesn't, that's a bug.

    --
  • While you're frothing at the mouth flaming away, proud of your own correctness, note that slackware uses ".tgz" as its package format. It's like jar, it's a tarball with a manifest of some sort. Dumbass.

    --
  • If they want to be rude about it, don't cover them any more.

    -
  • What you described above is the exact same as RedHat's Rawhide thingie, thus we may imply that RedHat's development model is open too, right?
    --
  • RPM is not a packaging system. It is a POS created by people who obviously hate you.

    You're delusional, aren't you?

    It requires a database (databases are evil!) to track packages, it doesn't mesh well with compiled software, it has stupid dependency management,

    Databases are evil? Care to cite a few reasons, or is it just that you don't understand them?

    and it takes too much control away from the user.

    You really are delusional. What control does an RPM take away from the user? You do realize you can still build RPMs from source, right?

    How is anything in Slack 7.x NOT recent? They're glibc 2.2.3-based distros, and Slack 7.1 was the first distro to come with a KDE2 beta.

    Let me suggest a course in reading comprehension. Go back and read what I wrote again. I pointed out one package from slackerware 7.2 that is old, but harkened to the days when half of the packages were 3 or 4 versions old.
    --

  • It also doesn't make you deal with the POS RPM, and all the stupid circular dependencies that come with it.

    Which circular dependencies are those? Oh, you're probably one of those people that can't manage to grasp the concept of installing two mutually-dependent packages at the same time solves this "problem".

    While KDE on RedHat is a mess of a dozen RPMs, the same thing on Slackware is kde2.tgz.

    Not a fan of modularity, or a maintainable package model, eh? Slack's fine for one or two machines, when you go beyond that, it's a nightmare to maintain. Consistent package management is key. Doesn't matter if you're talking about RedHat, Mandrake, Debian, SuSE, or even one of the "fringe" distributions like Connectiva or Immunix. All of those have good working package models. I'm sorry, but tar and gzip does NOT constitute a packaging system.

    It is nice, however, to see Pat Volkerding putting some *RECENT* versions of software in his distribution, at least for the most part (XFree86 is a notable exception). It wasn't all that long ago that Pat & co. shipped packages that were 3, 4 or even more versions old...
    --

  • If it uses the same kernel as the rest? The best distro is always the one that you like the most. Not what the guy next to you says is the best.

    The only time this is not true is if you don't know anything about linux or distros. Then you have to trust your friend that knows more than you do to choose a distro for you.
  • How often are you going to change your services? Once, at install. After that you don't touch them anymore. If you know SysV style, it's easier. If you know BSD style, it's easier.

    It depends on where you're coming from. Some people think shuffling symlinks around is easiest. Others think commenting and uncommenting lines of shell script is easiest.
  • They got hacked because of *pilot error*, not because of any current insecurity in Slackware. They simply forgot to apply a fix to a running server.
  • Never having administered more than two machines at a time, I am no where nearly as qualified as you on this topic.

    But there are many ways to to "bsd" style scripts. Slackware does it one way. FreeBSD does it another. Under FreeBSD all local configurations are captured in rc.conf and rc.local. rc.conf is simply a list of options, where later options can override new options. Creating a script to add a new line at the end of rc.conf is trivial. I don't know how the other BSDs do it, but this method gives you the best of both worlds.
  • The whole crux of the matter is that in slackware world a release isn't final until it's out of slackware-current and in its own directory, like slackware-7.1. That's the way it's been ...

    Slackware-current is an ongoing staging area for the next release.

    As README72.TXT is in slackware-current .. it's just another file in the staging area.

    Plus .. really, do you think www.slackware.com wouldn't put up some sort of announcement if they had a new release?
  • Stability...

    Quoted from the slackware.com site:
    "Slackware [is] .. designed with the twin goals of ease of use and stability as top priorities."

    Bleeding edge isn't top priority .. stability is.

    If you want XFree86-4.0.2 in Slackware ... install the .tgz yourself [linuxmafia.org].

    If you want the 2.4.x kernel ... compile/install it yourself [kernel.org].
  • Personally I'd like to see support (latest modutils ...) for kernel 2.4 in one of them

    Red Hat 7 has support for kernel 2.4 [redhat.com].

  • At first look, it appears to be rude. However, consider your average slashdot effect. When you have 10K+ people start complaining that something is wrong with a release you haven't even released yet.... I actually thought it was a pretty funny response. Put a text file where it WON'T be missed, whereas a comment wouldn't be read by half the people even if it was +5 moderated.

    -Restil
  • Moderatrs: Please mod the parent of this back down. The security hole was fixed three days ago. Look at the ChangeLog.txt. [slackware.com]

    Wed Jan 10 12:46:50 PST 2001
    (* security fix *)
    glibc-2.2 contains a local vulnerability that affects all setuid root binaries. Any user on affected systems will be able to read any file on the system through a simple process: The user sets the RESOLV_HOST_CONF environment variable to the name of the file that they wish to read, then runs any setuid root program that makes use of that variable. The file is then written to stderr.
    a1/glibcso.tgz: Patched sysdeps/generic/unsecvars.h to fix the problem with RESOLV_HOST_CONF, and also to add HOSTALIASES to the list. (this change is noted in glibc-CVS)br> d1/glibc.tgz: Patched sysdeps/generic/unsecvars.h as above.

  • it's not like it isn't trivial to move the directories out of modules/2.4.0/kernel into modules/2.4.0 and make a symlink from modules/2.4.0 to modules/2.4.

  • it's a quote. click on the link. I think it is accurate in Australia, though no-one smokes anything but skunk weed here (ok, sometimes you can get someone who buys leaf but they're morons or they are just buying it to cut buds with). Prohibition leads to dealing, dealing leads to expensive pot, expensive pot leads to crime, crime leads to suffering.
  • you dont have the pthread library installed. Go get it [inria.fr], install it and try again. This is nothing like the trouble you have getting stuff to compile on *BSD.
  • We have the posix standard so we dont have to port between different variants of unix. Am I right?
  • The security comparison URL is here [securityfocus.com]. Caveat lector

    Agreed that most of the vulnerabilities are associated with the programs themselves. Newer versions fix old holes, but may make new ones.

    The distro can influence the final result by /etc/passwd, permissions, crontabs and the other configurations it makes or simply not installing some questionable pgms by default.
  • I've been a slackware user for 6 years now, and I love the distribution. The "minimalist" approach, and compiling and configuring your won server appeals to me for reasons that will probably be reiterated many times here.

    The thing that utterly frustrates me is that NOTHING COMPILES! I'm not sure which iteration of Slackware I'm using (current circa March 1999), and unless I'm compiling from GNU source I seem to be missing some obscure library that's pre-installed on RedHat and missing from Slackware. I'm not sure if its a libc vs glibc thing, but it's getting extremely frustrating and has made me consider shictching to another distro (likely Debian) the next time I install.

    OK, all of this is just Troll unless I can back it up. Let me go pull something from freshmeat and watch it not compile.

    OK,I admit it, it took me until my third try to find something that wouldn't compile for me. Must be a good day.

    I picked at random "BannerKiller". We've been having problems at work and need a simple dumb web proxy.

    phobos:tbradley:~/bannerkiller1.01> make
    (cd src; make)
    make[1]: Entering directory `/home/tbradley/bannerkiller1.01/src'
    cc -pthread -D_REENTRANT -DDEBUG -c proxy.c -o proxy.o
    cc: unrecognized option `-pthread'
    cc -pthread -D_REENTRANT -DDEBUG -c gestion.c -o gestion.o
    cc: unrecognized option `-pthread'
    cc -pthread -D_REENTRANT -DDEBUG -c connexion.c -o connexion.o
    cc: unrecognized option `-pthread'
    cc -pthread -D_REENTRANT -DDEBUG -c filtre.c -o filtre.o
    cc: unrecognized option `-pthread'
    cc -pthread -D_REENTRANT -DDEBUG -c utilsText.c -o utilsText.o
    cc: unrecognized option `-pthread'
    cc -pthread -D_REENTRANT -DDEBUG -c utils.c -o utils.o
    cc: unrecognized option `-pthread'
    utils.c: In function `startThread':
    utils.c:29: `pthread_attr_t' undeclared (first use this function)
    utils.c:29: (Each undeclared identifier is reported only once
    utils.c:29: for each function it appears in.)
    utils.c:29: parse error before `attr'
    utils.c:30: `attr' undeclared (first use this function)
    make[1]: *** [utils.o] Error 1
    make[1]: Leaving directory `/home/tbradley/bannerkiller1.01/src'
    make: *** [all] Error 2
    phobos:tbradley:~/bannerkiller1.01>

    OK, now, probably this isn't a good example; someone will be able to point out something I'm doing wrong or that the software I'm trying to compile is crap. Perhaps so. But often I see something cool I want to try out that flops horribly on Slackware.

    Should I jump distros, or become more realistic about what constitutes good source, and not try to compile everything I see on freshmeat? Would upgrading to Slackware 7.2 be a good choice for me in the future?

  • Which circular dependencies are those? Oh, you're probably one of those people that can't manage to grasp the concept of installing two mutually-dependent packages at the same time solves this "problem".
    >>>>>>>>>
    Why does everyone assume that when I complain about a problem in Linux, I can't fix it? I've been using RPM quite a lot. I can figure out how to type rpm -i XFree86*.rpm in order to install all the circularly dependant packages. It is still a stupid idea. If two packages depend on each other, they should come as one package. Given the huge amount of bandwidth available these days, there is no excuse for KDE to come as a dozen different packages that only .01% of the population will install seperately.

    Not a fan of modularity, or a maintainable package model, eh? Slack's fine for one or two machines, when you go beyond that, it's a nightmare to
    maintain.
    >>>>>>>>>>>
    Slack's a pain to maintain? How? I don't know what experiences you have (I'm not a sysadmin and proud of it) but I see RPM's "modularity" as a stupid splitting of of stuff that really shouldn't. Modularity does not refer to splitting stuff up for the hell of it. There has to be a good reason for doing so. Its like if Linus seperated out the Linux VM into a seperate module. You can't use a different VM with a particular kernel, and in order to use the kernel, you have to load the VM. So what's the point of splitting the two up?

    Consistent package management is key. Doesn't matter if you're talking about RedHat, Mandrake, Debian, SuSE, or even one of the "fringe" distributions like Connectiva or Immunix. All of those have good working package models. I'm sorry, but tar and gzip does NOT constitute a packaging system.
    >>>>>>>>>>>>
    RPM is not a packaging system. It is a POS created by people who obviously hate you. It requires a database (databases are evil!) to track packages, it doesn't mesh well with compiled software, it has stupid dependency management, and it takes too much control away from the user. That's why the packaging system I'm writing for BeOS will (hopefully) offer the power of a packager without all the crap in stuff like RPM.

    It is nice, however, to see Pat Volkerding putting some *RECENT* versions of software in his distribution, at least for the most part (XFree86 is a notable exception). It wasn't all that long ago that Pat & co. shipped packages that were 3, 4 or even more versions old...
    >>>>>>>>>>
    How is anything in Slack 7.x NOT recent? They're glibc 2.2.3-based distros, and Slack 7.1 was the first distro to come with a KDE2 beta.
  • I don't think you quite understand how shared libraries work. The reason BeOS includes this stuff in the kernel is not to boost performance, but because library loading is closely tied to program loading (programatically they are quite similar) and by putting both in the kernel you can share the common code for both. The BeOS feature I was referring to requires some knowledge of shared libraries. When a shared library is loaded, the code has to be relocated to whatever memory addresses are free. This is a time consuming job, so the dynamic linker caches the results of this process in memory. However, when the library changes, these caches have to be updated. BeOS supports all the symantics of correctly updating libraries as they are changed by the system. None of this requires any user intervention (like running ldconfig) and is handled transparently by the system. Its mainly the difference between a process that should be automatic, but is implemented as a manual one in Linux. (Just like module loading, but lets not go there...)

    As for the GUI and browser, BeOS is a microkernel. It even implements networking in userspace. I think positively ugly that Linux implements stuff like audio in kernel space ;)
  • Sorry. I missed the announcement of Sony's Linux-based IA. Since Sony is using this very dead OS in its eVilla IA [benews.com] I'm sure it has one based on the very not-dead LinuxOS, right?
  • Actually, the think the actual loading (at least on most *NIXs, I don't know about Linux) is done by ld.so.
  • It's not the same thing. Clumping all employee data together makes sense (since they all work at the same company) Different applications are totally unrelated, and their configurations should be kept seperate, but accessible from the same place. For instance, that's how the internet works. All the webpages aren't put on a central server. Instead, they're spread out and a common broker (DNS) allows you to access them from a central point. Stupid analogies aside, the fact remains that the only reason RPM and Windows keep a central registry of data is because that's the easy thing to do. Getting rid of that central registry, however, complicates things for the package manager designer (unless you've got great OS support, the reason I don't use a central DB is because the API's in BeOS make this method simpler for me ;) but frees the user from having to worry about database consistancy, or having to worry about what "going behind the tool's back" will do to their system. Think, for example, why you can't just delete a directory to uninstall an application. Apps litter your registry (Windows) or your home or /etc directory (UNIX) or you /config/settings directory (BeOS) with configuration data. Instead, if all configuration data was kept local the app, but the system provided a central access point for that data, you could just delete a directory and be done with it. Yet, you'd have the central access through the tools. Decide that you want to change the name of the app directory? In Windows, you have to reinstall, in Linux you have to reinstall, with a decentralized system, you just change the name.
  • I stand corrected, defeated, and humiliated ;) The point still stands that requiring a user-level program to ferret out library names is stupid.
  • ldconfig was, and they laughed as I explained it... until I told them they'd be rebooting on an MS box at that step.
    >>>>>>>>>>>>
    Except not really. Every other OS in the world is smart enough to automatically register DLLs without running programs like ldconfig. Without rebooting even. In fact, I was reading on article on dynamic linkng a few days ago, and they talked about how BeOS goes to great lengths to make sure that the cached and on-drive copies of DLLs are the same, and can add DLLs on the fly and have the relocated images updated.
  • You're delusional, aren't you?
    >>>>>>>
    Good drugs.

    Databases are evil? Care to cite a few reasons, or is it just that you don't understand them?
    >>>>>>>>>
    Right. I'm stupid. That is why I disagree with you. Grow up, jackass. I say databases are stupid when they are not used properly. Just as keeping a central database of all configuration data (the Windows registry) is stupid, keeping a central database of all files (locate) is stupid, and keeping a central database of all packages (RPM) is stupid. Package info should not be stored in one big database, but spread throughout a hierarchy and contained within the packages that they refer to. For example, I'm writing a package manager for BeOS. It has no central database. Instead, all dependency and package info is stored within the attributes of the folder where the package was installed. For example, if I install app.pkg to /boot/apps/app, then all the dependency info, version info, the description, update information, author, etc, is stored within the attributes of the /boot/apps/app folder. The folder is given a special key attribute, and every time I need to locate a dependency, I just search for that key and get the correct folder. The only centralized info is a cache of common searches. This is better than a centralized database for several reasons:
    A) No single point of failiure, and the importance of keeping the database's state correct dissapears.
    B) Packages can be moved, removed, renamed, etc, without having to update a central database, or having to go through tools like RPM.
    C) The user has total control over where packages are installed, and how dependencies are satisfied.
    D) The user has access to this data through any tool that deals with the (system standard) attribute system. This is unlike RPM, where only software coded for the RPM database is useful in accessing its data.

    While this would be harder to implement in Linux (which doesn't allow filesystem attributes) it wouldn't be terribly hard to emulate.

    You really are delusional. What control does an RPM take away from the user?
    >>>>>>>>>>
    You don't get to decide which dependencies are filled, the package maintainers do. You don't get to decide where stuff is installed (not without breaking things anyway) the package maintainers do. You don't get to decide how your system configuration is updated, the package maintainers do.

    You do realize you can still
    build RPMs from source, right?
    >>>>>>>>
    That doesn't solve any of the problems I just mentioned.

    Let me suggest a course in reading comprehension.
    >>>>>>>>>>
    Let me suggest a course in common courtesy.

    Go back and read what I wrote again. I pointed out one
    package from slackerware 7.2 that is old, but harkened to the days when half of the packages were 3 or 4
    versions old.
    >>>>>>>>>>>
    When I say that the Debian distro is out of date, people tell me to go use -unstable. If you're telling me that Slackware is out of date, then I'm assuming you're talking about 7.x, because the previous versions are too different to warrent any consideration.
  • you dont have the pthread library installed. Go get it, install it and try again. This is nothing like the trouble you have getting stuff to compile on *BSD.

    That's right, because on any recent BSD, you have a ports collection. cd /usr/ports/misc/foobar && make install, you're done. Nothing like the trouble on Slackware!

    And don't argue that it's harder to compile non-ported software. I have written and maintain a couple FreeBSD ports, and I'll tell you that it's nothing more than a few minutes of effort. Most people are good at writing portable code, you know.

  • How often are you going to change your services? Once, at install. After that you don't touch them anymore. If you know SysV style, it's easier. If you know BSD style, it's easier.

    Er, no. If it's using a server, and you're working for a company that has a valid reason for installing a new network service [for example, an intranet or instant messenging server], fairly frequently. That's one of the advantages of Linux [compared to the NT world] - you can actually run more than one service on a machine and maintain stability [security is a different matter, and DMZ etc are still an important consideration].

    For a desktop machine, all the time. Update monitoring tools, indexing tools for fast searches, ssh if you decide you need secure access to your CLI and GUI apps, etc. Desktop machines change services a lot.

    And despite knowing a few hundred Linux users, I've rarely seen anyone actually do the symlinking behaind the scenes themselves. They just run whatever tool came with their distro [especially for business use - wasting time on your clients watch is not a good thing].

    Then again, I also know of nobody who actually uses Slackware, apart from the odd IRC encounter. And everybody else knows Slackwares `packaging system' isn't [its a way of installing software and nothing more].
  • I'm not understanding what you're saying. Are you telling me that it is a common occurance for people to install ssh, uninstall ssh, reinstall shh, and so on, on a frequent basis?


    No, I'm not. That is obvious. I'm saying people often add services after they've installed and set of their box, because they want to use those services.

    A client of mine recently found a need for a external webmail server. This will be added as a service onto an existing box within their DMZ. The same client was also previously using sendmail to transfer mail between the internel mail server and the outside world. As sendmail runs as root [and should, thus, in my opinion, be uninstalled wherever it is encounted] sendmail was replaced with another, straight mail forwarding only service.

    Another client recently replaced all their insternal sendmail servers with qmail. Again, this was after the machines were originally installed.

    Is it that hard to grasp that a company might not be able to predict its future at the time its servers were installed, and may instead adjust their IT towards their own changing needs?

    Instead of making it easier for the user to perform these calisthenics, perhaps the best solution is to tell them to STOP!

    The users aren't performing calisthenics. They're doign what all good businesses to: acknowledging need and deficiency and adjusting their systems to meet those needs and address the deficiencies.

    Are you telling me that even business servers change their services on a regular basis?

    No, I'm telling you they change them on an occasional basis.

    How often are companies going to install a new network service? Daily? Weekly? Monthly? How often do new network services even arrive on the scene?

    Depending on the needs of the business. This ranges anywhere generally from yearly to bi-monthly, if you must know.

    Wow! You don't get out much do you?

    I suggest it mis you who needs to get out into the real world where companies actually change, and are smart enough to change their systems to meet those needs.

    Grow up.
  • In a utopian world yes but we are in an anti-utopia. A good example is Linux calling /bin/sh but in reality its really /bin/bash. Small things like that can ruin my week.
  • Did you consider the port maintainer might have made a tiny boo-boo? You could have fixed the problem by getting a newer ports tree in all likelihood. Blaming an entire OS because some high college kid forget a ${MAKEDESTDIR} in a Makefile do you? You don't throw the baby out with the bath water...
  • Debian ... The distro that's both true to the open source and still modern!

    Umm, how long was there between Slink and Potato?
    Debian is geneally a LOT more out-of-date then Slackware.

  • look at your error message and notice just how many times it complains about pthreads. Now, go intall posix thread support (found in the same place glibc is), and stop complaining because you cant interpret an error message.

  • Maybe I am wrong, but I don't know any other distribution that uses 2.2.18 yet (well, any other major distribution). SuSE doesn't, Red Hat doesn't etc.

    Maybe you have heard of Mandrake? The Cooker distro from Mandrake has both, 2.2.18 and 2.4.0

    And Cooker IS the best linux distro by far.
  • Man, this could get me back from Debian. Slackware was my first distro, and you never forget your first...

  • I just spent all day yesterday compiling that kernel and installing everything in the slackware-current changelogs from Slack 7.1.

    And so what do I see as the top story on /. the next day?

    THIS!!!

    Man if this is how my year's gonna go I may swear off keyboards. Damn damn DAMN!

  • The last thing we need is an army of thoughtless marketing droids.

    You mean things like this? "The best Linux distro out there has just released a new version"

    I'm always glad I can come to Slashdot for "valid, insightful opinions about features and technolology, rather than roboticly mouthing a party line."


    --

  • Xf86-4.0.2 is in the /contrib directory. Just don't install X upon setup, then go and installpkg the 2 packages there, and you've got the latest and greatest.
  • I prefer Slackware, because it is a "basic" linux. Unlike RedHat which has tons of excess stuff in it, Slackware is a pure (if you allow the expression) distribution. I guess Debian would be similar in this way, but it's latest distribution is always old... :)
  • Nothing compiles on slackware? Are you crazy? I have the opposite problem with redhat. Things compile perfectly on every version of slackware I've used (all of them). Then I take the same program to a friend's redhat box and it won't compile. Redhat puts includes and libraries in non-standard locations for some unknown reason. So most programs designed to be portable to any box need to be "fixed up" to compile under redhat.

    And before you go complaining about a distro check the program you are trying to compile. What is -pthread supposed to be??? It probably should be -lpthread. Thats not slackware's fault the author of your program screwed up.
  • My first taste of Linux was Debian. I hated it.
    Next up was Redhat 4.2, 5.0 followed. After I hosed the libs with rpm, I was reinstalling in custom mode and decided I didn't want xscreensaver installed. If I am away from my computer, I just shut the monitor off - it uses less power that way.

    The installer warned me that XFree86 REQUIRED xscreensaver, no problem I thought, no it doesn't I'll just continue and ignore it.
    The installer quit at that point.
    The Redhat guys had engineered xfree86 to require xscreensaver, user be damned.

    That is when I decided to switch distributions.
  • Why would anyone care if it is still "beta" it's not going to get significantly more stable just because it is final, infact a lot of "stable" versions are more buggy than their beta counterparts. I frequently use beta and cvs builds, out of the few crashed I have had, they were on the supposably stable software.
    --------------------------------------
    I'm a karma whore, mod me up damn you!
  • Firstly accept that there's no such thing as a benvolent "best" - and that "best" is just an opinion by whomever said it.

    You'll find life much calmer; and you won't have to type the same old tired tripe: "the best is what does the job", or "the best distro is always the one that you like the most"

    -- Eat your greens or I'll hit you!

  • Really now? (Score:3)

    by fireproof ( 6438 ) on Saturday January 13, 2001 @02:37PM (#510059) Homepage
    This situation - confusion about what is released and what is not - is one that most software developers avoid by utilizing new-fangled conventions such as "beta".

    And all this time I've been thinking that this situation -- confusion about what is released and what is not -- was one that most reputable web sites avoided by utilizing new-fangled ideas such as "research".

    ----
    "A fool does not delight in understanding, but only in revealing his own mind."

  • 2.2.18 - All most people Need... (Score:3)

    by benmhall ( 9092 ) on Saturday January 13, 2001 @05:38AM (#510060) Homepage Journal
    2.2.18 is great, it has the AGPART stuff, the DRI modules and all of the USB backported!

    This means that 3D Acceleration works with XFree86 4.x, so all of the newest games are a go!

    Really, from and end-user point of view there isn't much difference between 2.2.18 and 2.4.0.

    As for slack, never used it, but Debian Unstable sure is sweet!

    Cheers,

    Ben

  • michael, you moron (Score:3)

    by Lx ( 12170 ) on Saturday January 13, 2001 @03:26PM (#510061)
    /* Slackware says - rudely - that 7.2 isn't released yet. This situation - confusion about what is released and what is not - is one that most software developers avoid by utilizing new-fangled conventions such as "beta". */

    Why shouldn't they be rude? Some linux-kiddie site presumes to announce their releases for them, when they're still working on it - I think it's reasonable to tell them to get lost. And what most software developers do is make a new-fangled "release announcement" when the release is ready. If slashdot would put even the *slightest* effort into verifying stories before they run them, these things wouldn't happen. Fuckwit.

    -lx

  • Still on my boxen... (Score:3)

    by WareW01f ( 18905 ) on Saturday January 13, 2001 @07:24AM (#510062)
    Slackware, it's like that comfy pair of jeans that you have in the closet. Sure you could get a new pair, but you've broken them in. I will admit that in a work environment I'll grab the RedHat CD, but that's only because people look at you funny if you start compiling packages. In that environment I'm 'selling' Linux. At home, it's different.

    I was showing a couple of MS consultants how to install a program that didn't have an RPM available on a redhat box. I did the 'make install' and then an ldconfig. One asked what the ldconfig was, and they laughed as I explained it... until I told them they'd be rebooting on an MS box at that step... There are people out there that still think anything with a command line is behind the times... But when I go to a W2K box, cmd still works. I think Slackware gets a lot of the same comments from other distrib users that Linux gets from Windoze users. Kinda odd.

  • Until I can see the ISOs... (Score:3)

    by GC ( 19160 ) on Saturday January 13, 2001 @06:02AM (#510063)
    As far as I'm concerned Slackware 7.2 isn't released until Slackware-current gets move to Slackware-[number] and the ISO folder gets created and populated.

    Just because Patrick has put the README72 into the Slackware-current folder doesn't signify a release, impending or otherwise...

    having said that... should I go into the office to download possibly available ISOs tomorrow.... hmmm...

  • Re:"The Best Linux Distro Out There" (Score:3)

    by GC ( 19160 ) on Saturday January 13, 2001 @11:37AM (#510064)
    First was:
    ftp://ftp.slackware.com/.1/slackware/slackware-cur rent/GET_A_CLUE_SLASHDOT.TXT

    Then came:
    ftp://ftp.slackware.com/.1/slackware/slackware-cur rent/THIS_IS_NOT_A_BETA_EITHER.TXT

    But Slashdot fools never noticed that:
    ftp://ftp.slackware.com/.1/slackware/slackware-cur rent/CURRENT.WARNING

    has always been there.

  • Re:Hold it right there! (Score:3)

    by GC ( 19160 ) on Saturday January 13, 2001 @09:11AM (#510065)
    Another silly person... Read the changelogs and you will see that this was fixed last wednesday...

  • Re:"The Best Linux Distro Out There" (Score:3)

    by QuantumG ( 50515 ) <qg@biodome.org> on Saturday January 13, 2001 @05:30AM (#510066) Homepage Journal
    nah.. if it was a holy war then people would be hacking each other's web sites. Linux CyberTerrorist, news at eleven.

  • Well... (Score:3)

    by /dev/urandom ( 167536 ) on Saturday January 13, 2001 @07:29AM (#510067)
    I've been using Slackware since 1996, when I first started with Linux. I think, overall, it was and still is one of the best distros. I wouldn't recommend it to pure newbies, but it works great for me. I've tried numerous distros, including Red Hat, Caldera, Mandrake, and Storm Linux. None of those has worked as well for me as Slack -- they all had performance or security issues that did not please me.

    One good example of why I like Slack better: the NVidia drivers. I could not get them to work on Red Hat 6.2 or 7.0. When they did work, they were very crashy. It also took forever to get them to a usable state. But when I dumped RH and put Slackware back on here, the drivers installed flawlessly in minutes.

    Also, somebody on here posted: "The thing that utterly frustrates me is that NOTHING COMPILES!" -- I've never had a problem compiling programs on Slackware. In fact, programs I could never get to compile correctly on Red Hat, Mandrake, etc. work just fine on Slack.

    I'm not saying Slackware is the best, but it's certainly ONE of the best, especially for server-side uses. Use what ya like; the other distros are good, but I'm sticking to Slack. :-)

  • Linux Enthusiasm (Score:3)

    by Alien54 ( 180860 ) on Saturday January 13, 2001 @05:31AM (#510068) Journal
    Without wanting to get into a huge distro war thing, it is probably better that people are enthusiastic about Linux, even if favoring one distro over another.

    Debate is a healthy thing

    And besides, people who are expert can even offer valid insightful opinions about features and technologies, rather than roboticly mouthing a party line.

    The last thing we need is an army of thoughtless marketing droids.

    "Check out this years' new color scheme!"

  • The deth of Linux will come... (Score:3)

    by ChaoticCoyote ( 195677 ) on Saturday January 13, 2001 @06:49AM (#510069) Homepage

    ...not at the hands of Microsoft, but in the form of bickering over "the best" distribution.

    I thought Linux was about choice and freedom... I have [rustle, clatter, as he sifts through piles of CDs] five different distributions, all with their good and bad points.

    Diversity is the fuel for evolution; let's quit arguing about "my distro is better than yours", and start working toward making Linux even better through competition.

    Slashdot, BTW, should be ashamed for publishing an inaccurate (the release may not have happened yet) and biased (is Slackware really the best?) article. Get some journalism lessons, guys.

  • Re:Slackware rules, but 7.2 is not out yet (Score:3)

    by FreeMath ( 230584 ) on Saturday January 13, 2001 @09:43AM (#510070) Homepage Journal
    I think this says it all

    GET_A_CLUE_SLASHDOT [slackware.com]

  • Re:FTP... (Score:4)

    by GC ( 19160 ) on Saturday January 13, 2001 @06:35AM (#510071)
    I'm still waiting for an FTP install! I love slack, but I don't have the time to download and burn an ISO...and I'd rather not buy any CDs.

    Why not try out the NFS install? It's simple and really really easy.
    I use it for all my machines without CD-ROM drives. It's really quick too.

  • Re:Best? maybe - BUT for what ??? (Score:4)

    by be-fan ( 61476 ) on Saturday January 13, 2001 @07:33AM (#510072)
    To tell the truth, I have found Slack to be the easiest Linux distro I've ever used. It doesn't do a lot of crap behind your back, it installs stuff where you tell it, and it has the cleanest /etc/rc.d. It also doesn't make you deal with the POS RPM, and all the stupid circular dependencies that come with it. While KDE on RedHat is a mess of a dozen RPMs, the same thing on Slackware is kde2.tgz.

  • Comment removed (Score:5)

    by account_deleted ( 4530225 ) on Saturday January 13, 2001 @11:31AM (#510073)
    Comment removed based on user account deletion

  • GET_A_CLUE_SLASHDOT.TXT (Score:5)

    by tiny69 ( 34486 ) on Saturday January 13, 2001 @10:09AM (#510074) Homepage Journal
    This is funny.

    GET_A_CLUE_SLASHDOT.TXT [slackware.com].

    While you are at it, checkout the topic at #slackware on irc.openprojects.net.

  • Check the story BEFORE posting (Score:5)

    by tiny69 ( 34486 ) on Saturday January 13, 2001 @11:07AM (#510075) Homepage Journal
    Update: 01/13 01:47 PM by michael: Slackware says - rudely - that 7.2 isn't released yet. This situation - confusion about what is released and what is not - is one that most software developers avoid by utilizing new-fangled conventions such as "beta".

    Well if you would take the time to verify a story submission, they wouldn't have to tell you what a dumbass you are. They didn't use the word BETA because it has not been released as a beta yet.

  • Best? maybe - BUT for what ??? (Score:5)

    by redelm ( 54142 ) on Saturday January 13, 2001 @05:33AM (#510076) Homepage
    I too am a Slackware afficionado, but I wouldn't call Slackware the "best" without qualifying it. Nor would I call RedHat or Debian or ... the unqualified best.

    I certainly wouldn't call Slackware the best distro for newbies accustomed to MS-Windows and uninterested in learning the guts of Unix. That would be RedHat (or maybe Corel).

    But Slackware has some unique features that probably make it the best distro for someone coming from BSD (or SunOS) or who wants to learn the guts of Unix.

    Slackware runs a little behind the times in terms of program updates, but that also means that it has the fewest security holes (URL forgotten).

    AFAIK, it is the only distro with a BSD-style /etc/rc.d rather than the mess'o'symlinks SysV-style. That makes administration much easier to learn without depending on a tool like `linuxconf`.

  • Slackware rules, but 7.2 is not out yet (Score:5)

    by rveety ( 223650 ) on Saturday January 13, 2001 @05:51AM (#510077) Homepage
    Slackware was my first and still my current distro of choice. I've tried others, they just don't compare.

    Anyway, if you head on over to ftp.slackware.com/pub/slackware you will see there is no slackware-7.2 directory yet and no announcement on www.slackware.com. All they did was update the README file in the slackware-current directory in _preparation_ of releasing the next version.

Slashdot Top Deals

On the eighth day, God created FORTRAN.

Close