Live data from Hacker News

Osborning the Mac, or not

mondaynote.com

111–120 of 253 posts

Re: Osborning the Mac, or not

#111

Earlier quoted context omitted.

Also, if the transition from 32 to 64 bit is any indication, they don't care nearly as much about backwards compatibility as they used to. When they did the hardware transitions, they had a compatibility layer (Rosetta) that was supported for 5 years after the transition. But with the 32 bit change, the announced that it would no longer be supported in 2017, and dropped support in 2019, just 2 years later Apple hasn’…

>> Were developers really caught off guard that they shouldn’t be writing 32 bit software in 2017? Probably not, but end users shouldn't have to suffer because they bought software from bad developers. One reason why IE still ships with Windows is because a lot of companies are still using old enterprise software that never got updated for the modern web.

Have you read Raymond Chen's MS blog about all of the hacks that are in Windows just to keep backwards compatibility with one bad app? Maintaining backwards compatibility forever increases the security vulnerability to footprint, the testing surface for regressions, code size etc. Have you seen how badly Windows runs in low resource environments like the low end Surface line?

IE and the collapse of MS's browser market share is not exactly a shining example of how to successfully handle a product.

Re: Osborning the Mac, or not

#112

Earlier quoted context omitted.

68k to PPC was exactly "going from a popular architecture with broad software support to a less-popular architecture". ARM today is waaaaaaaaaaaay more popular than PowerPC ever was, and nearly infinitely more popular than when Apple switched from 68k, and 68k was very popular back then.

