And this is where the "web of trust" is built. If you download a file from a malicious host, time to label that host as a black hole. Let's say you're using gnutella and assume that it has implemented the following feature. If you find that host A is malicious, you ignore the hostmask, similar to IRC host matching ("ignore host-a.domain.tld" or "ignore *.domain.tld"). Now, whenever a query arrives from that host, your client replies something like "440: I'm ignoring you, because you have a poisoned share file(s): weird_al-eatit.mp3."
It's a simplistic approach, but it helps avoid the "unknown" on a first download from that host. It gives the user a course of action for future interaction with that host.
It's a referrence to Advanced Dungeons & Dragons (TM) character alignment definitions. True neutral is denoted as N-N, or Neutral Neutral. A true neutral alignment is one where a person may or may not obey the law, acting instead, to bring balance back to the system (whatever system that might be). Druids, in an AD&D context, are true neutral characters because of their ties to nature. i.e. "Mother Nature" has no regards for laws, just balance in the cycle of life.
My reference was intended to show how the action of supporting extreme views for the purpose of balance was indicitave of a true-neutral alignment. It was neither a compliment nor a criticism, just an observation.
True, without an RMS type around, we would not have GPL, but I differ in your opinion that free software would exist in a sorry disarray of poorly coded hacks.
If GPL wasn't around, Linus may very well have written Linux with a different library. NetBSD, OpenBSD, and FreeBSD would still be around, including their C libraries. Software developers would have a plethora of their own software licenses mimicing BSD, Alladin, or Netscape style licenses.
Would we see more shareware? Not likely, given the nature of the UNIX development philosophy. Overall, would be less of a community if RMS or his "type", as you put it, never existed? Not likely. Rather it would be of a different format, a different paradigm.
One cannot equate a developer's sense of pride in his/her code by the existence of GPL or RMS. One cannot credit the desire to share software with the public, or the desire to provide free alternatives to proprietary software solely by the presense of RMS. You give RMS far too much credit for the effort and talant of others.
Your action of funding extreme opinions is a perfect example of a true-neutral druid-like person. As frustrating as it is to those of us who don't stradle the line in the sand so effectively, your existence does not go unnoticed.
Likewise, RMS's left-wing approach to software development, distribution, and his contributions to his coined Free Software Movement, do not go unnoticed. That he sees otherwise is amusing.
Here is an extreme case: a company wants to rid itself of Windows, and rolls out Linux workstations to all of its employees. Catch 22: the employees have the right to the source code for Linux, since you are providing them with binaries for their use; but the employees by contract are only allowed to use the computers for approved activites, which does not require the availability or use of the Linux source code. This is not a silly construct, it is a serious legal opinion (not originating from myself).
Where is the Catch 22? What rights do the employees have regarding the tools they use to perform their job? They are not the consumer in this case, they are employees. The consumer is the company. If the company changes and redistributes the software within the company but not outside the company, it is not violating the GPL License. There is NO End User License Agreement (EULA) in the GPL, only provisions for redistributing modified code and/or binaries to the public or to customers. Unless such action is taken, the company is the end user, the consumer. It would certainly be nice if the company provided its employees with information on how to obtain and install free software for themselves, but they are not obligated to do so.
But common sense should tell you that hormones and antibiotics can't be harmless.
That argument is highly subjective to the hormones, antibiotics, and bacteria in question. Although there are harmful bacteria that live part of their lifecycle in livestock waste, applying a general argument that hormones and antibiotics are "bad" is to ignore the nature and building-blocks of these treatements.
Proteins, in general, do not survive well in the digestive tracks of animals. Even viruses, with their highly protective protein shells, are subjective to deconstruction in the digestive system. The same is true for hormones and antibiotics, which are protein structures.
When you injest an antibiotic pill, you are counting on absorbing enough of the antibiotic in your stomach before the remainder travels to your intestines, where the more dangerous peptidases and enzymes "live".
If the antibiotic or hormone were introduced subcutaneously or directly into the blood stream, your liver and kidneys are in charge of filtering out excess chemicals and toxins. If a hormone or antibiotic survives past the urea present in your urine, it would certainly be considered one "bad ass" of a protein. Urea is a very powerful denaturant. The carefully constructed and folded protein that is an antibody or hormone is hopelessly twisted out of shape and effectiveness. Associative chemical bonds are broken, and are usually unrecoverable. Only the simplest of protein structures are able to fold back into their original forms. The longer the peptide chain, the less likely the protein will re-fold w/o the help of the "scaffolding", helper proteins, that was used to create them.
Although it is possible that hormones or antibodies could survive an animal's many physiological obstacles, it's not likely. That they would survive unscathed, even more so improbable. So, don't get your dungarees all in a bind over this. Worry, instead, about the over prescription of drugs on living animals, not their waste product.
Re:assert(expired(knowldege)); core dump
on
GPL's Strength
·
· Score: 1
Knowledge does not have an expiration date. I, for one, am pleased that this article was published as a/. item. I hadn't read this document, because I didn't know it existed. I wasn't actively looking for this information, but now that I have read it, I'm happy I did. This article has given me motivation to dig further, and such an active response is always a Good Thing(tm).
This also opens up the possibility of not only catching the thief, but also the chop shops. Thieves are born every day with the promise of quick money. If you kill one chop shop, you stop the source of money for a number of thieves.
Related, but not directly. To protect from "stack smashing" techniques (buffer overflows), run your glibc apps with
libsafe. It should detect, stomp out (i.e. abort()) and email you about overflow and out-of-bounds conditions by simply adding its path to the/etc/ld.so.preload file.
I hate to label myself as "hair splitter" or worse yet, a "traitor" to GPL, but let me propose a way around your dilemma.
You stated that the highly desireable code was GPL, correct? Is there no way to write an LGPL CORBA or SOAP object to export the functionality to an external program? Provide yourself a legal padding of the communication protocol. Yes, you would have to develop and maintain two separate applications, but you wouldn't have to recode this incredibally useful GPL code {whatever it may be}.
Compulawyer, If you actually visited the Turnitin site, you must not have paid close attention to the user agreements, privacy statements, and other documentation available for download. I question the amount of research did you put into this comment before hitting the send button. Please reference comment 3109270 for a statement from one of the founders of the site. Regarding you statement about the 1976 US Copyright Act and how it applies to student works: your recollection of how copyright is applied may be correct, but the application of your argument is out of context with the services provided by Turnitin. It does not take into account the application of "fair use". Your rant is therefore flawed.
As for the moderators to this post, you should be able to recognize someone puffing up his/her ego by sacrificing accuracy. It certainly does not warrant the scores I'm seeing.
For those who actually want to learn more about copyrights, fair use, and how they apply to you, start your research at the Stanford Fair Use website. The next logical step for US citizens would be to visit the US Library of Congress site on copyrights. Good luck!
You know. This has always been an interest of mine, unifying the handling of application settings to configuration files through a generic, modular, and extensible structured data parsing interface. Ultimately, one should not need a grand, "swiss army knife" parser that does everything, you just need to be able to add tools to the "knife" as they are required. Of course, we would want to do this all without the use of the dreaded "metadata file".
Quick example. Let's say I write an application that uses an *.ini style config file. There are a number of generic function calls that I'm going to want to make through the program, one of which might be readconfig(file*,parser*,confdata*). The challenge is coming up with something simple enough to make it easy to use while flexible enough to support structured data trees.
Disclaimer: I haven't put a whole lot of thought into this. Such a level of API may be useful, but in some cases may not be pratical to implement. Regardless, it is a fun problem to stew over.
I'm not going to type up a large dissertation about the this topic; I simply want bring this question to the forefront of your mind. Why is it necessary to wrap up so many different protocols with different goals into a single, all-encompassing protocol? What is the benefit of such an endeavor? What is wrong with simply passing URI's, which are text-encodeable, between IM's to start up separate connection processes?
Or if one must really have a generic way of specifying things, use a generic protocol designator:
/dcc senduri udp://myhost.mydomain.tld:20001
The response might look something like:
/dcc yournick geturi 2
Why must we encapsulate everything? It's starting to sound like such a protocol would rendure existing firewall QOS and traffic management strategies useless. If you can encapsulate all of your traffic through one IM client, you effectively have a firewall/router-piercing tool.
I really don't see other advantages to this that are practicle or prudent.
info(1), IMHO is one of the best on-line document
readers I've ever used. I liked it when I first
was acquainted with gcc. Type in 'info libc' and
you get a full libc reference book! With examples!
Ever thought man pages were limited in that you
couldn't automatically go to a referenced manpage?
Use info, hit tab until you reach the reference,
then hit enter. Walla!
Yes, info has become my all-time favorite. Far
beyond the limited HTML markup. Not convinced?
I would like to bring to your attention a few posts
already made concerning info(1) and the document
format texinfo:
2818653
and 2819778
I've recently started the chore of changing an
existing TeX document into texinfo format. I would have
loved to use a converter or a formatter from TeX to
texinfo, but alas, such a tool was not available.
vim's search and replacement works pretty well.
Regardless, since texinfo docs can create TeX, XML,
and HTML documents, I believe it's the best of the
docformat-to-docformat wars. Additionally, it's
a pretty simple markup to use.
Check out info2www
by Roar Smith
for a simple way to push out your installed info docs.
If I had my choice on what to implement for the ultimate network distributed filesystem, I would concentrate on LDAP, GFS, and Kerberose. LDAP, by its very nature was designed to be a distributed, redundant resource locator and data respository. It can be back-ended by any number of engines, including your more popular RDBMS's. It may seem a bit overwhelming, but well worth the investment in time and energy. Check out the OpenLDAP site for more information.
The second issue you're trying to address is data redundancy and failover. You want a high-availability solution. Look into using the Linux Global Filesystem (GFS). In a nutshell, it's a clustered journaling filesystem whose participants are equally responsible for the data on disc. If one of the servers in the cluster goes down, the first server to see it plays back the unfinished journal of the downed server, and the whole cluster continues on its merry old way.
So, it would be one GFS+LDAP cluster with multiple 1U, fiberchannel servers attached to a fiberchannel disc array. Tack on a gigabit ethernet backbone, and you've got a winner.
As everyone else should be telling you, your existing codebase is a very valuable resource. It's been tested and debugged a number of times. It's mature, it's stable, it's there. Don't throw out the baby with the bathwater.
Now, on coding standards and how to incorporate them into a legacy project. Your concern is NOT format. The format of your code, such as indentation, spacing, etc, should be the least of yoru concerns. Everyone has their own style, but there are wonderful tools that you can use to force everyone to a single style, ident and astyle just to name a couple. Use a wrapper script to the CVS (or similar system) on checkins. Force the code through an automated cleanup. check the code back out and make sure it compiles/runs as expected.
What you should worry about is how much your design team has embraced the "black box" design principal. Parameters go in, results come out with no "side-effects" that impact the remainder of the code. Make your code re-entry safe, i.e. stay away from globally scoped variables as much as possible.
Someone's going to give you the whole OO-Design sales pitch. Yes it's nice on paper, but don't sell out because something looks nice on paper. I learned this the hard way. I have a tendency to overdesign things. When OO, this gets to be really scary. I waste my time writing object classes for "everything" instead of simply designing the software to its functionality spec. Make things more "object oriented", "functional", or "blackboxed" when you find yourself repeating code elsewhere in the application.
Don't spend a lot of time with naming standards such as Hungarian, Modified Hungarian, etc. Find a style that you and your team is comfortable with for the Interface API level. Below the Interface API, be more lenient. It's likely that portion of the code will undergo many changes anyway.
And most importantly, document! This is the singlemost important issue of any coding project. Either force your developers to write docs as they go, use embedded documentation solutions, or hire a techwriter to follow you and your team around for a few months. Documented API is the quickest way to start someone off in the project, and a great way to keep track of the flow of the program.
OK, quick reference for you:
FHS -- the file heirarchy standard -- details
the standard layout of a Linux filesystem. It's
basically a standard that helps you
organize your data on disk based on its volatility,
how often it changes. Obviously, directories
like/,/usr,/lib, and/boot won't be changing
much. You can disregard/tmp,/proc, and/dev.
If you're using a packaging system, you can be
pretty much guaranteed that you can rebuild the
system relatively painlessly, as long as you keep
a backup of the package lists you've installed.
Now, something that occurred to me regarding
the management of "archive" files, such as mp3's,
ogg's, and the like. Each time you rip a CD and
encode the wav's thereof, you've reduced your
storage requirements by nine (roughly). Why not
hardlink your archive files to an unorganized../discXXXX/
directory. Link enough files in each directory
to roughly equal the storage media you're using.
Then, when you have a full "disc", burn it to CD.
We're not talking about an organized disc, remember.
Just faithful backup of new data. Do all of your
heirarchical data management in a set of different
directories, or use a database of some kind. Essentially, you can take out
much of the load that would be handed off to
Amanda or other archiving schemes.
Oh, be it far from you to actually contribute
your energy to making a better product for yourself,
much less anyone else. Obviously, it is a waste of
your time making sure something is done "right" as
opposed to simply bitching about it. Don't worry
about giving Debian the Heismann if this is your
attitude, it's far better off without such leeches.
Regardless, since you're obviously not interested
in giving accurate statements about the current
state of the Debian projects, its software, or
its developers and users, why don't I throw out
a URL for those that may be interested. You can
simply over look this:
Actually, there's a filesystem designed for this very application. It's called JFFS,
or Journaling Flash Filesystem. The original development for the filesystem was done by Axis
Communications, but it has since migrated to
the kernel proper under the term JFFS2. You can probably follow discussions regarding this filesystem and the kernel API at the Memory Technology Devices site. Check out the mailing list archives and/or subscribe to linux-mtd from the aforementioned site.
Just take a look at the 2.4.16 changelog. There really weren't that many changes to the kernel, and this bug is a fairly troublesome one. I would only sit on 2.4.15 if I had a UPS and I touched the/forcefsck file in root (you should do that now, anyway).
There really is no reason NOT to install the new kernel. You probably haven't racked up much uptime anyway, and not that uptime on 2.4.15 is really worth bragging rights anyway.
Personally, I upgraded when 2.4.16-pre1 came out. I also converted many of my partitions to ext3 (finally). I've been waiting for ext3 to be merged in with stable for a very long time!
Another improvement that wasn't detailed because of the famous "...merge with Alan..." messages in the ChangeLog was that most of LVM is up to date in the stable kernel now. LVM has been at the 1.0.1rc4 release for some time now, and not having to patch my kernel is pretty nice (although, the LVM crew made creating patches quite simple). If you haven't checked out LVM yet, do so. It's quite sweet!
I'm sorry, but did you not read his question? He didn't ask which databases you could connect to with Linux, he asked which LARGE, MISSION CRITICAL RDBMS Servers ran on Linux. This is not a troll, rather a correction on what this post should have gotten: off topic.
Slashdot Mirror
It's a simplistic approach, but it helps avoid the "unknown" on a first download from that host. It gives the user a course of action for future interaction with that host.
My reference was intended to show how the action of supporting extreme views for the purpose of balance was indicitave of a true-neutral alignment. It was neither a compliment nor a criticism, just an observation.
If GPL wasn't around, Linus may very well have written Linux with a different library. NetBSD, OpenBSD, and FreeBSD would still be around, including their C libraries. Software developers would have a plethora of their own software licenses mimicing BSD, Alladin, or Netscape style licenses.
Would we see more shareware? Not likely, given the nature of the UNIX development philosophy. Overall, would be less of a community if RMS or his "type", as you put it, never existed? Not likely. Rather it would be of a different format, a different paradigm.
One cannot equate a developer's sense of pride in his/her code by the existence of GPL or RMS. One cannot credit the desire to share software with the public, or the desire to provide free alternatives to proprietary software solely by the presense of RMS. You give RMS far too much credit for the effort and talant of others.
Your action of funding extreme opinions is a perfect example of a true-neutral druid-like person. As frustrating as it is to those of us who don't stradle the line in the sand so effectively, your existence does not go unnoticed.
Likewise, RMS's left-wing approach to software development, distribution, and his contributions to his coined Free Software Movement, do not go unnoticed. That he sees otherwise is amusing.
Where is the Catch 22? What rights do the employees have regarding the tools they use to perform their job? They are not the consumer in this case, they are employees. The consumer is the company. If the company changes and redistributes the software within the company but not outside the company, it is not violating the GPL License. There is NO End User License Agreement (EULA) in the GPL, only provisions for redistributing modified code and/or binaries to the public or to customers. Unless such action is taken, the company is the end user, the consumer. It would certainly be nice if the company provided its employees with information on how to obtain and install free software for themselves, but they are not obligated to do so.
That argument is highly subjective to the hormones, antibiotics, and bacteria in question. Although there are harmful bacteria that live part of their lifecycle in livestock waste, applying a general argument that hormones and antibiotics are "bad" is to ignore the nature and building-blocks of these treatements.
Proteins, in general, do not survive well in the digestive tracks of animals. Even viruses, with their highly protective protein shells, are subjective to deconstruction in the digestive system. The same is true for hormones and antibiotics, which are protein structures.
When you injest an antibiotic pill, you are counting on absorbing enough of the antibiotic in your stomach before the remainder travels to your intestines, where the more dangerous peptidases and enzymes "live".
If the antibiotic or hormone were introduced subcutaneously or directly into the blood stream, your liver and kidneys are in charge of filtering out excess chemicals and toxins. If a hormone or antibiotic survives past the urea present in your urine, it would certainly be considered one "bad ass" of a protein. Urea is a very powerful denaturant. The carefully constructed and folded protein that is an antibody or hormone is hopelessly twisted out of shape and effectiveness. Associative chemical bonds are broken, and are usually unrecoverable. Only the simplest of protein structures are able to fold back into their original forms. The longer the peptide chain, the less likely the protein will re-fold w/o the help of the "scaffolding", helper proteins, that was used to create them.
Although it is possible that hormones or antibodies could survive an animal's many physiological obstacles, it's not likely. That they would survive unscathed, even more so improbable. So, don't get your dungarees all in a bind over this. Worry, instead, about the over prescription of drugs on living animals, not their waste product.
go ahead ;-)
Knowledge does not have an expiration date. I, for one, am pleased that this article was published as a /. item. I hadn't read this document, because I didn't know it existed. I wasn't actively looking for this information, but now that I have read it, I'm happy I did. This article has given me motivation to dig further, and such an active response is always a Good Thing(tm).
This also opens up the possibility of not only catching the thief, but also the chop shops. Thieves are born every day with the promise of quick money. If you kill one chop shop, you stop the source of money for a number of thieves.
Related, but not directly. To protect from "stack smashing" techniques (buffer overflows), run your glibc apps with libsafe. It should detect, stomp out (i.e. abort()) and email you about overflow and out-of-bounds conditions by simply adding its path to the /etc/ld.so.preload file.
You stated that the highly desireable code was GPL, correct? Is there no way to write an LGPL CORBA or SOAP object to export the functionality to an external program? Provide yourself a legal padding of the communication protocol. Yes, you would have to develop and maintain two separate applications, but you wouldn't have to recode this incredibally useful GPL code {whatever it may be}.
Just food for thought.
As for the moderators to this post, you should be able to recognize someone puffing up his/her ego by sacrificing accuracy. It certainly does not warrant the scores I'm seeing.
For those who actually want to learn more about copyrights, fair use, and how they apply to you, start your research at the Stanford Fair Use website. The next logical step for US citizens would be to visit the US Library of Congress site on copyrights. Good luck!
Quick example. Let's say I write an application that uses an *.ini style config file. There are a number of generic function calls that I'm going to want to make through the program, one of which might be readconfig(file*,parser*,confdata*). The challenge is coming up with something simple enough to make it easy to use while flexible enough to support structured data trees.
Disclaimer: I haven't put a whole lot of thought into this. Such a level of API may be useful, but in some cases may not be pratical to implement. Regardless, it is a fun problem to stew over.
Remember with PZ quit NAI because of the source code issues. He is fully on the GnuPG/OpenPG solution over NFI's PGP.
%s/practicle/practical/g
I'm not going to type up a large dissertation about the this topic; I simply want bring this question to the forefront of your mind. Why is it necessary to wrap up so many different protocols with different goals into a single, all-encompassing protocol? What is the benefit of such an endeavor? What is wrong with simply passing URI's, which are text-encodeable, between IM's to start up separate connection processes?
Or if one must really have a generic way of specifying things, use a generic protocol designator:
The response might look something like:
Why must we encapsulate everything? It's starting to sound like such a protocol would rendure existing firewall QOS and traffic management strategies useless. If you can encapsulate all of your traffic through one IM client, you effectively have a firewall/router-piercing tool.
I really don't see other advantages to this that are practicle or prudent.
Ever thought man pages were limited in that you couldn't automatically go to a referenced manpage? Use info, hit tab until you reach the reference, then hit enter. Walla!
Yes, info has become my all-time favorite. Far beyond the limited HTML markup. Not convinced? I would like to bring to your attention a few posts already made concerning info(1) and the document format texinfo: 2818653 and 2819778
I've recently started the chore of changing an existing TeX document into texinfo format. I would have loved to use a converter or a formatter from TeX to texinfo, but alas, such a tool was not available. vim's search and replacement works pretty well. Regardless, since texinfo docs can create TeX, XML, and HTML documents, I believe it's the best of the docformat-to-docformat wars. Additionally, it's a pretty simple markup to use.
Check out info2www by Roar Smith for a simple way to push out your installed info docs.
Here's the GNU Texinfo documentation.
The only other acceptable format, IMHO, would be docbook.
If I had my choice on what to implement for the ultimate network distributed filesystem, I would concentrate on LDAP, GFS, and Kerberose. LDAP, by its very nature was designed to be a distributed, redundant resource locator and data respository. It can be back-ended by any number of engines, including your more popular RDBMS's. It may seem a bit overwhelming, but well worth the investment in time and energy. Check out the OpenLDAP site for more information.
The second issue you're trying to address is data redundancy and failover. You want a high-availability solution. Look into using the Linux Global Filesystem (GFS). In a nutshell, it's a clustered journaling filesystem whose participants are equally responsible for the data on disc. If one of the servers in the cluster goes down, the first server to see it plays back the unfinished journal of the downed server, and the whole cluster continues on its merry old way.
So, it would be one GFS+LDAP cluster with multiple 1U, fiberchannel servers attached to a fiberchannel disc array. Tack on a gigabit ethernet backbone, and you've got a winner.
Now, on coding standards and how to incorporate them into a legacy project. Your concern is NOT format. The format of your code, such as indentation, spacing, etc, should be the least of yoru concerns. Everyone has their own style, but there are wonderful tools that you can use to force everyone to a single style, ident and astyle just to name a couple. Use a wrapper script to the CVS (or similar system) on checkins. Force the code through an automated cleanup. check the code back out and make sure it compiles/runs as expected.
What you should worry about is how much your design team has embraced the "black box" design principal. Parameters go in, results come out with no "side-effects" that impact the remainder of the code. Make your code re-entry safe, i.e. stay away from globally scoped variables as much as possible.
Someone's going to give you the whole OO-Design sales pitch. Yes it's nice on paper, but don't sell out because something looks nice on paper. I learned this the hard way. I have a tendency to overdesign things. When OO, this gets to be really scary. I waste my time writing object classes for "everything" instead of simply designing the software to its functionality spec. Make things more "object oriented", "functional", or "blackboxed" when you find yourself repeating code elsewhere in the application.
Don't spend a lot of time with naming standards such as Hungarian, Modified Hungarian, etc. Find a style that you and your team is comfortable with for the Interface API level. Below the Interface API, be more lenient. It's likely that portion of the code will undergo many changes anyway.
And most importantly, document! This is the singlemost important issue of any coding project. Either force your developers to write docs as they go, use embedded documentation solutions, or hire a techwriter to follow you and your team around for a few months. Documented API is the quickest way to start someone off in the project, and a great way to keep track of the flow of the program.
Now, something that occurred to me regarding the management of "archive" files, such as mp3's, ogg's, and the like. Each time you rip a CD and encode the wav's thereof, you've reduced your storage requirements by nine (roughly). Why not hardlink your archive files to an unorganized ../discXXXX/
directory. Link enough files in each directory
to roughly equal the storage media you're using.
Then, when you have a full "disc", burn it to CD.
We're not talking about an organized disc, remember.
Just faithful backup of new data. Do all of your
heirarchical data management in a set of different
directories, or use a database of some kind. Essentially, you can take out
much of the load that would be handed off to
Amanda or other archiving schemes.
Regardless, since you're obviously not interested in giving accurate statements about the current state of the Debian projects, its software, or its developers and users, why don't I throw out a URL for those that may be interested. You can simply over look this:
You are such a desktop luser.
Actually, there's a filesystem designed for this very application. It's called JFFS, or Journaling Flash Filesystem. The original development for the filesystem was done by Axis Communications, but it has since migrated to the kernel proper under the term JFFS2. You can probably follow discussions regarding this filesystem and the kernel API at the Memory Technology Devices site. Check out the mailing list archives and/or subscribe to linux-mtd from the aforementioned site.
Just take a look at the 2.4.16 changelog. There really weren't that many changes to the kernel, and this bug is a fairly troublesome one. I would only sit on 2.4.15 if I had a UPS and I touched the /forcefsck file in root (you should do that now, anyway).
There really is no reason NOT to install the new kernel. You probably haven't racked up much uptime anyway, and not that uptime on 2.4.15 is really worth bragging rights anyway.
Personally, I upgraded when 2.4.16-pre1 came out. I also converted many of my partitions to ext3 (finally). I've been waiting for ext3 to be merged in with stable for a very long time!
Another improvement that wasn't detailed because of the famous "...merge with Alan..." messages in the ChangeLog was that most of LVM is up to date in the stable kernel now. LVM has been at the 1.0.1rc4 release for some time now, and not having to patch my kernel is pretty nice (although, the LVM crew made creating patches quite simple). If you haven't checked out LVM yet, do so. It's quite sweet!
Ever try ash? Here's a size comparison just to intrigue you a bit.
I'm sorry, but did you not read his question? He didn't ask which databases you could connect to with Linux, he asked which LARGE, MISSION CRITICAL RDBMS Servers ran on Linux. This is not a troll, rather a correction on what this post should have gotten: off topic.