41–50 of 185 posts
A programming language implementation that is subject to sandboxing? Mac has become the parody of a computer.
Why do we still have platform-specific applications in 2015? Any good software engineering environment should set an example and show that we do not need to live by such artificial restrictions.
As required by the Mac App Store, Haskell for Mac is sandboxed. Consequently, Haskell code executed in a Haskell for Mac playground cannot access any data except for Haskell for Mac documents, the app container, and those system files white-listed by the operating system. Any attempt to access other files or to initiate a network connection will be rejected by the operating system. This seems unnecessarily crippling.…
Yes, it’s required. Only some apps are exempt from sandboxing because they existed before sandboxing was introduced. You can also reach out of the sandbox through some user actions, for example opening a file using the system file picker gives you permissions to access this file. Yes, it’s a big constraint. For some apps it’s a show-stopper. As user I mostly welcome it because of the additional protection it gets me.
Source: https://www.google.com/search?q=os+x+root+exploit&gws_rd=ssl
Earlier quoted context omitted.
Yes, it’s required. Only some apps are exempt from sandboxing because they existed before sandboxing was introduced. You can also reach out of the sandbox through some user actions, for example opening a file using the system file picker gives you permissions to access this file. Yes, it’s a big constraint. For some apps it’s a show-stopper. As user I mostly welcome it because of the additional protection it gets me.
Apart from that it doesn't get you any additional protection whatsoever. With all the root OS X exploits floating around that bust you out of the sandbox as well as giving you full system access, as someone that has several utilities on the Mac App Store, it would be trivial to put an app there that gets set off by a timer, exploits root, and wreaks havoc. Source: https://www.google.com/search?q=os+x+root+exploit&gws…
Earlier quoted context omitted.
Yes, it’s required. Only some apps are exempt from sandboxing because they existed before sandboxing was introduced. You can also reach out of the sandbox through some user actions, for example opening a file using the system file picker gives you permissions to access this file. Yes, it’s a big constraint. For some apps it’s a show-stopper. As user I mostly welcome it because of the additional protection it gets me.
Apart from that it doesn't get you any additional protection whatsoever. With all the root OS X exploits floating around that bust you out of the sandbox as well as giving you full system access, as someone that has several utilities on the Mac App Store, it would be trivial to put an app there that gets set off by a timer, exploits root, and wreaks havoc. Source: https://www.google.com/search?q=os+x+root+exploit&gws…
Why do we still have platform-specific applications in 2015? Any good software engineering environment should set an example and show that we do not need to live by such artificial restrictions.
Because there’s no environment that would give you native-like experience on multiple platforms without extra work. And developers have limited resources, even in 2015.
Sure, writing the GUI properly for each platform still requires more work, but far far less if all but the front end is cross platform.
However, it very rarely seems to be done, even with modern additions and improvements in C++.
Why do we still have platform-specific applications in 2015? Any good software engineering environment should set an example and show that we do not need to live by such artificial restrictions.
Because there’s no environment that would give you native-like experience on multiple platforms without extra work. And developers have limited resources, even in 2015.
Why do we still have platform-specific applications in 2015? Any good software engineering environment should set an example and show that we do not need to live by such artificial restrictions.
And what's the advantage to the average user? If I'm a Mac user, I'm interested in Application X working just like every other Mac application. Similarly if I'm a Windows user. I'm rarely bothered that Application X works the same on both Windows and Mac.
As required by the Mac App Store, Haskell for Mac is sandboxed. Consequently, Haskell code executed in a Haskell for Mac playground cannot access any data except for Haskell for Mac documents, the app container, and those system files white-listed by the operating system. Any attempt to access other files or to initiate a network connection will be rejected by the operating system. This seems unnecessarily crippling.…
Exhibit A for how questionable this Sandboxing is when it comes to things like programming languages. And exhibit A for how Mac is becoming a household appliance instead of a general-purpose computer that YOU own and do with what YOU want. If you want to own your Mac you need to stay away from the AppStore at the very least, and ideally build all your shit yourself.