Because the Terriers are old decomissioned US navy SAMs and thus pretty cheap to get these days and for this test even cheaper since they got the ride for free (see tony
tony_gardner's posting).
Please tell me one single browser that does support cookies and does not have this "feature"!
Actually all browsers I know have at least a third option ("warn/ask before accepting a cookie") and many allow even more control, like:
- "Only accept cookies originating from the same server as the page being viewed" (Netscape)/ "Enable cookies for the originating web site only" (Mozilla), "Don't accept third party cookies" (Opera) which prevents cross-site user tracking (Site A won't get any cookies Site B might set for it).
- Allowing/Disallowing cookies based on acess lists (Galeon/Lynx/Opera/Konqueror) or "Levels of Privacy" (Mozilla)
And in case your browser doesn't allow enough control over cookies for your taste, most filtering proxies like junkbuster do.
What you haven't understood is that this proposed EU privacy directive protects individuals (like e.g. Dmitry Sklyarov) against companies unlike US laws like DMCA which "protects" companies against individuals (like Dmitry Sklarov).
So if anything happens than an American corporation (which are known to give a damn about people's privacy, see e.g. Microsoft) might get into trouble (eg. the EU may "fine" that company) but not a citizen.
Well, the posting is titled with the question "Tunguska Mytery Blast Solved?" wich doesn't sound that definite to me.
But I agree with you that mfarah's summary of the article is misleading/wrong ("...an italian scientist team determined that... was in fact...") since the articles states "italian researchers believe they may have the definitive answer".
> If L1 is implemented as a direct-mapped cache of L2, then if L2 increases, L1's hit ratio goes
> down.
Yes, *if*, but it can't work this way, since the L2 cache isn't used as a direct access memory.
The L2 cache is a associative memory, i.e. you use the normal (physical, in seldom cases maybe even virtual) adresses to adress memory. (Otherwise it wouldn't be a cache...)
Which means that the adress space the L1 cache has to handle is not affected by the size of the L2 cache and that means the L2 cache has absolutely no influence on wether a access to the L1 cache results in a hit or miss - it doesn't even matter if there's a L2 cache or not.
> For instance, increasing vastly the size of the L2 cache will make the L2 hit ratio go up, but
> the L1 hit ratio go down (assuming the inclusion policy is in effect - this is not always so
> anymore -- see the 1st generatino Duron chips)
This is wrong - the size of the L2 cache has no effect on the hit rate of L1 cache(s). Just think about what a hit or miss really is and then ask yourself why 0MB, 1MB, 2MB... of L2 cache should make a difference for the hit-rate of the L1 cache.
And - since L1 caches usually work with virtual and not physical adresses - the L1 hitrate is not even influenced (much) by the amount of RAM.
Then go an buy something from Sun, IBM, Compaq -> AFAIK all three buy servers with that large L2 Caches. (Maybe HP and SGI as well).
E.g. something from IBM's z900 serie (mainframe - up to 32 MB L2 (per CPU?)) or pSeries 620 (workgroup/midrange server - up to 8MB L2 per CPU) or Sun Enterprise 450 (workgroup server - up to 8MB L2 Cache per CPU), Sun Fire 15K (High End Server, 8MB L2 per CPU), Compaq Alphaservers GS/ES series (up to 8MB per CPU).
And if you want just total of 8MB a SGI Origin 300 with more than 4 CPU should do it as well (2MB L2 per CPU).
> What if a plane flies through the beam, would it's electronics get mucked up?
And worse I guess...
But this no problem: Restrictions where (civilian) planes are not allowed to fly already exist in most nations, e.g. not near nuclear power plants, or over certain populated areas etc...
You just have to define safety zones around those ground stations as well.
Well, you wrote
> version x.y.odd_number aren't stable releases.
which means:
2.4.11 is unstable
2.4.12 is stable
2.4.13 will be unstable
2.4.14 will be stable
...
Maybe some longer time Linux users can tell us about there experiences with unstable kernels and which minor number those had - perhaps there's some statistical truth in this.
I think you are confusing something here: Virtual memory management is not only swaping, it's about mapping physical memory pages to the logical adress space of the CPU(s), managing access rights of different CPU modes and so on, the swapping stuff is just an added bonus.
Without virtual memory it's not possible to run a multiuser/multitasking OS.
"flops" is floating point operation per second. So if "flop" has a meaning at all, it would be "floating point operation" and thus "a teraflop per second" is "one teraflops" and a measurement of performance.
> TRU/64 is used because Compaq Alphas are 64 bit processors, and
> Compaq wanted to use their own Linux distribution.
Err, Tru64 as it's called now, is no Linux distribution. It's Digital/Compaq's version of Unix for the Alpha architecture (or "AXP" if you prefer that). It had the names "Digital Unix" and "DEC OSF/1" before it was renamed to Tru64.
I only now of SPARC (SPARC v7 instruction set), MicroSPARC (I,II[e|ep]), TurboSPARC, SuperSPARC, HyperSPARC (all four v8), UltraSPARC (I,II*,III*) and SPARC64 (both SPARC v9).
> Dunno where you have been for the last decade or so, but - PA-RISC was
> the first commercially shipping RISC implementation.
This is not true, first was Acorn with its ARM (first working silicon 1985, first available products with ARM CPU 1986), then MIPS (June 1986), then PA-RISC (October 1986).
Probably, the 700 series was quite fast for its time (I have a 715/80 myself!).
But AFAIK there was no "snake", but many of the 700s were named after snakes, maybe you mean one of these: Bushmaster (710/50), Cobra (720/50), King Cobra (730/66), Coral (750), Coral II (755)...
(I wonder if the HP engineers were fans of Elite (the game))
I have a MXTS-540S from Maxtor with the IBM P/N 17G3180 printed on it and the text "MANUFACTURED FOR IBM COPRPORATION ARMONK, NY".
It identifies itself as "IBM, MXT-540SL".
The Challenger is a really *bad* example to show how dangerous Hydrogen can be. (BTW: Were was the large BLUE fire?)
Maybe you should have read the final analysis of the Challenger accident:
The hydrogen tank started to leak and burn ~64.6 seconds after liftoff because a flame from the right solid rocket booster burnt a hole into the external tank.
But did Challenger explode then? No.
The "explosive burn" started roughly 9 seconds later, when the liquid oxygen tank was hit by the solid booster.
Slashdot Mirror
Please tell me one single browser that does support cookies and does not have this "feature"!
Actually all browsers I know have at least a third option ("warn/ask before accepting a cookie") and many allow even more control, like:
- "Only accept cookies originating from the same server as the page being viewed" (Netscape)/ "Enable cookies for the originating web site only" (Mozilla), "Don't accept third party cookies" (Opera) which prevents cross-site user tracking (Site A won't get any cookies Site B might set for it).
- Allowing/Disallowing cookies based on acess lists (Galeon/Lynx/Opera/Konqueror) or "Levels of Privacy" (Mozilla)
And in case your browser doesn't allow enough control over cookies for your taste, most filtering proxies like junkbuster do.
But it's not even remotely funny.
What you haven't understood is that this proposed EU privacy directive protects individuals (like e.g. Dmitry Sklyarov) against companies unlike US laws like DMCA which "protects" companies against individuals (like Dmitry Sklarov).
So if anything happens than an American corporation (which are known to give a damn about people's privacy, see e.g. Microsoft) might get into trouble (eg. the EU may "fine" that company) but not a citizen.
Well, the posting is titled with the question "Tunguska Mytery Blast Solved?" wich doesn't sound that definite to me.
...") since the articles states "italian researchers believe they may have the definitive answer".
But I agree with you that mfarah's summary of the article is misleading/wrong ("...an italian scientist team determined that... was in fact
> If L1 is implemented as a direct-mapped cache of L2, then if L2 increases, L1's hit ratio goes
> down.
Yes, *if*, but it can't work this way, since the L2 cache isn't used as a direct access memory.
The L2 cache is a associative memory, i.e. you use the normal (physical, in seldom cases maybe even virtual) adresses to adress memory. (Otherwise it wouldn't be a cache...)
Which means that the adress space the L1 cache has to handle is not affected by the size of the L2 cache and that means the L2 cache has absolutely no influence on wether a access to the L1 cache results in a hit or miss - it doesn't even matter if there's a L2 cache or not.
> For instance, increasing vastly the size of the L2 cache will make the L2 hit ratio go up, but
... of L2 cache should make a difference for the hit-rate of the L1 cache.
> the L1 hit ratio go down (assuming the inclusion policy is in effect - this is not always so
> anymore -- see the 1st generatino Duron chips)
This is wrong - the size of the L2 cache has no effect on the hit rate of L1 cache(s). Just think about what a hit or miss really is and then ask yourself why 0MB, 1MB, 2MB
And - since L1 caches usually work with virtual and not physical adresses - the L1 hitrate is not even influenced (much) by the amount of RAM.
"whatever it cost"?
Then go an buy something from Sun, IBM, Compaq -> AFAIK all three buy servers with that large L2 Caches. (Maybe HP and SGI as well).
E.g. something from IBM's z900 serie (mainframe - up to 32 MB L2 (per CPU?)) or pSeries 620 (workgroup/midrange server - up to 8MB L2 per CPU) or Sun Enterprise 450 (workgroup server - up to 8MB L2 Cache per CPU), Sun Fire 15K (High End Server, 8MB L2 per CPU), Compaq Alphaservers GS/ES series (up to 8MB per CPU).
And if you want just total of 8MB a SGI Origin 300 with more than 4 CPU should do it as well (2MB L2 per CPU).
> What if a plane flies through the beam, would it's electronics get mucked up?
And worse I guess...
But this no problem: Restrictions where (civilian) planes are not allowed to fly already exist in most nations, e.g. not near nuclear power plants, or over certain populated areas etc...
You just have to define safety zones around those ground stations as well.
2040 is "pretty near future" for you?
Please explain to me how software can have "too much speed" or "too much stability".
Somehow it broke from 0.9.3->0.9.4...
Well, you wrote
> version x.y.odd_number aren't stable releases.
which means:
2.4.11 is unstable
2.4.12 is stable
2.4.13 will be unstable
2.4.14 will be stable
...
Maybe some longer time Linux users can tell us about there experiences with unstable kernels and which minor number those had - perhaps there's some statistical truth in this.
> *is* there anything in FreeBSD that's of particular technical interest?
Well, that's difficult to answer, if you "don't actually follow other oprating systems", isn't it?
I think you are confusing something here: Virtual memory management is not only swaping, it's about mapping physical memory pages to the logical adress space of the CPU(s), managing access rights of different CPU modes and so on, the swapping stuff is just an added bonus.
Without virtual memory it's not possible to run a multiuser/multitasking OS.
"flops" is floating point operation per second. So if "flop" has a meaning at all, it would be "floating point operation" and thus "a teraflop per second" is "one teraflops" and a measurement of performance.
> TRU/64 is used because Compaq Alphas are 64 bit processors, and
> Compaq wanted to use their own Linux distribution.
Err, Tru64 as it's called now, is no Linux distribution. It's Digital/Compaq's version of Unix for the Alpha architecture (or "AXP" if you prefer that). It had the names "Digital Unix" and "DEC OSF/1" before it was renamed to Tru64.
And please: Don't feed the trolls...
And disallowing encryption will stop terrorists from using it?
So why not outlaw hijacking planes and flying them into buildings as well?
... wait, I think it is already outlawed...
And what is "Sparc III"?
WTF is Sparc3?
I only now of SPARC (SPARC v7 instruction set), MicroSPARC (I,II[e|ep]), TurboSPARC, SuperSPARC, HyperSPARC (all four v8), UltraSPARC (I,II*,III*) and SPARC64 (both SPARC v9).
Kerberos is still free.
Sorry, I've forgotten IBM's ROMP:
a q/hardware.txt )
First working sillicon in early 1981, first products (IBM RT) announced January 1986.
(See http://www.contrib.andrew.cmu.edu/~shadow/ibmrt/f
> Dunno where you have been for the last decade or so, but - PA-RISC was
> the first commercially shipping RISC implementation.
This is not true, first was Acorn with its ARM (first working silicon 1985, first available products with ARM CPU 1986), then MIPS (June 1986), then PA-RISC (October 1986).
Probably, the 700 series was quite fast for its time (I have a 715/80 myself!).
But AFAIK there was no "snake", but many of the 700s were named after snakes, maybe you mean one of these: Bushmaster (710/50), Cobra (720/50), King Cobra (730/66), Coral (750), Coral II (755)...
(I wonder if the HP engineers were fans of Elite (the game))
> IBM does not ship Maxtors.
Not true.
At least in the past IBM did ship Maxtors:
I have a MXTS-540S from Maxtor with the IBM P/N 17G3180 printed on it and the text "MANUFACTURED FOR IBM COPRPORATION ARMONK, NY".
It identifies itself as "IBM, MXT-540SL".
The Challenger is a really *bad* example to show how dangerous Hydrogen can be. (BTW: Were was the large BLUE fire?)
Maybe you should have read the final analysis of the Challenger accident:
The hydrogen tank started to leak and burn ~64.6 seconds after liftoff because a flame from the right solid rocket booster burnt a hole into the external tank.
But did Challenger explode then? No.
The "explosive burn" started roughly 9 seconds later, when the liquid oxygen tank was hit by the solid booster.
(And hydrogen planes don't need oxygen tanks...)