Which article did you read? I just tried to get to the DOI, BLM and USGS main sites and they are down. The only article I could get to was the one from indianz.com, and AFAICT it didn't say only the accounting systems would be taken down (that was the original intent, but the judge got angry that Interior was footdragging and told them to take it all down until they could figure it out.)
I still agree with the decision, but the stupidity of spreading access to this data so widely is mindboggling, even considering it *is* the US Govt.
What's irresponsible is that the systems holding this accounting data should be on the internet at all, and to make it worse, entangled to such a degree with other Interior systems that it makes them have to take down the *USGS*? WTF?
If you're considering Jam, also take a look at Cons. It's entirely written in perl, and the "Makefiles" (called Constructs and Conscripts) are also perl, which gives incredible power and flexibility. We use it and are very happy with it. Like Jam it maintains correct dependencies automatically and it can even correctly build large projects with many interdependent subprojects.
This (RGBR'G'B' compositing) is actually extremely useful, but almost nobody actually does it because (a) most current software doesn't support it, (b) it takes more storage - 6xwidthxheight rather than 4xwidthxheight, and (c) it's slower. But if you do premultiplied compositing, it lets you have "stained glass" effects which are impossible otherwise. It's definitely not just a curiosity.
In 1988 I designed a VME bus interface chip which was partially async, to do extremely quick DMA cycles. Worked great (in simulation -- never got built, long story) and yes, it was a lot more difficult than a straightforward clocked design. But the payoff was at least a 2x speed increase for DMA transfers, definitely worth it. Most logic won't get a 2x speedup, but you can easily see cases where you can do even better than that -- clocked logic always has to be designed so the slowest possible cycle still completes. Async can vary cycle times so the fastest cycles take almost no time.
The hardest thing about it though is the possibility of metastability -- clocking an input into a flipflop while the data input is changing. This can not only give wrong data, but can cause lengthy oscillations. Everything has to be checked to make sure that can't happen, and it's a LOT harder in an async chip. So don't expect to see fully async CPUs any time soon. But async (especially self-timed) connections between basic functional blocks is definitely an idea whose time has come.
One (ok two) of the nicest features of lisp, IMHO, are defmacro and defadvice, which allow you to use the full power of lisp to rewrite an arbitrary expression or function and thus extend the syntax and semantics of the language. This is so far beyond the C macro preprocessor it's not funny (and of course Java has no preprocessor at all, whine). I miss this more perhaps than any other Lisp feature. Various people have worked on getting something like this into C/C++/Java: ePerl lets you use perl as a macro language, and some of the AOP (Aspect-Oriented Programming) folks are old lisp hackers (I think Alan Bawden is in that group, for instance) and these people would like to see some kind of defmacro/defadvice functionality in C.
So here's my question: do you think that's possible, given C's irregular syntax and poor token/string handling, and would it be a good idea? Any thoughts on how it could work?
I have the same problem. Same with perl. PCs don't come with it, so I have to jump through hoops to get j.random luser to be able to run my utilities.
The only answer for me so far is vanilla C, compiled by me for each platform I care about. I would *dearly* love it if Python (or perl, or java, or any language) could have a facility for compiling into a single native file (or at least a small collection of files) on many platforms (at least SGI,Sun,PC,Mac,Linux).
>even if you are calling your next door neighbor,
>you will have to dial 1+Area Code+Number
This comment isn't quite right. If you read the actual web site you'll see that starting 4/2/2000, you must dial local calls with 10 digits and the prefix 1 will be optional. AAA-BBB-CCCC. Long distance calls will still require the 1 prefix. This is the part that seems screwy to me. Why not allow people to drop the 1 for long distance and make *everything* 10 digits?
Other universes in the multiverse DO interact with ours. These interactions are often hard to detect, but interference phenomena (e.g. standard two-slit experiment with only one photon) is one common example where it becomes easy. If there's only one photon, what interferes with it to prevent it from appearing at certain positions in the target? Its counterpart in a "nearby" universe which goes through the other slit. Another example is quantum computation: what you're really doing is creating N nearby universes which differ only in the states of a few particles, which is why the results are always probabilistic -- you want to set the computation up so that in "nearly all" those universes the result states are the same, and can thus be measured.
There are other explanations of this stuff but it's pretty much where quantum theory is headed these days. David Deutsch's The Fabric Of Reality has a pretty readable, if a bit annoying, intro to multiverse concepts.
This is exactly right. I haven't read Karn's paper (it's still slashdotted), but it's not hard to figure out: the VMSK folks claim 90 bps per hz of bandwidth. Doing the math we get that the required s/n ratio is 2^90 - 1, or 270dB. This is unlikely to say the least, in any medium I can think of.
One way to be invisible without being blind (or even transparent) would be to have cameras all over you and flexible LCD screens as well. Then transmit what each camera sees to the opposite screen. It would have to track the person to whom you want to appear invisible so as to render the world properly on your body, but within the usual limits (limited fidelity of LCD screens, time lag, etc.) you would seem invisible. And as long as the LCD screens covering your eyes had some transparency to them, you could see out. Eating might be harder.
If they, for instance, see you buying something from a company that sells AIDS drugs and caters to a "high-risk" population, and they sell the data to your insurance company, your rates might suddenly go up due to "administrative overhead". A worst case scenario? You're denied all health insurance because you're suddenly in a "high risk group". Then you have to sue them and spend mega-$. Please, people. It's not just targeted commercials.
The web sites are up, true, but no telnet/ftp/ssh access yet (at least to sepia.propagation.net, our CIHost server), so no site updates or even backups are possible. And www.cisupport.com, their support site, is still down (as it has been since this all started).
The web sites are up, true, but no telnet/ftp/ssh access yet (at least to sepia.propagation.net, our CIHost server), so no site updates or even backups are possible.
Slashdot Mirror
Which article did you read? I just tried to get to the DOI, BLM and USGS main sites and they are down. The only article I could get to was the one from indianz.com, and AFAICT it didn't say only the accounting systems would be taken down (that was the original intent, but the judge got angry that Interior was footdragging and told them to take it all down until they could figure it out.)
I still agree with the decision, but the stupidity of spreading access to this data so widely is mindboggling, even considering it *is* the US Govt.
What's irresponsible is that the systems holding this accounting data should be on the internet at all, and to make it worse, entangled to such a degree with other Interior systems that it makes them have to take down the *USGS*? WTF?
If you're considering Jam, also take a look at Cons. It's entirely written in perl, and the "Makefiles" (called Constructs and Conscripts) are also perl, which gives incredible power and flexibility. We use it and are very happy with it. Like Jam it maintains correct dependencies automatically and it can even correctly build large projects with many interdependent subprojects.
This (RGBR'G'B' compositing) is actually extremely useful, but almost nobody actually does it because (a) most current software doesn't support it, (b) it takes more storage - 6xwidthxheight rather than 4xwidthxheight, and (c) it's slower. But if you do premultiplied compositing, it lets you have "stained glass" effects which are impossible otherwise. It's definitely not just a curiosity.
In 1988 I designed a VME bus interface chip which was partially async, to do extremely quick DMA cycles. Worked great (in simulation -- never got built, long story) and yes, it was a lot more difficult than a straightforward clocked design. But the payoff was at least a 2x speed increase for DMA transfers, definitely worth it. Most logic won't get a 2x speedup, but you can easily see cases where you can do even better than that -- clocked logic always has to be designed so the slowest possible cycle still completes. Async can vary cycle times so the fastest cycles take almost no time.
The hardest thing about it though is the possibility of metastability -- clocking an input into a flipflop while the data input is changing. This can not only give wrong data, but can cause lengthy oscillations. Everything has to be checked to make sure that can't happen, and it's a LOT harder in an async chip. So don't expect to see fully async CPUs any time soon. But async (especially self-timed) connections between basic functional blocks is definitely an idea whose time has come.
One (ok two) of the nicest features of lisp, IMHO, are defmacro and defadvice, which allow you to use the full power of lisp to rewrite an arbitrary expression or function and thus extend the syntax and semantics of the language. This is so far beyond the C macro preprocessor it's not funny (and of course Java has no preprocessor at all, whine). I miss this more perhaps than any other Lisp feature. Various people have worked on getting something like this into C/C++/Java: ePerl lets you use perl as a macro language, and some of the AOP (Aspect-Oriented Programming) folks are old lisp hackers (I think Alan Bawden is in that group, for instance) and these people would like to see some kind of defmacro/defadvice functionality in C.
So here's my question: do you think that's possible, given C's irregular syntax and poor token/string handling, and would it be a good idea? Any thoughts on how it could work?
So why not write a preprocessor that turns braces into proper indentation? You could write it in python...
I have the same problem. Same with perl. PCs don't come with it, so I have to jump through hoops to get j.random luser to be able to run my utilities. The only answer for me so far is vanilla C, compiled by me for each platform I care about. I would *dearly* love it if Python (or perl, or java, or any language) could have a facility for compiling into a single native file (or at least a small collection of files) on many platforms (at least SGI,Sun,PC,Mac,Linux).
>even if you are calling your next door neighbor,
>you will have to dial 1+Area Code+Number
This comment isn't quite right. If you read the actual web site you'll see that starting 4/2/2000, you must dial local calls with 10 digits and the prefix 1 will be optional. AAA-BBB-CCCC. Long distance calls will still require the 1 prefix. This is the part that seems screwy to me. Why not allow people to drop the 1 for long distance and make *everything* 10 digits?
Other universes in the multiverse DO interact with ours. These interactions are often hard to detect, but interference phenomena (e.g. standard two-slit experiment with only one photon) is one common example where it becomes easy. If there's only one photon, what interferes with it to prevent it from appearing at certain positions in the target? Its counterpart in a "nearby" universe which goes through the other slit. Another example is quantum computation: what you're really doing is creating N nearby universes which differ only in the states of a few particles, which is why the results are always probabilistic -- you want to set the computation up so that in "nearly all" those universes the result states are the same, and can thus be measured.
There are other explanations of this stuff but it's pretty much where quantum theory is headed these days. David Deutsch's The Fabric Of Reality has a pretty readable, if a bit annoying, intro to multiverse concepts.
This is exactly right. I haven't read Karn's paper (it's still slashdotted), but it's not hard to figure out: the VMSK folks claim 90 bps per hz of bandwidth. Doing the math we get that the required s/n ratio is 2^90 - 1, or 270dB. This is unlikely to say the least, in any medium I can think of.
One way to be invisible without being blind (or even transparent) would be to have cameras all over you and flexible LCD screens as well. Then transmit what each camera sees to the opposite screen. It would have to track the person to whom you want to appear invisible so as to render the world properly on your body, but within the usual limits (limited fidelity of LCD screens, time lag, etc.) you would seem invisible. And as long as the LCD screens covering your eyes had some transparency to them, you could see out. Eating might be harder.
If they, for instance, see you buying something from a company that sells AIDS drugs and caters to a "high-risk" population, and they sell the data to your insurance company, your rates might suddenly go up due to "administrative overhead". A worst case scenario? You're denied all health insurance because you're suddenly in a "high risk group". Then you have to sue them and spend mega-$. Please, people. It's not just targeted commercials.
The web sites are up, true, but no telnet/ftp/ssh access yet (at least to sepia.propagation.net, our CIHost server), so no site updates or even backups are possible. And www.cisupport.com, their support site, is still down (as it has been since this all started).
The web sites are up, true, but no telnet/ftp/ssh access yet (at least to sepia.propagation.net, our CIHost server), so no site updates or even backups are possible.