Slashdot Mirror
Cross With the Platform
Tim Bray tweeted, No platform has hit the big time till it's been flamed by JWZ. He was referring to this rant in which Zawinski systematically dismantles any claim the iPhone has to cross-platform compatibility. "I finally got the iPhone/iPad port [of Dali Clock] working. It was ridiculously difficult, because I refused to fork the MacOS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right? Oh ho ho ho. I think it's safe to say that MacOS is more source-code-compatible with NextStep than the iPhone is with MacOS. ... they got some intern who was completely unfamiliar with the old library to just write a new one from scratch without looking at what already existed. It's 2010, and we're still innovating on how you pass color components around. Seriously?"
The OS is the same, but UIKit is NOT the AppKit. It's like bitching against linux when trying to build your Qt code against gtk.
The only valid complaint I see in this whole article is with NSColor/UIColor – NSColor really should be in the Foundation API (common to both Mac OS and iPhone OS), not the AppKit/UIKit APIs.
His OpenGL example is hilarious. "Oh my god, I can't use glBegin and glVertex"... Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!
As for UIKit being very different from AppKit... Well of course it is! UIKit is for building touch based UIs, if you transfer the exact same things as you have on Mac OS straight over, you end up with a shit mishmash of rubbish. The important thing here is that both APIs share their Foundation API (the basic programmery stuff you need like dictionaries, arrays, strings, etc).
No thanks.
Personally, I hate web apps. They're still vastly inferior to desktop applications. They need a constant connection, are less responsive than a desktop app, are limited in the GUI they can have, work or not depending on the browser, and are in many cases outside of my control, which is excellent for lock-in.
There still are many places where I have no internet connection. It happens when travelling in the underground. It's frequent above the ground in a train in some areas. It's unaffordable when roaming. It doesn't work in the middle of nowhere. I find it unacceptable to lose access to my stuff just because I happen to be somewhere without a cell tower.
What we need is more open architectures, where anybody can make anything they want without interference.
Um, not quite. The company doesn't control whether you can release the app to a device. The company controls whether the app will run on a device (either by buying the app through an app store or paying a set fee to the company). This isn't too far off from the XBox 360, either. To some extent, it's not that far off from most any commercial library/OS (the main difference is whether you effectively pay the fee upfront or whether they try to nickel and dime you later).
Apparently the Dali Clock is a rather old program (nearly 20 years) that's been ported to a variety of platforms. Presumably, the author chose to port the Dali Clock to the iPhone precisely because it was supposed to be relatively trivial to port from a Mac OS X version. The blog highlights how untrue that ended up being; comments on the blog suggest it's because Apple provided multiple graphical APIs and if the author had been lucky several years ago, he would have chosen the one that worked on the iPhone.
In short, it doesn't sound like the author bought his iPhone to write apps for it. It was more a porting exercise to see just how trivial the task would be.
No doubt. But, then, most blogs are a "[waste of breathe]". These comments, both yours and mine, would likely qualify as well. I don't think that'll stop me from commenting or considering the blog for what it is, a recognition of Apple having the same sort of failings that Microsoft does: designing too many APIs/interfaces/file formats, dropping support for them whenever they can, and generally being about as bad as any other platform when it comes to having a unified, solid solution to the many problems that exist for the developers. I will give Microsoft some credit, though, for generally waiting longer than most public, commercial software companies in maintaining strict backwards compatibility.
Eurohacker European paranoia, gun rights, and h
Entirely correct @ shaders.
However, I have to take exception with your description of immediate mode - the reason it performs so poorly now is that modern graphics chips are designed pretty much exclusively for DirectX (at least, this goes for ATI).
On machines where immediate mode performance was actually some kind of a priority (for instance, SGI Octane IMPACTSR and relatives), executing a glVertex command amounted to 3 memory writes into a command FIFO that was mapped into a fixed address in userspace which was accessible with a short form of a SW opcode (remember, this is MIPS, there is a range of 64k addresses that can be accessed without loading a base register: -32768 to 32767).
The hardware even managed the hiwater/lowater status of the fifo, and notified the kernel to perform a context switch to a non-gfx process when the gfx process was filling up the command FIFO. Those switches were as a matter of fact "virtualized" (before it was cool) by a combination of hardware, kernel (if hardware contexts are exceeded) and userspace - not entirely unlike what DX10 ADM was supposed to be, except this was in 1995.
For large static meshes (only transforms applied with Vertex Shaders), buffers are definitely going to perform better, because the meshes can be located in local memory (VRAM). However, if something is dynamically generated, immediate mode in a good implementation is no slower than a memcpy, and it does not require a kernel transition to submit a command buffer to card's ring (like modern cards like to do).