As others have already mentioned, dual-core Atom processors have been out for 2 years, so a dual-core Atom is nothing new.
As regards the support of DDR3 memory, it's unlikely to make any measurable performance difference over DDR2 given the relatively anaemic CPU performance of the Atom. The reason is far more prosaic. DDR3 is now cheaper than DDR2 and that trend will continue so Intel are doing the right thing in moving the chipset support over to the less expensive memory. In a budget platform anything else would be foolish.
Nothing like enough. I want a cast-iron guarantee that they will never, ever delete anything from my Kindle under any circumstances. They have absolutely no right to do so, and in fact, I'd go so far as to say I want them to remove any such capability. As has been pointed out endlessly, if I bought a physical book from them, they cannot do anything to it once it is in my possession. There shouldn't be any difference just because it's an eBook.
Yes, they are. You don't pay anything to download Google Earth, iTunes or Adobe Reader. Free as in beer. Note that that is why he did not say they were "open source". A belief that all software should be free as in open source does not invalidate the use of the term "free" for something that you didn't pay for but to which you do not receive access to the source. Unless your name is Richard Stallman that is:-P
As mentioned many times already, this has nothing to do with the iPhone and everything to do with GSM.
However, it seems AT&T are much worse. My personal phone is on T-Mobile and my work phone is on AT&T. The work phone produces much more interference. Switching the SIM from that into my phone, I get the same issue. I think AT&T must bump the transmit power to maximum on devices connected to their network. I wonder what this does to battery life!
"Or, maybe x86 will just get a lot more power-efficient."
Umm, have you heard of the Intel Atom? The biggest mill wheel around the neck of that processor is that there is no power-efficient chipset for the laptop/desktop-class processors (the 945 chipset is an absolute dog in terms of power consumption). The processors targetted at the netbook/mobile market have a very good support chipset by contrast.
For reference, the N270 has a TDP of 2W which is pretty power-efficient in my book:-)
Please be careful not to conflate the 32-bit Windows 2GB dump limit with not being able to get a crash dump on said systems. You cannot get a *complete* crash dump, but as TFA correctly states, these are hardly ever necessary. A kernel-only dump (which is not a mini-dump) is almost always sufficient. And these won't be >2GB on 32-bit Windows.
On 64-bit versions of Windows, it isn't an issue anyway (apart from having to tweak the registry if you actually want a complete dump).
Fundamentally, any time you lose power, you WILL lose some data that is cached. Period. The important part is not whether or not you lose data, but whether you KNOW what got written and what didn't. That's whole point of transactions.
Filesystem journals are (mostly) concerned with metadata integrity/consistency (ZFS is somewhat exceptional in this area). Unless you do full-data journalling (and the performance penalty means you don't want to), it is up to the application to implement transactional behaviour. This is a key feature of databases.
Part 2, ram can fail (refresh) before hard drive stops doing DMA. Frankly, I don't believe it. Data gets DMA'd to buffers on the drive. That's the cheap (powerwise) part. Moving the heads around and writing the data is the expensive bit. The drive is not going to tell you it has written something unless it has done so and modern drives won't try to write unless they have enough power to do so.
Part 3, you can lose cached data. Clue. The same problem happens if the drive dies or starts erroring out. If you don't do synchronous writes, you (the app) are responsible for checking to see that the writes actually got committed.
Part 3.2. This has NOTHING to do with bit flipping. The Gentoo Wiki is talking about enabling write-cacheing on the drives. This is incredibly dangerous (fatal) without a UPS. Basically, enabling write-cacheing on the drive allows the drive to say "yes this is committed to stable store" when it isn't, and if the cache is not protected, all bets are off. True, it's much more practical to do hard-luck recovery of unencrypted data in this case, but fundamentally, this is a no-no. A lot of RAID controllers offer writeback cacheing and most are smart enough to disallow this unless the cache is battery-backed.
Part 3.3 RAID. RAID 0 isn't worse than a single disk. RAID 1 potentially requires a full resync, but is recoverable. Similar rules for other RAID levels. This is all known/handled.
Part 3.4. VERY WRONG. All I can say is read up on ACID. Postgresql is fully ACID (http://en.wikipedia.org/wiki/ACID) compliant, as are most/any databases worthy of the name these days.
I won't argue that power failures are healthy or desirable. Hardware stress and failure are the most obvious issues here, but most of the "issues" brought up in the article are simply incorrect. Of course, there are an unbelievably large number of "applications"/programs out there that don't implement the necessary journalling/transactions to correctly deal with power outages/crashes etc. But that's another story. Badly-written applications are as old as the computer.
Actually, much to my surprise, on re-reading GPL v2, it's not. It is exactly correct. Here's the relevant verbiage:
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do ONE of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
I have emphasized the "ONE". So, if you meet the terms of a) and distribute COMPLETE machine-readable source code with your binary distribution, you meet the terms of the license and have no obligation to provide the source code to anyone else. HOWEVER, everyone who receives the code from you receives it licensed under the GPL is completely free to pass it on.
... and people who ran into all sorts of nasty incompatibilities in the more scary corner-areas of the spec (isochronous transfers, etc.). Microsoft remember this fun which is why they are not happy about this. I remember various issues with USB depending on whether you had and OHCI or UHCI controller.
It is not in the interests of the consumer nor of the standard to have multiple host-controller interfaces. You may care to muse on why it might be in Intel's interests to the detriment of all others.
Sorry, but that simply is not the case. The "Core brand did not use the new "Core 2" microarchitecture. The Core 2 microarchitecture *is* significantly different to the Pentium-M/Yonah microarchitecture. Intel marketing were total dickheads to label the warmed-over Pentium-M as "Core". If they had avoided doing so, we could have had a "Core" brand with the "Core microarchitecture" and avoided all of this confusion.
Core 2 was designed from the ground up (i.e. it isn't an updated Yonah/P-M), and incorporates ideas from both the Pentium-M design and the ill-fated Netburst architecture. The Core 2 execution unit is 4 issues wide unlike both Yonah/Netburst that were 3-issue cores. Core 2 is 64-bit across the board. It does single-cycle 128-bit SSE instructions. It has "macro-ops fusion" (the clever trick that combines a lot of "compare and jump" x86 instruction pairs into a single micro-op. It does memory-disambiguation to allow much more aggressive memory access reordering, etc. etc. Yes, it is logically a progression in the P6 family, but it was a very big jump architecturally. Ho hum.
Interesting. I am not convinced that I agree, but if you really don't care about performance much, then it's not a completely silly idea:
"GCC has a habit of dropping architectures because 'nobody uses them,' which causes some OpenBSD (and NetBSD) ports to remain stuck with old versions of GCC." - it does nothing of the sort. If you really care about them, step up to the plate and support them in gcc. If the gcc people won't take your changes, you can maintain them separately. Nobody is obligated to support architecture X just because you happen to care about it. You'd end up having to support it in PCC too. Besides, why do you care if it's an older version of gcc? What is so important about a newer version, if what you have works?
"The x86 backend for PCC was written in three weeks by one person, so it seems reasonable to assume it should be possible to add support for the other required platforms relatively easily." - It's really fairly easy to do a dumb, "poorly"-optimized backend. Several questions spring to mind. How well-tested/bug-free is said backend? How well does it perform? Why do you think it's so easy to add other backends? Again if they're really dumb and inefficient, it is very easy. Where things get hard and ugly and complicated is trying to do a really good job of optimization, especially for such a PITA architecture as ia32 and the also support other radically different architectures. If you don't give a crap about performance, then actually, it does make sense to go with a much simpler compiler. It's much easier to prove it is correct, to maintain it, etc.
They weren't caused by "catholics and protestants". They were caused by gangsters and thugs. Check out the reality. Punishments beatings, protection rackets,... Just because it was done in the name of religion doesn't mean that it's true. It was a convenient excuse.
What's disappointing is the church's relative silence on this. Both protestant and catholic faiths *should* have denounced the violence absolutely, clearly stated that these people were not Christians, and, in the case of the Catholics, excommunicated them.
People have been perverting religions for their own ends as long as religions have existed.
Precisely. I doubt that it has anything to do with the iPhone. AT&T has a track record of crippling phones that's almost as bad as Verizon's. If you want a perfect example compare the (crippled) Nokia E62 from Cingular, now AT&T, to the original version of the phone, the E61. Ooh look, no 3G, no Wifi, no SIP client. The only good thing they did was ditch the crappy proprietary Nokia connector and put a mini-usb connector on instead.
So, I have an E61 and am using it with T-Mobile (just swapped my SIM). There's even some chance the T-Mobile may get to use the "normal" UMTS/HSPDA frequencies and that my phone's 3G may actually work when they roll it out - it worked fine in Germany last month:-)
"My biggest question is why the PS3 is not significantly better than the 360, especially given the year's lead time?"
Because they held up delivery and screwed themselves over by sacrificing themselves on the altar of the entertainment division (a common theme at Sony, sigh). If they had said "to hell with Blu-Ray" and just aimed to get a games machine out there, they would have had it to market much earlier. But therein lies the tragedy of the PS3. They wanted everything. They wanted it to be the trojan horse to force their version of hi-def DRM-laden crap down your throat (as opposed to the other hi-def DRM-laden crap), and forgot that first and foremost, it's *still* supposed to be a games console.
To anyone still unable to understand why Nintendo are cleaning up, I give you the one simple word - "FUN". It may not be high-tech, it may not be , but it is FUN! Something the other console makers seem to have forgotten. Ho hum.
"They also know enough about 64-bit Windows to know that precious little software actually runs on 64-bit Windows, simply because it's not a consumer operating system. It's designed basically as a database server OS."
Ummm... you are joking, right??? I have XP x64 installed on one of my machines at home, and actually, there is precious little that does NOT run on it. The places where you will run into issues are a) No 16-bit support (Thank G*d). They killed NTVDM.EXE. Good thing too. b) Driver support. The breadth and maturity of driver support 64-bit is seriously lacking.
However, neither of the above apply to the vast majority of software out there. Whether it's PhotoShop, iTunes, games, etc. etc. etc. they all work just fine on the 64-bit version of the OS. If you had said "precious little hardware", that might have been closer to the truth.
Win XP pro x64 wasn't designed as a database server OS any more or less than XP was. 32-bit and 64-bit XP and Server share a common code base - the kernel is mostly the same.
As has been pointed out elsewhere, retail versions of Vista support 64-bit and 32-bit installs. If you have modern hardware, it's inconceivable to me that you wouldn't install 64-bit, so I am frankly very surprised that Apple didn't provide 64-bit support. Seems really stupid to me, but whatever.
Ummm, clue for you. People working in the US on a visa also get to pay taxes. And that is one reason why it's damned sight better for you that they are here working, instead of the jobs being outsourced to another country. In the latter case, the employees are not contributing one cent to your economy. Not that I think the above in anyway makes what these people were doing right. But I'd much rather have people coming to work in the US, than the jobs being offshored, and believe me, with our oh-so caring corporations and the requirements to "maximize shareholder value", you can be pretty sure it's going to be one or the other for anything except service industries that require someone to be physically present.
If you think the country should be giving priority for employment to its citizens, I suggest you take that up with the politicians. Given the level of corporate bribes^H^H^H^H^H^Hcampaign contributions these days, good luck with that.
Umm... the very link you quote above contains: "But I do know that we are paying for the hosting of the site, and helped Andrew with a bunch of things including legal advice, etc.", "We provide him free hosting and bandwidth.".
In what way, precisely, is this not contributing anything back to the community??
Sheesh, this is about as well-thought out as the no-fly list "algorithm". Well, Abdul looks a bit like Andrew so you're a suspect, eh?
If they didn't watermark, or put some other individual identifying marks in each of the CTPs handed out, then they have no clue who leaked it, and punishing the innocent is not going to improve their chances.
Exactly. The trick as I recall is dealing with the noise levels. Canon have been doing this for a long time, so it is amusing to see the "analysts" quote. Not that it surprises me. It seems that very few analysts live up to their name, i.e. actually do analysis.
Reminds me of the quote from "Scandal"
on
The PC Is Not Dead
·
· Score: 1
Mod parent up please. Yes, "Graffiti Anywhere" is your friend. The ROMs have Graffiti support built in but it's not enabled by default. I also disagree with this design decision - should have been an option, but GA makes the point moot. Check out "Treo Butler" too. I still love my 600:-)
This has come up numerous times before on lkml and been debated to death. Search the archives if you want to see the arguments. Executive summary is, it isn't going to happen. If you're into kernel-hacking, or just following the latest updates, I would hope that you already have 2.6.7, in which case the patch is not particularly large. There's no need to download the whole thing every time.
You are entirely correct. Simple FP (i.e. non-SSE etc.) code generally runs quite a bit faster on the AMD chips. Intel actually weakened the FP in the P4 compared to the P3 (things like FXCH no longer being a freebee) to give more space to devote to Screaming Cindy's Extensions (SSE/SSE2/SSE3). This doesn't look to be that much different.
As has been pointed out elsewhere, the L2 cache size probably made a large difference on a lot of these "benchmarks". Several of them stand to gain a lot by having 1M instead of 512K.
As everybody else said, a pity they didn't compare to an Opteron so we could see the results of two comparable chips.
You're quite correct. That is indeed their argument. By virtue of it, they also own Veritas' vxfs filesystem because that was included in OpenServer as I recall. Ho hum...
Slashdot Mirror
As others have already mentioned, dual-core Atom processors have been out for 2 years, so a dual-core Atom is nothing new.
As regards the support of DDR3 memory, it's unlikely to make any measurable performance difference over DDR2 given the relatively anaemic CPU performance of the Atom. The reason is far more prosaic. DDR3 is now cheaper than DDR2 and that trend will continue so Intel are doing the right thing in moving the chipset support over to the less expensive memory. In a budget platform anything else would be foolish.
Nothing like enough. I want a cast-iron guarantee that they will never, ever delete anything from my Kindle under any circumstances. They have absolutely no right to do so, and in fact, I'd go so far as to say I want them to remove any such capability. As has been pointed out endlessly, if I bought a physical book from them, they cannot do anything to it once it is in my possession. There shouldn't be any difference just because it's an eBook.
Yes, they are. You don't pay anything to download Google Earth, iTunes or Adobe Reader. Free as in beer. Note that that is why he did not say they were "open source". A belief that all software should be free as in open source does not invalidate the use of the term "free" for something that you didn't pay for but to which you do not receive access to the source. Unless your name is Richard Stallman that is :-P
As mentioned many times already, this has nothing to do with the iPhone and everything to do with GSM.
However, it seems AT&T are much worse. My personal phone is on T-Mobile and my work phone is on AT&T. The work phone produces much more interference. Switching the SIM from that into my phone, I get the same issue. I think AT&T must bump the transmit power to maximum on devices connected to their network. I wonder what this does to battery life!
"Or, maybe x86 will just get a lot more power-efficient."
Umm, have you heard of the Intel Atom? The biggest mill wheel around the neck of that processor is that there is no power-efficient chipset for the laptop/desktop-class processors (the 945 chipset is an absolute dog in terms of power consumption). The processors targetted at the netbook/mobile market have a very good support chipset by contrast.
For reference, the N270 has a TDP of 2W which is pretty power-efficient in my book :-)
Please be careful not to conflate the 32-bit Windows 2GB dump limit with not being able to get a crash dump on said systems. You cannot get a *complete* crash dump, but as TFA correctly states, these are hardly ever necessary. A kernel-only dump (which is not a mini-dump) is almost always sufficient. And these won't be >2GB on 32-bit Windows.
On 64-bit versions of Windows, it isn't an issue anyway (apart from having to tweak the registry if you actually want a complete dump).
Fundamentally, any time you lose power, you WILL lose some data that is cached. Period. The important part is not whether or not you lose data, but whether you KNOW what got written and what didn't. That's whole point of transactions.
Filesystem journals are (mostly) concerned with metadata integrity/consistency (ZFS is somewhat exceptional in this area). Unless you do full-data journalling (and the performance penalty means you don't want to), it is up to the application to implement transactional behaviour. This is a key feature of databases.
Part 2, ram can fail (refresh) before hard drive stops doing DMA. Frankly, I don't believe it. Data gets DMA'd to buffers on the drive. That's the cheap (powerwise) part. Moving the heads around and writing the data is the expensive bit. The drive is not going to tell you it has written something unless it has done so and modern drives won't try to write unless they have enough power to do so.
Part 3, you can lose cached data. Clue. The same problem happens if the drive dies or starts erroring out. If you don't do synchronous writes, you (the app) are responsible for checking to see that the writes actually got committed.
Part 3.2. This has NOTHING to do with bit flipping. The Gentoo Wiki is talking about enabling write-cacheing on the drives. This is incredibly dangerous (fatal) without a UPS. Basically, enabling write-cacheing on the drive allows the drive to say "yes this is committed to stable store" when it isn't, and if the cache is not protected, all bets are off. True, it's much more practical to do hard-luck recovery of unencrypted data in this case, but fundamentally, this is a no-no. A lot of RAID controllers offer writeback cacheing and most are smart enough to disallow this unless the cache is battery-backed.
Part 3.3 RAID. RAID 0 isn't worse than a single disk. RAID 1 potentially requires a full resync, but is recoverable. Similar rules for other RAID levels. This is all known/handled.
Part 3.4. VERY WRONG. All I can say is read up on ACID. Postgresql is fully ACID (http://en.wikipedia.org/wiki/ACID) compliant, as are most/any databases worthy of the name these days.
I won't argue that power failures are healthy or desirable. Hardware stress and failure are the most obvious issues here, but most of the "issues" brought up in the article are simply incorrect. Of course, there are an unbelievably large number of "applications"/programs out there that don't implement the necessary journalling/transactions to correctly deal with power outages/crashes etc. But that's another story. Badly-written applications are as old as the computer.
Actually, much to my surprise, on re-reading GPL v2, it's not. It is exactly correct. Here's the relevant verbiage:
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do ONE of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
I have emphasized the "ONE". So, if you meet the terms of a) and distribute COMPLETE machine-readable source code with your binary distribution, you meet the terms of the license and have no obligation to provide the source code to anyone else. HOWEVER, everyone who receives the code from you receives it licensed under the GPL is completely free to pass it on.
... and people who ran into all sorts of nasty incompatibilities in the more scary corner-areas of the spec (isochronous transfers, etc.). Microsoft remember this fun which is why they are not happy about this. I remember various issues with USB depending on whether you had and OHCI or UHCI controller.
It is not in the interests of the consumer nor of the standard to have multiple host-controller interfaces. You may care to muse on why it might be in Intel's interests to the detriment of all others.
Sorry, but that simply is not the case. The "Core brand did not use the new "Core 2" microarchitecture. The Core 2 microarchitecture *is* significantly different to the Pentium-M/Yonah microarchitecture. Intel marketing were total dickheads to label the warmed-over Pentium-M as "Core". If they had avoided doing so, we could have had a "Core" brand with the "Core microarchitecture" and avoided all of this confusion.
Core 2 was designed from the ground up (i.e. it isn't an updated Yonah/P-M), and incorporates ideas from both the Pentium-M design and the ill-fated Netburst architecture. The Core 2 execution unit is 4 issues wide unlike both Yonah/Netburst that were 3-issue cores. Core 2 is 64-bit across the board. It does single-cycle 128-bit SSE instructions. It has "macro-ops fusion" (the clever trick that combines a lot of "compare and jump" x86 instruction pairs into a single micro-op. It does memory-disambiguation to allow much more aggressive memory access reordering, etc. etc. Yes, it is logically a progression in the P6 family, but it was a very big jump architecturally. Ho hum.
Interesting. I am not convinced that I agree, but if you really don't care about performance much, then it's not a completely silly idea:
"GCC has a habit of dropping architectures because 'nobody uses them,' which causes some OpenBSD (and NetBSD) ports to remain stuck with old versions of GCC." - it does nothing of the sort. If you really care about them, step up to the plate and support them in gcc. If the gcc people won't take your changes, you can maintain them separately. Nobody is obligated to support architecture X just because you happen to care about it. You'd end up having to support it in PCC too. Besides, why do you care if it's an older version of gcc? What is so important about a newer version, if what you have works?
"The x86 backend for PCC was written in three weeks by one person, so it seems reasonable to assume it should be possible to add support for the other required platforms relatively easily." - It's really fairly easy to do a dumb, "poorly"-optimized backend. Several questions spring to mind. How well-tested/bug-free is said backend? How well does it perform? Why do you think it's so easy to add other backends? Again if they're really dumb and inefficient, it is very easy. Where things get hard and ugly and complicated is trying to do a really good job of optimization, especially for such a PITA architecture as ia32 and the also support other radically different architectures. If you don't give a crap about performance, then actually, it does make sense to go with a much simpler compiler. It's much easier to prove it is correct, to maintain it, etc.
... or, for $4.99 more per cpu, you could use the 3GHz Athlon 64 X2 6000+. That ought to have a positive effect on the performance numbers :-)
They weren't caused by "catholics and protestants". They were caused by gangsters and thugs. Check out the reality. Punishments beatings, protection rackets, ... Just because it was done in the name of religion doesn't mean that it's true. It was a convenient excuse.
What's disappointing is the church's relative silence on this. Both protestant and catholic faiths *should* have denounced the violence absolutely, clearly stated that these people were not Christians, and, in the case of the Catholics, excommunicated them.
People have been perverting religions for their own ends as long as religions have existed.
Precisely. I doubt that it has anything to do with the iPhone. AT&T has a track record of crippling phones that's almost as bad as Verizon's. If you want a perfect example compare the (crippled) Nokia E62 from Cingular, now AT&T, to the original version of the phone, the E61. Ooh look, no 3G, no Wifi, no SIP client. The only good thing they did was ditch the crappy proprietary Nokia connector and put a mini-usb connector on instead.
:-)
So, I have an E61 and am using it with T-Mobile (just swapped my SIM). There's even some chance the T-Mobile may get to use the "normal" UMTS/HSPDA frequencies and that my phone's 3G may actually work when they roll it out - it worked fine in Germany last month
"My biggest question is why the PS3 is not significantly better than the 360, especially given the year's lead time?"
Because they held up delivery and screwed themselves over by sacrificing themselves on the altar of the entertainment division (a common theme at Sony, sigh). If they had said "to hell with Blu-Ray" and just aimed to get a games machine out there, they would have had it to market much earlier. But therein lies the tragedy of the PS3. They wanted everything. They wanted it to be the trojan horse to force their version of hi-def DRM-laden crap down your throat (as opposed to the other hi-def DRM-laden crap), and forgot that first and foremost, it's *still* supposed to be a games console.
To anyone still unable to understand why Nintendo are cleaning up, I give you the one simple word - "FUN". It may not be high-tech, it may not be , but it is FUN! Something the other console makers seem to have forgotten. Ho hum.
"They also know enough about 64-bit Windows to know that precious little software actually runs on 64-bit Windows, simply because it's not a consumer operating system. It's designed basically as a database server OS."
Ummm... you are joking, right??? I have XP x64 installed on one of my machines at home, and actually, there is precious little that does NOT run on it. The places where you will run into issues are
a) No 16-bit support (Thank G*d). They killed NTVDM.EXE. Good thing too.
b) Driver support. The breadth and maturity of driver support 64-bit is seriously lacking.
However, neither of the above apply to the vast majority of software out there. Whether it's PhotoShop, iTunes, games, etc. etc. etc. they all work just fine on the 64-bit version of the OS. If you had said "precious little hardware", that might have been closer to the truth.
Win XP pro x64 wasn't designed as a database server OS any more or less than XP was. 32-bit and 64-bit XP and Server share a common code base - the kernel is mostly the same.
As has been pointed out elsewhere, retail versions of Vista support 64-bit and 32-bit installs. If you have modern hardware, it's inconceivable to me that you wouldn't install 64-bit, so I am frankly very surprised that Apple didn't provide 64-bit support. Seems really stupid to me, but whatever.
Ummm, clue for you. People working in the US on a visa also get to pay taxes. And that is one reason why it's damned sight better for you that they are here working, instead of the jobs being outsourced to another country. In the latter case, the employees are not contributing one cent to your economy. Not that I think the above in anyway makes what these people were doing right. But I'd much rather have people coming to work in the US, than the jobs being offshored, and believe me, with our oh-so caring corporations and the requirements to "maximize shareholder value", you can be pretty sure it's going to be one or the other for anything except service industries that require someone to be physically present.
If you think the country should be giving priority for employment to its citizens, I suggest you take that up with the politicians. Given the level of corporate bribes^H^H^H^H^H^Hcampaign contributions these days, good luck with that.
Umm... the very link you quote above contains: "But I do know that we are paying for the hosting of the site, and helped Andrew with a bunch of things including legal advice, etc.", "We provide him free hosting and bandwidth.".
In what way, precisely, is this not contributing anything back to the community??
Sheesh,
this is about as well-thought out as the no-fly list "algorithm". Well, Abdul looks a bit like Andrew so you're a suspect, eh?
If they didn't watermark, or put some other individual identifying marks in each of the CTPs handed out, then they have no clue who leaked it, and punishing the innocent is not going to improve their chances.
Exactly. The trick as I recall is dealing with the noise levels. Canon have been doing this for a long time, so it is amusing to see the "analysts" quote. Not that it surprises me. It seems that very few analysts live up to their name, i.e. actually do analysis.
aka the film about the Profumo Affair.
"Well, he would say that, wouldn't he?"
Mod parent up please. Yes, "Graffiti Anywhere" is your friend. The ROMs have Graffiti support built in but it's not enabled by default. I also disagree with this design decision - should have been an option, but GA makes the point moot. Check out "Treo Butler" too. I still love my 600 :-)
This has come up numerous times before on lkml and been debated to death. Search the archives if you want to see the arguments. Executive summary is, it isn't going to happen. If you're into kernel-hacking, or just following the latest updates, I would hope that you already have 2.6.7, in which case the patch is not particularly large. There's no need to download the whole thing every time.
You are entirely correct. Simple FP (i.e. non-SSE etc.) code generally runs quite a bit faster on the AMD chips. Intel actually weakened the FP in the P4 compared to the P3 (things like FXCH no longer being a freebee) to give more space to devote to Screaming Cindy's Extensions (SSE/SSE2/SSE3). This doesn't look to be that much different.
As has been pointed out elsewhere, the L2 cache size probably made a large difference on a lot of these "benchmarks". Several of them stand to gain a lot by having 1M instead of 512K.
As everybody else said, a pity they didn't compare to an Opteron so we could see the results of two comparable chips.
Tim
You're quite correct. That is indeed their argument. By virtue of it, they also own Veritas' vxfs filesystem because that was included in OpenServer as I recall. Ho hum...