I'm going to disagree with all the other replies and say that virtually all apps will remain 32-bit, so developers won't need to do anything. After all, that's how things work on Solaris, AIX, and Linux, so why should OS X be different?
The true advantage of CISC "bytecode" style instruction sets is that they have a small binary code footprint, which improves the performance of instruction caches.
And then Intel throws away that advantage by caching uops instead of instructions.
Linux is NOT different; if you build the kernel with everything enabled (as most distributions do), then the kernel does not need to be recompiled to add hardware. A tool to build a kernel customized for your hardware solves the wrong problem; you shouldn't have to rebuild the kernel at all.
Northwood Pentium 4s use as much space and power as Prestonia Xeons, because they're practically the same thing. To get high density you need to use much slower CPUs.
The support thing is a problem; I wonder if a little user education could solve it. Imagine if the Red Hat installer put up a screen during installation that says "Unless you have a registration card, you cannot get any support from Red Hat. [Cancel] [Accept]". Maybe this would make things more clear.
If you're going to distribute a RH-based distro it is absolutely appropriate and proper to completely disassociate it from RH, and IMHO RH is absolutely in the right to demand it.
But what if you're distributing the exact same bits as Red Hat? That's not a "knockoff", it's not "RH-based", it is Red Hat Linux. But Red Hat won't let companies like Cheapbytes do it. Red Hat is certainly within their rights, but it's too bad IMO.
There probably is an SDK, but us lowly users can't get our hands on it. In the cell phone universe, the carrier only lets you run apps written by their "strategic partners".
Also, if you could write apps then you might use more bandwidth than T-Mobile has budgeted for, putting them in the same pinch that P2P file sharing put the broadband ISPs in.
Option value is good and end-to-end is good; maybe someday the service providers will even figure it out.
Copyright currently lasts longer than the life of the author. A lot longer. If we shorten it to only the life of the author, how much harm will that do?
Re:SPECint / SPECfp vs. POWER4 / US III / P4
on
Itanium Problems
·
· Score: 2
There are two cores per chip, but you can't buy half a chip. You can buy a chip with one of the cores turned off, but I would guess it's more than half the price of one with both cores enabled.
Second, and more importantly, they have replaced KDE apps with equivalent apps, either from GNOME or independent projects. For example, they replaced konqueror with Mozilla, Koffice with OpenOffice, KMail with Evolution.
For one thing, even if you change the widget style, these apps aren't going to be very well-integrated into the rest of the desktop, both in terms of look-and-feel and interoperability with other apps. This tight integration is one of KDE's great strengths; without it, KDE is, well, crippled. Plus, since these apps depend on libraries that are not preloaded when KDE starts up, they will appear to be sluggish to the user, who might incorrectly conclude that KDE is slow and clunky.
Look at it the other way...
Second, and more importantly, they have replaced GNOME apps with equivalent apps from independent projects. For example, they replaced Galeon with Mozilla and GNOME Office with OpenOffice.
For one thing, even if you change the widget style, these apps aren't going to be very well-integrated into the rest of the desktop, both in terms of look-and-feel and interoperability with other apps. This tight integration is one of GNOME's great strengths; without it, GNOME is, well, crippled. Plus, since these apps depend on libraries that are not preloaded when GNOME starts up, they will appear to be sluggish to the user, who might incorrectly conclude that GNOME is slow and clunky.
Thanks; the article was a little unclear about what this project is actually about. Part of it talked about the Internet in general, part of it was about DHTs, and buried in there was a mention of storage.
The primary vulnerability lies within the Root DNS servers, which contain all DNS information for the entire Internet*. IIRC, there are only eleven or twelve of them. And because each replicates its data set to all other Root servers, catastrophic failure of one would bring down all of the others.
That would be a stupid way to run the root servers. My understanding is that the root servers are updated from an offline master; the whole point is that if one fails the others still work and can pick up the load.
Keep in mind that in 802.11b the farther out you are, and the more interference there is, the lower you rate is. It will switch from 11, to 5.5 to 2, and then 1 as the signal gets weaker or more corrupted. The same is true for 802.11A, accept [sic] the range is way smaller, so you will get a reduced rate at ranges where 802.11b is still running at full rate.
But reduced rate 802.11a is still twice as fast as full rate 802.11b.
CompactFlash cards have internal wear-leveling, so you can use regular filesystems. If FAT was so unsuitable for flash, you wouldn't see digital cameras using it.
For regular flash, there are specialized flash filesystems such as JFFS and the recently-announced YAFFS.
The parent post seems to be a perfect example of just enough knowledge to be dangerous.
Slashdot Mirror
A journaling filesystem does not "provide corporate Mac sites with a new, historical view of their data"; all it does is increase reliability.
No one has brought it up because virtually no one wants to waste an entire disk for a filesystem journal.
What if you need to add support for hardware that wasn't available when you installed your kernel?
Get a newer kernel binary package from your distributor.
Did you even look at the article? It says that the PowerPC 970 is "a 'lite' version of [IBM's] Power4 chip".
I think $12M was mentioned in the linux-kernel thread. Good luck; you'll need it.
I'm going to disagree with all the other replies and say that virtually all apps will remain 32-bit, so developers won't need to do anything. After all, that's how things work on Solaris, AIX, and Linux, so why should OS X be different?
The true advantage of CISC "bytecode" style instruction sets is that they have a small binary code footprint, which improves the performance of instruction caches.
And then Intel throws away that advantage by caching uops instead of instructions.
There have been plenty of 64-bit PowerPCs, they just weren't used by Apple. 620, Power3, Power4, RS64, etc.
An open source implementation is already in the works.
Linux is NOT different; if you build the kernel with everything enabled (as most distributions do), then the kernel does not need to be recompiled to add hardware. A tool to build a kernel customized for your hardware solves the wrong problem; you shouldn't have to rebuild the kernel at all.
The bottom line is the TiVo needs to produce a digital cable ready box.
Yep. I'm not interested in trying to integrate the two boxes, and don't get me started on the digital->analog->digital->analog thing.
Isn't there talk (or maybe even an FCC mandate) for an "open standard" for digital cable boxes?
OpenCable is mired in political problems, IIRC. We'll be lucky if we ever get it.
Northwood Pentium 4s use as much space and power as Prestonia Xeons, because they're practically the same thing. To get high density you need to use much slower CPUs.
The support thing is a problem; I wonder if a little user education could solve it. Imagine if the Red Hat installer put up a screen during installation that says "Unless you have a registration card, you cannot get any support from Red Hat. [Cancel] [Accept]". Maybe this would make things more clear.
If you're going to distribute a RH-based distro it is absolutely appropriate and proper to completely disassociate it from RH, and IMHO RH is absolutely in the right to demand it.
But what if you're distributing the exact same bits as Red Hat? That's not a "knockoff", it's not "RH-based", it is Red Hat Linux. But Red Hat won't let companies like Cheapbytes do it. Red Hat is certainly within their rights, but it's too bad IMO.
There probably is an SDK, but us lowly users can't get our hands on it. In the cell phone universe, the carrier only lets you run apps written by their "strategic partners".
Also, if you could write apps then you might use more bandwidth than T-Mobile has budgeted for, putting them in the same pinch that P2P file sharing put the broadband ISPs in.
Option value is good and end-to-end is good; maybe someday the service providers will even figure it out.
Copyright currently lasts longer than the life of the author. A lot longer. If we shorten it to only the life of the author, how much harm will that do?
There are two cores per chip, but you can't buy half a chip. You can buy a chip with one of the cores turned off, but I would guess it's more than half the price of one with both cores enabled.
The data sheet says 90MHz.
Second, and more importantly, they have replaced KDE apps with equivalent apps, either from GNOME or independent projects. For example, they replaced konqueror with Mozilla, Koffice with OpenOffice, KMail with Evolution.
For one thing, even if you change the widget style, these apps aren't going to be very well-integrated into the rest of the desktop, both in terms of look-and-feel and interoperability with other apps. This tight integration is one of KDE's great strengths; without it, KDE is, well, crippled. Plus, since these apps depend on libraries that are not preloaded when KDE starts up, they will appear to be sluggish to the user, who might incorrectly conclude that KDE is slow and clunky.
Look at it the other way...
Second, and more importantly, they have replaced GNOME apps with equivalent apps from independent projects. For example, they replaced Galeon with Mozilla and GNOME Office with OpenOffice.
For one thing, even if you change the widget style, these apps aren't going to be very well-integrated into the rest of the desktop, both in terms of look-and-feel and interoperability with other apps. This tight integration is one of GNOME's great strengths; without it, GNOME is, well, crippled. Plus, since these apps depend on libraries that are not preloaded when GNOME starts up, they will appear to be sluggish to the user, who might incorrectly conclude that GNOME is slow and clunky.
Yet you don't hear the GNOME folks complaining.
Thanks; the article was a little unclear about what this project is actually about. Part of it talked about the Internet in general, part of it was about DHTs, and buried in there was a mention of storage.
The primary vulnerability lies within the Root DNS servers, which contain all DNS information for the entire Internet*. IIRC, there are only eleven or twelve of them. And because each replicates its data set to all other Root servers, catastrophic failure of one would bring down all of the others.
That would be a stupid way to run the root servers. My understanding is that the root servers are updated from an offline master; the whole point is that if one fails the others still work and can pick up the load.
I never understood why nobody provided binaries either. I tried Eclipse back in the build-it-yoruself days and it worked fine on OS X.
Keep in mind that in 802.11b the farther out you are, and the more interference there is, the lower you rate is. It will switch from 11, to 5.5 to 2, and then 1 as the signal gets weaker or more corrupted. The same is true for 802.11A, accept [sic] the range is way smaller, so you will get a reduced rate at ranges where 802.11b is still running at full rate.
But reduced rate 802.11a is still twice as fast as full rate 802.11b.
There is no new threading model. The thread APIs are the same, so when you install the right kernel and glibc all apps will benefit.
CompactFlash cards have internal wear-leveling, so you can use regular filesystems. If FAT was so unsuitable for flash, you wouldn't see digital cameras using it.
For regular flash, there are specialized flash filesystems such as JFFS and the recently-announced YAFFS.
The parent post seems to be a perfect example of just enough knowledge to be dangerous.