The car runs on rotting organic waste AND gasoline. I'd imagine that when you're accelerating to 60mph in 6 seconds it's running primarily off of the gasoline.
Another alternative is to use supercritical water. (ie, water at high pressures and temperatures). Apparently the chemistry of water changes dramatically as the temperature and pressure are increased, and it becomes pretty non-polar, and consequently can act as a solvent for all sorts of messy organics.
At least, that's how I understand it -- it isn't my research or even my field so I don't really understand any of the details.
Maybe I'm missing something, but why does this have to be a single system? Generally speaking, servers aren't designed to have pretty user interfaces.
If I were in charge of this, I'd get a Supermicro 6010H (about $5000 including hotswap 10K RPM SCSI drives) and a $5000 laptop (of whatever variety you prefer). And pocket^H^H^H^H^H^Hgive back the remaining $10000.
When this was posted, the bandwidth meter read 34.4 Mbps. Five minutes later it was at 40 Mbps. Five minutes after that it was at 50 Mbps. Now it is at 71.39 Mbps.
Can't you guys wait a while and download it from the mirrors?
There are several problems which you have to worry about here. High among them are latency and bandwidth.
Most scientific computing code is written in a manner which implicitly assumes low latency. Linpack, for example, needs interprocessor latency on the order of a few microseconds; most other applications require similarly low latencies. Unless you can develop new algorithms which are latency-tolerant and rewrite all the necessary code to implement them, the speed of light will kill you.
As for bandwidth, "huge data crunching" obviously requires moving large amounts of data around. Can your network handle it? Can your network handle it sufficiently cheaply to be practical?
Another issue, of course, is finding interested customers. The idea of having data spread around to any number of unknown people isn't something many companies look forward to. Add to that the question of how rapidly they need results -- using a "keep re-assigning work until it all gets done" scheduler on processors which only complete 80% of the work sent out you'll find that it takes a long time to get jobs finished -- and it will take quite a bit of marketing to find paying customers.
If a router doesn't understand certain option bits, it's supposed to IGNORE them.
I don't know about these specific routers (have we been told which they are?) but the problem might be that they do understand those bits -- in a different meaning. The TOS bits have been redefined a number of times, and the bits used by ECN have been used for other things in the past.
Putting aside for now the arguments about supporting experimental protocols and the use of one-used-and-now-reserved bits, there is a very simple issue here regarding firewall design.
Secure firewalls are designed to block traffic by default.
In other words, if the firewall doesn't understand the packets being sent through it, it will drop them. There's nothing wrong with this behaviour; in fact, if you try to build a "default-accept" firewall by blocking off packets which you know to be undesireable, you'll inevitably run into problems. However, anyone who has tried to get streaming media, or play warcraft, or use any other new protocols through an old firewall will be able to say that this policy can be a nuisance.
Which, of course, is one reason why there is an internet *standards track* giving people time to adapt to new protocols.
The fact ECN is written up as a request for comments document (RFC) means it *is* well on its way to becoming an Internet standard. Even the process itself of becoming an Internet standard is written up as an RFC. Look at the main web page at www.ietf.org and click on the link marked "The Internet Standards Process." Look at what is there! RFC 2026!
In case people are too lazy to look up RFC 2026 themselves, here's the relevant section:
4.2 Non-Standards Track Maturity Levels
Not every specification is on the standards track. A specification
may not be intended to be an Internet Standard, or it may be intended
for eventual standardization but not yet ready to enter the standards
track. A specification may have been superseded by a more recent
Internet Standard, or have otherwise fallen into disuse or disfavor.
Specifications that are not on the standards track are labeled with
one of three "off-track" maturity levels: "Experimental",
"Informational", or "Historic". The documents bearing these labels
are not Internet Standards in any sense.
4.2.1 Experimental
The "Experimental" designation typically denotes a specification that
is part of some research or development effort. Such a specification
is published for the general information of the Internet technical
community and as an archival record of the work, subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process (see below). An
Experimental specification may be the output of an organized Internet
research effort (e.g., a Research Group of the IRTF), an IETF Working
Group, or it may be an individual contribution.
And from the top of RFC 2481:
A Proposal to add Explicit Congestion Notification (ECN) to IP
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
ECN is mature and at the Minn. IETF meeting it was voted to be added to the host requirement standard.
BZZZZZT. Nope, try again. There is now a [B]draft proposed standard[/B] for ECN. That's it. It isn't a standard yet, and won't be for quite some time yet.
Only broken routers who DO NOT OBEY the RFCs fail to pass ECN.
Right... only routers which do not obey an EXPERIMENTAL RFC run into problems. Guess what? You don't have to obey experimental RFCs. That's why they're *experimental*, not *standards*.
it's clear that blocking ECN is an abnormal activity that violates RFC's as well as common sense.
No, it isn't. ECN is an experimental protocol, and there is no requirement for everybody to implement every experimental protocol invented.
In fact, there's a very strong argument to be made that linux is being non-standards compliant, since the first rule of experimental protocols is "don't send packets to people who haven't asked for them".
Get the story right guys. This isn't a "linux is up to date while other people aren't" story -- this is a "linux is using a protocol marked as EXPERIMENTAL" story. EXPERIMENTAL protocols are protocols which are not only not internet standards, but are not even standard track.
If using an EXPERIMENTAL protocol breaks stuff, don't use it. You certainly shouldn't expect people to conform to your own non-standard behaviour.
maybe someone will hack the control signals and fly it to their home?
Do you really want a plane loaded with 15,000 pounds of fuel crashing into your home?
Re:What didn't they do that promised in their...
on
Eazel On The Ropes
·
· Score: 2
They probably *did* do what they promised in their funding proposals. Given that they started up in August 1999, the single word "linux" was probably enough to bring them their $11 million of venture capital.
At the last month's IETF in Minneapolis there was a slide during the plenary (which hasn't seem to have made it to the web site yet) that showed the average speed of route convergance. It was on the order of 90% propagation of route changes within 1-2 minutes. That's pretty fuckin fast.
Two points to respond to here. First, 90% of route changes propagation occurs within 1-2 minutes; that doesn't necessarily help much if the remaining 10% take two hours. Yes, I know they don't, but in any case an average statistic would be more useful than a 90th percentile statistic.
Second, 1-2 minutes is fast when it comes to switching between working routes. Internet routing works pretty well when it comes to the problem of determining *which route is faster*. However, when it comes to routing around faults, 1-2 minutes is a pretty long time: With ISPs advertising "99.9999% uptime" (ie, down for at most a few seconds each month) downtime of 1-2 minutes is a Bad Thing.
What I'd like to see is some mechanism by which updates could be marked as "urgent" if they relate to fault-recovery -- that way, the few updates which are necessary in order for packets to be routed away from downed links could be propagated within a few seconds, while routine "link x is faster/slower than link y" updates could be handled more slowly.
I think much of the blame lies with the routing protocols currently in use on the internet. Due to concern over maximizing performance -- and minimizing overhead -- most routing systems are set to react quite slowly to changing conditions. This helps eliminate route flapping, but has the unfortunate consequence of taking several minutes to route around a downed router or link.
We can hope that someday we'll have better protocols to deal with this -- don't ask me, I'm no expert on this stuff -- but until the gurus come up with one I guess we just have to suffer.
Regardless of the poor condition of the advertising market, I can't believe that free email is about to go extinct. The cost of providing email access is so minimal -- and going down every day -- that even $0.01 CPM advertising would probably cover it.
Come on, admit it, we all rely upon security through obscurity. I mean, how many of you (security challenges notwithstanding) make your root passwords available on the 'net for anyone to see?
Slashdot Mirror
The car runs on rotting organic waste AND gasoline. I'd imagine that when you're accelerating to 60mph in 6 seconds it's running primarily off of the gasoline.
Another alternative is to use supercritical water. (ie, water at high pressures and temperatures). Apparently the chemistry of water changes dramatically as the temperature and pressure are increased, and it becomes pretty non-polar, and consequently can act as a solvent for all sorts of messy organics.
At least, that's how I understand it -- it isn't my research or even my field so I don't really understand any of the details.
...the guy who wrote this who seems to think that RFC == standard.
;)
Oh, and of course the crack-smoking moderators who consider bogosity to be insightful.
Maybe I'm missing something, but why does this have to be a single system? Generally speaking, servers aren't designed to have pretty user interfaces.
If I were in charge of this, I'd get a Supermicro 6010H (about $5000 including hotswap 10K RPM SCSI drives) and a $5000 laptop (of whatever variety you prefer). And pocket^H^H^H^H^H^Hgive back the remaining $10000.
Why exactly does using 71.39% cause a problem?
As usage tends towards 100%, speed tends towards zero and packet retransmission increases.
When this was posted, the bandwidth meter read 34.4 Mbps. Five minutes later it was at 40 Mbps. Five minutes after that it was at 50 Mbps. Now it is at 71.39 Mbps.
Can't you guys wait a while and download it from the mirrors?
There are several problems which you have to worry about here. High among them are latency and bandwidth.
Most scientific computing code is written in a manner which implicitly assumes low latency. Linpack, for example, needs interprocessor latency on the order of a few microseconds; most other applications require similarly low latencies. Unless you can develop new algorithms which are latency-tolerant and rewrite all the necessary code to implement them, the speed of light will kill you.
As for bandwidth, "huge data crunching" obviously requires moving large amounts of data around. Can your network handle it? Can your network handle it sufficiently cheaply to be practical?
Another issue, of course, is finding interested customers. The idea of having data spread around to any number of unknown people isn't something many companies look forward to. Add to that the question of how rapidly they need results -- using a "keep re-assigning work until it all gets done" scheduler on processors which only complete 80% of the work sent out you'll find that it takes a long time to get jobs finished -- and it will take quite a bit of marketing to find paying customers.
If a router doesn't understand certain option bits, it's supposed to IGNORE them.
I don't know about these specific routers (have we been told which they are?) but the problem might be that they do understand those bits -- in a different meaning. The TOS bits have been redefined a number of times, and the bits used by ECN have been used for other things in the past.
Putting aside for now the arguments about supporting experimental protocols and the use of one-used-and-now-reserved bits, there is a very simple issue here regarding firewall design.
Secure firewalls are designed to block traffic by default.
In other words, if the firewall doesn't understand the packets being sent through it, it will drop them. There's nothing wrong with this behaviour; in fact, if you try to build a "default-accept" firewall by blocking off packets which you know to be undesireable, you'll inevitably run into problems. However, anyone who has tried to get streaming media, or play warcraft, or use any other new protocols through an old firewall will be able to say that this policy can be a nuisance.
Which, of course, is one reason why there is an internet *standards track* giving people time to adapt to new protocols.
In case people are too lazy to look up RFC 2026 themselves, here's the relevant section:
And from the top of RFC 2481:
Maybe RFC 1812 - "4.2.2.6 Unrecognized Header Options:
Which doesn't apply here, since ECN is implemented via bits in the TOS octet, not in an optional IP header.
Which RFC would that be? I can't seem to find it anywhere.
ECN is mature and at the Minn. IETF meeting it was voted to be added to the host requirement standard.
BZZZZZT. Nope, try again. There is now a [B]draft proposed standard[/B] for ECN. That's it. It isn't a standard yet, and won't be for quite some time yet.
Only broken routers who DO NOT OBEY the RFCs fail to pass ECN.
Right... only routers which do not obey an EXPERIMENTAL RFC run into problems. Guess what? You don't have to obey experimental RFCs. That's why they're *experimental*, not *standards*.
it's clear that blocking ECN is an abnormal activity that violates RFC's as well as common sense.
No, it isn't. ECN is an experimental protocol, and there is no requirement for everybody to implement every experimental protocol invented.
In fact, there's a very strong argument to be made that linux is being non-standards compliant, since the first rule of experimental protocols is "don't send packets to people who haven't asked for them".
Get the story right guys. This isn't a "linux is up to date while other people aren't" story -- this is a "linux is using a protocol marked as EXPERIMENTAL" story. EXPERIMENTAL protocols are protocols which are not only not internet standards, but are not even standard track.
If using an EXPERIMENTAL protocol breaks stuff, don't use it. You certainly shouldn't expect people to conform to your own non-standard behaviour.
maybe someone will hack the control signals and fly it to their home?
Do you really want a plane loaded with 15,000 pounds of fuel crashing into your home?
They probably *did* do what they promised in their funding proposals. Given that they started up in August 1999, the single word "linux" was probably enough to bring them their $11 million of venture capital.
Just imagine the uproar this would have caused if people woke up one morning to find DAEMONS spray-painted everything.
At the last month's IETF in Minneapolis there was a slide during the plenary (which hasn't seem to have made it to the web site yet) that showed the average speed of route convergance. It was on the order of 90% propagation of route changes within 1-2 minutes. That's pretty fuckin fast.
Two points to respond to here. First, 90% of route changes propagation occurs within 1-2 minutes; that doesn't necessarily help much if the remaining 10% take two hours. Yes, I know they don't, but in any case an average statistic would be more useful than a 90th percentile statistic.
Second, 1-2 minutes is fast when it comes to switching between working routes. Internet routing works pretty well when it comes to the problem of determining *which route is faster*. However, when it comes to routing around faults, 1-2 minutes is a pretty long time: With ISPs advertising "99.9999% uptime" (ie, down for at most a few seconds each month) downtime of 1-2 minutes is a Bad Thing.
What I'd like to see is some mechanism by which updates could be marked as "urgent" if they relate to fault-recovery -- that way, the few updates which are necessary in order for packets to be routed away from downed links could be propagated within a few seconds, while routine "link x is faster/slower than link y" updates could be handled more slowly.
I think much of the blame lies with the routing protocols currently in use on the internet. Due to concern over maximizing performance -- and minimizing overhead -- most routing systems are set to react quite slowly to changing conditions. This helps eliminate route flapping, but has the unfortunate consequence of taking several minutes to route around a downed router or link.
We can hope that someday we'll have better protocols to deal with this -- don't ask me, I'm no expert on this stuff -- but until the gurus come up with one I guess we just have to suffer.
I wanna know why they don't just use an acelerometer to detect the devices motion and subtract that from the detected motion?"
I'd guess that they don't have accelerometers accurate enough for the purpose. They're dealing with *very* small movements.
Regardless of the poor condition of the advertising market, I can't believe that free email is about to go extinct. The cost of providing email access is so minimal -- and going down every day -- that even $0.01 CPM advertising would probably cover it.
As far as I can see, this is a tax credit for R&D, including all type of programming.
I can't see any statement anywhere which indicates that "Open Source" programming would be treated any differently from "Closed Source" programming.
Come on, admit it, we all rely upon security through obscurity. I mean, how many of you (security challenges notwithstanding) make your root passwords available on the 'net for anyone to see?