"I own an Apple and I like the OS, but I beleive Apple's business practices are designed to drain every last cent from the consumers pockets."
...as opposed to those other publicly traded companies that are in business for the good of the common man, right? Your statement about Apple's business practices is basically a crude restatement of what the law requires of every public corporation. Welcome to America:-)
The G4 uses a nice'n'sexy 0.22 um copper process just to go 400 to 500 MHz.
Do you think that's as fast as it'll go in using that manufacturing process?
Look at McCalpin's STREAM benchmark scores for effective system memory bandwidth. The best Apple score is a G3/266 system with a STREAM SCALE score of 128 Mbyte/sec. A 440BX system with a Pentium II/350 gets 279 Mbyte/sec (and an Alpha EV6/500 XP1000 gets 971 Mbyte/sec).
...and the Sawtooth G4 Macs haven't even been tested. Their claimed throughput is 800MB/sec. We'll see what the actual scores are.
The MPC7400 equals or beats any x86 chip (including the Athlon) of the same clock speed in integer and FP benchmarks. Its SIMD execution unit is faster and more capable than MMX, SSE, and 3DNow. It's smaller, uses fewer transistors, costs less to manufacture, and uses far less power.
So...remind me again why Apple should switch to a different processor family?
I've never seen a decent game [...] Bungie. [...] I've never heard of Halo, but Oni looks like another boring first person shooter with the tedium of Mortal Combat thrown in to make you fall asleep faster.
First, Oni is third-person.
Second, Halo (also third person) looks very cool. Grab this movie (bigger version here) and tell me that your jaw doesn't drop.
Third, WC3 owes pretty much everything to Bungie's Myth. You know, that game that was released several years ago that featured full 3D terrain, a total lack of resource management and unit building, etc. Now let's look at the features of WC3 gameplay...hmmmm...
Who guarantees you that apple will not raise the fee to 20 bucks anytime in the future? or forbid "clone makers" to employ FW anytime in the future? or when apple decides to cut FW because "it has no future" (things like floppies and serial bus come to mind) and withdraws all third party licenses and you are stuck with your FW peripherals with no new supporting HW available? Does that sound nice to you?
No, that sounds horrible. Good thing it's impossible, huh? Apple does not control IEEE 1394. Like any IEEE standard (802.3 ethernet, etc.), it's completely open and not controlled by any single private company. There are license fees involved, but those fees are split among many companies (Compaq, Matsushita, Philips, Sony, Toshiba), not just Apple. This is how the electronics industry works. For example, Philips and Sony collect license fees on every CD player made. Let's try to keep the FUD under control here, people.
ADB is not supported on the iMac or G4 Macs (without a USB-to-ADB adapter or somesuch). It is a dead technology. It was Apple's single, self-powered, self-configuring, keyboard and mouse interface for the past 12 years.
RS422 and "the stupid d-sub vga connector" have not been on a Mac since the introduction of the iMac and Blue and White G3's over a year ago.
For the lazy and/or illiterate, here's the bottom line:
IEEE 1394 licensing is not an issue anymore (patent pool)
IEEE 1394 does 400Mbps right now.
USB 2.0 is "expected to perform in the 360-480Mb per second range" some time in the future.
USB 2.0 could conceivably push IEEE 1394 into a niche, but it would be a huge, huge shame, and it would have absolutely nothing to do with superior technology. What else is new in the PC industry...
Re:No X -- we need a media-savvy, compositing GUI
on
Is X The Future?
·
· Score: 1
"We need to replace X with a media-ready, true-color-plus-alpha, image-compositing gui that runs on the framebuffer device."
See also: Apple's "Quartz" imaging model for Mac OS X...
"Nobody is ever going to write software for the NeXT API except for the few software companies that did so before Apple bought NeXT."
We'll see. In the short term, Mac developers will just port to Carbon. But in the long term, I suspect they'll switch to either Cocoa (Yellow Box) or the BSD layer. But it doesn't really matter, since all the APIs leverage Mach at the lowest level, the Quartz imaging model, and "middleware" APIs like the CF classes. Even using "just" Carbon will be pretty nice.
"So instead of hoping Apple will give you the features you need, and paying for upgrades that break your software, just install LinuxPPC."
Upgrades that "break" software, imagine! Welcome to the world of computers. Mac OS is pretty amazing in this respect, actually. As of Mac OS 8.1, the oldest piece of software I own (the game Lode Runner) still ran. I haven't tried it since then. I have no complaints about Apple's treatment of backward compatability. Hell, they switched CPUs without breaking my software.
Also, I have LinuxPPC installed, but do most of my work in Mac OS.
Item 3 never existed. Be was looked at (along with Sun's Solaris and NeXT), but it was never a "strategy", just one of many options.
Items 4 and 5 are not accurate. The Rhapsody strategy is alive and well. It had Carbon (the "modernized" Mac OS API) added to it. Nothing was removed. It is not a "new strategy." It does not, nor has it ever "run on top of BSD." Both NeXTSTEP and Rhapsody have always had a BSD compatibility layer. Ther kernal has always been Mach.
...seems to be that the features listed as strengths by one side are the same things listed as weaknesses by the other side: "flexible" syntax, "everything is a string", modules, etc.
In their respective optimal environments, TCL and Perl may be comparable if all you're doing is firing off SQL queries and spitting out the results intermixed with some markup. But in my experience, the vast majority of web development asks much more of the glue language. YMMV.
Granted, this second edition is more open-minded than the first, but comments from the author like this are bound to stick in the craw of more than a few web developers:
"The only conceivable way to write a correct Perl program IMHO is cutting and pasting from someone else's code."
"the only thing that a Web nerd can usefully do with Perl is grind over a bunch of HTML files and touch them up"
"Perl 5 does indeed offer 1000 times the syntactic complexity of Common Lisp, 10 times the semantic complexity of Common Lisp, and 1/10th the power of Fortran II."
Yes, language wars are boring and we all have our favorite tools, but you have to expect strong reactions from comments like that.
Greenspun provides useful information and is entertaining, but he's also self-absorbed and narrow-minded. You get the impression that he thinks anyone not using AOLServer, TCL, and Oracle is not doing "real work." Most unforgivable, IMO, is his Perl-bashing. He's entitled to his opinion, but to write a book about web development that actively discourages the use of Perl? Foolishness.
As someone mentioned earlier, Jakob Nielsen is an example of someone who's just as fanatic about adherence to web standards (AHEM, Slashdot!) and good design, but without the sour/arrogant attitude.
This thing is the size of a big wallet and requires nothing but a FireWire cable to plug into it. It's from VST, a company that also makes a lot of notebook accessories and drives. This is not a giant desktop drive for use with digital video, nor is it representative of what a FireWire drive aimed at such a market could do. Get a grip.
You've got to be kidding me. XSL is all fine and dandy, but browsers don't even fully support CSS yet! A few points brought up regarding CSS:
1. "No popular sites use CSS"
Try viewing source as you browse for a week or so. You'd be surprised how many sites use it. Of course, support is very limited in 4.x browsers, so it's not as common as the whole FONT tag crap-o-rama, but it is used.
2. "What does CSS have that HTML doesn't?"
Anyone who asks this has obviously never done any web development beyond a personal home page or two. Hmmm, should I double the size of my HTML pages with 10,000 impossible to manage, lame-ass FONT tags, or should I define a style sheet in one location and use structural markup? Boy, tough choice.
A properly run web site using CSS has smaller pages, displays quicker, and can have its look radically altered via small changes to one or two files. Try manually changing every album title on a music web site to a different typeface when you've used FONT tags. Regexes and search and replace, you say? Good luck matching "an album title" in thousands of HTML files full of non-structural markup. Using CSS, you'd just change one line in a style sheet.
Database-backed web sites help in this regard, but mostly they just give webmasters an excuse to make their lives easier (since they can wrap DB-generated pages in any markup they want--they just have to change a few scripts) while continuing to saddle the public with bulky, slow-displaying, buggy, invalid HTML. And although DB-generated content makes a web admin's life a bit easier, changing several scripts is still more annoying and more risk-prone than changing one or two style sheets.
I'm not saying CSS are the best style sheet mechanism in the universe, but it makes the best match for HTML (itself a limited standard), and at this point we're lucky if we can get browsers to support CSS 1 and 2, let alone XML and XSL. "Skipping over" CSS in favor or waiting another 3 years for the X-family of standards to filter into browsers is insane, IMO. I want ease of maintenance and fast-loading pages now not in three years. We should have had it since 1996/7, but the "browser wars" gunked up the works.
...I think it's time someone at slashdot took a look at the horror-show that passes for HTML at slashdot.org. Standards? Try running the slashdot.org home page through a w3.org HTML validator, I dare you. Practice what you preach!
Slashdot Mirror
"I own an Apple and I like the OS, but I beleive Apple's business practices are designed to drain every last cent from the consumers pockets."
...as opposed to those other publicly traded companies that are in business for the good of the common man, right? Your statement about Apple's business practices is basically a crude restatement of what the law requires of every public corporation. Welcome to America :-)
Er, sorry, stray "e" there. Why doesn't Slashdot allow authors to edit their own comments?
The "extensible architecture" is part of the previously announced "Booke E" project:
Check it out.
Do you think that's as fast as it'll go in using that manufacturing process?
...and the Sawtooth G4 Macs haven't even been tested. Their claimed throughput is 800MB/sec. We'll see what the actual scores are.
The MPC7400 equals or beats any x86 chip (including the Athlon) of the same clock speed in integer and FP benchmarks. Its SIMD execution unit is faster and more capable than MMX, SSE, and 3DNow. It's smaller, uses fewer transistors, costs less to manufacture, and uses far less power.
So...remind me again why Apple should switch to a different processor family?
"Book E" is the "extensible architecture" mentioned in the light purple G5 block of Moto's PPC roadmap.
"They make firewire proprietary, which effectively kills it."
Um...excuse me? What exactly is "proprietary" about IEEE 1394?
First, Oni is third-person.
Second, Halo (also third person) looks very cool. Grab this movie (bigger version here) and tell me that your jaw doesn't drop.
Third, WC3 owes pretty much everything to Bungie's Myth. You know, that game that was released several years ago that featured full 3D terrain, a total lack of resource management and unit building, etc. Now let's look at the features of WC3 gameplay...hmmmm...
No, that sounds horrible. Good thing it's impossible, huh? Apple does not control IEEE 1394. Like any IEEE standard (802.3 ethernet, etc.), it's completely open and not controlled by any single private company. There are license fees involved, but those fees are split among many companies (Compaq, Matsushita, Philips, Sony, Toshiba), not just Apple. This is how the electronics industry works. For example, Philips and Sony collect license fees on every CD player made. Let's try to keep the FUD under control here, people.
ADB is not supported on the iMac or G4 Macs (without a USB-to-ADB adapter or somesuch). It is a dead technology. It was Apple's single, self-powered, self-configuring, keyboard and mouse interface for the past 12 years.
RS422 and "the stupid d-sub vga connector" have not been on a Mac since the introduction of the iMac and Blue and White G3's over a year ago.
Here's an informative URL:
For the lazy and/or illiterate, here's the bottom line:
USB 2.0 could conceivably push IEEE 1394 into a niche, but it would be a huge, huge shame, and it would have absolutely nothing to do with superior technology. What else is new in the PC industry...
See also: Apple's "Quartz" imaging model for Mac OS X...
I think you have the logo confused with chemical dependence.
Re: 68k code
I meant gone in Mac OS X (Server now, Client later)
"Yea, and they left a lot of 68k assembly in MacOS too"
Well worth it, IMO, when the alternative was to just scrap all 68K apps. It's gone now, BTW.
"Nobody is ever going to write software for the NeXT API except for the few software companies that did so before Apple bought NeXT."
We'll see. In the short term, Mac developers will just port to Carbon. But in the long term, I suspect they'll switch to either Cocoa (Yellow Box) or the BSD layer. But it doesn't really matter, since all the APIs leverage Mach at the lowest level, the Quartz imaging model, and "middleware" APIs like the CF classes. Even using "just" Carbon will be pretty nice.
"So instead of hoping Apple will give you the features you need, and paying for upgrades that break your software, just install LinuxPPC."
Upgrades that "break" software, imagine! Welcome to the world of computers. Mac OS is pretty amazing in this respect, actually. As of Mac OS 8.1, the oldest piece of software I own (the game Lode Runner) still ran. I haven't tried it since then. I have no complaints about Apple's treatment of backward compatability. Hell, they switched CPUs without breaking my software.
Also, I have LinuxPPC installed, but do most of my work in Mac OS.
Some corrections:
Item 3 never existed. Be was looked at (along with Sun's Solaris and NeXT), but it was never a "strategy", just one of many options.
Items 4 and 5 are not accurate. The Rhapsody strategy is alive and well. It had Carbon (the "modernized" Mac OS API) added to it. Nothing was removed. It is not a "new strategy." It does not, nor has it ever "run on top of BSD." Both NeXTSTEP and Rhapsody have always had a BSD compatibility layer. Ther kernal has always been Mach.
...seems to be that the features listed as strengths by one side are the same things listed as weaknesses by the other side: "flexible" syntax, "everything is a string", modules, etc.
In their respective optimal environments, TCL and Perl may be comparable if all you're doing is firing off SQL queries and spitting out the results intermixed with some markup. But in my experience, the vast majority of web development asks much more of the glue language. YMMV.
Granted, this second edition is more open-minded than the first, but comments from the author like this are bound to stick in the craw of more than a few web developers:
Yes, language wars are boring and we all have our favorite tools, but you have to expect strong reactions from comments like that.How about "My Way or the Highway"?
Greenspun provides useful information and is entertaining, but he's also self-absorbed and narrow-minded. You get the impression that he thinks anyone not using AOLServer, TCL, and Oracle is not doing "real work." Most unforgivable, IMO, is his Perl-bashing. He's entitled to his opinion, but to write a book about web development that actively discourages the use of Perl? Foolishness.
As someone mentioned earlier, Jakob Nielsen is an example of someone who's just as fanatic about adherence to web standards (AHEM, Slashdot!) and good design, but without the sour/arrogant attitude.
Old, but interesting. Check it out.
Follow the link
This thing is the size of a big wallet and requires nothing but a FireWire cable to plug into it. It's from VST, a company that also makes a lot of notebook accessories and drives. This is not a giant desktop drive for use with digital video, nor is it representative of what a FireWire drive aimed at such a market could do. Get a grip.
You've got to be kidding me. XSL is all fine and dandy, but browsers don't even fully support CSS yet! A few points brought up regarding CSS:
1. "No popular sites use CSS"
Try viewing source as you browse for a week or so. You'd be surprised how many sites use it. Of course, support is very limited in 4.x browsers, so it's not as common as the whole FONT tag crap-o-rama, but it is used.
2. "What does CSS have that HTML doesn't?"
Anyone who asks this has obviously never done any web development beyond a personal home page or two. Hmmm, should I double the size of my HTML pages with 10,000 impossible to manage, lame-ass FONT tags, or should I define a style sheet in one location and use structural markup? Boy, tough choice.
A properly run web site using CSS has smaller pages, displays quicker, and can have its look radically altered via small changes to one or two files. Try manually changing every album title on a music web site to a different typeface when you've used FONT tags. Regexes and search and replace, you say? Good luck matching "an album title" in thousands of HTML files full of non-structural markup. Using CSS, you'd just change one line in a style sheet.
Database-backed web sites help in this regard, but mostly they just give webmasters an excuse to make their lives easier (since they can wrap DB-generated pages in any markup they want--they just have to change a few scripts) while continuing to saddle the public with bulky, slow-displaying, buggy, invalid HTML. And although DB-generated content makes a web admin's life a bit easier, changing several scripts is still more annoying and more risk-prone than changing one or two style sheets.
I'm not saying CSS are the best style sheet mechanism in the universe, but it makes the best match for HTML (itself a limited standard), and at this point we're lucky if we can get browsers to support CSS 1 and 2, let alone XML and XSL. "Skipping over" CSS in favor or waiting another 3 years for the X-family of standards to filter into browsers is insane, IMO. I want ease of maintenance and fast-loading pages now not in three years. We should have had it since 1996/7, but the "browser wars" gunked up the works.
...I think it's time someone at slashdot took a look at the horror-show that passes for HTML at slashdot.org. Standards? Try running the slashdot.org home page through a w3.org HTML validator, I dare you. Practice what you preach!