Hasn't the Notes/Domino server supported Linux for a long time? The problem seems to be that (1) there's no Notes client for Linx, or (2) a lot of people just don't want to use the Notes client.
Hammer does not compete against Itanic
on
AMD Delays Hammer
·
· Score: 2
It competes against the Pentium 4. If the K7 tops out at "3000+" as I've read, AMD is going to need Hammer to compete with 3GHz+ Pentium 4s.
If you have tasks that require memory managed by another processor, you have to go through the hypertransport link and the other processor's memory controller to get it. This will be _slow_. HT is decent, but nowhere near as good as a direct connection to memory, and there _will_ be delays due to arbitration on the second chip and the various buffering stages the data transfer has to go through.
So, for multiple processors working on a shared workload, you're screwed.
From the Hammer presentations I've seen, this is not true at all. The HT link between CPUs is 6.4GB/s, which is actually faster than the direct-attached memory (~5.3GB/s). Since the HT controllers are running at >2GHz, they introduce minimal latency.
And under some cases - like tasks on multiple processors competing for access to a lock or all heavily modifying the same data page - you're screwed no matter what you do.
I don't think this is true either. Contention for a cache line will simply bounce the line between caches, which is much faster on Hammer than on a 400MHz shared-bus SMP.
iCal isn't open source, and since it runs on OS X it won't help people trying to migrate to Linux. (Personally, I think migrating from Windows to Mac is more realistic in the short term than Windows to Linux, but that's just my opinion.)
It will be very easy to enforce; future Macs will have new hardware and Apple just won't write OS 9 drivers for that hardware. Or maybe they'll do something else; I don't know. My point is that Apple's reason for not supporting OS 9 isn't arbitrary: writing drivers costs money.
I have the following conspiracy theory: manufacturers are afraid of releasing large capacity tapes at a low cost, because they would be ideal for pirating video.
So what? Tape manufacturers aren't liable for how their tapes are used.
KeyKOS solved a lot of the problems this paper describes in the 80s, and its descendent EROS is solving them today (and open source, too!).
Unfortunately, in the 80s people were so infatuated with micros that secure timesharing wasn't a big market, and today people have been living with insecure systems so long they have stopped caring.
GSM is not analog. GPRS is the high-speed data extension to GSM; for voice you still need GSM. And I'd imagine that by 2004 every GSM chipset will include GPRS.
Slashdot Mirror
Too bad no public terminals support smart cards.
IIRC, it's patented, but not by Sun.
So buy an 18GB SCSI drive. :-)
AFAIK, ext2 has been endian-safe for a while.
AFAIK, IBM supports several distros, not just Red Hat.
There is a standard; it's called LSB and IBM is a big supporter.
Server apps are much easier to port than GUI apps.
Hasn't the Notes/Domino server supported Linux for a long time? The problem seems to be that (1) there's no Notes client for Linx, or (2) a lot of people just don't want to use the Notes client.
It competes against the Pentium 4. If the K7 tops out at "3000+" as I've read, AMD is going to need Hammer to compete with 3GHz+ Pentium 4s.
If you have tasks that require memory managed by another processor, you have to go through the hypertransport link and the other processor's memory controller to get it. This will be _slow_. HT is decent, but nowhere near as good as a direct connection to memory, and there _will_ be delays due to arbitration on the second chip and the various buffering stages the data transfer has to go through.
So, for multiple processors working on a shared workload, you're screwed.
From the Hammer presentations I've seen, this is not true at all. The HT link between CPUs is 6.4GB/s, which is actually faster than the direct-attached memory (~5.3GB/s). Since the HT controllers are running at >2GHz, they introduce minimal latency.
And under some cases - like tasks on multiple processors competing for access to a lock or all heavily modifying the same data page - you're screwed no matter what you do.
I don't think this is true either. Contention for a cache line will simply bounce the line between caches, which is much faster on Hammer than on a 400MHz shared-bus SMP.
iCal isn't open source, and since it runs on OS X it won't help people trying to migrate to Linux. (Personally, I think migrating from Windows to Mac is more realistic in the short term than Windows to Linux, but that's just my opinion.)
Since there are no binaries for unstable packages, prepare to spend several days building all the prereqs for any major app.
:-(
Why post binaries on SourceForge when you could force 1,000 people to compile them instead?
The new fangled wireless media gateway needs to be on the same channel as your access point, so it can talk to your PC.
Does Intel make an ARM compiler? I've never heard of it.
Yes, V-Twin (AIAT) is still alive in OS X.
Hashcash can be verified by the receiver; SETI blocks cannot.
Try dvbackup.
It will be very easy to enforce; future Macs will have new hardware and Apple just won't write OS 9 drivers for that hardware. Or maybe they'll do something else; I don't know. My point is that Apple's reason for not supporting OS 9 isn't arbitrary: writing drivers costs money.
Do you think a non-Apple version of Classic is going to be any better? Why?
Looks like you are wrong. OS 9 will not boot at all on future Macs.
I have the following conspiracy theory: manufacturers are afraid of releasing large capacity tapes at a low cost, because they would be ideal for pirating video.
So what? Tape manufacturers aren't liable for how their tapes are used.
KeyKOS solved a lot of the problems this paper describes in the 80s, and its descendent EROS is solving them today (and open source, too!).
Unfortunately, in the 80s people were so infatuated with micros that secure timesharing wasn't a big market, and today people have been living with insecure systems so long they have stopped caring.
This is just a slightly-rebranded version of listen.com's Rhapsody, and the price is the same, so I don't see how this is likely to save AudioGalaxy.
Actually, you don't need the firmware. MOL runs on non-Apple PowerPC machines (all 5 of them).
GSM is not analog. GPRS is the high-speed data extension to GSM; for voice you still need GSM. And I'd imagine that by 2004 every GSM chipset will include GPRS.
Actually, the StrongARM was designed by DEC; ARM only designed the ISA.