If the future is supposedly going to be this locked down, I wonder what will happen to the internet when there is no hardware left where you can develop stuff like apache-httpd and php and mysqld.
Nothing stopping you from installing Blink Shell or Prompt on your iPad-like device and connecting to a GCE instance or your own linux server to work on those things.
Apple already has several ARM powered laptops drifting around internally
31–40 of 48 posts
Re: Apple already has several ARM powered laptops drifting around internally
#32Earlier quoted context omitted.
Mac is dead for developers and pro users if this is the case. My current Mac will be my last, and I'll be happy to give my money to Dell instead and anyone else selling more open hardware. One of our devs just got a new XPS 15. It's a gorgeous machine. Amazing. First time I've envied a non-Apple machine since the early 2000s. I still marginally prefer the Mac track pad but the rest is on par or better.
Can confirm. I sold my MBP and bought myself one of the new Dell 15" developer editions. Trackpad is about on par with the prior physically-clicking mac trackpads. I run Fedora and the only thing that doesn't work is hot-plugging the Ethernet adapter. Otherwise all the usual Linux pitfalls like sleep/wake, wifi, hidpi, touch screen, etc. work fine out of the box. No plans to switch away.
Re: Apple already has several ARM powered laptops drifting around internally
#33Makes sense. Allegedly they had pretty much every version OS X after Rhapsody continuing to run on x86 in some capacity until the x86 version of OS X finally came out. Keeping an ARM version around seems like a no brainer. I suspect this isn't being held in case the Mac market falls apart, but in case the iPad market starts losing to Surface and friends.
(That said, even on this account they had laptops running Intel for several years before the transition was decided upon).
Re: Apple already has several ARM powered laptops drifting around internally
#34Makes sense. Allegedly they had pretty much every version OS X after Rhapsody continuing to run on x86 in some capacity until the x86 version of OS X finally came out. Keeping an ARM version around seems like a no brainer. I suspect this isn't being held in case the Mac market falls apart, but in case the iPad market starts losing to Surface and friends.
Exactly, in fact there's even more to it then that. Particularly at Apple's scale, maintaining a codebase across multiple architectures internally, even if there is absolutely zero foreseeable intention to use them, offers significant value. Strategically of course it creates some hedge against over dependence on any single supplier, it's not just "the Mac market falling apart" so much as Intel/AMD dropping the ball…
Re: Apple already has several ARM powered laptops drifting around internally
#35Re: Apple already has several ARM powered laptops drifting around internally
#36I don't know how CPUs and instructions work but wouldn't this mean that every app has to be recompiled for ARM or run in an emulator?
Re: Apple already has several ARM powered laptops drifting around internally
#37Earlier quoted context omitted.
Yeah, I think they'll lose 99.5% developer mindshare as well. Which is the one thing Ballmer got right. Don't underestimate the value of developer support for a platform like iOS.
developers go where there is money to be made. only having xcode on osx/macos hasn't hurt apple a bit.
Re: Apple already has several ARM powered laptops drifting around internally
#38Earlier quoted context omitted.
Isn't Apple still in the better position here? Since it comes with Unix-friendly tools, and most of the languages and tools you listed.
Do you think you'll be able to use those tools in a gatekeeper-MAS-only world? Or if Apple ships prebuilt versions, how well supported will they be by the authors of those tools if they can't develop and compile new versions on the platform on their own? For a preview of the future, try this one on macOS 10.12 today: % lldb --one-line run /usr/bin/python spoiler: Current executable set to '/usr/bin/python' (x86_64).…
There is a genuine argument about control but overselling it just lowers your credibility, especially since it reveals tunnel vision: statistically very few Mac users need to run a debugger but more are at risk for malware which uses sensitive APIs.
Re: Apple already has several ARM powered laptops drifting around internally
#39Earlier quoted context omitted.
Yeah, I think they'll lose 99.5% developer mindshare as well. Which is the one thing Ballmer got right. Don't underestimate the value of developer support for a platform like iOS.
developers go where there is money to be made. only having xcode on osx/macos hasn't hurt apple a bit.
Re: Apple already has several ARM powered laptops drifting around internally
#40Earlier quoted context omitted.
Do you think you'll be able to use those tools in a gatekeeper-MAS-only world? Or if Apple ships prebuilt versions, how well supported will they be by the authors of those tools if they can't develop and compile new versions on the platform on their own? For a preview of the future, try this one on macOS 10.12 today: % lldb --one-line run /usr/bin/python spoiler: Current executable set to '/usr/bin/python' (x86_64).…
Your example is just showing that Apple picked decent security defaults for binaries which they ship. SIP can be disabled any time you want and it doesn't apply to things you compile. There is a genuine argument about control but overselling it just lowers your credibility, especially since it reveals tunnel vision: statistically very few Mac users need to run a debugger but more are at risk for malware which uses se…
Also, if you have malware getting far enough to try to ptrace binaries running on your uid, I would imagine things are still game over despite being prevented from debugging a new interpreter process. I'm not buying the malware scare when it comes to debugging newly forked processes on a non-root uid.
I think your argument would have been valid if I'd never clicked "enable debugging for this mac" in xcode.