> 68k to PPC was exactly "going from a popular architecture with broad software support to a less-popular architecture". And Apple nearly went bankrupt. (Not saying Apple is in any danger of going bankrupt, but it's not a successful transition story.)

Commodore (known for the Amiga line) did go bankrupt due to the death of 68k. And Atari exited the home computer biz. It was a huge issue back in the day.

Re: Osborning the Mac, or not

#113
post #9

The author mentions Nokia as an example, I didn't follow the transition closely. Was everyone really waiting for the Windows Nokia phones or did Nokia just lose mindshare (as I remember it)? Any other good examples for Osborne Effect? Wikipedia does list SEGA's transition from Mega Drive/Genesis to 32X and Saturn and I can see how this confused potential customers but I guess there must be more (better?) examples. ht…

That announcement killed the little developer love that they still had.

Symbian was transitioning to better Java support, moving aways from Symbian C++ via Qt and PIPS (POSIX support for Symbian), 3rd Reboot of Symbian IDE (2nd Eclipse based attempt), having Python and Web based widgets as well.

Then comes the Windows phones announcement telling Symbian developers that all the tooling improvements from the last couple of years would be thrown out the Window.

That was the last drop to just abandon Nokia phones as platform for many of those developers, that decided to focus on Android/iOS instead.

Also as former employee that deal was quite a surprise to us, Nokia used to have a strong anti-MS culture on the engineering units.

Re: Osborning the Mac, or not

#114
post #47

Earlier quoted context omitted.

> Why would an app maker update their old apps before an announcement was made that they would be deprecated? Almost immediately after 64-bit support was added in 2005, it was the recommended path, not only for new apps but for existing ones to migrate to. For example, an document called "64-bit Transition Guide for Cocoa" [1] was first published in 2007. A few years later, another document [2] was more explicit: > S…

And that's why in 2006 they introduced Macbook Pros which were 32-bit only? If you want to switch to 64-bit, you don't introduce machines that cannot do that, that need their 32-bit ABI and have to be supported for years to follow.

Apple didn’t really have a choice. The choice required a fairly decent amount of legacy support for the next decade or so; I doubt they really wanted to commit to that if they didn’t have to.

Re: Osborning the Mac, or not

#115

Earlier quoted context omitted.

>> Were developers really caught off guard that they shouldn’t be writing 32 bit software in 2017? Probably not, but end users shouldn't have to suffer because they bought software from bad developers. One reason why IE still ships with Windows is because a lot of companies are still using old enterprise software that never got updated for the modern web.

Have you read Raymond Chen's MS blog about all of the hacks that are in Windows just to keep backwards compatibility with one bad app? Maintaining backwards compatibility forever increases the security vulnerability to footprint, the testing surface for regressions, code size etc. Have you seen how badly Windows runs in low resource environments like the low end Surface line? IE and the collapse of MS's browser marke…

You’re sort of picking the worst example, the alternate is the fact that Windows has maintained a gargantuan desktop OS market share for decades in large part because of their dedication to application compatibility.

Re: Osborning the Mac, or not

#116
1. Apple designed chips are already faster per-core than a top-end MacBook Pro.

2. There's no reason dedicated ASIC modules for specialized tasks (like video rendering) can't be connected by Thunderbolt 3 just as external video/compute modules are now.

3. There's no reason a dedicated x86-64 dongle can't be sold for ARM-powered Macs that need to run software that hasn't been ported yet. It would be a spectacular coup if those x86-64 dongles had chips made by AMD but I digress...

Re: Osborning the Mac, or not

#117

Earlier quoted context omitted.

>> Were developers really caught off guard that they shouldn’t be writing 32 bit software in 2017? Probably not, but end users shouldn't have to suffer because they bought software from bad developers. One reason why IE still ships with Windows is because a lot of companies are still using old enterprise software that never got updated for the modern web.

Have you read Raymond Chen's MS blog about all of the hacks that are in Windows just to keep backwards compatibility with one bad app? Maintaining backwards compatibility forever increases the security vulnerability to footprint, the testing surface for regressions, code size etc. Have you seen how badly Windows runs in low resource environments like the low end Surface line? IE and the collapse of MS's browser marke…

I didn't say there were not any tradeoffs made to support those users with legacy systems.

What do you define as a low end Surface line on x86? I have a Surface Pro 1 that I still use to this day. I also have a GPD Win handheld that's running an Atom processor that is surprisingly good for what it is. I also have some older Atom based stick PCs that are pretty bad (only 2GB RAM), but those are designed for signage and kiosks, for which they are... adequate.

Re: Osborning the Mac, or not

#118
post #65

Earlier quoted context omitted.

>But Apple can chew gum and walk at the same time. No. Look at MS and the difference in quality. They are both samey in the $$$ department, but MS much larger focus and enormous dev base makes it not such a nice thing for products. Apple reduced scope is what lets them have quality thing. They do not have much manpower (I mean, they are one of the few trillion dollar company, their human resources don't look like tha…

Even back in 2006, there were at least 7-8 different ways to define a string on Windows depending on which API you were using.

You may have missed GP's point. Microsoft is casts a very wide net, running on a huge array of hardware and trying to do everything from mobile to console gaming to datacenter servers. The dev experience is equally diverse: you don't even need a Windows box to develop for Windows.

Apple jettisoned all of that diversity to refine a few precious use cases to earn that "quality" aura.

I think this move to ARM is signaling a couple more use cases being tossed to the curb, like beefy workstations and PC gaming.

Re: Osborning the Mac, or not

#119

Earlier quoted context omitted.

> This seems inevitable, especially if Catalyst is central to how Apple carry out any ARM transition. That seems really unlikely to me. Catalyst is primarily a tool for porting iOS applications to macOS. Apple already has plenty of ARM-based devices that run iOS applications; there's no reason for them to muddy the waters by introducing another one and calling it a macOS system.

By my count, every new built-in app which Apple has introduced in the past two years has been a Catalyst app. It's possible I'm forgetting one, but the trend is pretty clear. Stock apps set the example for how third party apps should use your platform. IMO, Apple is setting a pretty clear example.

Music, TV, and App Store are “native”. (Yes, they suck.)

Re: Osborning the Mac, or not

#120

It's actually a brilliant move by Apple. After the new machines are released, all Mac app store apps will just magically work because they were recompiled behind the scenes by Apple to run on ARM. Only independent releases (stuff not in the app store) will have to deal with the shit show, which will also push more developers to the Apple tax. For regular Mac users (who are already using the app store for everything),…

> After the new machines are released, all Mac app store apps will just magically work because they were recompiled behind the scenes by Apple to run on ARM. That would be really magical; this is essentially impossible.

It's not every app as far as I know because I believe you can opt out of BitCode, but this would be widely the case with exceptions:

https://thenextweb.com/apple/2015/06/17/apples-biggest-devel...

https://www.highcaffeinecontent.com/blog/20190518-Translatin... (other direction but clearly demonstrative of what apple can do here)

Post reply on HN