Just from a legal standpoint . . . where are you guaranteed privacy under (US) federal law?
Strictly speaking, the burden is upon the government to prove that it has a right to acquire private information. One of the first principles of a constitutional republic is that the government posesses no "rights" or "powers" that are not delegated to it. The question is not whether we're guaranteed privacy - the question is where and how was the government authorized to violate our privacy?
This is why many people argued against the Bill of Rights. Not because they opposed the right to a free press, but because they feared a legal culture would emerge that assumed only enumerated rights exist, and that other rights are not guaranteed. What do you think the 10th amendment is for?
Of course, that's how it works in theory. Most people will let the government do whatever it damn well pleases as long as they've got a job and their house isn't being sacked by roving gangs.
This doesn't really address the problem... there are times when you want a limited set of formatting strings to be in a user-input string.
The LOCALE stuff is just the best example of this.
PScan would flag "hey, you're using user input for a format string!" (which is what we want/need to do), and gcc only validates against strings that are known at compile-time (certainly not the case here), so neither of these is particularly useful in this case.
What's really needed is a run-time library to validate a format string against the set of arguments you want to send along with it.
Ignoring the issue is one thing. Responding by giving RMS the literary finger is something completely different.
RMS pointed out that there remains one single legitimate licensure issue, indicated that there is a clear and simple path to resolving it, and took the initiative to address it and make it a non-issue as far as is within his power.
If KDE doesn't give a rip about licensing (a common criticism), well good for them, but there are much more diplomatic ways to say so. Responding with verbiage like "absurd", and with a "solution" (see paragraph 6) which is itself a continued violation of the forfeiture clause of the GPL (once you have forfeited your rights under the GPL to a piece of software, you do not re-gain those rights by undoing whatever violation caused that forfeiture), seems to me childish at best.
Maybe RMS should have made explicit that he was talking about "legal forgiveness" and not "ethical/moral forgiveness". He does tend to be more legal/license savvy than the KDE folks, and assuming they would understand that meaning (rather than interpret it as a last-volley personal assault) may have been an unfortunate oversight on his part.
First problem that springs to mind is that you've just ballooned the root domain.
Second problem that comes up is that there are a number of stock exchanges around the world, and there's nothing to keep two completely different companies from having the same symbol on two different exchanges. You could address this by making the various stock exchanges TLDs... you would have "*.csco.nasdaq", "*.t.nyse", etc. (Doing this would solve the first problem as well.)
Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
they have to work around the miserable way that HTTP handles state.
Not the problem at all. You can handle state in at least two ways in HTTP (there are others, but some of them are patented:-P), neither of which necessitate the shoddy practices seen on theses sites.
Cookies (example: yahoo)
Use proper redirection (302 Found or similar) to a URL embedding a session ID (example: amazon) instead of the claptrap HTTP-equiv refresh crap these sites use.
What kind of statefulness do you have in mind that Cookies don't deliver? (BTW: you might want to look at the most recent IETF drafts; Set-Cookie2 et al are much more mature than Netscape's hack.)
Ballocks. The problem here isn't web sites trying to "lock you in" - it's crappy web designers showing poor engineering skills and lack of knowledge of their tools. Specifically, lots of these sites (homedepot is a prime example) use the nefarious META http-equiv="refresh" kludge instead of sending proper 302/303/etc redirection responses. They're using an HTML-level mechanism to perform an HTTP-level function. Nothing more, nothing less.
If they wanted to lock you in, I would wager they could actually disable the Back button with JavaScript (I think some on-line banks do this so they can keep you from going "back" to a page providing info that you just invalidated by performing some transaction).
Is Motif a POSIX or IEEE standard? (I don't really know).
AFAIK, it's not. It IS Sinle Unix (i.e. Open Group), which enfolded and extended most of the POSIX APIs.
Why does the Open Group need to certify something as being normally distributed with Debian?
Again, you're ramming your head against the legal bootstrap problem: you want to declare Qt "normally distributed with Debian" to make it legal to distribute binaries of KDE. Well, fine... I now officially declare that my new library, libTravelingSalesmanInLinearTime.so, is "a normal part of the AdamLinux Distribution", and as such, I can "borrow" GPL code from anywhere I want to and link against it without having to distribute the code of said library. See the problem? If doing that is legal, you've opened up a loophole seven continents wide.
But the GPL does not have these requirements. It only talks about stuff normally distributed with the OS or major components.
I think you're misinterpreting that phrase - the word "the" (in "the OS or major components") has a very different meaning (legally speaking) than the word "an" or "some". "The" requires generality; "an" or "some" implies that an "existence proof" suffices.
Simply declaring a library to be normative just doesn't work - you need evidence from a cross-section of similar platforms (if such a thing exists) to validate a claim of "normalcy". (Non-existence of similar platforms would, presumably, exempt "standardized" BeOS and WinXX APIs, which would be defined in terms of the standard development toolkits available from those two providers.) Hence the sample UNIX list I threw out - they represent a WIDE cross-section of unices (mea culpa, *BSD should have been included as ONE entry; also, "Linux" would probably enfold "any OS distribution centered around the GNU user environment, i.e. glibc", thus enfolding GNU/Hurd whenever that becomes viable, since it's essentially the same userspace), and the overlap of a majority of items in the list (there were 7 items, hence the number 4) would therefore represents a very robust definition of "normal". If it's represented in a super-majority, that makes your case even stronger; the fewer it's represented in, the weaker your case.
I'm loosely applying the "internet standard acceptance criteria" here - multiple, independent, "interoperating" implementations.
Like it or not, some version or another of Qt is normally distributed with Debian GNU/Linux, Corel LinuxOS, Redhat Linux, SuSE Linux, FreeBSD, NetBSD, and many others.
If it's a GPL-compatible Qt (QPL2 will be AFAIK, but it doesn't yet exist), it's a non-issue.
If they also include KDE, and they introduced the two simultaneously, then they're still in the bootstrap quagmire, because a priori normalcy was not established prior to distributing the binaries in violation of the GPL. They might be able to argue for a loophole if there was a major point release of the distribution including Qt prior to including KDE - are there any examples of this?
I will also note that all three Linuxes you site offer the glibc2.1 API and essentially the same toolset at their core, so they are not clearly distinct. Similarly, *BSD do not represent independent userspaces. So you have 2 examples... not yet a compelling case for "normalcy".
My apologies. I was replying to a message which was terse and argumentative.
Prediction: within the next two years Qt will replace Motif as the X toolkit of choice by commercial unix developers.
That may very well be. My original point was that it is not the case now.
Already it is used for Opera and Kylix. So how many applications is required before you give Qt gets its official imprimatur of "system library"?
Three possibilities spring immediately to mind. I would be open to others.
The Qt API is adopted as a POSIX, IEEE, or other organization which publishes standard cross-platform interfaces.
The Qt API is certified by the Open grou (as Motif is) or in some other way by the holder of the Unix trademark.
The Qt library is included as a component (on distribution media) of any 4 of the following unices:
AIX
Tru64
IRIX
Solaris
SCO
Linux (any distribution)
Pick another Unix-like operating system (Ultrix, etc...)
Any of these would establish Qt as an accepted, "normally distributed" component.
But difference does it make if its primary use is with KDE?
It's a "legal bootstrap" problem - GPL code can only be distributed linked againts QPL code if that QPL code is some sort of normative interface (i.e. it falls under the paragraph 3 exception), where normative must be clear a priori, disregarding the particular use in question (in this case KDE). Without the a priori requirement, anyone can wedge anything into the paragraph 3 exemption and declare it part of his own personal "normative interface", and the GPL licence quickly becomes worthless.
I understand that QPL2 no longer suffers from the GPL-contrary clauses that would force Qt under the paragraph 3 exemption, so (hopefully) this whole debate will soon become moot.
There's stuff in debian that's only used by its maintainer, and sometimes even he's only a tinkerer:-)
Let's see... what packages in frozen-main depend on libqt2? A licq plugin... qbrew... qcad... qcam (superceded by v4l)... regexplorer... xgmod... xsidplay... that's it. 7. Wow.
And how many of those are primarily front-ends for software someone else wrote?
I stand by my assertion - Qt is seldom present unless (a) the system belongs to a developer targeting Qt specifically or (b) the system has KDE installed. (a) is fine (I've got Qt on a few systems myself - it's a nice library to work with) - just don't pretend that anyone except KDE advocates thinks Qt qualifies as any sort of "standard" component.
The point is this: you're quoting one specific part of the GPL and excluding other parts. You're also *completely* excluding the terms of the QPL.
I didn't quote the QPL because the QPL isn't the problem. The terms of the QPL are totally satisfiable under the status quo arrangement. The terms of the GPL aren't. The problem isn't that either licence is bad - it's that when the two are co-applied to binary distributions, they cause the GPL to become unsatisfiable.
And it shouldn't surprise you that most of the arguments are directed at KDE, since it has tried from the beginning to garner as much press as possible. Making yourself a highly visible target has its consequences. (WMfinder - hmm - can't find it in Debian, can't find it in RedHat - have there been pushes to have it included in either?)
But this argument has been beaten into the ground a thousand times before...
That's an interesting assertion, and in the abstract it might be possible. The GPL says:
(Paragraph 3)
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Which leaves us with one question: On what platforms is Qt "normally distributed with [a] major component"? ATM, the only substantive reason a distribution would include Qt is so it can include KDE, which is predicated inclusion, while the GPL exception is for non-specific inclusion. There would need to be a non-trivial base of non-KDE Qt applications out there to argue that such an inclusion is non-specific.
So your assertion does not address "the fundamental KDE problem": their target platforms do not satisfy the condition that would make them non-problematic for binary distribution.
There's an important distinction to be made, though, between "results that need a fixup for IEEE compliance" and "producing an incorrect answer". Most chips fall into the first category by design, and they include "hints" to help in the fixup process (FP status words, etc). FDIV caused certain divisors to yield less-than-signle-precision accuracy on division. It can be fixed by (this is the list that comes immdiately to mind):
Trapping all FDIV instructions and examining the operands
Inserting code into the compiler that tests for the magic operand values before executing an FDIV instruction
Inserting code into the compiler that proves inductively that the arguments cannot be the magic values
The first is a performance killer (SoftFP anyone?) The third is tricky to get right. The second and third break backward compatibility (i.e. old code will produce incorrect results).
Also: intel didn't pretend there was no bug - rather, they said "yeah, we've known about it for months, but noone except Prof. Nicely will get bitten by it more than once every thousand years." IBM counter-claimed that it would bite every few days and stopped shipping Pentium-based PCs, and that's when Intel started re-thinking their position.
Best of luck... everyone else is planning to take control of your life, too.
Re:Every technilogical[sic] breakthrough is like t
on
Frankenstein Time
·
· Score: 2
Ah, yes, the ever-popular "technology is morally neutral" line. Given how patently ignorant most people in the "science+technology" field are of philosophy and the other humanities (political science, sociology, history), I guess it should come as no surprise that so many unreservedly toe this line.
Every new technology has the potential to be profoundly dangerous to someone. It would, indeed, be a grievous error to argue that we should therefore cease and decist in developing new technologies; however, too many of us are, in our arrogance, far too eager to do the opposite and flip the bird at (or just ignore) anyone who urges caution, particularly in our own areas of expertice.
Unfortunately some people irresponsibly pervert our best intentions, and though unfortunate, I do not see this ending any time soon.
You have made what is perhaps the best argument for us, the vanguards of new technologies, to be particularly cautious in what we choose to pursue, investigate, and disclose. The truth is that we are moral agents, that technologies have moral consequences, and (I'm borrowing a bit from existentialist philosophy here) to fail to take ownership of the moral consequences of our actions and discoveries is the highest form of moral failure. There is something sick about the modern western scientific tradition that causes it to exalt knowledge for its own sake, and dismiss cautions regarding the content and potential of that knowledge. Our exaltation of "science" and our obliviousness to its moral implications causes us to charge agead with projects like the HGP, and only as the project nears completion do we even begin to think pragmatically about the effects this knowledge will have on our culture and our posterity.
What BXXP is going to help get rid of, is using HTTP for more than what it was designed to do... which was transfer Hypertext documents.
More accurately, HTTP was designed for moving documents around in a hypertext context. Which actually encompasses a whole lot of things if you don't artifically constrain your definition of "document".
And BXXP won't get rid of all the different protocols; what it might do is provide a common framing mechanism for protocols. Which means you have to do just as much work in protocol design determining semantics of what each extension and flag and whatnot else carried within the framework means. (And HTTP has some very well-developed and real-world-motivated concepts and semantics, f.e. in the caching and proxying and transactional areas; don't expect those to disappear any time soon.) It could, I suppose, makes it easier to build parsers, to which I say two things:
Violating protocol synatax/grammar is commonplace. BXXP will not cause people to magically get it right.
Many modern protocols have similar/identical parsing rules already. Consider RTCP's similarity to HTTP... you can basically parse them with the same code, just hook them up to different semantic backends.
Because multiple TCP connections do not share congestion information, it is possible for a greedy user to get more than his "fair share" of a pipe by using many parallel connections
Each TCP socket takes up system (kernel) resources on the server. Forcing the server to maintain a larger number of connections will cause its overall performance to take a hit.
It introduces throttling/aggregation difficulties for proxies (see RFC2616's requirements for maximum upstream/inbound connections from a proxy; a server throwing lots of parallel connections at a complient proxy will be sorely disappointed itself, and will waste the proxy's resources [see 2], ergo degrade its performance).
Why MUX (HTTP-NG's name for this idea) is a bad idea:
(If not done intelligently) it introduces artificial synchronization between responses, i.e., your quick-to-serve GIF could get stuck "behind" a slow-to-serve Perl-generated HTML page in the MUX schedule
As a general case of [1], creating the MUX schedule and framing the data is hard, and difficult to parameterize (Where do progressive GIFs chunks go in the schedule? What if the browser doesn't support progressive rendering of HTML? What size chunks should be used in the schedule - a low bandwidth client might prefer smaller chunks for more "even" fill-in of a document, while a high bandwidth client would prefer bigger chunks for greater efficiency)
DEMUXing is more work for the client at the application-protocol level.
MIME type - image/png. If PNG images on your server show up as broken images within Web pages and as gobbledygook text when referenced directly (i.e., as standalone URLs), you probably don't have the MIME type set up correctly. On the other hand, if they show up correctly for MSIE and some versions of Netscape but not others, you're probably running Microsoft's IIS server. Technically it's a bug in older versions of Netscape (versions 4.04 through 4.5), but consider switching to Apache anyway...
Netscape 4.72 (and previous versions I presume) have a subtle and evil PNG-related bug... when the browser loads an embeded image, it specifies a small subset of "image/*" types in its "Accept:" line, the last being "image/png". The problem is, someone forgot to put a comma before it; as a result, compliant web servers see the last acceptable type as "image/pjpeg image/png", which is nonsense, and (if they support negotiation properly) they'll return 406 errors instead of image/png files.
Sigh... guess I should report this to Netscape (only discovered it last night...)
Look at the length of the 1.3 development cycle, including the number of releases. Over a hundred. Many of those came literally within days (in a few cases hours) of each other.
It's only recently Linus started doing "pre-patches" instead of just daily point-releases to try to get "more stable" code out to the masses in "official" point-releases while getting the dismembering-edge stuff out in an accessible form, which led to the whole "-pre" nightmare (reminiscent of 0.99 days...)
And having an -ac* fork is nothing new either. Who remembers the fiasco about vger's CVS tree accumulating patches to the kernel mainline, and the flaming Linux gave davem about it?
Welcome to Linux development... we want to get it right, and doing so is hard, which means our best asset is as many eyeballs as we can get looking at new code.
In an interesting counter-example: The xiafs (I think it disappeared in 2.1 somewhere) was once a contender for the title of "the standard Linux fs". The author wanted to call it "LinuxFS", but people got all worked up about that, so instead he had to attach his name (Xia) to it.
Slashdot Mirror
This is why many people argued against the Bill of Rights. Not because they opposed the right to a free press, but because they feared a legal culture would emerge that assumed only enumerated rights exist, and that other rights are not guaranteed. What do you think the 10th amendment is for?
Of course, that's how it works in theory. Most people will let the government do whatever it damn well pleases as long as they've got a job and their house isn't being sacked by roving gangs.
Correction: 10:30 pm tonight, midnight friday and saturday.
I just heard that the new General Cinema at Landmark Center (former Sears building near Fenway) is having a $2 midnight showing of the Matrix tonight.
Hope you guys can make it!
What's really needed is a run-time library to validate a format string against the set of arguments you want to send along with it.
IMHO, YMMV, etc...
RMS pointed out that there remains one single legitimate licensure issue, indicated that there is a clear and simple path to resolving it, and took the initiative to address it and make it a non-issue as far as is within his power.
If KDE doesn't give a rip about licensing (a common criticism), well good for them, but there are much more diplomatic ways to say so. Responding with verbiage like "absurd", and with a "solution" (see paragraph 6) which is itself a continued violation of the forfeiture clause of the GPL (once you have forfeited your rights under the GPL to a piece of software, you do not re-gain those rights by undoing whatever violation caused that forfeiture), seems to me childish at best.
Maybe RMS should have made explicit that he was talking about "legal forgiveness" and not "ethical/moral forgiveness". He does tend to be more legal/license savvy than the KDE folks, and assuming they would understand that meaning (rather than interpret it as a last-volley personal assault) may have been an unfortunate oversight on his part.
Naturally caffeinated potatos (or potatoes)... caffeinated celery... caffeinated parsley... caffeinated beef (mmmm)...
First problem that springs to mind is that you've just ballooned the root domain.
Second problem that comes up is that there are a number of stock exchanges around the world, and there's nothing to keep two completely different companies from having the same symbol on two different exchanges. You could address this by making the various stock exchanges TLDs... you would have "*.csco.nasdaq", "*.t.nyse", etc. (Doing this would solve the first problem as well.)
- Cookies (example: yahoo)
- Use proper redirection (302 Found or similar) to a URL embedding a session ID (example: amazon) instead of the claptrap HTTP-equiv refresh crap these sites use.
What kind of statefulness do you have in mind that Cookies don't deliver? (BTW: you might want to look at the most recent IETF drafts; Set-Cookie2 et al are much more mature than Netscape's hack.)If they wanted to lock you in, I would wager they could actually disable the Back button with JavaScript (I think some on-line banks do this so they can keep you from going "back" to a page providing info that you just invalidated by performing some transaction).
I hate META http-equiv.
Simply declaring a library to be normative just doesn't work - you need evidence from a cross-section of similar platforms (if such a thing exists) to validate a claim of "normalcy". (Non-existence of similar platforms would, presumably, exempt "standardized" BeOS and WinXX APIs, which would be defined in terms of the standard development toolkits available from those two providers.) Hence the sample UNIX list I threw out - they represent a WIDE cross-section of unices (mea culpa, *BSD should have been included as ONE entry; also, "Linux" would probably enfold "any OS distribution centered around the GNU user environment, i.e. glibc", thus enfolding GNU/Hurd whenever that becomes viable, since it's essentially the same userspace), and the overlap of a majority of items in the list (there were 7 items, hence the number 4) would therefore represents a very robust definition of "normal". If it's represented in a super-majority, that makes your case even stronger; the fewer it's represented in, the weaker your case.
I'm loosely applying the "internet standard acceptance criteria" here - multiple, independent, "interoperating" implementations.
If it's a GPL-compatible Qt (QPL2 will be AFAIK, but it doesn't yet exist), it's a non-issue.If they also include KDE, and they introduced the two simultaneously, then they're still in the bootstrap quagmire, because a priori normalcy was not established prior to distributing the binaries in violation of the GPL. They might be able to argue for a loophole if there was a major point release of the distribution including Qt prior to including KDE - are there any examples of this?
I will also note that all three Linuxes you site offer the glibc2.1 API and essentially the same toolset at their core, so they are not clearly distinct. Similarly, *BSD do not represent independent userspaces. So you have 2 examples... not yet a compelling case for "normalcy".
Good for a grin, if nothing else.
- The Qt API is adopted as a POSIX, IEEE, or other organization which publishes standard cross-platform interfaces.
- The Qt API is certified by the Open grou (as Motif is) or in some other way by the holder of the Unix trademark.
- The Qt library is included as a component (on distribution media) of any 4 of the following unices:
- AIX
- Tru64
- IRIX
- Solaris
- SCO
- Linux (any distribution)
- Pick another Unix-like operating system (Ultrix, etc...)
Any of these would establish Qt as an accepted, "normally distributed" component. It's a "legal bootstrap" problem - GPL code can only be distributed linked againts QPL code if that QPL code is some sort of normative interface (i.e. it falls under the paragraph 3 exception), where normative must be clear a priori, disregarding the particular use in question (in this case KDE). Without the a priori requirement, anyone can wedge anything into the paragraph 3 exemption and declare it part of his own personal "normative interface", and the GPL licence quickly becomes worthless.I understand that QPL2 no longer suffers from the GPL-contrary clauses that would force Qt under the paragraph 3 exemption, so (hopefully) this whole debate will soon become moot.
Let's see... what packages in frozen-main depend on libqt2? A licq plugin... qbrew... qcad... qcam (superceded by v4l)... regexplorer... xgmod... xsidplay... that's it. 7. Wow.
And how many of those are primarily front-ends for software someone else wrote?
I stand by my assertion - Qt is seldom present unless (a) the system belongs to a developer targeting Qt specifically or (b) the system has KDE installed. (a) is fine (I've got Qt on a few systems myself - it's a nice library to work with) - just don't pretend that anyone except KDE advocates thinks Qt qualifies as any sort of "standard" component.
And it shouldn't surprise you that most of the arguments are directed at KDE, since it has tried from the beginning to garner as much press as possible. Making yourself a highly visible target has its consequences. (WMfinder - hmm - can't find it in Debian, can't find it in RedHat - have there been pushes to have it included in either?)
But this argument has been beaten into the ground a thousand times before...
Sounds like the NPL.
Which leaves us with one question: On what platforms is Qt "normally distributed with [a] major component"? ATM, the only substantive reason a distribution would include Qt is so it can include KDE, which is predicated inclusion, while the GPL exception is for non-specific inclusion. There would need to be a non-trivial base of non-KDE Qt applications out there to argue that such an inclusion is non-specific.
So your assertion does not address "the fundamental KDE problem": their target platforms do not satisfy the condition that would make them non-problematic for binary distribution.
- Trapping all FDIV instructions and examining the operands
- Inserting code into the compiler that tests for the magic operand values before executing an FDIV instruction
- Inserting code into the compiler that proves inductively that the arguments cannot be the magic values
The first is a performance killer (SoftFP anyone?) The third is tricky to get right. The second and third break backward compatibility (i.e. old code will produce incorrect results).Also: intel didn't pretend there was no bug - rather, they said "yeah, we've known about it for months, but noone except Prof. Nicely will get bitten by it more than once every thousand years." IBM counter-claimed that it would bite every few days and stopped shipping Pentium-based PCs, and that's when Intel started re-thinking their position.
Every new technology has the potential to be profoundly dangerous to someone. It would, indeed, be a grievous error to argue that we should therefore cease and decist in developing new technologies; however, too many of us are, in our arrogance, far too eager to do the opposite and flip the bird at (or just ignore) anyone who urges caution, particularly in our own areas of expertice.
You have made what is perhaps the best argument for us, the vanguards of new technologies, to be particularly cautious in what we choose to pursue, investigate, and disclose. The truth is that we are moral agents, that technologies have moral consequences, and (I'm borrowing a bit from existentialist philosophy here) to fail to take ownership of the moral consequences of our actions and discoveries is the highest form of moral failure. There is something sick about the modern western scientific tradition that causes it to exalt knowledge for its own sake, and dismiss cautions regarding the content and potential of that knowledge. Our exaltation of "science" and our obliviousness to its moral implications causes us to charge agead with projects like the HGP, and only as the project nears completion do we even begin to think pragmatically about the effects this knowledge will have on our culture and our posterity.
God help us all.
And BXXP won't get rid of all the different protocols; what it might do is provide a common framing mechanism for protocols. Which means you have to do just as much work in protocol design determining semantics of what each extension and flag and whatnot else carried within the framework means. (And HTTP has some very well-developed and real-world-motivated concepts and semantics, f.e. in the caching and proxying and transactional areas; don't expect those to disappear any time soon.) It could, I suppose, makes it easier to build parsers, to which I say two things:
- Because multiple TCP connections do not share congestion information, it is possible for a greedy user to get more than his "fair share" of a pipe by using many parallel connections
- Each TCP socket takes up system (kernel) resources on the server. Forcing the server to maintain a larger number of connections will cause its overall performance to take a hit.
- It introduces throttling/aggregation difficulties for proxies (see RFC2616's requirements for maximum upstream/inbound connections from a proxy; a server throwing lots of parallel connections at a complient proxy will be sorely disappointed itself, and will waste the proxy's resources [see 2], ergo degrade its performance).
Why MUX (HTTP-NG's name for this idea) is a bad idea:Sigh... guess I should report this to Netscape (only discovered it last night...)
It's only recently Linus started doing "pre-patches" instead of just daily point-releases to try to get "more stable" code out to the masses in "official" point-releases while getting the dismembering-edge stuff out in an accessible form, which led to the whole "-pre" nightmare (reminiscent of 0.99 days...)
And having an -ac* fork is nothing new either. Who remembers the fiasco about vger's CVS tree accumulating patches to the kernel mainline, and the flaming Linux gave davem about it?
Welcome to Linux development... we want to get it right, and doing so is hard, which means our best asset is as many eyeballs as we can get looking at new code.
Go figure!