Sounds like I was on the right track; sadly, I never managed to get it to produce any output at all, even booting from the floppies made from the CD...
I remember making the FD images from the CD, but even booting from those it never got far. It seemed to get stuck sometime before doing any output at all.
From the very PDF you link to, Question 1, right at the beginning:
the more recent epidemiological studies show little evidence that either power lines or "electrical occupations" are
associated with an increase in cancer (see Q19);
laboratory studies have shown little evidence of a link between power-frequency fields and cancer (see Q16);
an extensive series of studies have shown that life-time exposure of animals to power-frequency magnetic fields does not
cause cancer (see Q16B);
a connection between power line fields and cancer is physically implausible (see Q18).
... Overall, most scientists consider that the evidence that power line fields cause or contribute to cancer is weak to nonexistent.
Do you have any links for this? I checked my local traffic regulations (Cambridge, MA) a couple of weeks ago and didn't see any language at all that hinted that traffic lights might be optional for cyclists.
"Abstract: I survey physics theories involving parallel universes, which form a natural four-level hierarchy of multiverses allowing progressively greater diversity. Level I: A generic prediction of inflation is an infinite ergodic universe, which contains Hubble volumes realizing all initial conditions — including an identical copy of you about 101029 m away. Level II: In chaotic inflation, other thermalized regions may have different physical constants, dimensionality and particle content. Level III: In unitary quantum mechanics, other branches of the wavefunction add nothing qualitatively new, which is ironic given that this level has historically been the most controversial. Level IV: Other mathematical structures give different fundamental equations of physics. The key question is not whether parallel universes exist (Level I is the uncontroversial cosmological concordance model), but how many levels there are. I discuss how multiverse models can be falsified and argue that there is a severe “measure problem” that must be solved to make testable predictions at levels II-IV."
Advantages of no-cash: [...] All the rich people would have to pay all their taxes.
This would only be the case if all the rich people happened to carry their vast wealth around as cash in order to avoid the tax collector. They don't. They keep it in banks and investments.
A Fire Upon the Deep is definitely better, as is A Deepness in the Sky. Both are very well worthwhile; in fact both number among my favourite science fiction novels.
You tell a convincing tale; but why would anyone do the required rewriting by hand? The rules you mention sound very much within reach of the kinds of things obfuscating rewriters -- or compilers in general, for that matter -- do. I mean, if expensive, pointless adherence to some bureaucratic mandate is the aim, of course.
Solving the problem wrong, indeed.
If you weren't aware that your browser already has very rich network interaction capabilities, I suggest reading up on AJAX. Reversehttp, when running in a browser, is built from sandboxed javascript code, running in a page, using XMLHttpRequest, just like everything else.
It's also not actually browser specific, and applies equally well to thick clients (think Skype, or practically anything that wants to receive messages rather than just send them; you might make a broad comparison with UPNP or STUN). It's just a happy coincidence that it can be used to lift the browser up to equal status with other programming environments.
Well, the next time you, your girlfriend, daughter, mom, dad etc writes a web service, perhaps they'll get some leverage out of it:-)
(One interesting demo, not linked on the site but present in the source code on github, is a PubSubHubBub endpoint in the browser, which can subscribe to PubSubHubBub's feed update notifications for real-time feed tracking. (PSHB deliberately doesn't include any long-polling ad-hockery, so this is otherwise not possible.) The URL of the page is subscribed to the PSHB hub, and when new atom entries arrive, they're POSTed directly to the page -- or rather, as direct as possible given that there's the reversehttp gateway relaying the POST on.)
You've missed the point: this is one of the situations when reversehttp actually saves the day. The reversehttp gateway is outside the firewall. Services inside the firewall contact the gateway to get it to relay requests in to them, using long-polling (or any other method, current or yet to be invented). The point is that the gateway is in exactly the right place to dole out names/URLs and to handle the routing, filtering and relaying.
Can you explain a scenario where such a set-up makes sense (from a business or usability perspective) and where other protocols are unable to get the job done?
Anywhere you'd otherwise be configuring apache/DNS/firewall/CGI/reverseproxy rules by hand. There aren't any protocols for that other than reversehttp yet. The goal was to make it as easy to get a name/URL and become a full server in the HTTP network as it is to anonymously participate as a client. Particularly interesting is the way it makes short-lived services suddenly viable: previously, you'd either have to reconfigure your gateway apache instance (or similar) each time a service came and went (or moved!), or ad-hoc up some way of doing roughly what reversehttp does, but on a case-by-case basis.
(It's also, by the way, no more difficult to secure the gateway than it is to secure any other web service -- the demo server hands out URL space pretty freely, but obviously if you were deploying it yourself you'd apply normal HTTP access control policies to limit who was allowed to register which names and so on.)
It'd be useful in the same way decentralised version control systems are useful by comparison with their centralised counterparts. The replication topologies are no longer constrained to the simple hub-and-spoke model. Think google wave, without the centralised server. Think google docs, without the centralised server.
3) how is your browser going to access a Database like mysql with php, local on your machine? The pages would have to be cached and static or some other wizard way of doing it.
There's nothing that limits reversehttp to the browser. Any HTTP client library can use it. The demo implementation has clients not just for browser-hosted Javascript but also for Python and Java. Besides the clients included with the demo implementation, Paul Jones has written hookout, for Ruby programs, and Tatsuhiko Miyagawa has written AnyEvent-ReverseHTTP for exposing HTTP services via reversehttp from programs written in Perl.
Huh? Did you read the spec draft? The metacircular use of HTTP is a cute hack, but in no way central to the idea. If you like, think of reversehttp as a kind of "remote CGI" -- like what people already do with apache's reverse proxying, but dynamically configurable.
So people do not like caching proxies, why would they like one in their browser ? Why would they like getting content from another user browser instead of from the original source ?
What if the other user's browser is the original source? Think something like Tiddlywiki instances running in the browser and synchronising peer-to-peer.
"[...] we need to be able to act as if being able to respond to HTTP requests was within easy reach of every program, so that we can notify interested parties of changes by simply sending an HTTP request to them. This is the core idea of web hooks.
We need to push the messy business of dealing with long-polling away from the core and toward the edge of the network, where it should be.
We need to let programs dynamically claim a piece of URL space [...] and handle requests sent to URLs in that space [...].
Once that's done suddenly asynchronous notification of events is within reach of any program [...], and protocols and services layered on top of HTTP no longer have to contort themselves to deal with the asymmetry of HTTP. They can assume that all the world's a server, and simply push and pull content to and from whereever they please."
The details of getting the requests through the gateway to the serving application are pretty trivial and interchangeable. The new idea is in registering endpoint names. UPNP and STUN cover some of the same space, but IP's addressing is fundamentally different to HTTP's URL-based addressing in that it's possible with URLs to have recursive delegations of portions of the namespace -- something that IP just can't do (because it's flat).
Slashdot Mirror
Sounds like I was on the right track; sadly, I never managed to get it to produce any output at all, even booting from the floppies made from the CD...
I remember making the FD images from the CD, but even booting from those it never got far. It seemed to get stuck sometime before doing any output at all.
How did you get it running under Virtualbox? I've tried but couldn't get the CDs to boot. (I have original Warp CDs.)
(Emphasis mine.)
Do you have any links for this? I checked my local traffic regulations (Cambridge, MA) a couple of weeks ago and didn't see any language at all that hinted that traffic lights might be optional for cyclists.
The paper you want to read is Max Tegmark, "Parallel Universes," 2003. Available here: http://arxiv.org/pdf/astro-ph/0302131v1
"Abstract: I survey physics theories involving parallel universes, which form a natural four-level hierarchy of multiverses allowing progressively greater diversity. Level I: A generic prediction of inflation is an infinite ergodic universe, which contains Hubble volumes realizing all initial conditions — including an identical copy of you about 101029 m away. Level II: In chaotic inflation, other thermalized regions may have different physical constants, dimensionality and particle content. Level III: In unitary quantum mechanics, other branches of the wavefunction add nothing qualitatively new, which is ironic given that this level has historically been the most controversial. Level IV: Other mathematical structures give different fundamental equations of physics. The key question is not whether parallel universes exist (Level I is the uncontroversial cosmological concordance model), but how many levels there are. I discuss how multiverse models can be falsified and argue that there is a severe “measure problem” that must be solved to make testable predictions at levels II-IV."
Advantages of no-cash: [...] All the rich people would have to pay all their taxes.
This would only be the case if all the rich people happened to carry their vast wealth around as cash in order to avoid the tax collector. They don't. They keep it in banks and investments.
Does this help?
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script> <script type="text/javascript"> if (!("jQuery" in this)) { document.write('<'+'script type="text/javascript" src="query.min.js"></'+'script>'); } </script>
In 100 smokers, 17 will die from lung cancer. In 100 non-smokers, 1 will die from lung cancer, often a second-hand smoke victim.
Do you have a reference for that?
A Fire Upon the Deep is definitely better, as is A Deepness in the Sky. Both are very well worthwhile; in fact both number among my favourite science fiction novels.
You tell a convincing tale; but why would anyone do the required rewriting by hand? The rules you mention sound very much within reach of the kinds of things obfuscating rewriters -- or compilers in general, for that matter -- do. I mean, if expensive, pointless adherence to some bureaucratic mandate is the aim, of course. Solving the problem wrong, indeed.
I would like a right to a paycheck despite not working, a right to house despite not paying rent,
You're welcome! Enjoy.
a right to a signifigant other provided to me by the state of the gender of my choosing.
Slavery is a different kettle of fish, don't you think?
Screw work, it is for suckers, I want to play video games all day and make the state pay for it!
Again, enjoy. I hope you recover some motivation soon.
It's also not actually browser specific, and applies equally well to thick clients (think Skype, or practically anything that wants to receive messages rather than just send them; you might make a broad comparison with UPNP or STUN). It's just a happy coincidence that it can be used to lift the browser up to equal status with other programming environments.
(One interesting demo, not linked on the site but present in the source code on github, is a PubSubHubBub endpoint in the browser, which can subscribe to PubSubHubBub's feed update notifications for real-time feed tracking. (PSHB deliberately doesn't include any long-polling ad-hockery, so this is otherwise not possible.) The URL of the page is subscribed to the PSHB hub, and when new atom entries arrive, they're POSTed directly to the page -- or rather, as direct as possible given that there's the reversehttp gateway relaying the POST on.)
You've missed the point: this is one of the situations when reversehttp actually saves the day. The reversehttp gateway is outside the firewall. Services inside the firewall contact the gateway to get it to relay requests in to them, using long-polling (or any other method, current or yet to be invented). The point is that the gateway is in exactly the right place to dole out names/URLs and to handle the routing, filtering and relaying.
Can you explain a scenario where such a set-up makes sense (from a business or usability perspective) and where other protocols are unable to get the job done?
Anywhere you'd otherwise be configuring apache/DNS/firewall/CGI/reverseproxy rules by hand. There aren't any protocols for that other than reversehttp yet. The goal was to make it as easy to get a name/URL and become a full server in the HTTP network as it is to anonymously participate as a client. Particularly interesting is the way it makes short-lived services suddenly viable: previously, you'd either have to reconfigure your gateway apache instance (or similar) each time a service came and went (or moved!), or ad-hoc up some way of doing roughly what reversehttp does, but on a case-by-case basis.
(It's also, by the way, no more difficult to secure the gateway than it is to secure any other web service -- the demo server hands out URL space pretty freely, but obviously if you were deploying it yourself you'd apply normal HTTP access control policies to limit who was allowed to register which names and so on.)
It'd be useful in the same way decentralised version control systems are useful by comparison with their centralised counterparts. The replication topologies are no longer constrained to the simple hub-and-spoke model. Think google wave, without the centralised server. Think google docs, without the centralised server.
3) how is your browser going to access a Database like mysql with php, local on your machine? The pages would have to be cached and static or some other wizard way of doing it.
There's nothing that limits reversehttp to the browser. Any HTTP client library can use it. The demo implementation has clients not just for browser-hosted Javascript but also for Python and Java. Besides the clients included with the demo implementation, Paul Jones has written hookout, for Ruby programs, and Tatsuhiko Miyagawa has written AnyEvent-ReverseHTTP for exposing HTTP services via reversehttp from programs written in Perl.
Huh? Did you read the spec draft? The metacircular use of HTTP is a cute hack, but in no way central to the idea. If you like, think of reversehttp as a kind of "remote CGI" -- like what people already do with apache's reverse proxying, but dynamically configurable.
Yes :-)
So people do not like caching proxies, why would they like one in their browser ? Why would they like getting content from another user browser instead of from the original source ?
What if the other user's browser is the original source? Think something like Tiddlywiki instances running in the browser and synchronising peer-to-peer.
The details of getting the requests through the gateway to the serving application are pretty trivial and interchangeable. The new idea is in registering endpoint names. UPNP and STUN cover some of the same space, but IP's addressing is fundamentally different to HTTP's URL-based addressing in that it's possible with URLs to have recursive delegations of portions of the namespace -- something that IP just can't do (because it's flat).
The Russians and Chinese are keeping their nukes up to date....why should we not do the same?
Because nuclear weapons are morally indefensible.
XP ran like shit on less than 64MB of RAM, so why is Vista bashed for having the same comparative requirements?
Are you seriously claiming it's acceptable for an operating system to run like shit with fewer than 64 MB of RAM?
They last five years, so cost NZ$30 per year (more than US$20). Looked at that way, it's en par with the cost of an SSL certificate.