It goes further than that. The dongle is incompatible with battery cases and is incompatible with charging while listening. So there are categories of users for whom wired headphones aren't even an option with the iPhone 7.
No doubt, some of them did. Others chose the 6s over the 7. Others decided that carrying around an adapter was more of a pain than charging headphones every day, and bought Bluetooth headphones. Still others designed an iPhone case to add the headphone jack back. And a fifth group bought the 7, tried Bluetooth, hated it, and returned the iPhone 7 for a refund. The important question is how many people fell into each group. Unfortunately, Apple stopped breaking down iPhone sales by product, so we'll never know for certain.
You can only guarantee code that you have tested. Logic that exists in external libraries should not just suddenly change without you retesting the whole thing all over again.
Which means you can never guarantee anything. After all, the kernel changes with every OS update, often in ways that require incompatible changes to the libraries that sit on top of it. Libraries aren't shared just to save space. They're shared because they have to handle changes in the code underneath. Similarly, apps sometimes have to get updated to accommodate changes to libraries. This should generally be rare, and Apple does an amazing job of ensuring that through linked-on-or-after behavior based on versioned symbols, but it does happen.
And the issue of security updates - well, all apps should be updated, test and redistributed by their authors when new static library versions come out. (OK, using shared libraries fixed at a particular version is possible, but then what's the point, you can't just hotfix those libraries without retesting, either.)
Apps should be tested and, if necessary, updated and redistributed by their authors when new OS versions result in changes to the dynamic libraries. It isn't as though the changes happen every day or anything. OS updates happen on average every two or three months (concentrated right after a major release and becoming less frequent as the next release approaches). But app developers don't, and that's why apps break. If a sizable number of developers don't update their apps regularly to accommodate changes in the shared libraries, what makes you think they'll ever bother to update static libraries built into the apps themselves if they aren't forced to do so?
We've gotten to the point where Apple was threatening a mass purge of apps that have broken because of abandonment for years. I don't know if that has happened, but I can think of a decent number of apps that haven't worked reliably since at least iOS 6 that were still on the app store as of a few months ago. Imagine a world where there are critical security holes in a library that have been unpatched by multiple app vendors for the past four years. That's what you're suggesting right here. The app developers have shown beyond any doubt that they cannot be trusted to keep their app even moderately up-to-date. Far better to risk breaking it entirely by using shared libraries than to run such a high risk of compromise.
And in the desktop world, it is even worse, because manufacturers routinely release new major versions of their apps and then stop supporting the old ones. If Photoshop CS6 installed its own copies of the OS frameworks and then Apple found a security hole and fixed it, you'd be out of luck, because Adobe certainly wouldn't roll a new version of an unsupported app just to fix a security hole. By contrast, with Apple in control, there's a high probability that they're still testing Photoshop CS6, and will at least make a best effort at preventing it from breaking while they patch the security hole for everyone.
Making those shared libraries global means that security flaws can be patched, sure. But updating a library then means you're running untested software. The developer didn't have that library when he was writing the program, so you have no guarantee at all that you are not introducing massive bugs in the software, security-related or otherwise. For all you know, the new software you've produced may not even run at all.
While true, that's also true all the way down to system calls and other kernel interfaces. At some point, you just have to accept that the code underneath you probably works, and that if it doesn't, it is highly likely that the breakage will break lots of other software, too, and thus will get fixed quickly.
In my experience, when apps break after a library update, it is invariably because the developer made an assumption that was not stated in the documentation, and usually it is because they did something so glaringly contrary to the documentation that it was an absolute miracle that it worked at all. So in spite of substantial changes to shared libraries, the vast majority of apps continue to work for release after release with no changes.
And I can point at specific developers whose code breaks with every single OS release. Those companies need to take the time to figure out why they're the only ones who are breaking. I know their code is crap, because there are so many outward signs of sloppiness—such heresies as loading frameworks from incorrect paths that only work because the default filesystem is case-insensitive, security patches every few weeks to fix yet another batch of vulnerabilities in their flagship products, etc. But somehow, they still haven't figured out that invariably they are the problem, rather than the shared code that they're using.
IMO, shared libraries should be broadly capable, and the only thing that should be in an application is code that isn't likely to be used by any other application. Make everything else shared. That way, whenever bugs get fixed, I get the bug fixes immediately.
For many security-oriented engineers, software that won't start is better than software with a security flaw. From the user's point of view, this security is not about your front door security: nobody is going to enter their house, beat you and run away with your money. On the other hand, your presentation program will crash due to an automatic OS update the morning of your career-changing meeting.
First, if you really have a career-changing meeting on your schedule, you should have turned off automatic updates a week before and isolated it from the network as much as possible, using it exclusively for meeting-related work, to ensure that no matter what, that device will be in exactly the state you left it in.
Second, although the users might at first naïvely believe that this "is not about your front door security", they'll still blame the OS manufacturer when they keep getting malware on their devices, and they'll demand to know why these security holes weren't fixed. You seem to be under the misunderstanding that we live in a 1980s world, where computers are disconnected most of the time, and bad things only happen when you go to sketchy websites, rather than the 2010s world where malware is served by advertisements on major websites, where merely opening an email without clicking on an attachment can compromise your computer or device, etc. The attackers have massively stepped up their game, and if OS vendors don't match that pace, tech will quickly become unusable.
From a security perspective, I've seen far too many app vendors who basically abandon their apps. Things start breaking after two or three OS releases as features that they depend on get deprecated and start to break, and five years later, the app no longer functions. And when you talk about bringing in lots of per-app library code, what you're really saying is that this library won't nee
It has to be more than gimmick. MS has been trying to do smart phones since 1996 with Windows CE and so far they have nothing. If people were just looking for gimmicks and integration, MS would have had more that 10% of the market at any one time. Blackberry, which was a good phone, fell very quickly.
People also like phones that don't BSOD.:-D
But seriously, Blackberry's problem, and really Windows Phone's problem as well, is a lack of app momentum. Phil Schiller's implication that the iPhone would have been successful without the App Store is kind of laughable, because we've seen what happens when other manufacturers put out innovative products without that ecosystem.
First, we have Palm, who under the leadership of no doubt the same person who pushed for a web-app-only iPhone, came out with a web-app-only Palm Pre. The product died, because web apps suck.
Then, we have Windows Phone, which has a decent UI, but has so little marketshare that nobody builds apps for it, and because nobody builds apps for it, nobody buys it. It's a chicken-and-egg situation, and until somebody at Microsoft comes up with a way to convince enough major developers into building apps for the thing so that it can take off, it will remain basically stillborn.
In fact, I'd go so far as to say that if Apple hadn't developed an app ecosystem when they did, iOS would have gone into a death spiral when the Android Market opened just three months later. The ability to extend the technology is so fundamental to what makes a smartphone useful that any smartphone that lacks that capability or lacks a sufficiently large group of developers taking advantage of that capability will wither on the vine. Apple still exists solely because the upper management at Apple finally listened to the engineers.
I covered that possibility when I said, "unless the means for making those holes is something particularly complex." If they have a unique way of growing a crystalline lattice with a hole in it, that's novel. But unless the mechanism for creating the hole is novel, the entire patent is likely obvious. After all, routing traces around a hole is basic circuit design, fudging the brightness of adjacent subpixels to hide dead ones is a trivial extension of how digital cameras deal with dead sensor pixels, etc. (I'm assuming that they are doing those things; I haven't read the patent.)
Nonsense. It has two benefits. You also have a greater chance of dropping the phone while trying to hold it in a way that doesn't cover up part of the screen. It's pretty obvious why zero-bezel cell phones are good for manufacturers. I have yet to see any reason why they are good for users.
Now a zero-bezel laptop screen... that would be useful....
No, but if it has been done repeatedly with multiple other kinds of screens, there's a good chance that it fails the non-obvious test, unless the means for making those holes is something particularly complex.
Flaws in shared libraries can't enable privilege escalation in any operating system that I'm aware of except possibly some of those really old, pre-MMU mainframe operating systems. In modern OSes, shared library code runs in the same environment privilege-wise as the rest of the code in the app.
In fact, quite the opposite. Copying libraries introduces one of Windows's key security flaws: Any exploitable bug in a shared library is only truly fixed after every single app that provides a copy of that library gets updated to include a new version of that library. From a security perspective, providing multiple copies of a framework or library is generally seen as very, very bad.
Of course, the reason for it in this case was that the library was evolving quickly, and apps would get built against different versions. By including it in the app, you can run apps compiled against newer versions of the Swift library on older versions of the OS that lacked that version (or any version) of the library. IMO, what's really needed is a systemwide mechanism for downloading updated versions of these shared libraries in such a way that they get automatically kept up-to-date, but that's a much more complex solution than just including a copy of the framework in each app. Alternatively, I'd settle for block-level deduplication in iOS, but again....
Perhaps now that things have settled down a bit, they can move it into/S/L/Frameworks.
Wikipedia doesn't offer paid accounts. This is a targeted law intended to get that info removed from IMDB. It not only fails first amendment scrutiny, but also arguably fails equal protection scrutiny, as there's no rational reason why a company should be banned from publishing publicly available information merely because it also happens to offer paid accounts for people working in the industry; the law can't make meaningful progress towards a legitimate legislative goal as written, and appears to exist solely to screw over a single company.
IMO, the price and the lack of 3G were the only problems. The other stuff was just noise. And, of course, the price came down with subsidies, and 3G came in the second hardware rev (which IMO should have been the first). And now that the subsidies are gone, Apple is having trouble with sales again. Apple is, of course, in the best position to take advantage of the lack of subsidies by continuing OS support for existing hardware for much longer than Android makers so that their hardware is perceived as less disposable. Whether they will do so or not remains to be seen.
Sure, some of them would be crap, but presumably at least a couple of those manufacturers would emerge as knowing what they're doing. I mean, if they stick with standard Intel chipsets and one of the NVIDIA or AMD GPUs that Apple already uses, it should "just work", and if they use other NVIDIA or AMD GPUs... well, it's not like Apple writes those drivers anyway, so they shouldn't be that much worse than what Apple ships.
The official release announcement was in December, but it was shown in the iF Design Awards in September. So actually more like 16 weeks. (For some reason, I incorrectly thought that was in October.)
You do realize that Microsoft doesn't support all that third party hardware, either, right? Companies like Dell have programmers in-house who are responsible for systems integration, and the various chipset makers write their own drivers. All Apple has to do is provide the licensing, and the hardware vendors will take care of the rest.
Instead, in their zeal to make it possible to work with documents online so that they can try (unsuccessfully) to compete with Google Docs, they've cut out many of the features that gave them an advantage. At this point, IMO, folks might as well save their money and just use Google Docs instead.
That said, I've mostly ignored the iWork suite. I got burned badly when Apple dropped AppleWorks for iWork, because so much of the functionality I used (the "draw" module and the database module) didn't really make the cut, and there's no way to open those documents without running AppleWorks in a Mac OS 9 emulator. And then I got further burned by DVD Studio Pro, and then again by Final Cut X's lack of proper support for tapes. As a result, I no longer trust apps made by Apple to still be usable in five years, which means I basically avoid them like the plague. Give me something I can compile myself, like LaTeX and vim.
Every non-iOS developer I've spoken to about the new MacBook Pro has said that their next laptop will be a Windows laptop unless Apple reverts this design change. IMO, the touch bar was a major screw-up. The real mistakes were introducing this in the Pro laptop instead of the consumer one (it's a very consumer-oriented feature), and putting it on the keyboard instead of right above it.
... but you have so little control over how an image is focused digitally because the sensor doesn't snap the entire image at once, especially in CMOS sensors.
Only in toy cameras—those with CMOS sensors that lack a global electronic shutter, when used in cameras that lack a mechanical shutter. With DSLRs, there's a physical, mechanical shutter in front of that sensor, so the sensor is, in fact, exposed at once, and then read out after it is no longer being exposed, just like film. And many mirrorless cameras instead have a global electronic shutter.
The problem is not that digital tech isn't capable of being as good as film, but rather that cell phones are not real cameras and probably never will be. They're toys. A global shutter requires more electronics on die, which is not easy to reconcile with the desire to make the entire surface area of a tiny sensor be photo-sensitive. It can be done, sure, but AFAIK nobody has done it yet. I find it utterly depressing that a decade after folks started complaining about the iPhone's rolling shutter, Apple's engineers still haven't insisted on making the one camera change that would actually dramatically improve the quality of their cameras... and neither has anybody else.
But moving to film as an alternative to cell phones is like switching to a 1970 Mustang because your hoverboard isn't powerful enough, doesn't have enough range, and can't carry any cargo, then claiming that EVs are inferior for those three reasons.:-)
None of UIKit is part of OS X, and AFAIK, it doesn't share any code with AppKit—it doesn't even use the same coordinate system. That means it wouldn't have been just the home screen, but rather all of the user interface views, touch handling, gesture recognition, etc. Realistically, that's not a few weeks' work.
Besides, the iOS UI is very much the natural evolution of Newton OS. All touchscreen OSes, including the LG Prada, are basically just imitations of that original design with varying degrees of refinement, so it's no surprise that design-wise, the iOS home screen is almost identical to the Newton's, all the way down to the bottom row of icons being reserved for commonly-used features. The only big difference is that the Newton was in black-and-white/greyscale. By contrast, the iOS home screen looks almost nothing like the home screen on the KE850 except to the extent that they both involve a touchscreen containing some icons. It seems pretty obvious that the iOS UI evolved in-house, inspired mainly by the Newton, and that the LG Prada had no meaningful impact on it, unless I missed something subtle.
The 7 is demonstrably better in every single metric than both the iPhone 6 or 6s. The processor isn't just a little bit faster, it's a lot faster.
Which is good, but as Steve Jobs was quick to point out, most real people don't care about specs. They care about what the device will actually do. Sure, the CPU in the iPhone 7 might be half again faster than the one in the iPhone 6s, but if the one in the iPhone 6s was fast enough to meet their needs, the extra speed gives them nothing of value. I mean, there's nothing wrong with CPU speeds increasing, but realistically, that isn't a feature that users care about at all (at least until after they have updated the OS through three or four major releases and it starts to bog down).
It's not just faster, it's more efficient per clock cycle. Meanwhile, it has twice the storage regardless of selected tier, gets the same battery life,
This is the point where your argument went off the rails. If the CPU is more efficient per clock cycle, you'd expect it to get much better battery life. If it just gets the same battery life, then IMO there's something fundamentally wrong....
unlocks faster and has a better camera.
I don't recall ever feeling like my 6s unlocks too slowly. It's a small amount of time and done fairly infrequently. Any effort to optimize that is, IMO, wasted effort that could have been spent improving other things that actually impact consumers, like battery life, visibility in sunlight, or the idiotic power button placement that makes it hard to press without simultaneously pressing a volume button, thus canceling the power button's behavior. There are so many glaring flaws in the iPhone 6s that it isn't even funny, yet they chose to focus on making the phone unlock faster—something which I suspect exactly *zero* real users care about.
As for the camera improvements, the "portrait mode" is a gimmick. It often looks glaringly fake, and to really get it right, you would need a minimum of five cameras and a lot more distance between them. The 2x zoom capability from the second camera would be nice on occasion, but it isn't enough to be very useful in practice. I can't think of a single situation where a 2x zoom ratio or faux bokeh would cause me to leave my DSLR at home. So from my perspective, the iPhone 7 camera isn't really any better than the iPhone 6s camera except for the half stop difference in aperture, which might occasionally result in a shot being salvageable when it otherwise wouldn't be, and only if I didn't have my real camera with me.
Don't get me wrong, I'd love to have that camera in my 6s, but I would get far less use out of it than I do my headphone jack, which I use almost daily, as opposed to my iPhone camera which (if you don't count barcode scanning with the Amazon app) I use probably single-digit times per year. And the notion of that being a major improvement is kind of crazy. A major improvement is comparing the iPhone 3G camera to the iPhone 4 camera. In the same number of generations, it added autofocus and backside illumination. The difference was jaw-dropping. Now compare the iPhone 6 and the iPhone 7, and the difference is basically meh. Heck, the difference between the iPhone 5 camera and the iPhone 7 camera is pretty meh by comparison. The technology is largely mature, and there aren't really many improvements to be made at this point.
See, the problem with complaining about it being 'barely different' is that it seems to largely hinge on the aesthetic, which people complained changed TOO MUCH before. "Why can't Apple just leave things alone? This design is great!" Now it's, "God, this looks a lot like the last one. Apple has lost its touch!" Apple will never win that stupid war, because someone will always complain.
It has nothing to do with the appearance. The iPhone 7 removed a feature that some peo
While it has a lot to do with Apple's culture and leadership, I wonder if it also has to do with the company's organization. I saw an article recently claiming that their organization is unusual of a company of their size, and maybe they've outgrown it. Something about they don't have separate macOS and iOS divisions, so much as software and hardware divisions. So when iOS takes over focus, everyone is shifted on to that, and macOS is left with a skeleton crew for maintenance.
Actually, Apple has teams that work on specific technology areas. So there's a team that works on, for example, kernel networking, and within that area, there are folks who focus on iOS-specific stuff, folks who focus on Mac-specific stuff, and a bunch of generalists who work on whatever needs to be improved at that particular moment. At no point is there just a "skeleton crew" working on OS X, because most people are working on code that impacts both platforms equally. The only real exceptions are folks working on applications (platform-specific), Springboard (iOS only), Dock (OS X only), AppKit, UIKit, and a few other miscellaneous pieces. And those folks aren't really interchangeable, so I don't think they borrow any of them from one side of the organization to beef up the other side.
They have the cash to hire legions of more engineers, to have full teams for all products, but they don't want to do it.
Actually, Apple hiring legions of engineers is part of the problem. If you've looked at Apple's hiring numbers, they're growing at a crazy rate, and have been ever since the iPhone came out. The result is that there's too much new blood who don't understand why things were done the way they were done, and whose inclination is to do something new and different because it is new and different, rather than because it is better.
The result is the new iMovie, an endless string of major iTunes UI redesigns, the death of Aperture in favor of the Photos app, the death of FCP in favor of FCP X, the flat icon abomination, the Helvetica Neue abomination, and a developer docs website that does everything in its power to discourage actual development.
Trust me, hiring more people isn't the answer. It's the problem. Hiring fewer, better people with more experience is the answer.
It's like if something isn't being directly thought about by the executive team, nobody on the company is allowed to work on it.
Actually, the current iMovie that you complained about was, IIRC, originally just such a skunkworks project, and then somebody liked it so much that they wanted everybody to use it. I'm sure such things still happen all the time at Apple. I'm not so sure that they don't get released as finished products far more often than they should, however.
I suspect it is actually the other way around—that the deadlines were unrealistic, and that Tim Cook's insistence on meeting those deadlines anyway caused products to be announced (and in some cases to ship) before they were really ready, but I suppose it could be a combination of the two.
With SJ, if the technology had not been ready, he would probably have said something like, "We can't release this s**t. Call me when you're actually ready to show me something." If they had a fallback plan at all, it would have been a minor speed bump with no other changes, intended to hold folks over until the real product could be released a few months later, but realistically they would probably have slipped the announcement date by a few months to accommodate the delays in component availability so that they could ship what they wanted to ship instead of a shipping a compromise.
Apple's iOS devices didn't ship precisely on a yearly schedule under Jobs. Before his death, they shipped in June, July, June, June, and October, respectively. (Okay, so the October release was technically after his death, but just days after.) Ever since then, the iPhone has shipped precisely in mid-to-late September every single year. And OS X releases fell into a fairly strict 1-year release cadence at the same time. I think that this deadline-oriented planning is a major contributing factor to the decline in product quality that many of us perceive. They aren't taking the time they need to get things right before the products go out the door, and more and more often, they aren't able to get the bugs fixed in the previous software release before they ship a new release that introduces new bugs. And now, we're seeing the same problems on the hardware side.
I think it is time for Apple management to take a step back and slow down a little.
Slashdot Mirror
It goes further than that. The dongle is incompatible with battery cases and is incompatible with charging while listening. So there are categories of users for whom wired headphones aren't even an option with the iPhone 7.
No doubt, some of them did. Others chose the 6s over the 7. Others decided that carrying around an adapter was more of a pain than charging headphones every day, and bought Bluetooth headphones. Still others designed an iPhone case to add the headphone jack back. And a fifth group bought the 7, tried Bluetooth, hated it, and returned the iPhone 7 for a refund. The important question is how many people fell into each group. Unfortunately, Apple stopped breaking down iPhone sales by product, so we'll never know for certain.
Which means you can never guarantee anything. After all, the kernel changes with every OS update, often in ways that require incompatible changes to the libraries that sit on top of it. Libraries aren't shared just to save space. They're shared because they have to handle changes in the code underneath. Similarly, apps sometimes have to get updated to accommodate changes to libraries. This should generally be rare, and Apple does an amazing job of ensuring that through linked-on-or-after behavior based on versioned symbols, but it does happen.
Apps should be tested and, if necessary, updated and redistributed by their authors when new OS versions result in changes to the dynamic libraries. It isn't as though the changes happen every day or anything. OS updates happen on average every two or three months (concentrated right after a major release and becoming less frequent as the next release approaches). But app developers don't, and that's why apps break. If a sizable number of developers don't update their apps regularly to accommodate changes in the shared libraries, what makes you think they'll ever bother to update static libraries built into the apps themselves if they aren't forced to do so?
We've gotten to the point where Apple was threatening a mass purge of apps that have broken because of abandonment for years. I don't know if that has happened, but I can think of a decent number of apps that haven't worked reliably since at least iOS 6 that were still on the app store as of a few months ago. Imagine a world where there are critical security holes in a library that have been unpatched by multiple app vendors for the past four years. That's what you're suggesting right here. The app developers have shown beyond any doubt that they cannot be trusted to keep their app even moderately up-to-date. Far better to risk breaking it entirely by using shared libraries than to run such a high risk of compromise.
And in the desktop world, it is even worse, because manufacturers routinely release new major versions of their apps and then stop supporting the old ones. If Photoshop CS6 installed its own copies of the OS frameworks and then Apple found a security hole and fixed it, you'd be out of luck, because Adobe certainly wouldn't roll a new version of an unsupported app just to fix a security hole. By contrast, with Apple in control, there's a high probability that they're still testing Photoshop CS6, and will at least make a best effort at preventing it from breaking while they patch the security hole for everyone.
While true, that's also true all the way down to system calls and other kernel interfaces. At some point, you just have to accept that the code underneath you probably works, and that if it doesn't, it is highly likely that the breakage will break lots of other software, too, and thus will get fixed quickly.
In my experience, when apps break after a library update, it is invariably because the developer made an assumption that was not stated in the documentation, and usually it is because they did something so glaringly contrary to the documentation that it was an absolute miracle that it worked at all. So in spite of substantial changes to shared libraries, the vast majority of apps continue to work for release after release with no changes.
And I can point at specific developers whose code breaks with every single OS release. Those companies need to take the time to figure out why they're the only ones who are breaking. I know their code is crap, because there are so many outward signs of sloppiness—such heresies as loading frameworks from incorrect paths that only work because the default filesystem is case-insensitive, security patches every few weeks to fix yet another batch of vulnerabilities in their flagship products, etc. But somehow, they still haven't figured out that invariably they are the problem, rather than the shared code that they're using.
IMO, shared libraries should be broadly capable, and the only thing that should be in an application is code that isn't likely to be used by any other application. Make everything else shared. That way, whenever bugs get fixed, I get the bug fixes immediately.
First, if you really have a career-changing meeting on your schedule, you should have turned off automatic updates a week before and isolated it from the network as much as possible, using it exclusively for meeting-related work, to ensure that no matter what, that device will be in exactly the state you left it in.
Second, although the users might at first naïvely believe that this "is not about your front door security", they'll still blame the OS manufacturer when they keep getting malware on their devices, and they'll demand to know why these security holes weren't fixed. You seem to be under the misunderstanding that we live in a 1980s world, where computers are disconnected most of the time, and bad things only happen when you go to sketchy websites, rather than the 2010s world where malware is served by advertisements on major websites, where merely opening an email without clicking on an attachment can compromise your computer or device, etc. The attackers have massively stepped up their game, and if OS vendors don't match that pace, tech will quickly become unusable.
From a security perspective, I've seen far too many app vendors who basically abandon their apps. Things start breaking after two or three OS releases as features that they depend on get deprecated and start to break, and five years later, the app no longer functions. And when you talk about bringing in lots of per-app library code, what you're really saying is that this library won't nee
People also like phones that don't BSOD. :-D
But seriously, Blackberry's problem, and really Windows Phone's problem as well, is a lack of app momentum. Phil Schiller's implication that the iPhone would have been successful without the App Store is kind of laughable, because we've seen what happens when other manufacturers put out innovative products without that ecosystem.
First, we have Palm, who under the leadership of no doubt the same person who pushed for a web-app-only iPhone, came out with a web-app-only Palm Pre. The product died, because web apps suck.
Then, we have Windows Phone, which has a decent UI, but has so little marketshare that nobody builds apps for it, and because nobody builds apps for it, nobody buys it. It's a chicken-and-egg situation, and until somebody at Microsoft comes up with a way to convince enough major developers into building apps for the thing so that it can take off, it will remain basically stillborn.
In fact, I'd go so far as to say that if Apple hadn't developed an app ecosystem when they did, iOS would have gone into a death spiral when the Android Market opened just three months later. The ability to extend the technology is so fundamental to what makes a smartphone useful that any smartphone that lacks that capability or lacks a sufficiently large group of developers taking advantage of that capability will wither on the vine. Apple still exists solely because the upper management at Apple finally listened to the engineers.
I covered that possibility when I said, "unless the means for making those holes is something particularly complex." If they have a unique way of growing a crystalline lattice with a hole in it, that's novel. But unless the mechanism for creating the hole is novel, the entire patent is likely obvious. After all, routing traces around a hole is basic circuit design, fudging the brightness of adjacent subpixels to hide dead ones is a trivial extension of how digital cameras deal with dead sensor pixels, etc. (I'm assuming that they are doing those things; I haven't read the patent.)
Nonsense. It has two benefits. You also have a greater chance of dropping the phone while trying to hold it in a way that doesn't cover up part of the screen. It's pretty obvious why zero-bezel cell phones are good for manufacturers. I have yet to see any reason why they are good for users.
Now a zero-bezel laptop screen... that would be useful....
No, but if it has been done repeatedly with multiple other kinds of screens, there's a good chance that it fails the non-obvious test, unless the means for making those holes is something particularly complex.
Flaws in shared libraries can't enable privilege escalation in any operating system that I'm aware of except possibly some of those really old, pre-MMU mainframe operating systems. In modern OSes, shared library code runs in the same environment privilege-wise as the rest of the code in the app.
In fact, quite the opposite. Copying libraries introduces one of Windows's key security flaws: Any exploitable bug in a shared library is only truly fixed after every single app that provides a copy of that library gets updated to include a new version of that library. From a security perspective, providing multiple copies of a framework or library is generally seen as very, very bad.
Of course, the reason for it in this case was that the library was evolving quickly, and apps would get built against different versions. By including it in the app, you can run apps compiled against newer versions of the Swift library on older versions of the OS that lacked that version (or any version) of the library. IMO, what's really needed is a systemwide mechanism for downloading updated versions of these shared libraries in such a way that they get automatically kept up-to-date, but that's a much more complex solution than just including a copy of the framework in each app. Alternatively, I'd settle for block-level deduplication in iOS, but again....
Perhaps now that things have settled down a bit, they can move it into /S/L/Frameworks.
Get off my lawn.
Wikipedia doesn't offer paid accounts. This is a targeted law intended to get that info removed from IMDB. It not only fails first amendment scrutiny, but also arguably fails equal protection scrutiny, as there's no rational reason why a company should be banned from publishing publicly available information merely because it also happens to offer paid accounts for people working in the industry; the law can't make meaningful progress towards a legitimate legislative goal as written, and appears to exist solely to screw over a single company.
IMO, the price and the lack of 3G were the only problems. The other stuff was just noise. And, of course, the price came down with subsidies, and 3G came in the second hardware rev (which IMO should have been the first). And now that the subsidies are gone, Apple is having trouble with sales again. Apple is, of course, in the best position to take advantage of the lack of subsidies by continuing OS support for existing hardware for much longer than Android makers so that their hardware is perceived as less disposable. Whether they will do so or not remains to be seen.
Who, in turn, basically copied it from the Newton.
Sure, some of them would be crap, but presumably at least a couple of those manufacturers would emerge as knowing what they're doing. I mean, if they stick with standard Intel chipsets and one of the NVIDIA or AMD GPUs that Apple already uses, it should "just work", and if they use other NVIDIA or AMD GPUs... well, it's not like Apple writes those drivers anyway, so they shouldn't be that much worse than what Apple ships.
The official release announcement was in December, but it was shown in the iF Design Awards in September. So actually more like 16 weeks. (For some reason, I incorrectly thought that was in October.)
I'm guessing the escape key (for vi/vim/nvi).
You do realize that Microsoft doesn't support all that third party hardware, either, right? Companies like Dell have programmers in-house who are responsible for systems integration, and the various chipset makers write their own drivers. All Apple has to do is provide the licensing, and the hardware vendors will take care of the rest.
Instead, in their zeal to make it possible to work with documents online so that they can try (unsuccessfully) to compete with Google Docs, they've cut out many of the features that gave them an advantage. At this point, IMO, folks might as well save their money and just use Google Docs instead.
That said, I've mostly ignored the iWork suite. I got burned badly when Apple dropped AppleWorks for iWork, because so much of the functionality I used (the "draw" module and the database module) didn't really make the cut, and there's no way to open those documents without running AppleWorks in a Mac OS 9 emulator. And then I got further burned by DVD Studio Pro, and then again by Final Cut X's lack of proper support for tapes. As a result, I no longer trust apps made by Apple to still be usable in five years, which means I basically avoid them like the plague. Give me something I can compile myself, like LaTeX and vim.
Every non-iOS developer I've spoken to about the new MacBook Pro has said that their next laptop will be a Windows laptop unless Apple reverts this design change. IMO, the touch bar was a major screw-up. The real mistakes were introducing this in the Pro laptop instead of the consumer one (it's a very consumer-oriented feature), and putting it on the keyboard instead of right above it.
Only in toy cameras—those with CMOS sensors that lack a global electronic shutter, when used in cameras that lack a mechanical shutter. With DSLRs, there's a physical, mechanical shutter in front of that sensor, so the sensor is, in fact, exposed at once, and then read out after it is no longer being exposed, just like film. And many mirrorless cameras instead have a global electronic shutter.
The problem is not that digital tech isn't capable of being as good as film, but rather that cell phones are not real cameras and probably never will be. They're toys. A global shutter requires more electronics on die, which is not easy to reconcile with the desire to make the entire surface area of a tiny sensor be photo-sensitive. It can be done, sure, but AFAIK nobody has done it yet. I find it utterly depressing that a decade after folks started complaining about the iPhone's rolling shutter, Apple's engineers still haven't insisted on making the one camera change that would actually dramatically improve the quality of their cameras... and neither has anybody else.
But moving to film as an alternative to cell phones is like switching to a 1970 Mustang because your hoverboard isn't powerful enough, doesn't have enough range, and can't carry any cargo, then claiming that EVs are inferior for those three reasons. :-)
Also, IIRC, Ektachrome was Kodak's only slide film, and maybe there's a resurgence in slide projectors.... :-D
None of UIKit is part of OS X, and AFAIK, it doesn't share any code with AppKit—it doesn't even use the same coordinate system. That means it wouldn't have been just the home screen, but rather all of the user interface views, touch handling, gesture recognition, etc. Realistically, that's not a few weeks' work.
Besides, the iOS UI is very much the natural evolution of Newton OS. All touchscreen OSes, including the LG Prada, are basically just imitations of that original design with varying degrees of refinement, so it's no surprise that design-wise, the iOS home screen is almost identical to the Newton's, all the way down to the bottom row of icons being reserved for commonly-used features. The only big difference is that the Newton was in black-and-white/greyscale. By contrast, the iOS home screen looks almost nothing like the home screen on the KE850 except to the extent that they both involve a touchscreen containing some icons. It seems pretty obvious that the iOS UI evolved in-house, inspired mainly by the Newton, and that the LG Prada had no meaningful impact on it, unless I missed something subtle.
Which is good, but as Steve Jobs was quick to point out, most real people don't care about specs. They care about what the device will actually do. Sure, the CPU in the iPhone 7 might be half again faster than the one in the iPhone 6s, but if the one in the iPhone 6s was fast enough to meet their needs, the extra speed gives them nothing of value. I mean, there's nothing wrong with CPU speeds increasing, but realistically, that isn't a feature that users care about at all (at least until after they have updated the OS through three or four major releases and it starts to bog down).
This is the point where your argument went off the rails. If the CPU is more efficient per clock cycle, you'd expect it to get much better battery life. If it just gets the same battery life, then IMO there's something fundamentally wrong....
I don't recall ever feeling like my 6s unlocks too slowly. It's a small amount of time and done fairly infrequently. Any effort to optimize that is, IMO, wasted effort that could have been spent improving other things that actually impact consumers, like battery life, visibility in sunlight, or the idiotic power button placement that makes it hard to press without simultaneously pressing a volume button, thus canceling the power button's behavior. There are so many glaring flaws in the iPhone 6s that it isn't even funny, yet they chose to focus on making the phone unlock faster—something which I suspect exactly *zero* real users care about.
As for the camera improvements, the "portrait mode" is a gimmick. It often looks glaringly fake, and to really get it right, you would need a minimum of five cameras and a lot more distance between them. The 2x zoom capability from the second camera would be nice on occasion, but it isn't enough to be very useful in practice. I can't think of a single situation where a 2x zoom ratio or faux bokeh would cause me to leave my DSLR at home. So from my perspective, the iPhone 7 camera isn't really any better than the iPhone 6s camera except for the half stop difference in aperture, which might occasionally result in a shot being salvageable when it otherwise wouldn't be, and only if I didn't have my real camera with me.
Don't get me wrong, I'd love to have that camera in my 6s, but I would get far less use out of it than I do my headphone jack, which I use almost daily, as opposed to my iPhone camera which (if you don't count barcode scanning with the Amazon app) I use probably single-digit times per year. And the notion of that being a major improvement is kind of crazy. A major improvement is comparing the iPhone 3G camera to the iPhone 4 camera. In the same number of generations, it added autofocus and backside illumination. The difference was jaw-dropping. Now compare the iPhone 6 and the iPhone 7, and the difference is basically meh. Heck, the difference between the iPhone 5 camera and the iPhone 7 camera is pretty meh by comparison. The technology is largely mature, and there aren't really many improvements to be made at this point.
It has nothing to do with the appearance. The iPhone 7 removed a feature that some peo
Actually, Apple has teams that work on specific technology areas. So there's a team that works on, for example, kernel networking, and within that area, there are folks who focus on iOS-specific stuff, folks who focus on Mac-specific stuff, and a bunch of generalists who work on whatever needs to be improved at that particular moment. At no point is there just a "skeleton crew" working on OS X, because most people are working on code that impacts both platforms equally. The only real exceptions are folks working on applications (platform-specific), Springboard (iOS only), Dock (OS X only), AppKit, UIKit, and a few other miscellaneous pieces. And those folks aren't really interchangeable, so I don't think they borrow any of them from one side of the organization to beef up the other side.
Actually, Apple hiring legions of engineers is part of the problem. If you've looked at Apple's hiring numbers, they're growing at a crazy rate, and have been ever since the iPhone came out. The result is that there's too much new blood who don't understand why things were done the way they were done, and whose inclination is to do something new and different because it is new and different, rather than because it is better.
The result is the new iMovie, an endless string of major iTunes UI redesigns, the death of Aperture in favor of the Photos app, the death of FCP in favor of FCP X, the flat icon abomination, the Helvetica Neue abomination, and a developer docs website that does everything in its power to discourage actual development.
Trust me, hiring more people isn't the answer. It's the problem. Hiring fewer, better people with more experience is the answer.
Actually, the current iMovie that you complained about was, IIRC, originally just such a skunkworks project, and then somebody liked it so much that they wanted everybody to use it. I'm sure such things still happen all the time at Apple. I'm not so sure that they don't get released as finished products far more often than they should, however.
I suspect it is actually the other way around—that the deadlines were unrealistic, and that Tim Cook's insistence on meeting those deadlines anyway caused products to be announced (and in some cases to ship) before they were really ready, but I suppose it could be a combination of the two.
With SJ, if the technology had not been ready, he would probably have said something like, "We can't release this s**t. Call me when you're actually ready to show me something." If they had a fallback plan at all, it would have been a minor speed bump with no other changes, intended to hold folks over until the real product could be released a few months later, but realistically they would probably have slipped the announcement date by a few months to accommodate the delays in component availability so that they could ship what they wanted to ship instead of a shipping a compromise.
Apple's iOS devices didn't ship precisely on a yearly schedule under Jobs. Before his death, they shipped in June, July, June, June, and October, respectively. (Okay, so the October release was technically after his death, but just days after.) Ever since then, the iPhone has shipped precisely in mid-to-late September every single year. And OS X releases fell into a fairly strict 1-year release cadence at the same time. I think that this deadline-oriented planning is a major contributing factor to the decline in product quality that many of us perceive. They aren't taking the time they need to get things right before the products go out the door, and more and more often, they aren't able to get the bugs fixed in the previous software release before they ship a new release that introduces new bugs. And now, we're seeing the same problems on the hardware side.
I think it is time for Apple management to take a step back and slow down a little.