That's like a Windows user saying the command prompt sucks because all they're used to is DOS. Any great idea can be implemented poorly.
Re:How can I submit feature requests to Apple?
on
10.4 on Display at FOSE
·
· Score: 2, Interesting
Apple guys always say to just post your bug and they'll work out if it's a duplicate. They count duplicatations as votes for getting that bug fixed or feature implemented.
You realize, right, that this is the exact opposite of what the German government is trying to do? As a nation they are terribly ashamed of what happened and take steps to inform people that it did happen. I've got a government tourism(!) pamphlet that rails against Nazi actions during WWII in relation to some chateau that was used as an HQ at one point.
Now, sure, the censorship thing is over the top, no blood in video games, no Nazi symbols, etc. But the objective is categorically *not* to sweep it under the rug.
I don't know about Doom 3, but Quake was coded in Objective C, which, as the name suggests, is most definitely object-oriented.
Now, I really love Objective-C and hype it 'till people are bored of hearing about it... but Quake simply wasn't written in it. Here's the source code to prove it:
ftp://ftp.idsoftware.com/idstuff/source/q1source.z ip
I think you're thinking of the original tool set that *was* written in Objective-C. If I remember correctly a lot of the original Doom code was developed on NeXT boxes too. Too lazy to find a reference for that right now though.
Having precious few good PDF viewers on Linux should tell you something about its readiness as a desktop OS. If someone like you, adept enough to be reading/. and hold opinions about file formats and viewers, has a hard time reading a PDF file then that probably tells you more than that report ever will.
Take it easy,
Guy
OSX Server 1.0 was what Rhapsody became. It was based on a Mach kernel with a BSD personality in the kernel space and a driver model that uses Objective-C. Threading API is cthreads. The user land was BSD but a little outdated. It used the classic NeXT stuff like Display PostScript, all OpenStep APIs, directory layout, plist format, etc. It had the BlueBox for Mac OS compatibility. It was a full screen app that ran legacy stuff in a single Mac OS context. Look and feel is of OS 8ish widgets but you could customize the colors (so you'd have blue windows with tan window backgrounds, etc).
OS X isn't built from BSD. It has an updated Mach kernel and retains the BSD personality in kernel space. Threading API is pthreads. It does share some of the filesystem and network code with the BSDs. The driver model (IOKit) is drastically different from standard BSD and uses C++. The user land is FreeBSD 4.4-ish come Jaguar. "Classic", the compatibility system, is essentially a rootless BlueBox. It retains OpenStep (as Cocoa) but adds Carbon (modern ToolBox API). It removed the DPS server and went for the shared memory model of Quartz. Obviously it introduced Aqua.
All that said. Nope: There was never any clear upgrade path. For a while Apple was even selling the OS but it wouldn't run on any of the machines they were shipping. They botched the upgrade to 1.2 and generally wished it was dead and buried. See www.stepwise.com for the gory details. Was it a dead end? Yeah. Better to avoid? I used it as a development machine to play with the OpenStep APIs and was very happy to have used it. As a production server it was lacking.
The image buffering thing is really unsettling. Given that Quartz is an inherently vector-based system, wouldn't it make much more sense to store the vector representation of the window, rather than the image contents? The memory requirements for this would be much more nominal.
No.
- Its not all vector based, there are plenty of bitmaps flying around.
- A backing store is "the right way" to do it. The perpixel backing store is what allows all the funky blending operations like shadows & transparency.
- A hack exists to turn on the built in backing store compression which substantially cuts the memory usage. If a windows contents don't change for a while CoreGraphics will automatically compress the backing store and decompress it again when it needs to. Fast, efficient and effective.
- Memory is cheap, OS X is designed to last a long time. You should avoid assumptions based on todays hardware when designing something thats meant to last. CoreGraphics will scale well to future generations of graphics cards with tons of on board memory. These cards could render to on board backing stores and composite them totally off the processor. 3D cards do most of this work now, its only a matter of precision and flexibility before this becomes common.
In reference to the main article, I'm always impressed with Johns ability to communicate his opinions. I don't always agree with him but its always worth a read, this one being no exception. Unless he flames me with that extensions vs type/creator code again, then he can rot in.hell:)
Slashdot Mirror
Troll!? I think it's a modest proposal and brilliant to boot.
That's like a Windows user saying the command prompt sucks because all they're used to is DOS. Any great idea can be implemented poorly.
Guy
Uh ... isn't most of the planet pissed at America right now?
You realize, right, that this is the exact opposite of what the German government is trying to do? As a nation they are terribly ashamed of what happened and take steps to inform people that it did happen. I've got a government tourism(!) pamphlet that rails against Nazi actions during WWII in relation to some chateau that was used as an HQ at one point.
Now, sure, the censorship thing is over the top, no blood in video games, no Nazi symbols, etc. But the objective is categorically *not* to sweep it under the rug.
Take care,
Guy
I think you're thinking of the original tool set that *was* written in Objective-C. If I remember correctly a lot of the original Doom code was developed on NeXT boxes too. Too lazy to find a reference for that right now though.
Having precious few good PDF viewers on Linux should tell you something about its readiness as a desktop OS. If someone like you, adept enough to be reading /. and hold opinions about file formats and viewers, has a hard time reading a PDF file then that probably tells you more than that report ever will.
Take it easy,
Guy
OSX Server 1.0 was what Rhapsody became. It was based on a Mach kernel with a BSD personality in the kernel space and a driver model that uses Objective-C. Threading API is cthreads. The user land was BSD but a little outdated. It used the classic NeXT stuff like Display PostScript, all OpenStep APIs, directory layout, plist format, etc. It had the BlueBox for Mac OS compatibility. It was a full screen app that ran legacy stuff in a single Mac OS context. Look and feel is of OS 8ish widgets but you could customize the colors (so you'd have blue windows with tan window backgrounds, etc).
OS X isn't built from BSD. It has an updated Mach kernel and retains the BSD personality in kernel space. Threading API is pthreads. It does share some of the filesystem and network code with the BSDs. The driver model (IOKit) is drastically different from standard BSD and uses C++. The user land is FreeBSD 4.4-ish come Jaguar. "Classic", the compatibility system, is essentially a rootless BlueBox. It retains OpenStep (as Cocoa) but adds Carbon (modern ToolBox API). It removed the DPS server and went for the shared memory model of Quartz. Obviously it introduced Aqua.
All that said. Nope: There was never any clear upgrade path. For a while Apple was even selling the OS but it wouldn't run on any of the machines they were shipping. They botched the upgrade to 1.2 and generally wished it was dead and buried. See www.stepwise.com for the gory details. Was it a dead end? Yeah. Better to avoid? I used it as a development machine to play with the OpenStep APIs and was very happy to have used it. As a production server it was lacking.
We have Medicare and "boot to the ass" is covered.
A quick interview with ATI here:0 01 31.html
http://www.sourcemagazine.com/csm/Forum2/HTML/0
The image buffering thing is really unsettling. Given that Quartz is an inherently vector-based system, wouldn't it make much more sense to store the vector representation of the window, rather than the image contents? The memory requirements for this would be much more nominal.
.hell :)
No.
- Its not all vector based, there are plenty of bitmaps flying around.
- A backing store is "the right way" to do it. The perpixel backing store is what allows all the funky blending operations like shadows & transparency.
- A hack exists to turn on the built in backing store compression which substantially cuts the memory usage. If a windows contents don't change for a while CoreGraphics will automatically compress the backing store and decompress it again when it needs to. Fast, efficient and effective.
- Memory is cheap, OS X is designed to last a long time. You should avoid assumptions based on todays hardware when designing something thats meant to last. CoreGraphics will scale well to future generations of graphics cards with tons of on board memory. These cards could render to on board backing stores and composite them totally off the processor. 3D cards do most of this work now, its only a matter of precision and flexibility before this becomes common.
In reference to the main article, I'm always impressed with Johns ability to communicate his opinions. I don't always agree with him but its always worth a read, this one being no exception. Unless he flames me with that extensions vs type/creator code again, then he can rot in
Take it easy,
Guy