Any suggestions for what I should do next to try and get Yahoo! to stop sending these unwanted messages?
Sue them in small claims court for a few hundred
dollars. They'll probably settle and pay you off, but if they keep sending you the unwanted messages, you can just keep suing them and collecting money from them.
IANAL, so I don't really know how well this will work.
The telemarketers sued over the recently created Colorado do-not-call list, too. They apparently don't even act in their own rational self interest! Surely it would be a benefit to them, saving them time and money, to be able to easily avoid calling people who they know will not buy the products or services they are selling.
Or do telemarketers get paid based on the number of calls made, without regard to the number of actual sales? I can't imagine any of their clients would be willing to pay on such a basis, but I guess stranger things have happened.
Who doesn't need physics to understand thins? Me? I beg to differ.
The reason you don't need to know physics to understand it is that it can be explained by simple geometry. If you have a 1W radiator (antenna) that is omnidirectional, only a small amount of power will be radiated in any given direction. So when the AP is communicating with a specific node, most of the power is wasted.
If you use a directional antenna, allmost the transmit power is sent in one direction, so if that's where the receiver is, the same 1W gets more power to where it's useful.
A phased-array antenna can be directional to an arbitrarily chosen direction, so what the Vivato AP does is readjust the phased-array direction for each client.
My microwave may 'put out' a kilowatt
As others have pointed out, it doesn't do that, but assuming it did...
but whats the apparent energy at 10m, 100m? I have a sneaky recollection that physics has some equations for that kind of shit!
The inverse square law. This was pretty obvious to me years before I took physics. Microwaves aren't doing anything unusual, just think about a light bulb. If you put a sheet of paper 1 foot from a light bulb, it will collect 4 times as much light as if you put the paper 2 feet from the light bulb.
In California it is illegal to use a recognizable image of a person as a target. Though I somewhat doubt that anyone's been hauled in for using Bin Laden targets. Anyhow, the same stupid law probably would cover dolls.
Our elected representatives often exempt themselves from various laws; it would be nice if they would exempt themselves from this one, so that we could use their images on targets.
Doesn't this point to a failure of the peer review process? Aren't the reviewers bothering to check whether the references are relevant, and for the ones that are, whether the paper actually interprets and builds on the prior work in a reasonable manner?
Didn't see the smiley, huh? It was a joke, based on the dictionary definition of geologist. I'm not actually so narrowminded as to believe that the dictionary definition is definitive and anything that contradicts it is wrong.
--
Make everything as simple as possible, but no simpler. -- Albert Einstein
As far as I can remember, democracy requires an active citizenry who understand the issues before them, who engage in public dialogue, and who excercise their political power by engaging in the decision-making process
That's desirable, but it is by no means necessary to the democratic process.
It most certainly is! At least in a capitalist economy. People vote with their wallets. If they don't want a new platform, they won't buy it.
If they think they can hold a niche, they should target that niche, instead of trying to be the all-singing all-dancing general purpose wonder platform, because that path is doomed to failure.
I guess my point is I don't really think a smooth hardware upgrade cycle is what keeps people locked to x86. If anything it's software.
It's both. People would be willing to change one or the other, or even both, if somehow they could continue doing what they're doing now, while getting better performance or new capabilities.
That's where new platforms almost always fall flat. You get something new, but you have to give up a LOT of the old.
I don't know about the veracity of the numbers, but I don't think there's any particular reason that they're suspect.
Russia was much more pragmatic in several ways about their space program. Once they had a working, reliable, man-rated launch vehicle and spacecraft, they stuck with it. They built other launch vehicles for heavy lift. They didn't try for the super-amazing do-everything all-in-one model made out of 102% pure unobtanium, the way NASA tries to do everything.
MorphOS/Pegasos is a brand new platform (the last full OS+HW platform released was 7 years ago with Be's BeBox)
And it's doomed to failure, just like Be, because people don't want another new, different, mostly incompatible platform. They want improved software for the platform they've already got, or improved hardware that's still compatible. Otherwise people would have ditched PCs and Windows many years ago.
People want a nice smooth migration path. It's even OK to have a major inovation once in a while, as long as it still works with their older stuff (and without a huge performance penalty, which is why IA64 is going nowhere fast).
IBM tried to do away with the ISA bus in 1987, by pushing their proprietary MCA bus as an all-or-nothing proposition. Despite its technical merit, it failed to take over any of the PC market. EISA, VESA local bus, and PCI were more successful because they were provided as a gradual shift. "Look, you can have some ISA slots AND some PCI slots." Of course, now ISA slots have almost vanished, but the transition period was eight years.
EISA and VESA LB died because although they also offered a gradual transition, PCI had more technical merit. So technical merit does count for something, but it's not sufficient to justify an overwhelming degree of incompatibility.
so it is very modern and it has support for 3D cards, USB, SMP
Yes, so modern that it does the same stuff as all the other OSes out there. Oh, except actually having any application software. And it won't support all the 3D cards and USB devices, just a few that they've written drivers for.
while it also features partial Amiga application binary compatibility!
Great, if I want to run a few old Amiga games, it can do that. Woo hoo, I'm so excited.
Pardon me if I don't rush right out to buy one. I think I'll stick to my dual Athlon box running Linux. It has support for 3D cards, USB, and SMP, and actually runs the applications I need.
you could produce your own hydrogen quite easily from electricity and water
The only reason it would make any sense to do that, and then to use the hydrogen in a fuel cell to produce electricity, is if you didn't have some more efficient way to store the energy, or you need it stored in a portable form.
In general it is MUCH more efficient to store energy by pumping water uphill, storing it as gravitational potential energy. There are many generating facilities that do this. They pump the water uphill at night, when there is excess generating capacity from other sources, and then do hydroelectric generation during the day to meet peak demands.
Which is, of course, why Serial ATA is spec'd for cable lengths up to 1M.
If I had to set up a server today, using plain 'ol parallel IDE drives on a plain 'ol IDE port, I'd stick Serial ATA adapters on everything and dump the parallel cables entirely.
The article is IBM-centric so there's no discussion of say the CDC Cyber series
Maybe that's because CDC's mainframe business is dead, while IBM's is still going strong?
I wonder if they still make card readers, too?
Nope. IBM dropped punched cards back in the
mid 1980s. There are still a few companies supporting the equipment. They still sell new
card readers (non IBM brands), but it's not clear whether any are still being manufactured; these could just be NOS (new old stock).
One of the last remaining uses of punched card technology was aperture cards, which had a hole to
which you affixed a piece of microfilm. This was used for engineering document control. But even that is obsolete these days, especially since most engineering documents now are created in machine-readable form.
You still haven't explained how refactoring enters into it at all. There's nothing wrong with refactoring, and it can improve 32-bit applications without needing a 64-bit CPU. But it is neither necessary nor sufficient to take advantage of a 64-bit CPU.
It makes a 64-bit CROSS COMPILE of the 32-bit applciation you had before.
Or you can compile natively on the 64-bit machine. It shouldn't make any difference.
It is true that some applications will break if you simply try to compile them on a 64-bit platform. This is because those applications violate the C standard, typically assuming that sizeof(int)==sizeof(void *). Applications that make such assumptions aren't necessarily portable to other 32-bit platforms, let alone 64-bit. If you write your application badly to start with, it's not a surprise if it's harder to port. But if you write it well, porting to Hammer (or IA64, or Alpha) should be a piece of cake.
You can refactor til the cows come home, but that won't by itself isn't going to help with porting a poorly written application.
Re:32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 2
The benefit will be higher performance, whether the user runs 64-bit apps or not, for the reasons I stated. It's a simple fact that the Hammer will offer higher performance on 32-bit applications than the 32-bit Athlon, because it's a newer design. AMD can't get as much performance improvement from simple process geometry scaling on the 32-bit part as they can from the redesigned core of the Hammer. This has nothing to do with the 64-bit-ness of the Hammer. If Moore's law was enough by itself, Intel wouldn't have had to make the Pentium IV; they would have just kept scaling the Pentium III (or II, or I, or the 486...). So that doesn't seem like a negligible benefit to me.
Also, "porting" and "refactoring" aren't necessary. Just recompile. All your 64-bit operations (e.g., operations on ISO C int64_t and uint64_t types) get faster. And you can access more per-process memory. That's really the point. There's nothing magic about 64-bit mode that requires you do do amazingly special stuff to take advantage of it.
If you were somehow expecting using 64-bit pointers to make your software (that fits OK in under 4G address space) run faster, think again.
If you're proposing some other sort of speedup from native 64-bit applications, you'll have to explain what you think is going to provide that.
"64bit" refers to the size of the instruction word, not "how much data the processor handles at once".
That's certainly not true in the x86 world. x86 instructions are variable length, and can be as short as one byte. Surely you wouldn't call the Pentium IV an 8-bit processor?
There is something else... a 64bit app may even be *slower* as the cache can only hold half the number of words, given an equal cache size.
In 64-bit mode, the only things that MUST be 64 bits wide are pointers. Instructions are generally the same size (or one byte longer). 64-bit code can still use 8-, 16-, and 32-bit data, so it doesn't force your data to be 64 bits wide unless you specifically want it. So in general I wouldn't expect too much of a degradation on cache hit performance on typical applications.
the big difference between AMD and IBM is that the new 64bit PPC970 doesn't take a performance hit switching between 32 and 64bit applications.
x86-64 doesn't appear to have any serious performance hit there either. I suspect this
was a design requirement for the architecture.
Re:32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 2
No real benefit will come until geniune 64-bit apps hit the consumer market.
Given that the Hammer will offer more 32-bit performance per dollar than the current Athlon parts (and, for that matter, Intel parts), I would say that there's at least some benefit even if there are NO 64-bit apps.
But the advantage of Hammer is that you don't need to migrate ALL of your apps to 64-bit to get a serious performance benefit. With the IA64, the performace of 32-bit applications is terrible, so it's a poor choice unless most of your software is 64-bit.
when you buy a radio do you get the schematics for how it was built and with what parts?
For many years you did. In the 1970s this stopped happening. So perhaps it's reasonable for software to come with source code for the first seventy years or so that the software industry exists. The software industry originated in the 1960s, so by this argument we should get source code until at least 2030.
Running a website costs the webmaster behind that site time and money. The only way to cover for that income is using banner ads and pop ups.
Strange, I was of the impression that there were
other business models that worked better than banner ads and popups. In fact, the majority of web sites that I use somehow have managed to stay in business for years despite NOT having banner ads and pop ups. I guess I should expect those sites to fold at any moment.
Slashdot Mirror
IANAL, so I don't really know how well this will work.
Or do telemarketers get paid based on the number of calls made, without regard to the number of actual sales? I can't imagine any of their clients would be willing to pay on such a basis, but I guess stranger things have happened.
If you use a directional antenna, allmost the transmit power is sent in one direction, so if that's where the receiver is, the same 1W gets more power to where it's useful.
A phased-array antenna can be directional to an arbitrarily chosen direction, so what the Vivato AP does is readjust the phased-array direction for each client.
As others have pointed out, it doesn't do that, but assuming it did... The inverse square law. This was pretty obvious to me years before I took physics. Microwaves aren't doing anything unusual, just think about a light bulb. If you put a sheet of paper 1 foot from a light bulb, it will collect 4 times as much light as if you put the paper 2 feet from the light bulb.Our elected representatives often exempt themselves from various laws; it would be nice if they would exempt themselves from this one, so that we could use their images on targets.
Doesn't this point to a failure of the peer review process? Aren't the reviewers bothering to check whether the references are relevant, and for the ones that are, whether the paper actually interprets and builds on the prior work in a reasonable manner?
--
Make everything as simple as possible, but no simpler. -- Albert Einstein
If they think they can hold a niche, they should target that niche, instead of trying to be the all-singing all-dancing general purpose wonder platform, because that path is doomed to failure.
That's where new platforms almost always fall flat. You get something new, but you have to give up a LOT of the old.
Russia was much more pragmatic in several ways about their space program. Once they had a working, reliable, man-rated launch vehicle and spacecraft, they stuck with it. They built other launch vehicles for heavy lift. They didn't try for the super-amazing do-everything all-in-one model made out of 102% pure unobtanium, the way NASA tries to do everything.
People want a nice smooth migration path. It's even OK to have a major inovation once in a while, as long as it still works with their older stuff (and without a huge performance penalty, which is why IA64 is going nowhere fast).
IBM tried to do away with the ISA bus in 1987, by pushing their proprietary MCA bus as an all-or-nothing proposition. Despite its technical merit, it failed to take over any of the PC market. EISA, VESA local bus, and PCI were more successful because they were provided as a gradual shift. "Look, you can have some ISA slots AND some PCI slots." Of course, now ISA slots have almost vanished, but the transition period was eight years.
EISA and VESA LB died because although they also offered a gradual transition, PCI had more technical merit. So technical merit does count for something, but it's not sufficient to justify an overwhelming degree of incompatibility.
Yes, so modern that it does the same stuff as all the other OSes out there. Oh, except actually having any application software. And it won't support all the 3D cards and USB devices, just a few that they've written drivers for. Great, if I want to run a few old Amiga games, it can do that. Woo hoo, I'm so excited.Pardon me if I don't rush right out to buy one. I think I'll stick to my dual Athlon box running Linux. It has support for 3D cards, USB, and SMP, and actually runs the applications I need.
In general it is MUCH more efficient to store energy by pumping water uphill, storing it as gravitational potential energy. There are many generating facilities that do this. They pump the water uphill at night, when there is excess generating capacity from other sources, and then do hydroelectric generation during the day to meet peak demands.
If I had to set up a server today, using plain 'ol parallel IDE drives on a plain 'ol IDE port, I'd stick Serial ATA adapters on everything and dump the parallel cables entirely.
One of the last remaining uses of punched card technology was aperture cards, which had a hole to which you affixed a piece of microfilm. This was used for engineering document control. But even that is obsolete these days, especially since most engineering documents now are created in machine-readable form.
It is true that some applications will break if you simply try to compile them on a 64-bit platform. This is because those applications violate the C standard, typically assuming that sizeof(int)==sizeof(void *). Applications that make such assumptions aren't necessarily portable to other 32-bit platforms, let alone 64-bit. If you write your application badly to start with, it's not a surprise if it's harder to port. But if you write it well, porting to Hammer (or IA64, or Alpha) should be a piece of cake.
You can refactor til the cows come home, but that won't by itself isn't going to help with porting a poorly written application.
Also, "porting" and "refactoring" aren't necessary. Just recompile. All your 64-bit operations (e.g., operations on ISO C int64_t and uint64_t types) get faster. And you can access more per-process memory. That's really the point. There's nothing magic about 64-bit mode that requires you do do amazingly special stuff to take advantage of it.
If you were somehow expecting using 64-bit pointers to make your software (that fits OK in under 4G address space) run faster, think again.
If you're proposing some other sort of speedup from native 64-bit applications, you'll have to explain what you think is going to provide that.
But the advantage of Hammer is that you don't need to migrate ALL of your apps to 64-bit to get a serious performance benefit. With the IA64, the performace of 32-bit applications is terrible, so it's a poor choice unless most of your software is 64-bit.