Limiting total outbound packets is not necessarily going to help him. Consider:
o If the outbound packets are limited at random, rather than preferrentially limiting non-"ACK only" packets over ACK packets, then the outbound ACKs are going to be dropped, resulting in the same situation.
o Even if there is preferential limiting -- which I think I've demonstrated is only possible with virtual circuit protocols -- the problem can still occur.
At issue is the fact that you can not control the input buffer depth on the outbound rate limiter, unless it's a bridge, not a router. What's going to control it is whether or not the data outbound has been ACK'ed or not, and the normal interactions with your machine on the other side of the limiter's retransmit timers.
The problem is all about pool retention time. The amount of time that a packet sits in RAM on the rate limiter is going to be your effective introduced latency. The only way you can know what this is going to be is empirically, because there's no way for you to know the buffer size.
Actually, with all the people wanting to play with window size ("It *has* to work because I *want* it to work!" [stamps feet]), they would be much better off setting the transmit window to 1 packet. This would self-pace transmissions at the transmit rate. Of course, you would still be screwed if you had a lot of transmit connections open behind the rate limiter (e.g. you were running a web or game server, or you were running a peer-to-peer application).
Actually, optimizing incoming bandwidth at the expense of outgoing bandwidth, even if you could do it successfully on the client side of things, rather than at the rate limiting server, would be the absolute worst possible thing you could do, if you wanted to run peer-to-peer, if both sides of peers were doing the same thing. 8-).
If you want to look at it another way: you are actually talking about how to go about reserving however much up channel bandwidth is needed to support the down channel.
We jokingly discussed an Evil Plan where I worked when CodeRed first came out.
One thing we discussed doing was getting a copy, disassembling it, and building a version that would install FreeBSD with Apache with Front Page Extensions and the Active Server Pages module over top of the Windows installation, with all of the web site content left more or less intact.
We figured that it would be pretty cool if we could make it so that people would not notice that their server had been "competitively upgraded" until the next scheduled reboot/update.
We thought that it would be even more likely to go a long time if we captured the console screen of the running server, and used it as the boot "splash screen" for the replacement OS...
Of course, as I said, doing this would be Evil, so we only discussed the possibility.
His upstream is 96Kbit, and his downstream is 1.5Mbit.
In round numbers, this means his upstream is slightly less than 1/16th his downstream.
Say his MTU is 1500 bytes. Let's say his ACK packets are 64 bytes (we were generous on the 1/16th, so 64 instead of 60 is not that far off).
That basically means that, assuming no packets are lost, and that all ACK packets are precisely equally spaced, then 2/3rds of his upstream bandwidth needs to be dedicated to ACK traffic for the downstream bandwidth.
Why do we have to assume equal spacing? Because he can't control anything other than his send order, because he can't control the rate limiting machine's discard.
Is it possible to do this with a traffic shaper on the client machine? Yes, with a very sophisticated traffic shaper, which maintains stateful information (e.g. like a PIX firewall maintains per connection state information). It's possible because now we know the numbers for his connection -- we don't know the general numbers, though, for *any* assymetric link, so this isn't something you could make into an installable package, without the user having to resort to math/tuning tools.
Even so... this only works if the traffic is connection oriented. So far, people have asked -- and he hasn't responded -- about the kind of traffic he's running.
If the download traffic is RTSP or UDP or any protocol based on packets other than TCP packets, then there's no way to make preference choices on packets sent out. And then he's back in exactly the same boat he was in before.
So it's not possible to say "install this", and it's not possible to say "install this, and set these tuning values based on your relative upstream and downstream speeds", unless you really limit the problem you are trying to solve.
Doing that will probably not be satisfying, since the primary reason for a (mostly) unidirectional pipe is to push content to users, and most content streaming protocols are not based on TCP or other things which can be stateful.
Making the receive window larger is going to delay the amount of time before an ACK is mandatory, not reduce the contention once an ACK becomes necessary.
In other words, if I'm filling a bucket a 10 gallons a minute and emptying it at 1 gallong a minute, no matter how big you make the bucket, it's going to overflow eventually.
In other words, your outbound ACKs are still going to have to stand in line behind your outbound data at the outbound rate limiting box.
I will now point out that every outbound buffer between you and the rate limiter will also be full, and need to drain before your ACKs get through...
-- Terry
You aren't going to be able to fix this locally
on
Traffic Shaping on DSL?
·
· Score: 5, Informative
The reason your downstream rate gets limited by your upstream rate limit is because of your inability to send acknowledgements upstream for the downstream packets you are receiving because of the congestion on the upstream link.
Once the advertised receive window is filled with packets, the remote side is not going to send any more data until it gets an ack from your computer.
At the point that the rate is being limited, the way to fix this is to give preference to ACK packets -- i.e. packets without payload.
The problem is that this has to be done at the point the rate is being limited, which is at your providers router, not at your router, and not at your Windows machine.
Installing the Microsoft packet scheduler, or some UNIX box with a real netowrking stack that you can exercise fine control over packet priority, as some people have suggested, isn't really going to fix your problem, except by maybe 10% (the exact amount depends on your average outbound payload size relative to an "empty" ACK-only packet).
This is because the problem is the queued data in the transmit buffer in the rate limiting device not containing your ACK's for inbound data.
Really, the TCP/IP protocol wasn't built for asymmetric reates, without equally asymmetric data transfers.
Effectively, you need to be able to control the transmission of data packets from your end based on knowledge of how full the input buffor on the outbound leg for the rate limiting device gets, so that you can throttle your data payload packets accordingly, to keep that buffer as empty as possible.
The only way you can really do this is to put code in your stack to monitor the advertised window from the other side, and the locally classify outbound packets as to whether or not they contain data payload, or are merely acks. You basically have to avoid filling the outbound queue on the rate limiter above 50%.
In an ideal world, the machine doing the rate limiting would do this for you. Some rate limiting machines for asynchronous connection do this, and it's not a problem (you can see the posts from the people who are rate limited, and don't understand your problem). But those machines are more expensive, and it's just as well for the provider if you feel pain as feedback for uploading, since it serves their purpose in providing you asymmetric service in the first place.
The problem's a lot easier when you are trying to avoid filling the inbound receive buffer for a router with a speed differential on one side (e.g. the inbound receive buffer on a router connected to a dialup modem bank, with a customer on a modem wanting to do QoS based on protocol type, so their SSH didn't lock up when an FTP or large HTTP transfer started up). *That's* where things like "AltQ" and the Microsoft packet scheduling engine become useful... not here.
If you had not made this posting, I would have had to have made it.
They also don't want you using only the second half of a round trip ticket, or splitting a round trip ticket in order to get two one-way tickets for different riders out of it.
It's simple economics.
Now I *do* object to anyone having access to the records after the tickets have expired, if the plane didn't end up going down, since I don't like having my movements tracked by people who have no positive reason to track my movements (them making money because they can market to me might be positive for them -- I mean positive for *me*).
To turn this around... suppose it was a telemarketing company that wanted this information, rather than the government, so that they could be sure to call you when you at a specific time to sell you, say, travellers insurance or air-sickness or jet lag products... would you want them to have it?
I'm actually surprised that there hasn't been more telesurgery experiments; I find the whole idea fascinating, and that the process can be made to work at all really amazing and impressive.
But I think that the referenced article had a better take on it than this posting, whose "additional technical details" are, at best, unintentionally misleading.
The implication of "video over IP" is that you did this over the public IP network, which in fact is not the case.
The fact that you did this over what was effectively a dedicated point-to-point link means that the use of the IP transport was irrelevant (worse; it added unnecessary overhead, subtracting from the total data rate).
I understand not wanting to risk someone's knee on a link succeptible to a DOS (or only succeptible as a result of a substantial investment of effort on the part of the attacker). But your posting implies that this is something which took place over the public Internet, or *could* take place over the public Internet, when it's not.
That may be; but as soon as you *fill in* that framework at its attach points, you are back to facing the IP issue, aren't you?
The existance of the framework encourages the use of technology that fills the hole... just as a pothole in the road wants to be filled.
It seems to me that we will end up with it as an "optional implementation item", which means "implemented in Windows and not elsewhere because of the patents", unless SGI steps up and answers the $64,000 question: is their grant of license still valid now that they've sold the patents to Microsoft... or isn't it?
If you have looked at the "bucket brigade" graphic in the article, then you will know what I'm talking about...
Is it just me, or does that picture seem to imply that you get a lower "buckets per unit time" throughput from asynchronous processing?
I know that this is not the claim of the article... but it's still my gut reaction to the graphic.
"Gandy Dancers" (railroad manual track laying and repair teams) were so-called because the first part of their name was the Chicago tool maker that made track laying tools, and the second part of their name came from the fact that they worked to a rhythm.
A better analogy would be a work-content based multipath route, where the amount of time is based on the type of work to be performed.
This would have implied (correctly) that, in an synchronous system, you should be able to "make up for" slow elements by doubling them up: i.e., when you are faced with a slow section of pipe, rather than bottle-necking, make it wider, instead.
Or to use their analogy, if you have a slow guy, then get another slow guy to stand next to him so he doesn't bottlneck the brigade.
Probably a more apt analogy would be nice: it's hard to show throughput increases, except by number of buckets in the hands of the people.
Depth textures and shadow textures, enabling real-time shadows and related image-based rendering techniques
Vertex programming framework, setting the stage for user-defined geometry, lighting and shading programs and enabling high-level general-purpose shading languages
Automatic texture mipmap generation, providing rapid updates and high-quality texture filtering for dynamic textures
Numerous smaller enhancements including:
Multiple draw arrays, for higher geometry throughput
Window raster position, for precise 2D and image rendering
User-defined fog coordinate, for advanced fog effects
User-defined secondary color, point parameters, texture level-of-detail bias, texture crossbar, and new frame buffer blending modes and stenciling functions for more flexible shading and rendering effects
So, yes, it includes the disputed Vertex shading that Microsoft claims is under patent not publically licensed, as it was before it acquired the patent from SGI.
Since SGI got the GPL religion, for them to have agreed to the inclusion of the technology in the specification implies that they think the patent is not enforcible, and that their license is still valid.
It would be nice if SGI would state a position on this and clear up the fud, wouldn't it?
From my reading of the patent, it's not just the domain name in use; they also parse out the whois information for the owner information from the relevent whois information, and they support the concept of zoning by delegation (e.g. "freebsd.org" is in the U.S., but "uk.FreeBSD.org" is in the U.K., etc.).
Basically, they have an entire process based on the information that was generally available at the time the patent was filed, and the information that was expected to be available, based on geographic information draft RFC's published around the time, and the ratified-but-seldom-implemented RFCs for inclusion of missle coordinates in your DNS, in case you wanted to inte an ICBM to land in your swimming pool.
So it's technically patentable as a process patent, though I would certainly argue that it was obvious to a skilled practitioner in the arts.
The 20 year penalty is for "an attempt to commit bodily harm". The Life sentence is for "an attempt to cause a death".
Nevertheless, the bill does not *merely* do what the news reports claim, and in that, it is alarming.
The interesting part is the definition of "protected system", which is taken from "18 U.S.C. 1030" (search for it in your favorite search engine), and the modifications made to it by the bill.
It does not involve only government computers, as the text of the bill itself implies. It also involves "any restricted data, as defined in paragraph y. of section 11 of the Atomic Energy Act of 1954" -- most of which is public information these days, and available from many web sites containing information on basic high energy physics (apparently, congress-critters believe that if they can't figure something out without a crib sheet, neither can your average university-trained physicist or engineer, which is why they think they could successfully legislate against light switches).
Further, it includes records from "information contained in a financial record of a financial institution, or of a card issuer as defined in section 1602(n) of title 15, or contained in a file of a consumer reporting agency on a consumer", per "15 U.S.C. 1681".
This can be loosely interpreted to mean "any system which stores credit card numbers".
--
The real question that we should be asking is whether this is a Writ Of Mandamus... it seems so, since there do not appear to be practical restraints on use of information gathered under the terms of this bill (i.e. "We thought he was a terrorist; as it turns out, our justification was bogus, but we still get to use the evidence gathered to inform against him for that Metallica MP3 he downloaded").
From my reading, it's unconstitutional, under the 4th Ammendment.
Of course, since it passed by such an incredible amount in the House, there no reason to believe that it will not quickly become law: it clearly has wide bipartisan support, and will clearly get the White House's approval (see below).
What that effectively means is that it will remain law, until it is challenged by a perpetrator on the basis of constitutionality. Basically, the law will have to be violated to be tested, at considerable risk to the violators, given the tendency recently for the Federal Government to use the Bill Of Rights in place of toilet paper.
I guess the only thing we don't know is whether this is an overreaction to last September, or if its an overreaction to the lack of consumer confidence in the market, where they think if they can point to themselves "*doing* something about some real market risk", we will forget all about "the man behind the curtain", and not insist on substantive tort reform.
If you read the House Report version of the bill, you'd think the latter (e.g. reaction to "Enron")... almost all of the listed congressmen are from -- *surprise!* -- Texas.
The Constitutional basis for incorporation itself is to serve the public and shareholders interests (read the relevent USC on incorporation, if you don't believe me); this seems to have been reduced to nothing more than "fiduciary responsibility to protect shareholder value, and screw public interst". More fundamental reform is required: this is not about people not acting like a--holes for fear of the penalty, it's about people not acting like a--holes because they *aren't* a--holes.
http://www.imc.org/ietf-calendar/cap-examples/ Definitely contain the IMAP4 command tags, and uses the "." as a list output terminator. The draft specification which was located at:
http://www.imc.org/ids.html#calsch
8 months ago specifically references differences between IMAP4 and ICAP serversm and how a server can be both. I still have a copy of it in the directory with my Cyrus patches on my other machine.
I intentionally went out of my way to implement an ICAP server in the context the the Cyrus IMAP4 server, thinking that there would be clients, other than the PHP4 client I implemented. I was going to release the Cyrus patches at some point, once I had cleaned them up.
I guess it's a good idea to never implement anything until the standards have settled down, to keep them from changing out from under you. 8-(. Unfortunately, vendors love to change standards out from under you, so that their implementation complies and yours doesn't, and so that you can't beat them to market with a product (beats competing on quality of implementation).
IMO, the correct way to implement this is via an LTAP-type protocol. My personal bias is for adding the transaction and notification features to LDAP, since the Lucent patent is based on the use of a proxy.
I realize that the draft specifically references "BEEP" (not legal in RFC-land, that...;^)), but I still maintain that it requires a client/server relationship to correctly implement calendaring.
This basically means that there are two options: the first is that the BEEP protocol will be used in a client/server mode, rather than the peer-to-peer mode that the BEEP designers intended, OR people are simply going to be unable to implement usable calendaring applications with the newer iCAL, as specified by the new draft.
I still maintain that a peer-to-peer calendaring application is not viable, since it fails to have the minimal features present in, say, OnTrack's "Meeting Maker" (i.e. the ability to schedule a conference room, since peer-to-peer networks are designed -- and intended -- to support paroxial participation in the network).
Or in plain English: there is a lot of hype about peer-to-peer, and not a lot of delivery of the goods.
FWIW: I worked at Artisoft when the Artisoft LANtastic product was *the* preeminent peer-to-peer networking software out there, and was one of just 4 engineers involved in the UNIX (initially, Linux) port, so I'm not talking from ignorance here.
The ICAP protocol is based on the IMAP4 protocol. As such, it has the assumption of a client/server relationship. It also has state assumptions that are not necessarily valid over time, and BEEP appears to not support the concept of nested transactions (the IMAP4 and ICAP protocols are biased toward set encapsulation -- that's why there are all the irritating nested parenthesis -- which lends a strong bias toward stack based interpretation of requests: transactions).
Since BEEP is intended as a peer-to-peer connection oriented protocol, it's not ever going to really be practical as an ICAP transport.
The main issue that a server deals with is a shared resource that belongs to the system, rather than participates as a peer. This becomes an issue when you want to schedule use of a confernece room or interview office, where these resources, unlike human beings, don't have a machine which participates in the process as a peer. It's not possible to totally distribute such a system, since the peers are not the only mutually contended resources (if "Bob" drops out, then you can have a request outstanding, but not accepted; no matter who else attends your meeting, though, the conference room *must* "attend").
As far as a peer-to-peer workgroup calendaring service, it *may* be possible to use MIME encapsulated calendar update notifications, similar to the way Microsoft Outlook can be a transport for Microsoft Schedule information (the message type involved lack standardization).
However, such an approach would have the drawback of "netsplits" (in the IRC sense) redulting in shared resources ending up with conflicting scheduling (just like "operator" status in an IRC network following recovery from a "netsplit").
In general, calendaring is a much more complicated problem than people tend to give it credit for being.
Right now, the best protocol bet for Calendaring is LDAPv3 with the "persistant search" or a similar notification mechanism (e.g. LTAP), except not as a proxy, and mandatorily integrated into the LDAP server itself (due to replication requirements).
One place BEEP *might* be useful is data replication between peered servers. The primary reason it could be useful here is that the entity relationship is *peer*, not *client/server*.
When I first joined the project, dpkg was a very evil shell script that was little more than a placeholder.
Listen, lad. I built this kingdom up from nothing. When I started here, all there was was swamp. Other kings said I was daft to build a castle on a swamp, but I built it all the same, just to show 'em. It sank into the swamp.
"I wrote dpkg v2, a Perl script, because it was the thing that needed writing next."
So, I built a second one. That sank into the swamp.
"The current C dpkg is actually the third dpkg. I think there may have been parts of the Perl one that were done by someone else, but I basically wrote the Perl version, and wrote all of the C version."
So, I built a third one. That burned down, fell over, then sank into the swamp
"Around the introduction of the C version, the format was changed from the old `two lines of text and two gzipped tarfiles'. I wanted something more extensible, with room for some additional out-of-band metadata. I also wanted something you didn't need Debian-specific tools to unpack."
but the fourth one... stayed up! And that's what you're gonna get, lad: the strongest castle in these islands.
[ Dammit, I hate people who use cookies instead of hidden fields for forms ]
"I think you're being terribly naive about this, particularly the It's now nearly impossible for a commercially paid developer to contribute usefully to FreeBSD comment. Development work on FreeBSD succeeds on both fronts."
I have built or contributed to 5 embedded systems products based on FreeBSD. If you count licensing the source code to third parties, that number goes up to 12. This list includes IBM, Ricoh, Deutch Telekom, Ricoh, Seagate, ClickArray, and NTT, among other lessers.
There has been no case where any of these projects have involved use of FreeBSD-current. It just does not happen: the intent of the commercial is to work on the product itself, not on the platform on which the product is intended to run. Toward that end, every one of these projects has used a stabilized snapshot of FreeBSD, usually a release, and, on only two occasions, a -security (release plus security bug fixes) or -stable (release plus any bug fixes) branch. Under no circumstances has the employer *paid* me to work on -current on their time.
There are notable exceptions to this practice, where there have been specific DARPA grants, or Yahoo has a number of highly placed people who get to pick what they work on; these opportunities are few and far between.
"Plainly, it is concievable that were a commercial team to submit changes to -CURRENT, they would be timed for integration into -STABLE in the same manner as current changes are. And try not to make a mistake, a *lot* of things are folded back from -CURRENT on a regular basis. They may have a lengthy test period, but hey, shouldn't every new feature?"
Your argument is that FreeBSD -current and FreeBSD -stable bear a strong relationship to each other, besides each having the prefix "FreeBSD", and that integration into -current means that testing will be done, and that after testing, integration into -stable will happen.
I disagree strongly. The two source bases run different tool chains, and they are significantly different, under the hood, as well. It is nearly impossible to write kernel code that operates identically, without substantial modification, on both -stable and -current. The differences in process vs. thread context, and locking *alone* mean that there is not one subsystem in the kernel that has not be touched. This ignores the semantics and API changes, etc., on top of that.
Despite back-porting, there is nearly two years difference between -stable and -current. I have a system that I updated to -current in October of 2000. It claims to be 5.0. FreeBSD has not made a code cut off the HEAD branch in that entire time -- or FreeBSD 5.0 would have been its name.
It would be a serious mistake for Linux to follow FreeBSD down this path. Linux should continue to make release code cuts off their HEAD branch, stabilize, *and then deprecating* the releases.
FreeBSD has failed to deprecate its branches, following releases. This means that if a commercial developer wants to contribute code for inclusion in future version of FreeBSD in order to avoid local maintenance (FreeBSD, unlike Linux, does not *require* such contributions, it relies on this and other emergent properties), they must first take their code from where it's running, and port it to an entirely *alien* environment. Then they must wait for approval, and then back-port it, since no one is going to do the work for them, to the minor version after the one that they stabilized on for their product.
"It keeps the stable kernels stable, and it folds in new changes in an orderly and well tested fashion."
`Orderly' and `tested' are one thing. Two *years* of API and interface evolution are something else entirely.
The first time Linux cuts a distribution that isn't a pure maintenance point release of a minor number (e.g. NOT 2.5.1 off 2.5, and NO 2.6 off of 2.5 if a 3.0 is in the works), it will have effectively forked itself.
[...Putting on my "politically incorrect" hat... ]
It's a common Open Source Software problem: there is the last release, and there is the developement branch.
Developers would all prefer that you use the developement branch, report bugs against *that*, provide patches for the bugs against *that*, do all new work in the context of *that*.
But it's not how things work, outside of an Ivory Tower.
In the real world, people who are using the system are using it as a platform to do real work *unrelated to developement of the system itself*.
I know! Unbelieveable! Heretics! Sacreligios!
FreeBSD has this disease, and has it bad. It very seldom accepts patches against it's last release, even in the developement branch of the last release, if those patches attempt to solve problems that make the submitted work look suspiciously like "developement". The cut-off appears to be "it fixes it in -stable, but would be hard to port to -current; do it in -current, as your price of admission, and back-port it instead, even if you end up with identical code".
The only real answer is to keep the releases fairly close together -- and *end-of-life* the previous release *as soon as posible*.
The FreeBSD 4.x series has lived on well past FreeBSD 4.4 -- supposedly the last release on the 4.x line before 5.0. FreeBSD 4.6 is out, and 4.7 is in the planning stages.
It's now nearly impossible for a commercially paid developer to contribute usefully to FreeBSD, since nearly all commercially paid developers are running something based on -stable. FreeBS -current -- the 5.x developement work -- is *nearly two years* off the branch point from the 4.x -stable from which it is derived.
Linux *MUST* strive to keep the differences between "this release" and "the next release" *as small as possible*. They *MUST* not "back-port" new features from their -current branch to their -stable branch, simply because their -current branch is -*UN*stable.
Delaying the 2.6 release until the 2.7 release so that you can "stabilize" and "jam as many 2.7 features into 2.6 as possible" is a mistake.
Make the cut-off on 2.6. And then leave it alone. People who are driven by features will have to either run the developement version of 2.7, or they will simply have to wait.
Bowing to the people who want to "have their cake and eat it, too" is the biggest mistake any Open Source Software project can make.
Don't drag out 2.7, afterward, either... and that's inevitable, if everything that makes 2.7 desirable is pushed back into 2.6. Learn from the mistakes of others.
"From a scientific perspective, though, this isn't a very satisfying situation. Without some kind of theory about why corn is worse than all these other foods, all you have is some anecdotal evidence."
No, it's not satisfying. Which is why I suggested that people contact an allergist to obtain better statistical information than I was personally able to offer. I don't claim to have done a scientific study. If you read the article, youll see that NIH doesn't tend to fund scientific studies that challenge the status quo. I rather suspect that ADM would dislike any study that implicated corn, as well.
"Or perhaps corn was a particularly large proportion of your diet."
That's rather one of the points of my posting; corn is a particularly large proportion of the diet of *every* American.
"It doesn't sound as though you've done any serious control tests at all, so you really don't have a basis for drawing a conclusion."
You're right. I'm not personally a nationally recognized medical research facility. 8-). I will point out the "?" on the end of my subject line, in my defense.
"Your anecdotes about corn don't really qualify, unfortunately - it just puts you right there alongside the people who claim that it's only the fat, or only the sugar, or... I'd be willing to bet any amount of money that you're all wrong."
Read back over this thread. You practically had to *beat* anecdotes out of me. It took you three posts to get there. I was very reluctant to provide anecdotes initially, knowing the probability was high that you would react as you have reacted, and dismiss the entire idea because I have given anecdotal evidence at any point during the discussion.
"It's a complex business, and humans don't seem to be good at intuitively analyzing situations that involve multiple interacting variables."
You are hanging out with the wrong humans; you need to hang out with engineers.
Eventually we *will* solve this problem, with brute force if we can't find any other way, and we'll simply have billions of small robots *undo* any result we find undesirable, if it takes having them carry the fat out of the fat cells on their backs, a molecule at a time, and carry nutrients in, one molecule at a time, if all we choose to eat is Cheetos(tm) cheese flavored corn puffs, or whatever.
---
It seems to be a common problem with doctors that they have elevated the "Above all else, do no harm" provision of the Hippocratic Oath to the point it's "Above all else, do nothing, unless you know for a provable fact that it will do good, rather than merely being benign". There is no longer such a thing as "practice of medicine".
It seems to me that doctors are unwilling to address problems anymore, and they concentrate on symptoms. It's as if everything they see is somehow the result of ideopathic causes, and there's no effort to eliminate base causes. As a group, doctors appear to have had their curiosity as to *why* things happen surgically removed some time after their third year of medical school, and have substituted *how can I make the symptoms go away?*. IMO, this is a poor substitute.
When was the last time you saw a doctor test for non-ideopathic causes for a patient with high blood pressure, rather than simply writing script for Atenol, Toporol, Minoxodil, or some other Beta-blocker, ACE Inhibitor, Calcium Channel blocker flavor-of-the-month being pushed by the drug company patent medicine sample-fairies?
I guess maybe "90% ideopathic" is the cut off point for a disease to be treated as if it were "100% ideopathic", and damn the consequences for people with kidney problems or other identifiable and *curable* root causes.
It's really annoying when a profession that claims to be based on scientific principles ignores scientific principles; a patient taken off corn products is not going to suddenly suffer a grand mal seizure as she's walking into the subway, and fall over dead, with the coronor's report ruling cause of death as "corn deficiency". There are at least 7,600 years of recorded corn-free human history, prior to the discovery of the New World. For a doctor to fear recommending avoiding corn products is ridiculous.
If it's really about "above average" bandwidth users costing them money, then why aren't they falling all over themselves to refund money to "below average" bandwidth users, who are saving them money?
The infrastructure is there, and I can guarantee you that they are not upgrading it all the time. It's all about how much money they can suck out of how many wallets, per month.
Sharing your connection is one less "on *grunt* going *grunt* customer *grunt* relationship!".
I talked to an allergist about food allergies vs. patient weight.
I and five other people I know are off corn now.
We have all lost weight -- at least 15 pounds *each*; I still eat pizza, Hagan Daas Ice cream (Chocolate Chocolate Chip), etc., and fried food that was fried in anything but corn oil. I eat Safeway brand sugar cream wafer cookies (sugar, not corn syrup). I eat *tons* of bread (I am a bread fanatic).
I definitely like the article's claims with regard to high glycemic indices, but, the fact is I haven't cut out anything but the corn. All of my other high glycemic index food consumption has remained the same, and I've found substitutes for every product that I used to eat that contained corn (most of them claim a *higher* number of total calories per serving, actually).
You could argue coincidence, like the aluminum industry argues with regard to alzheimers disease and aluminum cooking pots and soft drink cans. On the other hand, you have to wonder how you could get little plaques in your brain containing aluminum, if you didn't consume any aluminum ("How can my people build bricks without straw?").
After all this, when I read the labels on the "Weight Watchers" and "Lean Cuisine" meals and similar "dietetic" foods, I just *have to* laugh, since they all contain corn products.
On a final note, I'll notice that for all these supposed "cures" for obesity, you always end up having to buy something from someone; either something with a high marginal cost that they sell one of (e.g. a book), or an ongoing treatment (e.g. "SlimFast" shakes).
I guess if they actually *cured* the condition, then they would lose their customers. It's a hell of a lot more profitable to sell *treatments* than it is to sell *cures*. They have the same incentive to cure obesity that the pharmaceutical industry has to cure AIDS, diabetes, high blood pressure, yeast infections, and the common cold: none.
Slashdot Mirror
Limiting total outbound packets is not necessarily going to help him. Consider:
o If the outbound packets are limited at random, rather than preferrentially limiting non-"ACK only" packets over ACK packets, then the outbound ACKs are going to be dropped, resulting in the same situation.
o Even if there is preferential limiting -- which I think I've demonstrated is only possible with virtual circuit protocols -- the problem can still occur.
At issue is the fact that you can not control the input buffer depth on the outbound rate limiter, unless it's a bridge, not a router. What's going to control it is whether or not the data outbound has been ACK'ed or not, and the normal interactions with your machine on the other side of the limiter's retransmit timers.
The problem is all about pool retention time. The amount of time that a packet sits in RAM on the rate limiter is going to be your effective introduced latency. The only way you can know what this is going to be is empirically, because there's no way for you to know the buffer size.
Actually, with all the people wanting to play with window size ("It *has* to work because I *want* it to work!" [stamps feet]), they would be much better off setting the transmit window to 1 packet. This would self-pace transmissions at the transmit rate. Of course, you would still be screwed if you had a lot of transmit connections open behind the rate limiter (e.g. you were running a web or game server, or you were running a peer-to-peer application).
Actually, optimizing incoming bandwidth at the expense of outgoing bandwidth, even if you could do it successfully on the client side of things, rather than at the rate limiting server, would be the absolute worst possible thing you could do, if you wanted to run peer-to-peer, if both sides of peers were doing the same thing. 8-).
If you want to look at it another way: you are actually talking about how to go about reserving however much up channel bandwidth is needed to support the down channel.
-- Terry
We jokingly discussed an Evil Plan where I worked when CodeRed first came out.
One thing we discussed doing was getting a copy, disassembling it, and building a version that would install FreeBSD with Apache with Front Page Extensions and the Active Server Pages module over top of the Windows installation, with all of the web site content left more or less intact.
We figured that it would be pretty cool if we could make it so that people would not notice that their server had been "competitively upgraded" until the next scheduled reboot/update.
We thought that it would be even more likely to go a long time if we captured the console screen of the running server, and used it as the boot "splash screen" for the replacement OS...
Of course, as I said, doing this would be Evil, so we only discussed the possibility.
-- Terry
His upstream is 96Kbit, and his downstream is 1.5Mbit.
In round numbers, this means his upstream is slightly less than 1/16th his downstream.
Say his MTU is 1500 bytes. Let's say his ACK packets are 64 bytes (we were generous on the 1/16th, so 64 instead of 60 is not that far off).
That basically means that, assuming no packets are lost, and that all ACK packets are precisely equally spaced, then 2/3rds of his upstream bandwidth needs to be dedicated to ACK traffic for the downstream bandwidth.
Why do we have to assume equal spacing? Because he can't control anything other than his send order, because he can't control the rate limiting machine's discard.
Is it possible to do this with a traffic shaper on the client machine? Yes, with a very sophisticated traffic shaper, which maintains stateful information (e.g. like a PIX firewall maintains per connection state information). It's possible because now we know the numbers for his connection -- we don't know the general numbers, though, for *any* assymetric link, so this isn't something you could make into an installable package, without the user having to resort to math/tuning tools.
Even so... this only works if the traffic is connection oriented. So far, people have asked -- and he hasn't responded -- about the kind of traffic he's running.
If the download traffic is RTSP or UDP or any protocol based on packets other than TCP packets, then there's no way to make preference choices on packets sent out. And then he's back in exactly the same boat he was in before.
So it's not possible to say "install this", and it's not possible to say "install this, and set these tuning values based on your relative upstream and downstream speeds", unless you really limit the problem you are trying to solve.
Doing that will probably not be satisfying, since the primary reason for a (mostly) unidirectional pipe is to push content to users, and most content streaming protocols are not based on TCP or other things which can be stateful.
-- Terry
The problem is outbound pool retention time.
Making the receive window larger is going to delay the amount of time before an ACK is mandatory, not reduce the contention once an ACK becomes necessary.
In other words, if I'm filling a bucket a 10 gallons a minute and emptying it at 1 gallong a minute, no matter how big you make the bucket, it's going to overflow eventually.
In other words, your outbound ACKs are still going to have to stand in line behind your outbound data at the outbound rate limiting box.
I will now point out that every outbound buffer between you and the rate limiter will also be full, and need to drain before your ACKs get through...
-- Terry
The reason your downstream rate gets limited by your upstream rate limit is because of your inability to send acknowledgements upstream for the downstream packets you are receiving because of the congestion on the upstream link.
Once the advertised receive window is filled with packets, the remote side is not going to send any more data until it gets an ack from your computer.
At the point that the rate is being limited, the way to fix this is to give preference to ACK packets -- i.e. packets without payload.
The problem is that this has to be done at the point the rate is being limited, which is at your providers router, not at your router, and not at your Windows machine.
Installing the Microsoft packet scheduler, or some UNIX box with a real netowrking stack that you can exercise fine control over packet priority, as some people have suggested, isn't really going to fix your problem, except by maybe 10% (the exact amount depends on your average outbound payload size relative to an "empty" ACK-only packet).
This is because the problem is the queued data in the transmit buffer in the rate limiting device not containing your ACK's for inbound data.
Really, the TCP/IP protocol wasn't built for asymmetric reates, without equally asymmetric data transfers.
Effectively, you need to be able to control the transmission of data packets from your end based on knowledge of how full the input buffor on the outbound leg for the rate limiting device gets, so that you can throttle your data payload packets accordingly, to keep that buffer as empty as possible.
The only way you can really do this is to put code in your stack to monitor the advertised window from the other side, and the locally classify outbound packets as to whether or not they contain data payload, or are merely acks. You basically have to avoid filling the outbound queue on the rate limiter above 50%.
In an ideal world, the machine doing the rate limiting would do this for you. Some rate limiting machines for asynchronous connection do this, and it's not a problem (you can see the posts from the people who are rate limited, and don't understand your problem). But those machines are more expensive, and it's just as well for the provider if you feel pain as feedback for uploading, since it serves their purpose in providing you asymmetric service in the first place.
The problem's a lot easier when you are trying to avoid filling the inbound receive buffer for a router with a speed differential on one side (e.g. the inbound receive buffer on a router connected to a dialup modem bank, with a customer on a modem wanting to do QoS based on protocol type, so their SSH didn't lock up when an FTP or large HTTP transfer started up). *That's* where things like "AltQ" and the Microsoft packet scheduling engine become useful... not here.
-- Terry
If you had not made this posting, I would have had to have made it.
They also don't want you using only the second half of a round trip ticket, or splitting a round trip ticket in order to get two one-way tickets for different riders out of it.
It's simple economics.
Now I *do* object to anyone having access to the records after the tickets have expired, if the plane didn't end up going down, since I don't like having my movements tracked by people who have no positive reason to track my movements (them making money because they can market to me might be positive for them -- I mean positive for *me*).
To turn this around... suppose it was a telemarketing company that wanted this information, rather than the government, so that they could be sure to call you when you at a specific time to sell you, say, travellers insurance or air-sickness or jet lag products... would you want them to have it?
-- Terry
I'm actually surprised that there hasn't been more telesurgery experiments; I find the whole idea fascinating, and that the process can be made to work at all really amazing and impressive.
But I think that the referenced article had a better take on it than this posting, whose "additional technical details" are, at best, unintentionally misleading.
The implication of "video over IP" is that you did this over the public IP network, which in fact is not the case.
The fact that you did this over what was effectively a dedicated point-to-point link means that the use of the IP transport was irrelevant (worse; it added unnecessary overhead, subtracting from the total data rate).
I understand not wanting to risk someone's knee on a link succeptible to a DOS (or only succeptible as a result of a substantial investment of effort on the part of the attacker). But your posting implies that this is something which took place over the public Internet, or *could* take place over the public Internet, when it's not.
-- Terry
That may be; but as soon as you *fill in* that framework at its attach points, you are back to facing the IP issue, aren't you?
The existance of the framework encourages the use of technology that fills the hole... just as a pothole in the road wants to be filled.
It seems to me that we will end up with it as an "optional implementation item", which means "implemented in Windows and not elsewhere because of the patents", unless SGI steps up and answers the $64,000 question: is their grant of license still valid now that they've sold the patents to Microsoft... or isn't it?
-- Terry
If you have looked at the "bucket brigade" graphic in the article, then you will know what I'm talking about...
Is it just me, or does that picture seem to imply that you get a lower "buckets per unit time" throughput from asynchronous processing?
I know that this is not the claim of the article... but it's still my gut reaction to the graphic.
"Gandy Dancers" (railroad manual track laying and repair teams) were so-called because the first part of their name was the Chicago tool maker that made track laying tools, and the second part of their name came from the fact that they worked to a rhythm.
A better analogy would be a work-content based multipath route, where the amount of time is based on the type of work to be performed.
This would have implied (correctly) that, in an synchronous system, you should be able to "make up for" slow elements by doubling them up: i.e., when you are faced with a slow section of pipe, rather than bottle-necking, make it wider, instead.
Or to use their analogy, if you have a slow guy, then get another slow guy to stand next to him so he doesn't bottlneck the brigade.
Probably a more apt analogy would be nice: it's hard to show throughput increases, except by number of buckets in the hands of the people.
-- Terry
I've already read all of William Gibson's writing that has ever been published. 8-).
-- Terry
Sorry; didn't read that discussion.
-- Terry
Since SGI got the GPL religion, for them to have agreed to the inclusion of the technology in the specification implies that they think the patent is not enforcible, and that their license is still valid.
It would be nice if SGI would state a position on this and clear up the fud, wouldn't it?
-- Terry
Oh!
Most Excellent subtle reference to William Gibson's "Idoru"!
Extra points awarded for the Australians doing the installing...
-- Terry
It's not just domain name based.
From my reading of the patent, it's not just the domain name in use; they also parse out the whois information for the owner information from the relevent whois information, and they support the concept of zoning by delegation (e.g. "freebsd.org" is in the U.S., but "uk.FreeBSD.org" is in the U.K., etc.).
Basically, they have an entire process based on the information that was generally available at the time the patent was filed, and the information that was expected to be available, based on geographic information draft RFC's published around the time, and the ratified-but-seldom-implemented RFCs for inclusion of missle coordinates in your DNS, in case you wanted to inte an ICBM to land in your swimming pool.
So it's technically patentable as a process patent, though I would certainly argue that it was obvious to a skilled practitioner in the arts.
-- Terry
The 20 year penalty is for "an attempt to commit bodily harm". The Life sentence is for "an attempt to cause a death".
Nevertheless, the bill does not *merely* do what the news reports claim, and in that, it is alarming.
The interesting part is the definition of "protected system", which is taken from "18 U.S.C. 1030" (search for it in your favorite search engine), and the modifications made to it by the bill.
It does not involve only government computers, as the text of the bill itself implies. It also involves "any restricted data, as defined in paragraph y. of section 11 of the Atomic Energy Act of 1954" -- most of which is public information these days, and available from many web sites containing information on basic high energy physics (apparently, congress-critters believe that if they can't figure something out without a crib sheet, neither can your average university-trained physicist or engineer, which is why they think they could successfully legislate against light switches).
Further, it includes records from "information contained in a financial record of a financial institution, or of a card issuer as defined in section 1602(n) of title 15, or contained in a file of a consumer reporting agency on a consumer", per "15 U.S.C. 1681".
This can be loosely interpreted to mean "any system which stores credit card numbers".
--
The real question that we should be asking is whether this is a Writ Of Mandamus... it seems so, since there do not appear to be practical restraints on use of information gathered under the terms of this bill (i.e. "We thought he was a terrorist; as it turns out, our justification was bogus, but we still get to use the evidence gathered to inform against him for that Metallica MP3 he downloaded").
From my reading, it's unconstitutional, under the 4th Ammendment.
Of course, since it passed by such an incredible amount in the House, there no reason to believe that it will not quickly become law: it clearly has wide bipartisan support, and will clearly get the White House's approval (see below).
What that effectively means is that it will remain law, until it is challenged by a perpetrator on the basis of constitutionality. Basically, the law will have to be violated to be tested, at considerable risk to the violators, given the tendency recently for the Federal Government to use the Bill Of Rights in place of toilet paper.
I guess the only thing we don't know is whether this is an overreaction to last September, or if its an overreaction to the lack of consumer confidence in the market, where they think if they can point to themselves "*doing* something about some real market risk", we will forget all about "the man behind the curtain", and not insist on substantive tort reform.
If you read the House Report version of the bill, you'd think the latter (e.g. reaction to "Enron")... almost all of the listed congressmen are from -- *surprise!* -- Texas.
The Constitutional basis for incorporation itself is to serve the public and shareholders interests (read the relevent USC on incorporation, if you don't believe me); this seems to have been reduced to nothing more than "fiduciary responsibility to protect shareholder value, and screw public interst". More fundamental reform is required: this is not about people not acting like a--holes for fear of the penalty, it's about people not acting like a--holes because they *aren't* a--holes.
-- Terry
This appears to be a fairly recent developement.
The examples at:
http://www.imc.org/ietf-calendar/cap-examples/
Definitely contain the IMAP4 command tags, and uses the "." as a list output terminator. The draft specification which was located at:
http://www.imc.org/ids.html#calsch
8 months ago specifically references differences between IMAP4 and ICAP serversm and how a server can be both. I still have a copy of it in the directory with my Cyrus patches on my other machine.
I intentionally went out of my way to implement an ICAP server in the context the the Cyrus IMAP4 server, thinking that there would be clients, other than the PHP4 client I implemented. I was going to release the Cyrus patches at some point, once I had cleaned them up.
I guess it's a good idea to never implement anything until the standards have settled down, to keep them from changing out from under you. 8-(. Unfortunately, vendors love to change standards out from under you, so that their implementation complies and yours doesn't, and so that you can't beat them to market with a product (beats competing on quality of implementation).
IMO, the correct way to implement this is via an LTAP-type protocol. My personal bias is for adding the transaction and notification features to LDAP, since the Lucent patent is based on the use of a proxy.
I realize that the draft specifically references "BEEP" (not legal in RFC-land, that...;^)), but I still maintain that it requires a client/server relationship to correctly implement calendaring.
This basically means that there are two options: the first is that the BEEP protocol will be used in a client/server mode, rather than the peer-to-peer mode that the BEEP designers intended, OR people are simply going to be unable to implement usable calendaring applications with the newer iCAL, as specified by the new draft.
I still maintain that a peer-to-peer calendaring application is not viable, since it fails to have the minimal features present in, say, OnTrack's "Meeting Maker" (i.e. the ability to schedule a conference room, since peer-to-peer networks are designed -- and intended -- to support paroxial participation in the network).
Or in plain English: there is a lot of hype about peer-to-peer, and not a lot of delivery of the goods.
FWIW: I worked at Artisoft when the Artisoft LANtastic product was *the* preeminent peer-to-peer networking software out there, and was one of just 4 engineers involved in the UNIX (initially, Linux) port, so I'm not talking from ignorance here.
-- Terry
The ICAP protocol is based on the IMAP4 protocol. As such, it has the assumption of a client/server relationship. It also has state assumptions that are not necessarily valid over time, and BEEP appears to not support the concept of nested transactions (the IMAP4 and ICAP protocols are biased toward set encapsulation -- that's why there are all the irritating nested parenthesis -- which lends a strong bias toward stack based interpretation of requests: transactions).
Since BEEP is intended as a peer-to-peer connection oriented protocol, it's not ever going to really be practical as an ICAP transport.
The main issue that a server deals with is a shared resource that belongs to the system, rather than participates as a peer. This becomes an issue when you want to schedule use of a confernece room or interview office, where these resources, unlike human beings, don't have a machine which participates in the process as a peer. It's not possible to totally distribute such a system, since the peers are not the only mutually contended resources (if "Bob" drops out, then you can have a request outstanding, but not accepted; no matter who else attends your meeting, though, the conference room *must* "attend").
As far as a peer-to-peer workgroup calendaring service, it *may* be possible to use MIME encapsulated calendar update notifications, similar to the way Microsoft Outlook can be a transport for Microsoft Schedule information (the message type involved lack standardization).
However, such an approach would have the drawback of "netsplits" (in the IRC sense) redulting in shared resources ending up with conflicting scheduling (just like "operator" status in an IRC network following recovery from a "netsplit").
In general, calendaring is a much more complicated problem than people tend to give it credit for being.
Right now, the best protocol bet for Calendaring is LDAPv3 with the "persistant search" or a similar notification mechanism (e.g. LTAP), except not as a proxy, and mandatorily integrated into the LDAP server itself (due to replication requirements).
One place BEEP *might* be useful is data replication between peered servers. The primary reason it could be useful here is that the entity relationship is *peer*, not *client/server*.
-- Terry
-- Terry
[ Dammit, I hate people who use cookies instead of hidden fields for forms ]
"I think you're being terribly naive about this, particularly the It's now nearly impossible for a commercially paid developer to contribute usefully to FreeBSD comment. Development work on FreeBSD succeeds on both fronts."
I have built or contributed to 5 embedded systems products based on FreeBSD. If you count licensing the source code to third parties, that number goes up to 12. This list includes IBM, Ricoh, Deutch Telekom, Ricoh, Seagate, ClickArray, and NTT, among other lessers.
There has been no case where any of these projects have involved use of FreeBSD-current. It just does not happen: the intent of the commercial is to work on the product itself, not on the platform on which the product is intended to run. Toward that end, every one of these projects has used a stabilized snapshot of FreeBSD, usually a release, and, on only two occasions, a -security (release plus security bug fixes) or -stable (release plus any bug fixes) branch. Under no circumstances has the employer *paid* me to work on -current on their time.
There are notable exceptions to this practice, where there have been specific DARPA grants, or Yahoo has a number of highly placed people who get to pick what they work on; these opportunities are few and far between.
"Plainly, it is concievable that were a commercial team to submit changes to -CURRENT, they would be timed for integration into -STABLE in the same manner as current changes are. And try not to make a mistake, a *lot* of things are folded back from -CURRENT on a regular basis. They may have a lengthy test period, but hey, shouldn't every new feature?"
Your argument is that FreeBSD -current and FreeBSD -stable bear a strong relationship to each other, besides each having the prefix "FreeBSD", and that integration into -current means that testing will be done, and that after testing, integration into -stable will happen.
I disagree strongly. The two source bases run different tool chains, and they are significantly different, under the hood, as well. It is nearly impossible to write kernel code that operates identically, without substantial modification, on both -stable and -current. The differences in process vs. thread context, and locking *alone* mean that there is not one subsystem in the kernel that has not be touched. This ignores the semantics and API changes, etc., on top of that.
Despite back-porting, there is nearly two years difference between -stable and -current. I have a system that I updated to -current in October of 2000. It claims to be 5.0. FreeBSD has not made a code cut off the HEAD branch in that entire time -- or FreeBSD 5.0 would have been its name.
It would be a serious mistake for Linux to follow FreeBSD down this path. Linux should continue to make release code cuts off their HEAD branch, stabilize, *and then deprecating* the releases.
FreeBSD has failed to deprecate its branches, following releases. This means that if a commercial developer wants to contribute code for inclusion in future version of FreeBSD in order to avoid local maintenance (FreeBSD, unlike Linux, does not *require* such contributions, it relies on this and other emergent properties), they must first take their code from where it's running, and port it to an entirely *alien* environment. Then they must wait for approval, and then back-port it, since no one is going to do the work for them, to the minor version after the one that they stabilized on for their product.
"It keeps the stable kernels stable, and it folds in new changes in an orderly and well tested fashion."
`Orderly' and `tested' are one thing. Two *years* of API and interface evolution are something else entirely.
The first time Linux cuts a distribution that isn't a pure maintenance point release of a minor number (e.g. NOT 2.5.1 off 2.5, and NO 2.6 off of 2.5 if a 3.0 is in the works), it will have effectively forked itself.
-- Terry
[ ...Putting on my "politically incorrect" hat... ]
It's a common Open Source Software problem: there is the last release, and there is the developement branch.
Developers would all prefer that you use the developement branch, report bugs against *that*, provide patches for the bugs against *that*, do all new work in the context of *that*.
But it's not how things work, outside of an Ivory Tower.
In the real world, people who are using the system are using it as a platform to do real work *unrelated to developement of the system itself*.
I know! Unbelieveable! Heretics! Sacreligios!
FreeBSD has this disease, and has it bad. It very seldom accepts patches against it's last release, even in the developement branch of the last release, if those patches attempt to solve problems that make the submitted work look suspiciously like "developement". The cut-off appears to be "it fixes it in -stable, but would be hard to port to -current; do it in -current, as your price of admission, and back-port it instead, even if you end up with identical code".
The only real answer is to keep the releases fairly close together -- and *end-of-life* the previous release *as soon as posible*.
The FreeBSD 4.x series has lived on well past FreeBSD 4.4 -- supposedly the last release on the 4.x line before 5.0. FreeBSD 4.6 is out, and 4.7 is in the planning stages.
It's now nearly impossible for a commercially paid developer to contribute usefully to FreeBSD, since nearly all commercially paid developers are running something based on -stable. FreeBS -current -- the 5.x developement work -- is *nearly two years* off the branch point from the 4.x -stable from which it is derived.
Linux *MUST* strive to keep the differences between "this release" and "the next release" *as small as possible*. They *MUST* not "back-port" new features from their -current branch to their -stable branch, simply because their -current branch is -*UN*stable.
Delaying the 2.6 release until the 2.7 release so that you can "stabilize" and "jam as many 2.7 features into 2.6 as possible" is a mistake.
Make the cut-off on 2.6. And then leave it alone. People who are driven by features will have to either run the developement version of 2.7, or they will simply have to wait.
Bowing to the people who want to "have their cake and eat it, too" is the biggest mistake any Open Source Software project can make.
Don't drag out 2.7, afterward, either... and that's inevitable, if everything that makes 2.7 desirable is pushed back into 2.6. Learn from the mistakes of others.
-- Terry
"From a scientific perspective, though, this isn't a very satisfying situation. Without some kind of theory about why corn is worse than all these other foods, all you have is some anecdotal evidence."
No, it's not satisfying. Which is why I suggested that people contact an allergist to obtain better statistical information than I was personally able to offer. I don't claim to have done a scientific study. If you read the article, youll see that NIH doesn't tend to fund scientific studies that challenge the status quo. I rather suspect that ADM would dislike any study that implicated corn, as well.
"Or perhaps corn was a particularly large proportion of your diet."
That's rather one of the points of my posting; corn is a particularly large proportion of the diet of *every* American.
"It doesn't sound as though you've done any serious control tests at all, so you really don't have a basis for drawing a conclusion."
You're right. I'm not personally a nationally recognized medical research facility. 8-). I will point out the "?" on the end of my subject line, in my defense.
"Your anecdotes about corn don't really qualify, unfortunately - it just puts you right there alongside the people who claim that it's only the fat, or only the sugar, or... I'd be willing to bet any amount of money that you're all wrong."
Read back over this thread. You practically had to *beat* anecdotes out of me. It took you three posts to get there. I was very reluctant to provide anecdotes initially, knowing the probability was high that you would react as you have reacted, and dismiss the entire idea because I have given anecdotal evidence at any point during the discussion.
"It's a complex business, and humans don't seem to be good at intuitively analyzing situations that involve multiple interacting variables."
You are hanging out with the wrong humans; you need to hang out with engineers.
Eventually we *will* solve this problem, with brute force if we can't find any other way, and we'll simply have billions of small robots *undo* any result we find undesirable, if it takes having them carry the fat out of the fat cells on their backs, a molecule at a time, and carry nutrients in, one molecule at a time, if all we choose to eat is Cheetos(tm) cheese flavored corn puffs, or whatever.
---
It seems to be a common problem with doctors that they have elevated the "Above all else, do no harm" provision of the Hippocratic Oath to the point it's "Above all else, do nothing, unless you know for a provable fact that it will do good, rather than merely being benign". There is no longer such a thing as "practice of medicine".
It seems to me that doctors are unwilling to address problems anymore, and they concentrate on symptoms. It's as if everything they see is somehow the result of ideopathic causes, and there's no effort to eliminate base causes. As a group, doctors appear to have had their curiosity as to *why* things happen surgically removed some time after their third year of medical school, and have substituted *how can I make the symptoms go away?*. IMO, this is a poor substitute.
When was the last time you saw a doctor test for non-ideopathic causes for a patient with high blood pressure, rather than simply writing script for Atenol, Toporol, Minoxodil, or some other Beta-blocker, ACE Inhibitor, Calcium Channel blocker flavor-of-the-month being pushed by the drug company patent medicine sample-fairies?
I guess maybe "90% ideopathic" is the cut off point for a disease to be treated as if it were "100% ideopathic", and damn the consequences for people with kidney problems or other identifiable and *curable* root causes.
It's really annoying when a profession that claims to be based on scientific principles ignores scientific principles; a patient taken off corn products is not going to suddenly suffer a grand mal seizure as she's walking into the subway, and fall over dead, with the coronor's report ruling cause of death as "corn deficiency". There are at least 7,600 years of recorded corn-free human history, prior to the discovery of the New World. For a doctor to fear recommending avoiding corn products is ridiculous.
-- Terry
Really!
Intellectual property law in this country has gotten out of hand!
The IRS is a private corporation, 60% owned by British interests!
Taxation *with* representation sucks as bad as taxation *without* representation!
(Don't blame me, I voted for Khodos Perot!)
The UK seems to have avoided the patenting of software, and human genes... and it was your astute guidance that did it!
Oh, King George, Where Are You now!!!
Come Back To US, George!!!(*)
-- Terry
(*) Offer not valid in New Jersey or the District of Columbia; some restriction may apply. See your dealer for details.
MS can pay me *one hell of a lot of money*, and then I would probably be willing to answer this question.
I'll be damned if I'm going to identify all of their competitor's weak spots for them for free.
Nice try, though...
-- Terry
If it's really about "above average" bandwidth users costing them money, then why aren't they falling all over themselves to refund money to "below average" bandwidth users, who are saving them money?
The infrastructure is there, and I can guarantee you that they are not upgrading it all the time. It's all about how much money they can suck out of how many wallets, per month.
Sharing your connection is one less "on *grunt* going *grunt* customer *grunt* relationship!".
-- Terry
I talked to an allergist about food allergies vs. patient weight.
I and five other people I know are off corn now.
We have all lost weight -- at least 15 pounds *each*; I still eat pizza, Hagan Daas Ice cream (Chocolate Chocolate Chip), etc., and fried food that was fried in anything but corn oil. I eat Safeway brand sugar cream wafer cookies (sugar, not corn syrup). I eat *tons* of bread (I am a bread fanatic).
I definitely like the article's claims with regard to high glycemic indices, but, the fact is I haven't cut out anything but the corn. All of my other high glycemic index food consumption has remained the same, and I've found substitutes for every product that I used to eat that contained corn (most of them claim a *higher* number of total calories per serving, actually).
You could argue coincidence, like the aluminum industry argues with regard to alzheimers disease and aluminum cooking pots and soft drink cans. On the other hand, you have to wonder how you could get little plaques in your brain containing aluminum, if you didn't consume any aluminum ("How can my people build bricks without straw?").
After all this, when I read the labels on the "Weight Watchers" and "Lean Cuisine" meals and similar "dietetic" foods, I just *have to* laugh, since they all contain corn products.
On a final note, I'll notice that for all these supposed "cures" for obesity, you always end up having to buy something from someone; either something with a high marginal cost that they sell one of (e.g. a book), or an ongoing treatment (e.g. "SlimFast" shakes).
I guess if they actually *cured* the condition, then they would lose their customers. It's a hell of a lot more profitable to sell *treatments* than it is to sell *cures*. They have the same incentive to cure obesity that the pharmaceutical industry has to cure AIDS, diabetes, high blood pressure, yeast infections, and the common cold: none.
-- Terry