Slashdot Mirror
Slackware 7.2 [Not] Released
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".
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
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.
-Cutt
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
this sig limit is too small to put anything good h
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.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
> 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.
.tgz should specify a pthread dependency somehow, and if it doesn't, that's a bug.
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
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
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?
--
Information wants to be beer, or something like that.
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.
--
The unsig!
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...
--
The unsig!
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
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 ...
.. it's just another file in the staging area.
.. really, do you think www.slackware.com wouldn't put up some sort of announcement if they had a new release?
Slackware-current is an ongoing staging area for the next release.
As README72.TXT is in slackware-current
Plus
Stability...
.. designed with the twin goals of ease of use and stability as top priorities."
.. stability is.
... install the .tgz yourself.
... compile/install it yourself.
Quoted from the slackware.com site:
"Slackware [is]
Bleeding edge isn't top priority
If you want XFree86-4.0.2 in Slackware
If you want the 2.4.x kernel
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
Play with my webcams and lights here
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.
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
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.
How we know is more important than what we know.
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.
How we know is more important than what we know.
We have the posix standard so we dont have to port between different variants of unix. Am I right?
How we know is more important than what we know.
The security comparison URL is here. Caveat lector
/etc/passwd, permissions, crontabs and the other configurations it makes or simply not installing some questionable pgms by default.
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
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". .01% of the population will install seperately.
>>>>>>>>>
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
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.
A deep unwavering belief is a sure sign you're missing something...
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
A deep unwavering belief is a sure sign you're missing something...
Sorry. I missed the announcement of Sony's Linux-based IA. Since Sony is using this very dead OS in its eVilla IA I'm sure it has one based on the very not-dead LinuxOS, right?
A deep unwavering belief is a sure sign you're missing something...
Actually, the think the actual loading (at least on most *NIXs, I don't know about Linux) is done by ld.so.
A deep unwavering belief is a sure sign you're missing something...
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.
A deep unwavering belief is a sure sign you're missing something...
I stand corrected, defeated, and humiliated ;) The point still stands that requiring a user-level program to ferret out library names is stupid.
A deep unwavering belief is a sure sign you're missing something...
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.
A deep unwavering belief is a sure sign you're missing something...
You're delusional, aren't you?
/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:
>>>>>>>
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
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.
A deep unwavering belief is a sure sign you're missing something...
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.
Umm, how long was there between Slink and Potato?
Debian is geneally a LOT more out-of-date then Slackware.
Carousel is a lie!
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."
--
Sometimes it's best to just let stupid people be stupid.
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 hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
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... :)
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!
--------------------------------------
58.0% slashdot corrupt
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 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
/* 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
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.
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...
First was:r rent/GET_A_CLUE_SLASHDOT.TXT
r rent/THIS_IS_NOT_A_BETA_EITHER.TXT
r rent/CURRENT.WARNING
ftp://ftp.slackware.com/.1/slackware/slackware-cu
Then came:
ftp://ftp.slackware.com/.1/slackware/slackware-cu
But Slashdot fools never noticed that:
ftp://ftp.slackware.com/.1/slackware/slackware-cu
has always been there.
Another silly person... Read the changelogs and you will see that this was fixed last wednesday...
nah.. if it was a holy war then people would be hacking each other's web sites. Linux CyberTerrorist, news at eleven.
How we know is more important than what we know.
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.
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!"
"It is a greater offense to steal men's labor, than their clothes"
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.
All about me
GET_A_CLUE_SLASHDOT
This sig intentionally left blank.
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.
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.
A deep unwavering belief is a sure sign you're missing something...
Sorry Michael, if slackware made you guys look bad or called into question the "throughness" of your research, but you screwed up. Again.
They have to deal with the fallout of people writing and complaining to them that they can't find 7.2, or that 7.2 is broken because of YOUR incompetance. Maybe an appology is in order, instead of more name calling. Rude indeed.
(note: I'm both a Slackware and a Slashdot fan, but clearly the blame for all of this lies with you guys this time. Show some manners and integrity.)
Finkployd
GET_A_CLUE_SLASHDOT.TXT.
While you are at it, checkout the topic at #slackware on irc.openprojects.net.
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
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.
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
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.
/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`.
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
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.