Misbehaved applications or operating systems, distributed widely, can perform the accidental equivalent of accidental Denial of Service attacks. It happens. If it happened on the iPhone, Apple might suffer greatly. Their stock price would plummet. Sales might lag for months. They might find it harder to get agreements with carriers.
Just because Symbian, PalmOS, and Windows Mobile platforms allow uncontrolled developent and distribution of 3rd party applications doesn't means that this isn't a somewhat risky proposition for the network provider and platform maker. Given the sheer volume of scrutiny that Apple is getting as a result of being a late entrant to the cell phone market, I'd say their caution is warranted. I'd love to see them thinking hard enough about this issue to come up with some ways to help prevent it on their platform. Signed applications distributed through Apple? That might be a pretty reasonable model for a while. Who knows, maybe it would work so well that the model could be extended to the desktop/laptop market without adversely affecting consumers or 3rd party software developers. Maybe they'll decide to open it up wide later, but when they are getting started, I'm happy enough to see them exercising caution on this issue. It's probably not the *only* reason they are being cautious with the SDK/API, but it's certainly a real *enough* reason. It's not a smokescreen.
There have been a number of incidents with cell phone networks like this. The service providers are really freaky paranoid about updating software on the switches and other network components, and are utterly loathe to update the firmware on the cell phones partly because they live in constant fear of unintended consequences of change. The change control procedures on the software systems for the network devices are mind numbing.
These incidents don't get published, just like most worm outbreaks in large corporate and government networks don't get published. I know a lot of them happened because I saw them first hand. Can't prove them to some random snit on Slashdot, however. The victims are often more afraid of the bad publicity than anything else that could result from an incident, and they eschew publicity. (The world would probably be a better place if they did share these experiences more widely, because lessons could be learned, software and procedures improved, etc., but that's not how managers of bureaucratic organizations operate just yet.)
To those demanding to see a link, I say: Well, since most of the people who actually know things like this are restricted by NDA agreements and also have the integrity to honor those agreements, perhaps first, you prove to us that pluto exists. I'm not talking about some white dot that could be a pin prick on a slide. You don't really know that Pluto exists, and nobody here has time to educate you in both epistemology and information technology so that you understand enough that we can "prove" everything to your pathetic satisfaction. Before mouthing off and demanding a link as though that constituted proof, maybe you should start by asking yourselves, "hrm... why would he lie about this?" If there are no compelling motivations for a big lie, then maybe, just maybe, he's not lying. Or maybe you don't believe him because you yourselves lie so often that you don't believe anyone else? What a sad life that must be.
You're right on target. Furthermore, Apple has a long history, going back to the founding of NeXT, of being exceedingly careful with the publication of new API and SDK. They typically develop at least one application which makes extensive use of the new API, and ship that application first. Then they get feedback on the application, go through another app development cycle, improve the API, etc. Finally, after they are very happy internally with the API, they might publish a public version of it in a developer release of the next release of the OS, and get feedback from developers, incorporate that feedback to the extent possible, and then ship the API. Then, they sometimes go through that cycle again with the next release of the OS before the API has really settled.
This is a somewhat painful process for those of us on the outside, and it normally takes a couple years before the API is published. However, it has resulted in API which, on the whole, are widely respected by talented developers with experience on multiple platforms. Some of those API have evolved only modestly since initial creation, some of those over 15 years ago, and are still regarded as advanced and modern.
It's also clear that Apple will need to accelerate this process a bit for the iPhone, simply because they want to develop *several* applications internally. They need the API and developer tools themselves. The good news is that this will also give them the experience with making different kinds of apps which will help round out and debug the API faster. We won't need to wait two years for the first version of the API. There is a non-zero chance we might see it, or at least hear about it, at WWDC 2007, the Cocoa API, not merely the Widget API.
It's clear that Apple has legitimate reasons for wanting to get the application development stuff "right" on the iPhone. The app market on most of the other cell phone platforms is really a disaster in the making. In addition to zillions of apps that are utter crap, which drag performance of the device down to unbearably slow, which crash and which feature generally poorly integrated UI, there is the looming threat of malware. There have already been a few malware incidents, and one of these days there will be a big, big malware incident. Apple doesn't want to be the platform that got nailed first. They don't want to get nailed at all.
Apple was intentionally vague about the SDK at the announcement of the iPhone because they didn't have all the answers lined up, really, none of them. But there will be a 3rd part app market at some point. And it will be huge.
I have noticed that there is a remarkable amount of hostility in discussion forums all over the web, even though the articles by thoughtful reviewers tend to be rather positive, and clearly enough people are impressed by what they've seen so far to send the stock price through the roof. Places where there are only half a dozen comments, where geeks normally don't hang out and discuss stuff, places that are normally total fanboi sites that typically sport little criticism, etc. are littered with really hostile comments. One article at The Register had a discussion thread about stabbing an Apple fanboi repeatedl in the face for saying something nice about the iPhone. Good grief. I suspect a paid astroturfing anti-campaign.
See, that's just the thing. It's the software that will make the iPhone interesting. So the flip side of your argument is that you won't be able to run OS X software on the Windows Mobile based smart phones. That's a pretty serious detraction. I don't want some MP3 player patched onto my phone with duct-tape, I want the iPod version of iTunes, integrated seemlessly. I don't want some rinky-dink pretend-to-edit-a-spreadsheet-on-your-phone crap. Nobody really does that on a 2 inch screen with 100 dpi resolution. I want random access to my voicemails. I want Google maps so easy to use that you know how to use it from watching the damn commercial, without having to read the manual or sign up for a training session. I want seemless access to wifi hotspots and EDGE, until the day AT&T has their HSDPA network in place and I can upgrade to 3G. I don't want the endless futzing that is the hallmark of Windows 802.11 access.
More importantly, the innovation loop for Apple is pretty tight. I have an idea for something that I would like on the iPhone. I describe the idea and submit it to Apple's Bug Reporter system at Apple Developer Connection. They ponder it, maybe even improve it, and implement it. I get it on my iPhone in a future software update. I know this will happen because I've done it a bunch of times with Mac OS X.
I also know from experience that this loop is broken for Palm OS, Windows Mobile, and Symbian. Trying to help them improve their products by giving them an idea is really pretty futile. It's so bad that the hacker underground has been hacking assembly code and patching firmware to fix bugs. Oh, yes! There is actually an underground community and 3rd party market in hacking assembly code on cell phones to fix firmware bugs and even some UI issues on cell phones. That is so mind-bogglingly broken I have to meditate for a moment. I'll be right back... OK. Whew. Man, that's so broken. The entire industry is broken, that's so broken.
That's so broken that a guy who heads a company that makes PCs and MP3 players decided he finally had to bet the farm and try to fix it, because it was clear after five years of watching it carefully it was never going to get fixed by anybody else. Oh, and thousands of people were begging him to try to fix it, too.
It's even more broken than that, however. Suppose not an end user like me, but, say, a handset maker or wireless carrier has an idea. It's pretty clear from the extensive track record that the pace of innovation in software on PalmOS, Windows Mobile, and Symbian is really a lot slower than it should be. The handset makers using Symbian couldn't get ideas into Symbian fast enough, so they tried to solve this problem by building their own custom layer on top of Symbian, basically they are implementing their own OS as a layer on top so they can get changes in faster. The result has been at least three incompatible Symbian versions now, and they are sagging under the weight of the alliance that was supposed to provide a common platform. The 3rd party app market suffers. The vendors suffer. The users suffer. But nobody fixes the problem, because they all think of the problem as whatever little piece of broken bit they are looking at right now. They don't realize the problem is that a "common platform" has suddenly become a burden, drains resources from their developer communtiy, drains developer resources from the handset makers, and leads to a substantially heavier burden of bugs and performance and compatibility issues on the end users. Nobody realizes the problem is really the broken process for getting feedback from customers and turning it into software.
Flash based UI are another way to try to solve this problem. Here again, we see an attempt to recreate the full features of the OS so the handset maker can "innovate" without letting the handset maker actually change (imrove or fix) the OS, and without the OS vendor changing it for them. The result is a tower of complexity, brokenness,
When I started my first business, I spent about $1500 for help from an attorney and a CPA, both specialists in corporate law and tax law, respectively. I'm not facing jail time nor massive penalties, so I'm guessing that was money well spent.
Oh, I'm not really sure how much to make of the Leopard delay anyway. It seems likely that the iPhone will be the first Apple product to ship on a Leopard version of OS X.
Call the county health department and have them test your water. Tell them to look for high levels of lithium, anti-depressants or other mind altering substances.
Palm just announced that they hired Jon Rubenstein and sold a chunk of the company to raise cash for CPR. If their next step is to fire their entire managment team, they might have a chance.
The worst part is that those 15 problems could have been fixed by the vendor but the industry is distorted so that doesn't happen. Before the iPhone, the maker of the handset was under the impression that the telephone company was their customer, and they really don't care one iota about you, the person who must use the device. This little love-fest between the telcos and handset makers results in the consumer being left with no place to turn. It costs the telco money to fix problems on your handset, because they "signed off" on the "final design" months ago and the handset maker has moved on to work on new models. They would rather sell you a different phone altogether than fix the crap software on the handset that you already paid for.
A few weeks after the iPhone ships, Apple will release a software update for it. That will be the day the cell phone industry really changes. When people realize what a difference a vendor that treats them like a customer will make in their satisfaction of the handset, the industry will never be the same. All the pundits are focused on the magical multi-touch UI, and all the vendors are racing to catch up to the sleek hardware design and clean user interface. The software updates are the secret weapon.
You've just explained why Ginger hasn't been the society revolutionizing technology that it was, uh, hyped to be. When cities started banning the thing from their sidewalks to prevent pedestrian injury, it became quite clear that cities would need to be litteraly re-engineered to achieve the large scale society improving benefits that were predicted for it, and that cities in fact would not be re-engineered.
You could, if you tried, have the courage to engage jcr in a good argument. A nice start would be posting, as he does, using a handle that can be easily tied to your real name and professional reputation. You may find that it clarifies the conversation a bit. One tends to reserve labels like dimwit for, well, actual dimwits.
M: I came here for a good argument.
A: No you didn't; no, you came here for an argument.
M: An argument isn't just contradiction.
A: It can be.
M: No it can't. An argument is a connected series of statements intended to establish a proposition.
A: No it isn't.
M: Yes it is! It's not just contradiction.
A: Look, if I argue with you, I must take up a contrary position.
M: Yes, but that's not just saying 'No it isn't.'
A: Yes it is!
M: No it isn't!
Regarding the two things the iPod can't do... I haven't tried it myself, but an inexpensive 3rd party product which can waterproof your iPod will enable it to perform one of the two tasks on your list of things the iPod can't do, leaving you with taxes.
Palm will be the first victim of the iPhone. They so completely failed to grok their product and market that they were nearly crushed by WinCE. Imagine that. *shudder*
See, this is where the argument falls apart. The "in" crowd, aka "too cool for school" aka "hipster" crowd isn't even aware that the iPhone is a computer. They don't care about that. They may like the fact that the device is "sexy", but they want it to work well, too. The iPod took off with this crowd because it worked. There were many dozens of MP3 players trying directly to capture this market. They failed ultimately because their devices suck. Apple solved that problem. Honestly, the iPod doesn't suck. You know that, if you have any clue at all. You don't even need to have ever owned one to know that. In the same way, using the fantastic pattern recognition engine that is your brain, you can anticipate that, come June 29, their will be a cell phone on the market that doesn't suck, for the first time giving ordinary non-computer-geek people something that a lot of them already know they want: the internet in their pocket. There is no reason why Apple should have had to make a phone to please Steve Jobs. In fact, they resisted the temptation for a long, long time. Finaly, almost three years ago now, they gave up and decided to fix the problem themselves.
I for one welcome our new suck-free cell phone overlords.
Please consider submitting your request for Polish language support in Mac OS X to Apple via the Apple Developer Connection. It's free, as in T-Shirt (e.g. you need to fill out a little form with a bit of contact information including an email address). Obviously you're interested in the platform. If there's a store selling Macinsoth computers in Poland, then other people are, too, and you would be doing yourself a favor to point this out in your request. Include a URL to the store's contact information, if possible. Mac OS X provides pretty nice localization support for quite a few languges already.
By the way, the original post was a reference to a troll that showed up, if I recall correctly, early on, in every Apple related thread and a few unrelated threads for a while. I recall some speculation that it might even have been an automated troll bot. The AC poster this time was clearly trying to make people laugh by converting the troll to an iPhone troll with a trivial substitution Macintosh -> iPhone. The tip-off for people who didn't recognize the post is that nobody will be copying a 17MB file from a device (the Motorola RAZR) which only has, if memory serves, about 5MB of RAM (newer versions of this phone might have more RAM, but the most popular early model was RAM starved). It was really a bit of an inside joke, as grokiing it requires familiarity with too many things that nobody should bother to remember.
Apple doesn't seem to have described the localization features of the iPhone, although their plans to relase an iPhone in Europe later this year suggest that they are planning at least some support for other languages. The U.S. version of the phone could be limited to English and Spanish, or even merely English without hurting sales too much. As the hardware platform matures (mainly as solid state storage becomes cheaper at larger capacities) it's reasonable to expect that future versions of the iPhone will support multiple languages as a general feature, as does Mac OS X. But then, it's also reasonable to expect the European version of the iPhone to support 3G data networks, and we all know that won't stop people from whining about the presumed lack of 3G and how the iPhone won't sell in Europe without it, as though Apple doesn't know that. (Don't these people think Steve Jobs wants 3G on his iPhone? I'm sure he's personally lobbying AT&T to get their poop in a group and roll out 3G before they get crushed by Verizon's EVDO stuff here. )
Oh, and that store isn't an Apple Store, by the way. Apple doesn't have any Apple Stores in Poland.
I don't think you need to take an economics course to learn this. Anybody who forms a corporation should have an attorney and a CPA. Oneof those two people, if not both, should have said, "If you want to raise money that way, you need to follow certain rules, or you need to factor jail time for the corporate officers into the business plan."
Well, I'm sorry to be the bearer of bad news, but you haven't spelled anything out. In fact, you've accidentally helped me develop my case. We'll get to that in a moment, but first let me mention that interlocking design elements of the CPU, compilers, and programing languages combine to make buffer overflows possible.
To the extent that portions of POSIX are specified in terms of C or assume C language features, and to the extent that such dependencies upon the nature of the C language, compiler, and host CPU make buffer overflows possible, then, yes, you could say POSIX is broken. However, there is a corpse missing. If it were POSIX that were responsible for buffer overflows, then Microsoft's nortoriously broken implementation of POSIX on Windows NT/2000/XP should have either insulated them from buffer overflows (because it didn't work any better for worm authors than for anybody else), or exposed them to myriad POSIX exploiting buffer overflows (because it somewhat worked, and the presence of POSIX was responsible for buffer overflows). In point of painfully obvious fact, neither happened. It is the Win32 and related Microsoft API, not POSIX, that exposed Windows users to rather more buffer overflows than all the factually POSIX compliant systems on the planet combined. Yeah, the POSIX API is a little long in the tooth, and sure, parts of it are sub-optimal, broken if you like, but certainly not directly and soley responsible for buffer overflows as you imply. Good grief that's a silly notion. Where are all the POSIX worms? Last I checked, Win32 and application worms dominated.
Furthermore, it's certainly possible to dramatically reduce the exposure of a UNIX operating system like Linux or Mac OS X to buffer overflows, by re-implementing certain widely used network-facing services in a more secure language like Java. Why are BIND, Sendmail, IMAP servers, file servers like Samba, and application servers like Apache still largely written in C based languages? POSIX certainly isn't to blame for that. You can't even blame the limited POSIX security model, since it's been extended with more modern ACLs for quite some time. In most cases, we can't even blame language performance issues. In contrast with its reputation for poor performance on GUI tasks, Java gets pretty good marks for raw server side type benchmarks. Whey don't we see one or more of these projects refactoring in Java? Nothing about the modular flexible nature of the UNIX architecture prevents this.
The FUD about Mach is likewise painfully tedious. Mach's infamous performance problems apply to research versions of the kernel that neither NeXT, nor Apple, nor DEC, nor IBM, nor anybody else who's using Mach parts in their kernel ever shipped. Aside from being utterly irrelevant on the grounds that no shipping product was observed to have them, the performance problems were largely due to issues that don't apply when the UNIX server is compiled in with the Mach kernel, as it is with the BSD server in Mac OS X. Those infamous performance problems were due to the research attempt to run the API server in user space, so that the kernel could support multiple "OS personalities", and so that an execution thread could be made more easily migratable from one host OS instance to another. Those were a couple of interesting goals that appealed to a few geeks and super computer researchers, but were not relevant to a desktop or server operating system. Nothing much was sacrificed when Mach and BSD were united in one happy binary.
Conduct a little thought experiment. If there existed a massive performance delta in raw kernel performance between, say, Mac OS X and Linux, it would be easy to demonstrate, if, say, you could run both kernels on the same hardware easily, say, an iMac, Mac Mini, MacBook, etc. These problems would be widely documented by now, many months after the Intel platform equalized the hardware b
A programmer who is too proud to think about how other people solved the problem they're looking at is much more likely to invent a wheel with some number of road-contact surfaces "n" where n > 1.
UNIX has survived (indeed thrives) as a result of a number of major refactoring efforts, directed not only at improving the internal architecture, but even the underlying abstractions. Consider Mach and the microkernel revolution, which resulted in nearly every major operating system kernel being refactored to accomodate the design abstractions described in Programming Under Mach.
And now class, let us rejoin the mind to the body and gaze into the heart of the candle in meditation.
Hrm... you seem unaware that the very desktop (and mobile) friendly Macintosh and the coming generation of iPhones, iPods, and probably other digital appliances from Apple are based on a real UNIX underneath? The UNIX foundation of the system design is partly responsible for the rapid pace of evolution of Mac OS X.
Although extreme hubris might combine with extreme resources (both dollars and talent) at Google to lead to the creation of an entirely new OS from the ground up, there may not be any need for that. The UNIX wheel is relatively round these days, particularly considering the Mac OS X / OSX example. Better yet, UNIX is nicely modular. If anyone devises a clever way to "avoid buffer overflow situations" it seems likely, on the basis of past evidence concerning technology development and adoption within UNIX systems in general, that it would be easier to integrate that language and compiler, or whatever technology it happens to be, into a UNIX operating system than it would be to create a fully capable system on top of it from whole cloth.
Since you seem genuinely interested in the topic, here are some reasonable books on operating system design which you might enjoy.
The other issues you raise are largely issues of interface design, which the open source community seems to do rather poorly, or at least not as well as it does other things. Google certainly does not need to re-invent the entire operating system wheel to improve URL integration, or provide a "minimalist" desktop interface, for example. They don't even need to strip features, really. Mac OS X, for example, provides enough of a minimalist default interface that novice computer users are comfortable with it. A Linux based OS from Google could take a similar approach, perhaps being even more spartan in the basic features, if that's really a desirable goal (which is another question entirely).
This should drive home the point that connections should flow over encrypted tunnels whenever possible, to reduce the ease of performing man in the middle attacks. If this session flowed over an SSL style connection, the man in the middle would first need to figure out how to get into that session. That strategy seriously reduces the places where malicious code can exist "in the middle". Don't throw the baby (rich client interaction with services in the cloud) out with the bathwater.
Slashdot Mirror
Dude. I should have guess it was you. So sorry.
Misbehaved applications or operating systems, distributed widely, can perform the accidental equivalent of accidental Denial of Service attacks. It happens. If it happened on the iPhone, Apple might suffer greatly. Their stock price would plummet. Sales might lag for months. They might find it harder to get agreements with carriers.
Just because Symbian, PalmOS, and Windows Mobile platforms allow uncontrolled developent and distribution of 3rd party applications doesn't means that this isn't a somewhat risky proposition for the network provider and platform maker. Given the sheer volume of scrutiny that Apple is getting as a result of being a late entrant to the cell phone market, I'd say their caution is warranted. I'd love to see them thinking hard enough about this issue to come up with some ways to help prevent it on their platform. Signed applications distributed through Apple? That might be a pretty reasonable model for a while. Who knows, maybe it would work so well that the model could be extended to the desktop/laptop market without adversely affecting consumers or 3rd party software developers. Maybe they'll decide to open it up wide later, but when they are getting started, I'm happy enough to see them exercising caution on this issue. It's probably not the *only* reason they are being cautious with the SDK/API, but it's certainly a real *enough* reason. It's not a smokescreen.
I'm just saying. There is entirely too much utter baseless crap like this in all the forums. I'm guessing a paid campagin.
There have been a number of incidents with cell phone networks like this. The service providers are really freaky paranoid about updating software on the switches and other network components, and are utterly loathe to update the firmware on the cell phones partly because they live in constant fear of unintended consequences of change. The change control procedures on the software systems for the network devices are mind numbing.
These incidents don't get published, just like most worm outbreaks in large corporate and government networks don't get published. I know a lot of them happened because I saw them first hand. Can't prove them to some random snit on Slashdot, however. The victims are often more afraid of the bad publicity than anything else that could result from an incident, and they eschew publicity. (The world would probably be a better place if they did share these experiences more widely, because lessons could be learned, software and procedures improved, etc., but that's not how managers of bureaucratic organizations operate just yet.)
To those demanding to see a link, I say: Well, since most of the people who actually know things like this are restricted by NDA agreements and also have the integrity to honor those agreements, perhaps first, you prove to us that pluto exists. I'm not talking about some white dot that could be a pin prick on a slide. You don't really know that Pluto exists, and nobody here has time to educate you in both epistemology and information technology so that you understand enough that we can "prove" everything to your pathetic satisfaction. Before mouthing off and demanding a link as though that constituted proof, maybe you should start by asking yourselves, "hrm... why would he lie about this?" If there are no compelling motivations for a big lie, then maybe, just maybe, he's not lying. Or maybe you don't believe him because you yourselves lie so often that you don't believe anyone else? What a sad life that must be.
You're right on target. Furthermore, Apple has a long history, going back to the founding of NeXT, of being exceedingly careful with the publication of new API and SDK. They typically develop at least one application which makes extensive use of the new API, and ship that application first. Then they get feedback on the application, go through another app development cycle, improve the API, etc. Finally, after they are very happy internally with the API, they might publish a public version of it in a developer release of the next release of the OS, and get feedback from developers, incorporate that feedback to the extent possible, and then ship the API. Then, they sometimes go through that cycle again with the next release of the OS before the API has really settled.
This is a somewhat painful process for those of us on the outside, and it normally takes a couple years before the API is published. However, it has resulted in API which, on the whole, are widely respected by talented developers with experience on multiple platforms. Some of those API have evolved only modestly since initial creation, some of those over 15 years ago, and are still regarded as advanced and modern.
It's also clear that Apple will need to accelerate this process a bit for the iPhone, simply because they want to develop *several* applications internally. They need the API and developer tools themselves. The good news is that this will also give them the experience with making different kinds of apps which will help round out and debug the API faster. We won't need to wait two years for the first version of the API. There is a non-zero chance we might see it, or at least hear about it, at WWDC 2007, the Cocoa API, not merely the Widget API.
It's clear that Apple has legitimate reasons for wanting to get the application development stuff "right" on the iPhone. The app market on most of the other cell phone platforms is really a disaster in the making. In addition to zillions of apps that are utter crap, which drag performance of the device down to unbearably slow, which crash and which feature generally poorly integrated UI, there is the looming threat of malware. There have already been a few malware incidents, and one of these days there will be a big, big malware incident. Apple doesn't want to be the platform that got nailed first. They don't want to get nailed at all.
Apple was intentionally vague about the SDK at the announcement of the iPhone because they didn't have all the answers lined up, really, none of them. But there will be a 3rd part app market at some point. And it will be huge.
I have noticed that there is a remarkable amount of hostility in discussion forums all over the web, even though the articles by thoughtful reviewers tend to be rather positive, and clearly enough people are impressed by what they've seen so far to send the stock price through the roof. Places where there are only half a dozen comments, where geeks normally don't hang out and discuss stuff, places that are normally total fanboi sites that typically sport little criticism, etc. are littered with really hostile comments. One article at The Register had a discussion thread about stabbing an Apple fanboi repeatedl in the face for saying something nice about the iPhone. Good grief. I suspect a paid astroturfing anti-campaign.
See, that's just the thing. It's the software that will make the iPhone interesting. So the flip side of your argument is that you won't be able to run OS X software on the Windows Mobile based smart phones. That's a pretty serious detraction. I don't want some MP3 player patched onto my phone with duct-tape, I want the iPod version of iTunes, integrated seemlessly. I don't want some rinky-dink pretend-to-edit-a-spreadsheet-on-your-phone crap. Nobody really does that on a 2 inch screen with 100 dpi resolution. I want random access to my voicemails. I want Google maps so easy to use that you know how to use it from watching the damn commercial, without having to read the manual or sign up for a training session. I want seemless access to wifi hotspots and EDGE, until the day AT&T has their HSDPA network in place and I can upgrade to 3G. I don't want the endless futzing that is the hallmark of Windows 802.11 access.
More importantly, the innovation loop for Apple is pretty tight. I have an idea for something that I would like on the iPhone. I describe the idea and submit it to Apple's Bug Reporter system at Apple Developer Connection. They ponder it, maybe even improve it, and implement it. I get it on my iPhone in a future software update. I know this will happen because I've done it a bunch of times with Mac OS X.
I also know from experience that this loop is broken for Palm OS, Windows Mobile, and Symbian. Trying to help them improve their products by giving them an idea is really pretty futile. It's so bad that the hacker underground has been hacking assembly code and patching firmware to fix bugs. Oh, yes! There is actually an underground community and 3rd party market in hacking assembly code on cell phones to fix firmware bugs and even some UI issues on cell phones. That is so mind-bogglingly broken I have to meditate for a moment. I'll be right back... OK. Whew. Man, that's so broken. The entire industry is broken, that's so broken.
That's so broken that a guy who heads a company that makes PCs and MP3 players decided he finally had to bet the farm and try to fix it, because it was clear after five years of watching it carefully it was never going to get fixed by anybody else. Oh, and thousands of people were begging him to try to fix it, too.
It's even more broken than that, however. Suppose not an end user like me, but, say, a handset maker or wireless carrier has an idea. It's pretty clear from the extensive track record that the pace of innovation in software on PalmOS, Windows Mobile, and Symbian is really a lot slower than it should be. The handset makers using Symbian couldn't get ideas into Symbian fast enough, so they tried to solve this problem by building their own custom layer on top of Symbian, basically they are implementing their own OS as a layer on top so they can get changes in faster. The result has been at least three incompatible Symbian versions now, and they are sagging under the weight of the alliance that was supposed to provide a common platform. The 3rd party app market suffers. The vendors suffer. The users suffer. But nobody fixes the problem, because they all think of the problem as whatever little piece of broken bit they are looking at right now. They don't realize the problem is that a "common platform" has suddenly become a burden, drains resources from their developer communtiy, drains developer resources from the handset makers, and leads to a substantially heavier burden of bugs and performance and compatibility issues on the end users. Nobody realizes the problem is really the broken process for getting feedback from customers and turning it into software.
Flash based UI are another way to try to solve this problem. Here again, we see an attempt to recreate the full features of the OS so the handset maker can "innovate" without letting the handset maker actually change (imrove or fix) the OS, and without the OS vendor changing it for them. The result is a tower of complexity, brokenness,
When I started my first business, I spent about $1500 for help from an attorney and a CPA, both specialists in corporate law and tax law, respectively. I'm not facing jail time nor massive penalties, so I'm guessing that was money well spent.
Oh, I'm not really sure how much to make of the Leopard delay anyway. It seems likely that the iPhone will be the first Apple product to ship on a Leopard version of OS X.
Call the county health department and have them test your water. Tell them to look for high levels of lithium, anti-depressants or other mind altering substances.
Palm just announced that they hired Jon Rubenstein and sold a chunk of the company to raise cash for CPR. If their next step is to fire their entire managment team, they might have a chance.
The worst part is that those 15 problems could have been fixed by the vendor but the industry is distorted so that doesn't happen. Before the iPhone, the maker of the handset was under the impression that the telephone company was their customer, and they really don't care one iota about you, the person who must use the device. This little love-fest between the telcos and handset makers results in the consumer being left with no place to turn. It costs the telco money to fix problems on your handset, because they "signed off" on the "final design" months ago and the handset maker has moved on to work on new models. They would rather sell you a different phone altogether than fix the crap software on the handset that you already paid for.
A few weeks after the iPhone ships, Apple will release a software update for it. That will be the day the cell phone industry really changes. When people realize what a difference a vendor that treats them like a customer will make in their satisfaction of the handset, the industry will never be the same. All the pundits are focused on the magical multi-touch UI, and all the vendors are racing to catch up to the sleek hardware design and clean user interface. The software updates are the secret weapon.
You've just explained why Ginger hasn't been the society revolutionizing technology that it was, uh, hyped to be. When cities started banning the thing from their sidewalks to prevent pedestrian injury, it became quite clear that cities would need to be litteraly re-engineered to achieve the large scale society improving benefits that were predicted for it, and that cities in fact would not be re-engineered.
Regarding the two things the iPod can't do... I haven't tried it myself, but an inexpensive 3rd party product which can waterproof your iPod will enable it to perform one of the two tasks on your list of things the iPod can't do, leaving you with taxes.
Palm will be the first victim of the iPhone. They so completely failed to grok their product and market that they were nearly crushed by WinCE. Imagine that. *shudder*
There are not even enough apple fanboys to account for the sales of the MacBook and MacBook Pro. The XServe, maybe.
See, this is where the argument falls apart. The "in" crowd, aka "too cool for school" aka "hipster" crowd isn't even aware that the iPhone is a computer. They don't care about that. They may like the fact that the device is "sexy", but they want it to work well, too. The iPod took off with this crowd because it worked. There were many dozens of MP3 players trying directly to capture this market. They failed ultimately because their devices suck. Apple solved that problem. Honestly, the iPod doesn't suck. You know that, if you have any clue at all. You don't even need to have ever owned one to know that. In the same way, using the fantastic pattern recognition engine that is your brain, you can anticipate that, come June 29, their will be a cell phone on the market that doesn't suck, for the first time giving ordinary non-computer-geek people something that a lot of them already know they want: the internet in their pocket. There is no reason why Apple should have had to make a phone to please Steve Jobs. In fact, they resisted the temptation for a long, long time. Finaly, almost three years ago now, they gave up and decided to fix the problem themselves.
I for one welcome our new suck-free cell phone overlords.
Please consider submitting your request for Polish language support in Mac OS X to Apple via the Apple Developer Connection. It's free, as in T-Shirt (e.g. you need to fill out a little form with a bit of contact information including an email address). Obviously you're interested in the platform. If there's a store selling Macinsoth computers in Poland, then other people are, too, and you would be doing yourself a favor to point this out in your request. Include a URL to the store's contact information, if possible. Mac OS X provides pretty nice localization support for quite a few languges already.
By the way, the original post was a reference to a troll that showed up, if I recall correctly, early on, in every Apple related thread and a few unrelated threads for a while. I recall some speculation that it might even have been an automated troll bot. The AC poster this time was clearly trying to make people laugh by converting the troll to an iPhone troll with a trivial substitution Macintosh -> iPhone. The tip-off for people who didn't recognize the post is that nobody will be copying a 17MB file from a device (the Motorola RAZR) which only has, if memory serves, about 5MB of RAM (newer versions of this phone might have more RAM, but the most popular early model was RAM starved). It was really a bit of an inside joke, as grokiing it requires familiarity with too many things that nobody should bother to remember.
Apple doesn't seem to have described the localization features of the iPhone, although their plans to relase an iPhone in Europe later this year suggest that they are planning at least some support for other languages. The U.S. version of the phone could be limited to English and Spanish, or even merely English without hurting sales too much. As the hardware platform matures (mainly as solid state storage becomes cheaper at larger capacities) it's reasonable to expect that future versions of the iPhone will support multiple languages as a general feature, as does Mac OS X. But then, it's also reasonable to expect the European version of the iPhone to support 3G data networks, and we all know that won't stop people from whining about the presumed lack of 3G and how the iPhone won't sell in Europe without it, as though Apple doesn't know that. (Don't these people think Steve Jobs wants 3G on his iPhone? I'm sure he's personally lobbying AT&T to get their poop in a group and roll out 3G before they get crushed by Verizon's EVDO stuff here. )
Oh, and that store isn't an Apple Store, by the way. Apple doesn't have any Apple Stores in Poland.
I don't think you need to take an economics course to learn this. Anybody who forms a corporation should have an attorney and a CPA. Oneof those two people, if not both, should have said, "If you want to raise money that way, you need to follow certain rules, or you need to factor jail time for the corporate officers into the business plan."
Well, I'm sorry to be the bearer of bad news, but you haven't spelled anything out. In fact, you've accidentally helped me develop my case. We'll get to that in a moment, but first let me mention that interlocking design elements of the CPU, compilers, and programing languages combine to make buffer overflows possible.
To the extent that portions of POSIX are specified in terms of C or assume C language features, and to the extent that such dependencies upon the nature of the C language, compiler, and host CPU make buffer overflows possible, then, yes, you could say POSIX is broken. However, there is a corpse missing. If it were POSIX that were responsible for buffer overflows, then Microsoft's nortoriously broken implementation of POSIX on Windows NT/2000/XP should have either insulated them from buffer overflows (because it didn't work any better for worm authors than for anybody else), or exposed them to myriad POSIX exploiting buffer overflows (because it somewhat worked, and the presence of POSIX was responsible for buffer overflows). In point of painfully obvious fact, neither happened. It is the Win32 and related Microsoft API, not POSIX, that exposed Windows users to rather more buffer overflows than all the factually POSIX compliant systems on the planet combined. Yeah, the POSIX API is a little long in the tooth, and sure, parts of it are sub-optimal, broken if you like, but certainly not directly and soley responsible for buffer overflows as you imply. Good grief that's a silly notion. Where are all the POSIX worms? Last I checked, Win32 and application worms dominated.
Furthermore, it's certainly possible to dramatically reduce the exposure of a UNIX operating system like Linux or Mac OS X to buffer overflows, by re-implementing certain widely used network-facing services in a more secure language like Java. Why are BIND, Sendmail, IMAP servers, file servers like Samba, and application servers like Apache still largely written in C based languages? POSIX certainly isn't to blame for that. You can't even blame the limited POSIX security model, since it's been extended with more modern ACLs for quite some time. In most cases, we can't even blame language performance issues. In contrast with its reputation for poor performance on GUI tasks, Java gets pretty good marks for raw server side type benchmarks. Whey don't we see one or more of these projects refactoring in Java? Nothing about the modular flexible nature of the UNIX architecture prevents this.
The FUD about Mach is likewise painfully tedious. Mach's infamous performance problems apply to research versions of the kernel that neither NeXT, nor Apple, nor DEC, nor IBM, nor anybody else who's using Mach parts in their kernel ever shipped. Aside from being utterly irrelevant on the grounds that no shipping product was observed to have them, the performance problems were largely due to issues that don't apply when the UNIX server is compiled in with the Mach kernel, as it is with the BSD server in Mac OS X. Those infamous performance problems were due to the research attempt to run the API server in user space, so that the kernel could support multiple "OS personalities", and so that an execution thread could be made more easily migratable from one host OS instance to another. Those were a couple of interesting goals that appealed to a few geeks and super computer researchers, but were not relevant to a desktop or server operating system. Nothing much was sacrificed when Mach and BSD were united in one happy binary.
Conduct a little thought experiment. If there existed a massive performance delta in raw kernel performance between, say, Mac OS X and Linux, it would be easy to demonstrate, if, say, you could run both kernels on the same hardware easily, say, an iMac, Mac Mini, MacBook, etc. These problems would be widely documented by now, many months after the Intel platform equalized the hardware b
... as a pebble disturbs the stillness of the pond? [Ti Kwan Leep]
A programmer who is too proud to think about how other people solved the problem they're looking at is much more likely to invent a wheel with some number of road-contact surfaces "n" where n > 1.
UNIX has survived (indeed thrives) as a result of a number of major refactoring efforts, directed not only at improving the internal architecture, but even the underlying abstractions. Consider Mach and the microkernel revolution, which resulted in nearly every major operating system kernel being refactored to accomodate the design abstractions described in Programming Under Mach. And now class, let us rejoin the mind to the body and gaze into the heart of the candle in meditation.
Hrm... you seem unaware that the very desktop (and mobile) friendly Macintosh and the coming generation of iPhones, iPods, and probably other digital appliances from Apple are based on a real UNIX underneath? The UNIX foundation of the system design is partly responsible for the rapid pace of evolution of Mac OS X.
Although extreme hubris might combine with extreme resources (both dollars and talent) at Google to lead to the creation of an entirely new OS from the ground up, there may not be any need for that. The UNIX wheel is relatively round these days, particularly considering the Mac OS X / OSX example. Better yet, UNIX is nicely modular. If anyone devises a clever way to "avoid buffer overflow situations" it seems likely, on the basis of past evidence concerning technology development and adoption within UNIX systems in general, that it would be easier to integrate that language and compiler, or whatever technology it happens to be, into a UNIX operating system than it would be to create a fully capable system on top of it from whole cloth.
Since you seem genuinely interested in the topic, here are some reasonable books on operating system design which you might enjoy.
The Design and Implementation of the 4.4 BSD Operating System
Design of the UNIX Operating System
Operating System Design: The Xinu Approach
UNIX Internals: The New Frontiers
Mac OS X Internals: A Systems Approach
Solaris Internals
The other issues you raise are largely issues of interface design, which the open source community seems to do rather poorly, or at least not as well as it does other things. Google certainly does not need to re-invent the entire operating system wheel to improve URL integration, or provide a "minimalist" desktop interface, for example. They don't even need to strip features, really. Mac OS X, for example, provides enough of a minimalist default interface that novice computer users are comfortable with it. A Linux based OS from Google could take a similar approach, perhaps being even more spartan in the basic features, if that's really a desirable goal (which is another question entirely).
This should drive home the point that connections should flow over encrypted tunnels whenever possible, to reduce the ease of performing man in the middle attacks. If this session flowed over an SSL style connection, the man in the middle would first need to figure out how to get into that session. That strategy seriously reduces the places where malicious code can exist "in the middle". Don't throw the baby (rich client interaction with services in the cloud) out with the bathwater.
That should be: " too long to boot up..."