Re:How will this affect the Nintendo GameCube?
on
XBox Delayed
·
· Score: 1
The original Radeon really has little to with the Radeon 8500, its just the name, like Intel and Nvidia have done to capitalize on marketing.
Well, that's interesting then. I wonder if the 8500 is based on the Art-X tech. The Gamecube hardware was finalized before the first Radeon shipped.
The VCD and audio not playing in your DVD players is a matter of format.
What do you mean exactly? (I'd like to know). The audio CDs play fine on everything else, and the DVD player does play real VCDs and Audio CDs.
The only thing I am not sure of is whether or not it is possible to tell the difference between a burned DVD and a stamped one.
I believe that my DVD player can do that:-/
Also, us folks are only really capable of burning DVD-General discs, which are different from factory mastered disks (you can burn those if you want to pay for the equipment). So that's another hurdle:P
Re:How will this affect the Nintendo GameCube?
on
XBox Delayed
·
· Score: 1
1. Panasonic will make a DVD-Gamcube combo. This will have to be able to play DVD formated disk and gamecube games, so it seems logical that a DVD burned with a gamecube game would work.
It would seem logical that my DVD player would be able to play an audio or VCD burned onto a CD-R, but it can't.
Some DVD players can play 'mini-DVDs' (DVD volume on CD-R, if I remember correctly), some can't.
The point is, if they thought about it, and I'm sure they did (my DVD player is made by Sony, surprise surprise), it's not likely to work that way.
This could be used to hack shit up because after a regular game is authorized another game could be inserted masquerading as the authentic game that was removed.
I would assume that it is as hard to masquerade as another game as it is to be a valid game.
The 3DO was a very hacker-resistant system. The hardware (which I think they called Opera) was a total dud by itself. Now, that was before the days of mass CD-Rs and today's 'net, so maybe it's easier to hack that now.
PPC and ATI Radeon 8500 I believe
PPC derivative yes, Radeon no. It's not even ATi developed hardware. The ex-Nintendo 64 team from SGI founded Art-X, which developed the GPU for the Gamecube (SGI didn't feel gaming was an important or appropriate application of 3D graphics, apparently). ATi bought Art-X, and the original Radeon doesn't have anything to do with Art-X's stuff. The Radeon 8500 follows the Radeon, so, no.
You would probably see it emulated before you see it hacked:) The remaining challenge is getting a drive that lets you read those mini-DVDs.
The transfer of the film has been painstakingly reproduced on the digital format directly from the original film master.
Didn't Lucas have a digital master of this movie? I know a significant portion of the movie was digital anyway, and I thought he was going to run the rest of the film through digital processing so he could get a digital master.
The problem is that mac os x uses display technology that is not easily accelerated by current graphics cards. A lot of screen drawing is done with vectors and bezier curves that are closer to the type of acceleration that a 3d card provides and not a 2d card.
A few common misconceptions here. First of all, most of the drawing in OS X (which I'm using right now:) is done by blitting and compositing graphics. Quartz main claim to fame is its ability to composite graphics (which is how you get translucency). It's also capable of scaling and warping stuff, but those effects are used sparingly, and takes a CPU hit when you do. There's nothing there that a 3D card can't handle.
Quartz 2D does support creating vector graphics, but pretty much nothing you see on an average OS X screen is using vector graphics. The GUI is made up of a bunch of TIFF files.
So why is OS X slow? Because it's just ass slow. 10.1 addresses this. There were a LOT of changes in the last few months before release, and I'm sure making things fast was no where near as important as making things work (and complete!). Honestly, there are things that are just outright broken in 10.0 release (and still in 10.0.4).
10.1 is wickedly fast. But then, look at what you're comparing it too:) For example, top takes up 12% of this CPU (G3/400).
Every once in a while I hear 'Forth = cool' come up, and having not known much about it, have done a little searching and for whatever reason lost interest. I was more determined this time, and I have come to understand the 'cool' factor. Heh, factor. Anyway...
Good Forth programmers strive to write programs containing very short (often one-line), well-named word definitions and reused factored code segments. The ability to pick just the right name for a word is a prized talent.
good god, I would suck at this language. How many times have I named variables, even functions, 'foobar,' or otherwise named stuff with some combination of those letters? I've always wondered what names I might end up dooming my children with... I've even used raboof a few too many times to spice things up:(
Oh come on, it's much more polite to just provide a link to archives.nytimes.com instead of posting the article.
As in,
Both Hewlett-Packard and Compaq have been hurt by price wars in personal computers, where it has been difficult for makers to differentiate themselves when all except Apple Computer are offering operating systems from Microsoft.
Oh whoops. Wrong contents on the clipboard. But I like that quote:)
Actually, I think people get the impression that the PDF rendering is slow because IIRC, Display Postscript renderers would generate a ps file then send it to a ps rasterizer. The resulting system was less than speedy. I don't know if Apple does it the same way,
Dear god no, they don't do it the same way! If that way was done at all.
Like I said, it's the same model, but the rendering has NOTHING to do with PDF. You make CoreGraphics calls (CGDrawLine, stuff like that). It has nothing to do with PDF.
but I'd rather think that the GUI is slow because of a slow model rather than just plain crappy programming.
It's totally unoptimized. First you make something work, and then you make it fast. The number of changes under the hood to OS X since even the public beta are very, very dramatic. Even CoreFoundation has had it's share of updates from the 10.0 release to now.
As for OS-X, its slow largely because of Mach. The dated version of FreeBSD (3.2) doesn't help things, but the Mach 3.0 kernel is an absolute dog.
Mach 3 is a research project. Apple doesn't use pure Mach 3, and it's not slow. The dated-ness of FreeBSD has nothing to do with it. We use 3.x and 4.x, and you don't say that one's faster than the other:)
It's only the BSD api and utilities that's at 3.2, it has no affect on performance or usability. OS X is an operating system in itself; it can function without the BSD subsystem. It's an optional install, on by default.
Every so often a disscussion pops up on the HURD list about porting it to something better, but apparently they're quite stuck with it.
Mach rocks. If you ever get involved as a developer of application software with writing code that works with the kernel, it's quite impressive.
Mach is significant because of it's design. Implementations are free to be as slow as they want to be. There's a big difference between pure Mach and Apple's xnu kernel.
But yes, KDE on the G4 certainly runs faster than Aqua under
OS X - no wonder, since Aqua's rendering system is PDF based...
LOL! PDF-based rendering doesn't mean it creates a PDF and processes it to draw something, it means it uses the same imaging model as PDF.
Actually, it's almost identical to Postscript, but with Quartz they lose the programmability of PS and the licensing fees (fortunately). They gain "PostScript-like drawing features such as resolution independence, transformable coordinates (for rotation, scales, and skews), Bézier paths, and clipping operations." This gives them a unified model for printing and drawing. And it makes it easy to generate a PDF file, or to render a PDF file (printer spool files are PDF files). But how do you explain this to Joe user? Saying it uses the PDF model for rendering and describing image environments turns to "it uses PDF to draw."
For example, if they said it was OpenGL based, the reaility might be that it uses the same multi-stage rendering pipeline as OpenGL, in that you have data to draw represented by vertices, they get transformed by the model-view matrix, and then transformed by the camera, then clipped to the viewable area, then perspective is applied (3D to 2D), then drawn. But that doesn't mean that it is creating a new OpenGL context and running OpenGL commands every time it draws something.
There's also a misconception that Adobe worked on Quartz. They had nothing to do with it.
So why is it slow? Because OS X 10.0 is just ass-slow. At *everything*. I've got one of them high-end G4s. When I was at the expo and they were showing how fast 10.1 is, I heard some people in the audience say "yeah, but how fast is the machine that it's running on?" Pfft! It looked twice as fast as my machine, and before the expo they didn't come any faster:)
Now, presumably, Hubbard must be exposed to a *lot* of proprietary code in order to best optimize Darwin to run the OSX user interface.
Well, no. You can take Darwin and replace every corresponding component in an OS X distribution, and it will work perfectly (except for CoreFoundation, because Darwin has only a subset called CF-Lite, but the remaining CF code is identical). Darwin is perfectly in sync with OS X release. Actually, the current Darwin is newer than the 10.0 release.
If your assumption comes from the fact that Darwin is slow, then well, I'm sorry, but Mac OS X 10.0 is slow too:(
But how does your email program know that it's a JPEG?
That was the whole point of the article:)
The Mac encodes the file type as a 4 character code, 'JPEG'. So it's a JPEG file. The Be OS is no better or different as far as I know, except that it was designed after the MIME standard was introduced, so it's in sync with MIME.
Hell, even Apple's ProDOS, which ran on the//e (81? 83?) had file types (creator codes too, I think.. it's been a while since I've done a catalog:)
The AmigaOS (and later BeOS) had Datatypes, an OS-level solution to the JIT file-typing problem... you could install input and output filters for any type of data you had datatypes for, and any program that supported datatypes (e.g. for images, or sounds, or text) could use these modules.
I'd say it's the Windows machine's fault for not recognizing the file for what it was, just as much as it was the Apple's fault for not adding the extension. Interoperability requires both sides.
The Mac is doing it's part. Every Mac email program I've used adds MIME types, they have no obligation to add file extensions. The Windows apps ignore that info though.
Incidentally, has anyone else noticed that the MacOS scheme is equivalent to having 4 character extensions which aren't displayed, with the corresponding problem of having malicious executables named README.txt (or even README)?
Yes, and there are apps that sort of masquerade as files, particularly READMEs. But what difference does it make? If there's one thing I've learned as a software developer, users do NOT read Readmes.
If you're in list view the Mac will tell you it's an application. But fortunately, it's harder to write malicious code on a Mac than it is to do, say, #!/bin/sh, rm -rf/. You'd have to look up the file system API in a reference book, which reduces the trojan-writing to be uncool.
The thing that cheeses me is that the Internet is based on MIME. When I send a file "foobar" to a Windows user, and my email program tags the file as image/jpeg, the Windows email program should make the file name "foobar.jpg".
A lot of things would be better if the 'lower' OSes would just pay attention to MIME types. But there's one obvious situation where it falls apart.
Joe Mac User makes an HTML document referencing a bunch of JPEG and Flash images. The JPEG and Flash files don't have extensions in their names. He sends his HTML directory to his Windows-loving friend. Assuming that the Windows or Mac apps payed attention to the file types (either Just In Time on the Mac to add extensions, or the Windows app payed attention to MIME), the user's documents would have appropriate extensions added to them. The Windows user's HTML is busted.
While it royally bites that I have to put up with extensions in OS X, I can understand why Apple did this.
You non-tech-savvy computer user (I'd think that's 80% of computer users out there), are damn clueless, and would be completely unable to fix that HTML example.
is not quite the same as everyone else's. FYI, to 'innovate' actually means to 'invent.' It's been thrown around way too much lately.
In 1969, Raskin wrote a paper called "The Quick Draw Graphics System," or something like that. His argument was that processing power should be devoted to aiding the user, by drawing graphics to present an interface.
That was pretty unthinkable at the time. Parc hadn't been founded yet, and for those who don't know, it was Raskin who started the Macintosh project at Apple, before they ever went to Xerox.
Historians take a look at the past from primary documents. News reporters don't, and there are a lot of false truths out there, like "Xerox invented the GUI, and Apple took it and popularized it." Don't believe it's true unless if you hear it from the horse's mouth.
He helped change the course of computing. He doesn't feel Apple's doing that anymore (and they're not, they're just helping it evolve).
Still, I think he wants Apple to do too much too fast. Apple could have made landmark changes with Mac OS X's interface, but who would have wanted to use it? If it can't run Office, people won't buy it.
At this point, Apple's best off bringing change in bits and pieces, because Mac OS users are already freaking out with the changes in OS X.
But when building a new application, Java is more often than not a better choice than C/C++, simple because it was build with networking in mind.
It has nothing to do with Java having networking built in mind, it's just the java.net libraries.
If it's important to you, build your next app with a good base library. OOP can be a royal pain unless if you have a good framework to build on. C++ doesn't have one (just model objects & stuff). Java has a fairly crappy library that's supposed to scale from applets to servers.
Something (crappy libs) compared to nothing (C++) tends to win.
Personally, I find GNUstep and Cocoa to be much more useful and productive.
The problem is that anything can be attached to a PDF (executables, VBscript), and these things can be viewed using Acrobat. Does Acrobat run these things automatically, or what?
Otherwise, it's no more of a virus than sending a VBscript to someone who uses Eudora.
Renting was a way of sharing limited resources. When I 'rent' something online, I download the data to my computer, and it sits on my hard drive. That data's mine; having it expire is just stupid. That's not renting, that's fooling people into giving you money. The most I'll accept is paying for the download (purchasing the right to have a copy of the bits, and saying thanks for making the content).
Then of course there's piracy, which I guess is what they're afraid of. It's too easy for me to retransmit something I bought to someone else. I wouldn't do that though; if I spent my $40 on something, I'm not going to give it up to someone else for free. Duh. Of course, if you got it free, you don't care if you give it to someone free. They need to put value into owning something. Additionally, IMO most people are willing to play fair as long as they don't feel they're being ripped off.
But stupid stupid stupid. Here's a situation where people clearly want something—interesting stuff to read. People are willing to pay for that. The problem is where you have a clash of free content (I can write any interesting stuff on my web page and 'publish' it) and paid content (why should I pay if I can get it for free? Ah hell, I'll just steal it). Sorta like free software vs. commercial software. There's value in the commercial stuff, but how often do we need it?
Keep in mind, I fully need my Mac and have no political problems (as opposed to financial) paying for lots of good quality commercial software (WTF people buy outlook, I'll never know). There's lots of room for free software & content. It's really a shame that for the longest time we've had to give up hard earned money for those things.
You think this doesn't happen in other industries as well? For instance, you think a Lexus ES 300 is any better than a Camry XLE as far as performance? Okay the ES300 is 210hp and the Camry is 194hp... that's a 8% increase in performance yet it has a 20% markup for your wood trim and extra 2 choices in exterior colors!
In most cases, I'd say this argument is f'ing idiotic, but the Camry is a damn good car.
They're recommending using C++ and C to call the OS X Windowing APIs, which doesn't sound like a good idea, since the GUI could be built much quicker with Objective-C and AppBuilder.
Actually, Interface Builder supports making nib files for Carbon applications (C and C++) now. If OpenOffice is written using C++, it would be too hard to use Objective-C because you can't call C++ code from Obj-C and vice versa (the Objective-C++ compiler is too old).
I'd like to see a real example where you have this sort of problem, instead of some contrived (and clearly untrue) version. Enough with the FUD, please.
FUD? I dealt with that yesterday. Too often you write code that you would expect to work, but have to break it down because the compiler doesn't like it, because C++ is enforcing its overly complex design on you.
not least a forced mix of value and reference semantics, which is the root of one of the article's main complaints.
I was talking about the section on language syntax complexity.
I think a lot of people's well-worn objections to C++ are going to wear out when C++0x arrives.
Have you used any other OO languages? Besides Java? Because C++ is not the holy grail of OOP. I have a hard time considering it an OO language. The problem gets worse when you use the STL, which shoots programming complexity through the roof.
OOP is supposed to make things simpler, to encapuslate stuff and take crap out of your way. Hopefully, you sit there coding the logic that goes with your data, and get everything to work together as one big happy family. With C++, you spend time figuring out why the hell you can't get this innocent-looking line of code to work:
const Foo &bar = myMap[foo];
The answer is that foo is a const object (something like that anyway). Then you have to figure out how to get something out of a map without using overloaded operators (I'm not a fan of overloaded operators, in any language).
I've heard people say things like Java is a lesser language, because it doesn't have templates. Java doesn't need templates. C++ needs templates as a hack to support wickedly (and I mean that in a bad way) strong typing.
C++ is best as a compromise between C and object oriented programing. The STL is "nice" because it allows you to put plain structs and any other C type into containers. If you have to mix C code and object oriented programming, C++ can be very convenient. Personally, I'd rather use C with Object Oriented Design.
Stroustrup's book has 40 pages of technicalities for C++. That's far more pages than what covers the standard library for K&R's C book. C is a well designed language that's easy to use and very productive. As it says on the back of K&R, C wear's well as one's experience with it grows. I've been using C++ for a long time (pre-exceptions, pre-multiple inheritance), and as time goes on, I learn more and more about the intricacies of the language. There's much less to appreciate about it. I spend more time programming the language (templates, constructor initializer lists, overloading operators, making stupid function objects, and all the specific syntax you have to use to support that stuff) than I do programming my own code. If you want to use the STL, you need to waste your time doing these things.
Try Objective-C, try Smalltalk. Even try Python. The thing is you can't approach these languages as a C++ programmer; it's like a Windows user using a Mac and saying "The Mac's GUI sucks." You need to learn how this stuff (and proper OO) is used properly, and then the power you can get from it.
This article discusses SmallTalk versus Java. The same can be said for Java versus C++.
I am not a Java fan (its library is junk, IMO), but as a language it's not worse than C++. The only advantage that C++ has is that there are much fewer penalties for writing your own "standard" library.
Now I've landed in a small dotcom and have been forced to learn Perl, PHP and SQL. I use them everyday and after a few months of practice I have ecountered all the pitfalls.
All the pitfalls? Whoa there boy, you are way too optimistic.
Slashdot Mirror
Well, that's interesting then. I wonder if the 8500 is based on the Art-X tech. The Gamecube hardware was finalized before the first Radeon shipped.
The VCD and audio not playing in your DVD players is a matter of format.
What do you mean exactly? (I'd like to know). The audio CDs play fine on everything else, and the DVD player does play real VCDs and Audio CDs.
The only thing I am not sure of is whether or not it is possible to tell the difference between a burned DVD and a stamped one.
I believe that my DVD player can do that :-/
Also, us folks are only really capable of burning DVD-General discs, which are different from factory mastered disks (you can burn those if you want to pay for the equipment). So that's another hurdle :P
It would seem logical that my DVD player would be able to play an audio or VCD burned onto a CD-R, but it can't.
Some DVD players can play 'mini-DVDs' (DVD volume on CD-R, if I remember correctly), some can't.
The point is, if they thought about it, and I'm sure they did (my DVD player is made by Sony, surprise surprise), it's not likely to work that way.
This could be used to hack shit up because after a regular game is authorized another game could be inserted masquerading as the authentic game that was removed.
I would assume that it is as hard to masquerade as another game as it is to be a valid game.
The 3DO was a very hacker-resistant system. The hardware (which I think they called Opera) was a total dud by itself. Now, that was before the days of mass CD-Rs and today's 'net, so maybe it's easier to hack that now.
PPC and ATI Radeon 8500 I believe
PPC derivative yes, Radeon no. It's not even ATi developed hardware. The ex-Nintendo 64 team from SGI founded Art-X, which developed the GPU for the Gamecube (SGI didn't feel gaming was an important or appropriate application of 3D graphics, apparently). ATi bought Art-X, and the original Radeon doesn't have anything to do with Art-X's stuff. The Radeon 8500 follows the Radeon, so, no.
You would probably see it emulated before you see it hacked :) The remaining challenge is getting a drive that lets you read those mini-DVDs.
Just my $0.02 :)
Didn't Lucas have a digital master of this movie? I know a significant portion of the movie was digital anyway, and I thought he was going to run the rest of the film through digital processing so he could get a digital master.
A few common misconceptions here. First of all, most of the drawing in OS X (which I'm using right now :) is done by blitting and compositing graphics. Quartz main claim to fame is its ability to composite graphics (which is how you get translucency). It's also capable of scaling and warping stuff, but those effects are used sparingly, and takes a CPU hit when you do. There's nothing there that a 3D card can't handle.
Quartz 2D does support creating vector graphics, but pretty much nothing you see on an average OS X screen is using vector graphics. The GUI is made up of a bunch of TIFF files.
So why is OS X slow? Because it's just ass slow. 10.1 addresses this. There were a LOT of changes in the last few months before release, and I'm sure making things fast was no where near as important as making things work (and complete!). Honestly, there are things that are just outright broken in 10.0 release (and still in 10.0.4).
10.1 is wickedly fast. But then, look at what you're comparing it too :) For example, top takes up 12% of this CPU (G3/400).
I was going through A Brief Introduction to Forth, and in its section on Factoring, I came across this:
good god, I would suck at this language. How many times have I named variables, even functions, 'foobar,' or otherwise named stuff with some combination of those letters? I've always wondered what names I might end up dooming my children with... I've even used raboof a few too many times to spice things up :(
—
As in,
Both Hewlett-Packard and Compaq have been hurt by price wars in personal computers, where it has been difficult for makers to differentiate themselves when all except Apple Computer are offering operating systems from Microsoft.
Oh whoops. Wrong contents on the clipboard. But I like that quote :)
http://archives.nytimes.com/2001/09/04/business/04 DEAL.html
Makes it a perfect /. article :)
Dear god no, they don't do it the same way! If that way was done at all.
Like I said, it's the same model, but the rendering has NOTHING to do with PDF. You make CoreGraphics calls (CGDrawLine, stuff like that). It has nothing to do with PDF.
but I'd rather think that the GUI is slow because of a slow model rather than just plain crappy programming.
It's totally unoptimized. First you make something work, and then you make it fast. The number of changes under the hood to OS X since even the public beta are very, very dramatic. Even CoreFoundation has had it's share of updates from the 10.0 release to now.
As for OS-X, its slow largely because of Mach. The dated version of FreeBSD (3.2) doesn't help things, but the Mach 3.0 kernel is an absolute dog.
Mach 3 is a research project. Apple doesn't use pure Mach 3, and it's not slow. The dated-ness of FreeBSD has nothing to do with it. We use 3.x and 4.x, and you don't say that one's faster than the other :)
It's only the BSD api and utilities that's at 3.2, it has no affect on performance or usability. OS X is an operating system in itself; it can function without the BSD subsystem. It's an optional install, on by default.
Every so often a disscussion pops up on the HURD list about porting it to something better, but apparently they're quite stuck with it.
Mach rocks. If you ever get involved as a developer of application software with writing code that works with the kernel, it's quite impressive.
Mach is significant because of it's design. Implementations are free to be as slow as they want to be. There's a big difference between pure Mach and Apple's xnu kernel.
LOL! PDF-based rendering doesn't mean it creates a PDF and processes it to draw something, it means it uses the same imaging model as PDF.
Actually, it's almost identical to Postscript, but with Quartz they lose the programmability of PS and the licensing fees (fortunately). They gain "PostScript-like drawing features such as resolution independence, transformable coordinates (for rotation, scales, and skews), Bézier paths, and clipping operations." This gives them a unified model for printing and drawing. And it makes it easy to generate a PDF file, or to render a PDF file (printer spool files are PDF files). But how do you explain this to Joe user? Saying it uses the PDF model for rendering and describing image environments turns to "it uses PDF to draw."
For example, if they said it was OpenGL based, the reaility might be that it uses the same multi-stage rendering pipeline as OpenGL, in that you have data to draw represented by vertices, they get transformed by the model-view matrix, and then transformed by the camera, then clipped to the viewable area, then perspective is applied (3D to 2D), then drawn. But that doesn't mean that it is creating a new OpenGL context and running OpenGL commands every time it draws something.
There's also a misconception that Adobe worked on Quartz. They had nothing to do with it.
So why is it slow? Because OS X 10.0 is just ass-slow. At *everything*. I've got one of them high-end G4s. When I was at the expo and they were showing how fast 10.1 is, I heard some people in the audience say "yeah, but how fast is the machine that it's running on?" Pfft! It looked twice as fast as my machine, and before the expo they didn't come any faster :)
Well, no. You can take Darwin and replace every corresponding component in an OS X distribution, and it will work perfectly (except for CoreFoundation, because Darwin has only a subset called CF-Lite, but the remaining CF code is identical). Darwin is perfectly in sync with OS X release. Actually, the current Darwin is newer than the 10.0 release.
If your assumption comes from the fact that Darwin is slow, then well, I'm sorry, but Mac OS X 10.0 is slow too :(
Well duh, but it's still going to f*ck the user and anything else they might have access too (say their Windows partition).
Trying to achieve total wipeout wasn't my point :)
That was the whole point of the article :)
The Mac encodes the file type as a 4 character code, 'JPEG'. So it's a JPEG file. The Be OS is no better or different as far as I know, except that it was designed after the MIME standard was introduced, so it's in sync with MIME.
Hell, even Apple's ProDOS, which ran on the //e (81? 83?) had file types (creator codes too, I think.. it's been a while since I've done a catalog :)
The AmigaOS (and later BeOS) had Datatypes, an OS-level solution to the JIT file-typing problem... you could install input and output filters for any type of data you had datatypes for, and any program that supported datatypes (e.g. for images, or sounds, or text) could use these modules.
That's exactly what the Mac OS 8-9 has :P
The Mac is doing it's part. Every Mac email program I've used adds MIME types, they have no obligation to add file extensions. The Windows apps ignore that info though.
Yes, and there are apps that sort of masquerade as files, particularly READMEs. But what difference does it make? If there's one thing I've learned as a software developer, users do NOT read Readmes.
If you're in list view the Mac will tell you it's an application. But fortunately, it's harder to write malicious code on a Mac than it is to do, say, #!/bin/sh, rm -rf /. You'd have to look up the file system API in a reference book, which reduces the trojan-writing to be uncool.
A lot of things would be better if the 'lower' OSes would just pay attention to MIME types. But there's one obvious situation where it falls apart.
Joe Mac User makes an HTML document referencing a bunch of JPEG and Flash images. The JPEG and Flash files don't have extensions in their names. He sends his HTML directory to his Windows-loving friend. Assuming that the Windows or Mac apps payed attention to the file types (either Just In Time on the Mac to add extensions, or the Windows app payed attention to MIME), the user's documents would have appropriate extensions added to them. The Windows user's HTML is busted.
While it royally bites that I have to put up with extensions in OS X, I can understand why Apple did this.
You non-tech-savvy computer user (I'd think that's 80% of computer users out there), are damn clueless, and would be completely unable to fix that HTML example.
In 1969, Raskin wrote a paper called "The Quick Draw Graphics System," or something like that. His argument was that processing power should be devoted to aiding the user, by drawing graphics to present an interface.
That was pretty unthinkable at the time. Parc hadn't been founded yet, and for those who don't know, it was Raskin who started the Macintosh project at Apple, before they ever went to Xerox.
Historians take a look at the past from primary documents. News reporters don't, and there are a lot of false truths out there, like "Xerox invented the GUI, and Apple took it and popularized it." Don't believe it's true unless if you hear it from the horse's mouth.
He helped change the course of computing. He doesn't feel Apple's doing that anymore (and they're not, they're just helping it evolve).
Still, I think he wants Apple to do too much too fast. Apple could have made landmark changes with Mac OS X's interface, but who would have wanted to use it? If it can't run Office, people won't buy it.
At this point, Apple's best off bringing change in bits and pieces, because Mac OS users are already freaking out with the changes in OS X.
It has nothing to do with Java having networking built in mind, it's just the java.net libraries.
If it's important to you, build your next app with a good base library. OOP can be a royal pain unless if you have a good framework to build on. C++ doesn't have one (just model objects & stuff). Java has a fairly crappy library that's supposed to scale from applets to servers.
Something (crappy libs) compared to nothing (C++) tends to win.
Personally, I find GNUstep and Cocoa to be much more useful and productive.
The problem is that anything can be attached to a PDF (executables, VBscript), and these things can be viewed using Acrobat. Does Acrobat run these things automatically, or what?
Otherwise, it's no more of a virus than sending a VBscript to someone who uses Eudora.
Then of course there's piracy, which I guess is what they're afraid of. It's too easy for me to retransmit something I bought to someone else. I wouldn't do that though; if I spent my $40 on something, I'm not going to give it up to someone else for free. Duh. Of course, if you got it free, you don't care if you give it to someone free. They need to put value into owning something. Additionally, IMO most people are willing to play fair as long as they don't feel they're being ripped off.
But stupid stupid stupid. Here's a situation where people clearly want something—interesting stuff to read. People are willing to pay for that. The problem is where you have a clash of free content (I can write any interesting stuff on my web page and 'publish' it) and paid content (why should I pay if I can get it for free? Ah hell, I'll just steal it). Sorta like free software vs. commercial software. There's value in the commercial stuff, but how often do we need it?
Keep in mind, I fully need my Mac and have no political problems (as opposed to financial) paying for lots of good quality commercial software (WTF people buy outlook, I'll never know). There's lots of room for free software & content. It's really a shame that for the longest time we've had to give up hard earned money for those things.
In most cases, I'd say this argument is f'ing idiotic, but the Camry is a damn good car.
Actually, Interface Builder supports making nib files for Carbon applications (C and C++) now. If OpenOffice is written using C++, it would be too hard to use Objective-C because you can't call C++ code from Obj-C and vice versa (the Objective-C++ compiler is too old).
No it wasn't! After looking at the situation for a few minutes, I was able to undertand why the compiler barfed at me. But that's exactly my point...
In time I've come to prefer simple designs that scale well. I find that C++ is the exact opposite of that :P
I personally think the best way to get Linux Desktop development off the ground would be to pour resources into GNUstep.
FUD? I dealt with that yesterday. Too often you write code that you would expect to work, but have to break it down because the compiler doesn't like it, because C++ is enforcing its overly complex design on you.
not least a forced mix of value and reference semantics, which is the root of one of the article's main complaints.
I was talking about the section on language syntax complexity.
Have you used any other OO languages? Besides Java? Because C++ is not the holy grail of OOP. I have a hard time considering it an OO language. The problem gets worse when you use the STL, which shoots programming complexity through the roof.
OOP is supposed to make things simpler, to encapuslate stuff and take crap out of your way. Hopefully, you sit there coding the logic that goes with your data, and get everything to work together as one big happy family. With C++, you spend time figuring out why the hell you can't get this innocent-looking line of code to work:
const Foo &bar = myMap[foo];
The answer is that foo is a const object (something like that anyway). Then you have to figure out how to get something out of a map without using overloaded operators (I'm not a fan of overloaded operators, in any language).
I've heard people say things like Java is a lesser language, because it doesn't have templates. Java doesn't need templates. C++ needs templates as a hack to support wickedly (and I mean that in a bad way) strong typing.
C++ is best as a compromise between C and object oriented programing. The STL is "nice" because it allows you to put plain structs and any other C type into containers. If you have to mix C code and object oriented programming, C++ can be very convenient. Personally, I'd rather use C with Object Oriented Design.
Stroustrup's book has 40 pages of technicalities for C++. That's far more pages than what covers the standard library for K&R's C book. C is a well designed language that's easy to use and very productive. As it says on the back of K&R, C wear's well as one's experience with it grows. I've been using C++ for a long time (pre-exceptions, pre-multiple inheritance), and as time goes on, I learn more and more about the intricacies of the language. There's much less to appreciate about it. I spend more time programming the language (templates, constructor initializer lists, overloading operators, making stupid function objects, and all the specific syntax you have to use to support that stuff) than I do programming my own code. If you want to use the STL, you need to waste your time doing these things.
Try Objective-C, try Smalltalk. Even try Python. The thing is you can't approach these languages as a C++ programmer; it's like a Windows user using a Mac and saying "The Mac's GUI sucks." You need to learn how this stuff (and proper OO) is used properly, and then the power you can get from it.
This article discusses SmallTalk versus Java. The same can be said for Java versus C++.
http://www.smalltalkchronicles.net/edition3-1/whyj ava.html
I am not a Java fan (its library is junk, IMO), but as a language it's not worse than C++. The only advantage that C++ has is that there are much fewer penalties for writing your own "standard" library.
All the pitfalls? Whoa there boy, you are way too optimistic.