The trouble is that it is impossible for the surfer to know whether persistent cookies are used for gathering benign aggregate data or for more privacy intruding purposes.
The trouble is that the surfer can't be sure whether persistent cookies are used for benign aggregate statistics or for more privacy intrusive purposes.
So the prudent thing is to delete all cookies except for the few we know are benign.
Microsoft using open source code at the same time they are attempting to outlaw open source is hypocritical.
Not quite. Their UnAmerican Viral Communist Cancer spiel was directed at GPL and GPL only. MS never had any problem with software licenses that allows them to use the code in proprietary products - of which BSD is the most prominent.
And with regards to the BSD attribution requirement - I believe that requirement was removed in the '99 revision of the BSD license.
Microsoft also got caught doing this with a particular (early) version of Windows (was it 3.1?).
Sort of. IIRC, it was in a pre-release version which was distributed to betatesters and reviewers. If attempting to run on non PC/MS-DOS it would output a warning and exit.
The same code was also included in the release version of Win 3.1, but was disabled by a single bit flag. Leading some people to believe that MS had plans to silently flip the bit later (say, when installing MS Word) if DR-DOS became a serious threat.
Google for 'AARD Windows' for the full scoop, I believe Byte or DDJ had an in-depth article about it at the time.
So on any non-Intel CPU, the generic x86 code path will be chosen, but on Intel it will use the best supported (MMX/SSE/etc) code path.
So no specific test for AMD, but at the same time 'willful ignorance' of the x86 extensions supported by non-Intel CPUs. Definately not playing nice, and something that Intel compiler customers certainly are in their right to complain about. But I kind of doubt that it is illegal for Intel to do so, unless there is supporting evidence of Intel going beyond generic x86 in sabotaging AMD CPUs (e.g. generic x86 code especially crafted to run bad on AMD CPUs, smoking gun internal emails etc).
Being an AMD only customer for the last 5 years, I hope AMD has facts to back their claim.
Given that Intel and AMD are basically the only major players in the x86 CPU market, there seems to be no significant difference between detecting Intel vs non-Intel and detecting Intel vs AMD.
I'm not saying that it is very nice of the Intel compilers to generate binaries that only run MMX/SSE/etc code on Intel processors and falling back to generic x86 on everything else. The technically correct thing to do would be to check the capabilities flags and choose the code path most appropriate to the advertised capabilities of the CPU.
What I am saying is that I doubt that Intel has any obligation to check for the capabilities on non-Intel CPUs. AMD will obviously make the same point you are making, but I think they will fight an up-hill battle unless they can show that the code paths executed on AMD CPUs are deliberately pessimized (i.e., performs worse than reasonable generic x86 code).
But the compiler doesn't care whether a chip is capable or not, it just cares that it's Intel or not.
I think that's legitimate. It is an Intel optimizing compiler. I don't really see how they have an obligation to make the emitted code work optimally on an AMD processor.
However, deliberately pessimizing the code if an AMD is detected is something else.
That is, I think this is ok:
If (Intel) {
optimized_code(); } else
worksonanyprocessor_code();
But it seems like AMD claims that they do this:
If (Intel) {
optimized_code(); } else if (AMD) {
slow_code(); } else
worksonanyprocessor_code();
If price of cpu's were really such a big factor, AMD might have been alot more willing to offer discounts than Intel.
Don't forget that Intel is a one-stop-shop for the entire platform - CPU, motherboard chipset, motherboard reference design, etc. AMD can't deliver the entire package. I suspect that the Apple / Intel deal is for more than just the CPU alone. And not to forget XScale and the every-digital-format-under-the-sun portable player market that I'm sure Apple would like a piece of.
If by 'firewall' you mean a network device that only allows through traffic according to a set of rules, then a NAT is a firewall. The rules that a regular NAT implementation enforces is to only allow through TCP sessions and UDP pinholes initiated from the internal network.
I have not invited the slimy rip-off merchant to come in at the same time, push him out of the way and stand in front of me.
Yes, you have. If you don't want that 'slimy rip-off merchant' there don't install adware.
This case is whether adware on your computer can display competing ads when you surf.
How the adware got on your computer in the first place is a separate matter, and laws exist or are currently being drafted to make it illegal to sneak install adware (i.e. hidden deep in an EULA) on a computer.
But Windows got to be the prevalent OS BECAUSE of competition. MS earned it. It wasn't handed to them.
So far, so good.
Are you saying that in the US, you should be allowed to earn a set amount of money, and everything you make after that, you have to give up? If so, how is that determined, and whose job is it?
I don't see anyone in this thread saying that. Please elaborate.
That sends a message to business owners (such as myself) that says, "You can only be so successful, because after that point, we're taking it away from you".
Taking what away from whom? Taking away Intel's 'right' to use their dominant position to suspend market competition?
You'd need the source code to make that kind of statement with any certainty...or by doing the math or watching behaviour.
As in the AI enemy in a rts game producing more units than it should be able to, given the resources available.
Or for example you play a 4X genre game, where the technology level of the opponents are hidden from the player. Then, immediately after you make a technology breakthrough the AI hits you with 'give technology X or we declare war'. When this happens consistently, it is a certain indication of the AI having access to information that a normal player would not have.
From bridge perspective - yes. From device perspective - no. You can run a Sun HappyMeal on x86 and you can run an AMD lance designed for x86 on PPC. Once the bridge has been programmed the card is controlled in essentially the same way.
True, unless you want to boot from a device on the PCI bus. And you still need the proper driver for the bridge.
And I shall ignore them. Less then 10% market share.
Pretty much all modern x86 chipsets come with an integrated ethernet controller. That is more like 90% market share.
But yeah, ethernet isn't a large stumbling block if some of the popular chipsets used in PCI cards are supported.
Not entirely correct. You cannot run it in DMA mode
I thought that was only the case for IDE controllers. IDE is rapidly being phased out by SATA/SATA2 on modern motherboards. And PIO mode is dead slow. It works, just like default VGA works, but it is not much use except for getting the system installed and running so that you can install proper drivers.
They are already there. Darwin boots on x86 and if necessary can suck them out of the FreeBSD tree.
I thought OSX used a different driver model than FreeBSD. I've been trying to find a list of motherboard chipsets supported by the latest Darwin/x86, but came up empty. Could you give me some URLs please?
Apple tried that before, and the clonemakers quickly abandoned the specifications in order to use cheaper, less compatible parts
That sounds interesting. I didn't follow the Apple clone history closely, and just assumed that they killed the Macinclones because they made less money on OS licensing than they made on OS+HW. Any references would be greatly appreciated.
Slashdot Mirror
Does that still make me evil?
The trouble is that it is impossible for the surfer to know whether persistent cookies are used for gathering benign aggregate data or for more privacy intruding purposes.
So the prudent thing is to delete all cookies.
Does that still make me evil?
The trouble is that the surfer can't be sure whether persistent cookies are used for benign aggregate statistics or for more privacy intrusive purposes.
So the prudent thing is to delete all cookies except for the few we know are benign.
A couple of references to studies would be great. And get one of those stress balls.
Microsoft using open source code at the same time they are attempting to outlaw open source is hypocritical.
Not quite. Their UnAmerican Viral Communist Cancer spiel was directed at GPL and GPL only. MS never had any problem with software licenses that allows them to use the code in proprietary products - of which BSD is the most prominent.
And with regards to the BSD attribution requirement - I believe that requirement was removed in the '99 revision of the BSD license.
Microsoft also got caught doing this with a particular (early) version of Windows (was it 3.1?).
Sort of. IIRC, it was in a pre-release version which was distributed to betatesters and reviewers. If attempting to run on non PC/MS-DOS it would output a warning and exit.
The same code was also included in the release version of Win 3.1, but was disabled by a single bit flag. Leading some people to believe that MS had plans to silently flip the bit later (say, when installing MS Word) if DR-DOS became a serious threat.
Google for 'AARD Windows' for the full scoop, I believe Byte or DDJ had an in-depth article about it at the time.
but if they sold their product as simply a vanilla x86 compiler, then they've got shit to be responsible for
If so, the compiler customers might have something to sue about. Whether it is illegal under antitrust is a different question.
If the comments and links I've read are correct, the check is like this:
If (GenuineIntel)
{ supported_extentions = Check_CPU_Capabilities();
Run_optimised_code(supported_extentions);
}
else
{ Run_generic_x86_code(); }
So on any non-Intel CPU, the generic x86 code path will be chosen, but on Intel it will use the best supported (MMX/SSE/etc) code path.
So no specific test for AMD, but at the same time 'willful ignorance' of the x86 extensions supported by non-Intel CPUs. Definately not playing nice, and something that Intel compiler customers certainly are in their right to complain about. But I kind of doubt that it is illegal for Intel to do so, unless there is supporting evidence of Intel going beyond generic x86 in sabotaging AMD CPUs (e.g. generic x86 code especially crafted to run bad on AMD CPUs, smoking gun internal emails etc).
Being an AMD only customer for the last 5 years, I hope AMD has facts to back their claim.
Given that Intel and AMD are basically the only major players in the x86 CPU market, there seems to be no significant difference between detecting Intel vs non-Intel and detecting Intel vs AMD.
I'm not saying that it is very nice of the Intel compilers to generate binaries that only run MMX/SSE/etc code on Intel processors and falling back to generic x86 on everything else. The technically correct thing to do would be to check the capabilities flags and choose the code path most appropriate to the advertised capabilities of the CPU.
What I am saying is that I doubt that Intel has any obligation to check for the capabilities on non-Intel CPUs. AMD will obviously make the same point you are making, but I think they will fight an up-hill battle unless they can show that the code paths executed on AMD CPUs are deliberately pessimized (i.e., performs worse than reasonable generic x86 code).
But the compiler doesn't care whether a chip is capable or not, it just cares that it's Intel or not.
I think that's legitimate. It is an Intel optimizing compiler. I don't really see how they have an obligation to make the emitted code work optimally on an AMD processor.
However, deliberately pessimizing the code if an AMD is detected is something else.
That is, I think this is ok:
If (Intel) {
optimized_code();
} else
worksonanyprocessor_code();
But it seems like AMD claims that they do this:
If (Intel) {
optimized_code();
} else if (AMD) {
slow_code();
} else
worksonanyprocessor_code();
IBM thought it was big enough to set the trend by making a radical change with Micro Channel Architecture
Intel tried to set a new standard but flopped bad on the first iteration of the implementation.
On the other hand, MCA was excellent tech but was killed by IBM trying to use it as leverage for regaining control of the clone market.
If price of cpu's were really such a big factor, AMD might have been alot more willing to offer discounts than Intel.
Don't forget that Intel is a one-stop-shop for the entire platform - CPU, motherboard chipset, motherboard reference design, etc. AMD can't deliver the entire package. I suspect that the Apple / Intel deal is for more than just the CPU alone. And not to forget XScale and the every-digital-format-under-the-sun portable player market that I'm sure Apple would like a piece of.
If by 'firewall' you mean a network device that only allows through traffic according to a set of rules, then a NAT is a firewall. The rules that a regular NAT implementation enforces is to only allow through TCP sessions and UDP pinholes initiated from the internal network.
I have not invited the slimy rip-off merchant to come in at the same time, push him out of the way and stand in front of me.
Yes, you have. If you don't want that 'slimy rip-off merchant' there don't install adware.
This case is whether adware on your computer can display competing ads when you surf.
How the adware got on your computer in the first place is a separate matter, and laws exist or are currently being drafted to make it illegal to sneak install adware (i.e. hidden deep in an EULA) on a computer.
It's a good thing they didn't send him to Guantanamo, or this country would be in more trouble than Hollywood.
;-)
Yeah. It'd be hell on you if we'd have to send norwegian marinejegere over there to bring him back home.
But Windows got to be the prevalent OS BECAUSE of competition. MS earned it. It wasn't handed to them.
So far, so good.
Are you saying that in the US, you should be allowed to earn a set amount of money, and everything you make after that, you have to give up? If so, how is that determined, and whose job is it?
I don't see anyone in this thread saying that. Please elaborate.
That sends a message to business owners (such as myself) that says, "You can only be so successful, because after that point, we're taking it away from you".
Taking what away from whom? Taking away Intel's 'right' to use their dominant position to suspend market competition?
You know, just because something is legal or illegal doesn't necessarily make it right or wrong.
What, in your opinion, is right with Intel twisting the arms of OEMs?
You'd need the source code to make that kind of statement with any certainty. ..or by doing the math or watching behaviour.
As in the AI enemy in a rts game producing more units than it should be able to, given the resources available.
Or for example you play a 4X genre game, where the technology level of the opponents are hidden from the player. Then, immediately after you make a technology breakthrough the AI hits you with 'give technology X or we declare war'. When this happens consistently, it is a certain indication of the AI having access to information that a normal player would not have.
Two is more than one! Even if the two cores are lower clock speeds.
Singlethreaded performance.
You are in a maze of mailinglists.
> search
No search function is available.
Has that list been maintained at all?
While it lists supported motherboards, it does not show whether all on-board devices work or not.
It also does not show whether gfx chips have full 3D support, only accelerated 2D support or just basic VESA 2.0 support.
Not to mention no list of WiFi, USB, SCSI and a lot of other devices.
I believe that the common configurations most of have are already or could easily supported under Darwin.
The latest Darwin x86 won't even install in VMWare.
From bridge perspective - yes. From device perspective - no. You can run a Sun HappyMeal on x86 and you can run an AMD lance designed for x86 on PPC. Once the bridge has been programmed the card is controlled in essentially the same way.
True, unless you want to boot from a device on the PCI bus. And you still need the proper driver for the bridge.
And I shall ignore them. Less then 10% market share.
Pretty much all modern x86 chipsets come with an integrated ethernet controller. That is more like 90% market share.
But yeah, ethernet isn't a large stumbling block if some of the popular chipsets used in PCI cards are supported.
Not entirely correct. You cannot run it in DMA mode
I thought that was only the case for IDE controllers. IDE is rapidly being phased out by SATA/SATA2 on modern motherboards. And PIO mode is dead slow. It works, just like default VGA works, but it is not much use except for getting the system installed and running so that you can install proper drivers.
They are already there. Darwin boots on x86 and if necessary can suck them out of the FreeBSD tree.
I thought OSX used a different driver model than FreeBSD. I've been trying to find a list of motherboard chipsets supported by the latest Darwin/x86, but came up empty. Could you give me some URLs please?
Yes but the Darwin drivers would.
Is there an updated HCL available? The only one I could find was ancient, and listed only the 440BX chipset as supported.
What drivers are you talking about?
Motherboard chipset drivers is the big one.
Sound chip drivers, not everyone does AC97.
PCI is PCI regardless of the platform.
Right. Go look in the Linux kernel for all the tweaks required for all the different PCI bridges. And then you have PCI-E and PCI-X.
There are around 3 network card manufacturers left
If you ignore the Marvell Yukon in my computer, all the various on-chipset ethernet cores and companies like Syskonnect.
IDE is IDE regardless of the platform
You can not run a SiI 3114 with a PIIX IV driver. There is no driver-level compatibility standard for IDE/SATA/SATA2 controllers.
SCSI support is already there
You can not run an Adaptec SCSI controller with a Tekram driver. There is no driver-level compatibility standard for SCSI controllers.
USB is also already there
Ah, finally. With proper UHCI, EHCI and OHCI drivers USB chips should work fine. You might need device-specific drivers, though.
All it takes is to port drivers for the SAME hardware from existing Macs.
Motherboard chipset drivers!
Apple tried that before, and the clonemakers quickly abandoned the specifications in order to use cheaper, less compatible parts
That sounds interesting. I didn't follow the Apple clone history closely, and just assumed that they killed the Macinclones because they made less money on OS licensing than they made on OS+HW. Any references would be greatly appreciated.