...but that it is based on a new programming model. Many ideas are coming from the programming languages research community. All code will be type-safe and memory-safe. Interaction with the OS and other processes will make much more use of immutable data structures. Concurrency will be pervasive. It will be like one giant Erlang environment.
One could set up an entire MP3 futures trading market! You could invest in MP3's, hoping that their popularity will grow... This is part of the site already!
http://amiestreet.com/recs/buzzing/today/
Is it a legitimate case that a high upload rate should increase cost so significantly? YES. Upload rate is the basis for cash flow on the Internet. If you have no upload rate, you are generally pretty happy as a typical Internet end user. On the other hand, if you have an upload rate, and a static IP address... you are suddenly enabled as a potential web host. That is something of great value. If you are a business, paying for a T1 line and your own server may have similar cost to using collocation with the corresponding level of quality of service. Even if you are not a business, you can theoretically resell all unused upload bandwidth, recovering the high cost of the T1 line.
These suggestions may not be practical, but they at least explain why there is a market for upload bandwidth. Generally speaking, if everyone only paid for upload, and didn't pay for download, the economics of a non-P2P Internet would work quite well. It's like the post office, where the sender of the letter pays postage, and the receiver gets it for free. Every bit is paid for, since every bit has a source(the payer) and a destination. End users would have low prices, and therefore have more incentive to browse the net. Last-mile providers can build an infrastructure which exploits asymmetric connections. Big traffic web sites end up financing the cost of pushing bits around on the Internet (and since they are pretty much charged for the amount of content they produce, they have an incentive to keep that number down, leading to more efficient usage of bandwidth). Backbone ISPs should have an easier time pushing the bits downstream. Also, downstream providers have more incentive to find peering agreements and avoid the backbones... leading to better load balancing.
For big users of P2P technology, costs shift around. Much of the cost of Internet services is, ultimately, subsidized by advertising. This works well in the above model. With P2P, end users upload a lot more, and will have to directly face the cost of bandwidth themselves.. instead of relying on big-traffic web sites to generate a cash flow coming out of the advertiser's pockets. I'm curious to see how this will play out, with P2P TV on the way, and the last-mile providers increasingly incensed by this.
It's a little more complicated than that... it has to use a rolling hash so that it can get variable-size chunks. It won't work too well with fixed-size chunks.
After all, if a.js fails to satisfy Google, it's the author's loss and not Google's.
It can also be a grave loss to Google's user, if the ultimate result leads to a gross misrepresentation of the site's content.
Decidability is irrelevant in this context because Google is in a position where they can implement a JavaScript interpreter with hard limits on the resources available to the JavaScript script.
We both agree that this approach will not turn up the best possible results. However, if we assume that it does fairly well (and I'm not sure), look at the cost. This is an inherently stateful process... and that could a massive reduction in performance. I think crawling right now is probably stateless, leading to very fine-grained load balancing and redundancy. That's why, as I said in my post, that they should look at common cases that are easy to analyze.
It's not easy for Google to determine how to treat text inside of Document.write(). In some cases, that line of script will never be executed. In other cases, it may be executed multiple times. What is Google to do with something like this:
if (1 == 0) { document.write("pignoklot zimpogrit"); }
Obvously, "pignoklot zimpogrit" will never be emitted, but Google's crawler might not get that. In general, you run into decidability issues, like the Halting problem. The best approach would be for Google's crawler to fully emulate the session of a user, and execute all scripts like a browser would... but that may be difficult or impossible to automate on a large-scale. It is true that Google can do a better job than it does now. It can at least search for common cases where write() definitely gets called.
But I humbly invite you to consider that the ratio of of woman/man engineers is 5% greater today than it was 20 years ago; 10% greater than 40 years ago; and 100 years ago, women basically didn't engage in technical pursuits (except for rare, anomalous cases) and most technical schools didn't admit women. The term "computer" was first used as job title for people who would do manual calculations; this position was usually held by women. 60 years ago, when electronic computers were invented, programming was a 100% female-dominated field. All the programmers of the ENIAC were women. It was, in fact, seen as unmanly. As soon as programming began to be perceived as challenging and worthwhile, the whole thing turned inside out.
But it would require energy. The whole reason hydrocarbons are a good source of energy is precisely because the C + O2 -> CO2 reaction gives off energy. So to make it go the other way, you need input energy. Plants get it from the sun, where would we get it from. Then, of course, assuming you have a source the question is why not just cut the middle man and use that source directly? Getting a clean energy source is a key issue, but it's tangential to Branson's statement. He is talking about reversing damage that has been done by us. Yes, a clean energy source will at once prevent further damage from being done, but we could also use it to expend energy to remove atmospheric carbon that has been emitted by our generation.
Besides, DNS is for wussies anyways. Real men don't need user-friendly names for their ip addresses:) But seriously, I can imagine the Web still being useful without DNS if search engines linked to IP addresses instead of hostnames. And now that email is largely a WWW service (hotmail, gmail...) a big chunk of it could survive too. Let's take Google as an example. Google generates search results by looking at links. Links include URLs. URLs include domain names. So, Google depends on the existence of DNS to calculate PageRank. If we drop DNS altogether, all URLs on the WWW will need to be switched to IP addresses. Unless, Google wants to server a viable replacement mechanism for DNS that is driven by the search engine. For example, instead of linking to bmw.com, you would link to some-google-static-ip-address/feeling-lucky/q=bmw.
I can order up a computer, cell phone or HDTV, have it flown in and delivered by a man in a shiny brown truck with no pain, delay or unreasonable expense. This is actually more energy-efficient than driving to the store and picking it up yourself.
Re:VB already gets the respect it deserves...
on
Lisp and Ruby
·
· Score: 1
Haskell has a pretty standard "module" system. However, Haskell's "class" system is really an advanced module system. It's not OOP because there are no objects or instances. It's an expressive way to express generic, parametrized modules. It is similar in many ways to the module system of Standard ML. If you want to see a really powerful, unique paradigm.. check out the Standard ML module system. I guarantee you it would bring you many new insights into programming.
But, who cares if VB.Net is getting lambda expressions? I think you missed my point. It was that functional programmers are too smart to use OOP, and VB.Net programmers are too stupid to use it.
Re:VB already gets the respect it deserves...
on
Lisp and Ruby
·
· Score: 1
Understands what an interface is
Understands what a class method is
Understands inheritance
Really understands the difference between reference and value types
Uses classes instead of modules
Sounds like a user of functional programming languages! (LISP, ML, Haskell, etc) To be precise, interfaces are used, the difference between reference and value type is explicit, and OOP is often bolted on, as in CLOS and OCaml. But a seasoned functional programmer will use modules instead of classes, avoid references, and avoid inheritance. Granted, module systems in ML and Haskell are much more powerful than that of VB.NET.
You don't need OOP to solve problems. But, the choice of paradigm should be made given full awareness of the alternatives. While functional programmers are only too well acquainted with OOP, it sounds like these VB.NET developers don't even have a clue.
So long as you program using strictly functions, your program can be verified according to the rules of lambda calculus, and the verification would be as sure as a mathematical proof. This is the only sure way I know of really knowing with mathematical certainty that your application is secure. Rice's theorem. Proving any non-trivial property about functional programs is undecidable.
Here's a simple example: the halting problem. Just try to prove that your functional program will terminate. You can't do it! If you don't know that your daemons will terminate, an attacker can potentially make them non-terminating (e.g. an infinite loop). This definitely constitutes a security hole: it's a DoS attack.
There is a large body of work on program proving, and it certainly isn't bound to lambda calculus or even functional programming.
Your intentions are appreciated, but come on, your understanding is basic. Take another class or two if you want to really know what's going on here... or learn something you can use today.
Do you mean that rediculous movie where the guy travels eight hundred thousand years into the future, where that one lady spoke English: "Do you understand my words . . . ?", and that holographic librarian Orlando Jones was still there?
No, we mean the book, not the horrible movie adaptation of the book. The book did not have these foolish things that you describe.
Slashdot Mirror
$500 if you can prove otherwise. The Great Zero Challenge
...but that it is based on a new programming model. Many ideas are coming from the programming languages research community. All code will be type-safe and memory-safe. Interaction with the OS and other processes will make much more use of immutable data structures. Concurrency will be pervasive. It will be like one giant Erlang environment.
This article IS about Amie Street.
This is already a feature of the site. http://amiestreet.com/recs/buzzing/today/
There is an American company, Powercast, which is claiming to already have FCC approval for wireless power transmission.
These suggestions may not be practical, but they at least explain why there is a market for upload bandwidth. Generally speaking, if everyone only paid for upload, and didn't pay for download, the economics of a non-P2P Internet would work quite well. It's like the post office, where the sender of the letter pays postage, and the receiver gets it for free. Every bit is paid for, since every bit has a source(the payer) and a destination. End users would have low prices, and therefore have more incentive to browse the net. Last-mile providers can build an infrastructure which exploits asymmetric connections. Big traffic web sites end up financing the cost of pushing bits around on the Internet (and since they are pretty much charged for the amount of content they produce, they have an incentive to keep that number down, leading to more efficient usage of bandwidth). Backbone ISPs should have an easier time pushing the bits downstream. Also, downstream providers have more incentive to find peering agreements and avoid the backbones... leading to better load balancing.
For big users of P2P technology, costs shift around. Much of the cost of Internet services is, ultimately, subsidized by advertising. This works well in the above model. With P2P, end users upload a lot more, and will have to directly face the cost of bandwidth themselves.. instead of relying on big-traffic web sites to generate a cash flow coming out of the advertiser's pockets. I'm curious to see how this will play out, with P2P TV on the way, and the last-mile providers increasingly incensed by this.
It's a little more complicated than that... it has to use a rolling hash so that it can get variable-size chunks. It won't work too well with fixed-size chunks.
Haskell has a pretty standard "module" system. However, Haskell's "class" system is really an advanced module system. It's not OOP because there are no objects or instances. It's an expressive way to express generic, parametrized modules. It is similar in many ways to the module system of Standard ML. If you want to see a really powerful, unique paradigm.. check out the Standard ML module system. I guarantee you it would bring you many new insights into programming.
But, who cares if VB.Net is getting lambda expressions? I think you missed my point. It was that functional programmers are too smart to use OOP, and VB.Net programmers are too stupid to use it.
- Understands what an interface is
- Understands what a class method is
- Understands inheritance
- Really understands the difference between reference and value types
- Uses classes instead of modules
Sounds like a user of functional programming languages! (LISP, ML, Haskell, etc) To be precise, interfaces are used, the difference between reference and value type is explicit, and OOP is often bolted on, as in CLOS and OCaml. But a seasoned functional programmer will use modules instead of classes, avoid references, and avoid inheritance. Granted, module systems in ML and Haskell are much more powerful than that of VB.NET.You don't need OOP to solve problems. But, the choice of paradigm should be made given full awareness of the alternatives. While functional programmers are only too well acquainted with OOP, it sounds like these VB.NET developers don't even have a clue.
Here's a simple example: the halting problem. Just try to prove that your functional program will terminate. You can't do it! If you don't know that your daemons will terminate, an attacker can potentially make them non-terminating (e.g. an infinite loop). This definitely constitutes a security hole: it's a DoS attack.
There is a large body of work on program proving, and it certainly isn't bound to lambda calculus or even functional programming.
- Use a type system to express properties about your program
- Use Hoare logic to reason about your imperative programs, and possibly even embed the proof into the executable
Your intentions are appreciated, but come on, your understanding is basic. Take another class or two if you want to really know what's going on here... or learn something you can use today.I think a lot of people don't know about other search engines anymore.
Actually, check this out...
V --> W
M --> N
S --> T
WNT is one step ahead of VMS. Kind of like IBM is one step ahead of HAL.
You shouldn't object to them killing you either... because then they'll kill you twice.
They DID check him. For a long time, they thought it was Thallium, another radioactive element. They only ruled it out a couple days ago.
This was licensed from the Human Computation project, spearheaded by Luis von Ahn and Manuel Blum, at CMU. They also developed the CAPTCHA.
You can see a talk given at Google, and a summary of the research.