1. 18
  1.  

  2. 6

    I think the faulty assumption is that the happiness of users and developers is more important to the corporate bottom line than full control over the ecosystem.

    Linux distributions have shown for a decade that providing a system for reliable software distribution while retaining full user control works very well.

    Both Microsoft and Apple kept the first part, but dropped the second part. Allowing users to install software not sanctioned by them is a legacy feature that is removed – slowly to not cause too much uproar from users.

    Compare it to the time when Windows started “phoning home” with XP … today it’s completely accepted that it happens. The same thing will happen with software distributed outside of Microsoft’s/Apple’s sanctioned channels. (It indeed has already happened on their mobile OSes.)

    1. 8

      As a long-time Linux user and believer in the four freedoms, I find it hard to accept that Linux distributions demonstrate “providing a system for reliable software distribution while retaining full user control works very well”. Linux distros seems to work well for enthusiasts and places with dedicated support staff, but we are still at least a century away from the year of Linux on the desktop. Even many developers (who probably have some overlap with the enthusiast community) have chosen Macs with unreliable software distribution like Homebrew and incomplete user control.

      1. 2

        I agree with you that Linux is still far away from the year of Linux on the desktop, but I think it is not related to the way Linux deals with software distribution.

        There are other, bigger issues with Linux that need to be addressed.

        In the end, the biggest impact on adoption would be some game studios releasing their AAA title as a Linux-exclusive. That’s highly unlikely, but I think it illustrates well that many of the factors of Linux’ success on the desktop hinge on external factors which are outside of the control of users and contributors.

        1. 2

          All the devs I know that use mac use linux in some virtualisation options instead of homebrew for work. Obviously thats not scientific study by any means.

          1. 8

            I’ll be your counter example. Homebrew is a great system, it’s not unreliable at all. I run everything on my Mac when I can, which is pretty much everything except commercial Linux-only vendor software. It all works just as well, and sometimes better, so why bother with the overhead and inconvenience of a VM? Seriously, why would you do that? It’s nonsense.

            1. 4

              Maybe a VM makes sense if you have very specific wishes. But really, macOS is an excellent UNIX and for most development you won’t notice much difference. Think Go, Java, Python, Ruby work. Millions of developers probably write on macOS and deploy on Linux. I’ve been doing this for a long time and ‘oh this needs a Linux specific exception’ is a rarity.

              1. 4

                you won’t notice much difference.

                Some time ago I was very surprised that hfs is not case sensitive (by default). Due to a bad letter-case in an import my script would fail on linux (production), but worked on mac. Took me about 30 minutes to figure this out :)

                1. 3

                  You can make a case sensitive code partition. And now with APFS, partitions are continuously variable size so you won’t have to deal with choosing how much goes to code vs system.

                  1. 1

                    A case sensitive HFS+ slice on a disk image file is a good solution too.

                  2. 2

                    Have fun checking out a git repo that has Foo and foo in it :)

                    1. 2

                      It was bad when microsoft did it in VB, and it’s bad when apple does it in their filesystem lol.

                  3. 2

                    Yeah definitely. And I’ve found that accommodating two platforms where necessary makes my projects more robust and forces me to hard code less stuff. E.g. using pkg-config instead of yolocoding path literals into the build. When we switched Linux distros at work, all the packages that worked on MacOS and Linux worked great, and the Linux only ones all had to be fixed for the new distro. 🙄

                  4. 2

                    I did it for awhile because I dislike the Mac UI a lot but needed to run it for some work things. Running in a full screen VM wasn’t that bad. Running native is better, but virtualization is pretty first class at this point. It was actually convenient in a few ways too. I had to give my mac in for repair at one point, so I just copied the VM to a new machine and I was ready to run in minutes.

                    1. 3

                      I use an Apple computer as my home machine, and the native Mac app I use is Terminal. That’s it. All other apps are non-Apple and cross-platform.

                      That said, MacOS does a lot of nice things. For example, if you try to unmount a drive, it will tell you what application is still using it so you can unmount it. Windows (10) still can’t do that, you have to look in the Event viewer(!) to find the error message.

                      1. 3

                        In case it’s unclear, non-Native means webapps, not software that doesn’t come preinstalled on your Mac.

                        1. 3

                          It is actually pretty unclear what non-Native here really means. The original HN post is about sandboxed apps (distributed through the App Store) vs non-sandboxed apps distributed via a developer’s own website.

                          Even Gruber doesn’t mention actual non-Native apps until the very last sentence. He just talks/quotes about sandboxing.

                          1. 3

                            The second sentence of the quoted paragraph says:

                            Cocoa-based Mac apps are rapidly being eaten by web apps and Electron pseudo-desktop apps.

                      2. 1

                        full-screen VM high-five

                      3. 1

                        To have environment closer to production I guess (or maybe ease of installation, dunno never used homebrew). I don’t have to use mac anymore so I run pure distro, but everyone else I know uses virtualisation or containers on their macs.

                        1. 3

                          Homebrew is really really really easy. I actually like it over a lot of Linux package managers because it first class supports building the software with different flags. And it has binaries for the default flag set for fast installs. Installing a package on Linux with alternate build flags sucks hard in anything except portage (Gentoo), and portage is way less usable than brew. It also supports having multiple versions of packages installed, kind of half way to what nix does. And unlike Debian/CentOS it doesn’t have opinions about what should be “in the distro,” it just has up to date packages for everything and lets you pick your own philosophy.

                          The only thing that sucks is OpenSSL ever since Apple removed it from MacOS. Brew packages handle it just fine, but the python package system is blatantly garbage and doesn’t handle it well at all. You sometimes have to pip install with CFLAGS set, or with a package specific env var because python is trash and doesn’t standardize any of this.

                          But even on Linux using python sucks ass, so it’s not a huge disadvantage.

                          1. 1

                            Installing a package on Linux with alternate build flags sucks hard in anything except portage

                            You mention nix in the following sentence, but installing packages with different flags is also something nix does well!

                            1. 1

                              Yes true, but I don’t want to use NixOS even a little bit. I’m thinking more vs mainstream distro package managers.

                            2. 1

                              For all its ease, homebrew only works properly if used by a single user who is also an administrator who only ever installs software through homebrew. And then “works properly” means “install software in a global location as the current user”.

                              1. 1

                                by a single user who is also an administrator

                                So like a laptop owner?

                                1. 1

                                  A laptop owner who hasn’t heard that it’s good practice to not have admin privileges on their regular account, maybe.

                              2. 1

                                But even on Linux using python sucks ass, so it’s not a huge disadvantage.

                                Can you elaborate more on this? You create a virtualenv and go from there, everything works.

                                1. 2

                                  It used to be worse, when mainstream distros would have either 2.4 or 2.6/2.7 and there wasn’t a lot you could do about it. Now if you’re on python 2, pretty much everyone is 2.6/2.7. Because python 2 isn’t being updated. Joy. Ruby has rvm and other tools to install different ruby versions. Java has a tarball distribution that’s easy to run in place. But with python you’re stuck with whatever your distro has pretty much.

                                  And virtualenvs suck ass. Bundler, maven / gradle, etc. all install packages globally and let you exec against arbitrary environments directly (bundle exec, mvn exec, gradle run), without messing with activating and deactivating virtualenvs. Node installs all it’s modules locally to a directory by default but at least it automatically picks those up. I know there are janky shell hacks to make virtualenvs automatically activate and deactivate with your current working directory, but come on. Janky shell hacks.

                                  That and pip just sucks. Whenever I have python dependency issues, I just blow away my venv and rebuild it from scratch. The virtualenv melting pot of files that pip dumps into one directory just blatantly breaks a lot of the time. They’re basically write once. Meanwhile every gem version has it’s own directory so you can cleanly add, update, and remove gems.

                                  Basically the ruby, java, node, etc. all have tooling actually designed to author and deploy real applications. Python never got there for some reason, and still has a ton of second rate trash. The scientific community doesn’t even bother, they use distributions like Anaconda. And Linux distros that depend on python packages handle the dependencies independently in their native package formats. Ruby gets that too, but the native packages are just… gems. And again, since gems are version binned, you can still install different versions of that gem for your own use without breaking anything. Python there is no way to avoid fucking up the system packages without using virtualenvs exclusively.

                                  1. 1

                                    But with python you’re stuck with whatever your distro has pretty much.

                                    I’m afraid you are mistaken, not only distros ship with 2.7 and 3.5 at same time (for years now) it is usually trivial to install newer version.

                                    let you exec against arbitrary environments directly (bundle exec, mvn exec, gradle run), without messing with activating and deactivating virtualenvs

                                    You can also execute from virtualenvs directly.

                                    Whenever I have python dependency issues, I just blow away my venv and rebuild it from scratch.

                                    I’m not sure how to comment on that :-)

                                    1. 1

                                      it is usually trivial to install newer version

                                      Not my experience? How?

                                      1. 1

                                        Usually you have packages for all python versions available in some repository.

                        2. 2

                          Have they chosen Macs or have they been issued Macs? If I were setting up my development environment today I’d love to go back to Linux, but my employers keep giving me Macs.

                          1. 3

                            Ask for a Linux laptop. We provide both.

                            I personally keep going Mac because I want things like wifi, decent power management, and not having to carefully construct a house of cards special snowflake desktop environment to get a useable workspace.

                            If I used a desktop computer with statically affixed monitors and an Ethernet connection, I’d consider Linux. But Macs are still the premier Linux laptop.

                            1. 1

                              At my work place every employee is given a Linux desktop and they have to do a special request to get a Mac or Windows laptop (Which would be in addition to their Linux desktop).

                          2. 3

                            Let’s be clear though, what this author is advocating is much much worse from an individual liberty perspective than what Microsoft does today.

                            1. 4

                              Do you remember when we all thought Microsoft were evil for bundling their browser and media player? Those were good times.

                          3. 6

                            “One language, one IDE, one build system (built in into IDE), one workflow” is killing “native” apps. You can’t even compile cocoa app without XCode (which is quite crappy IDE), you can’t build cocoa apps on Linux CI, you (almost) can’t write cocoa apps in python/ruby/js. And now you should buy signing certificate from Apple. “Native” apps are feasible only if you are huge company like Google, or if you are targeting only Mac.

                            (I think GTK and Qt apps are not considered “native”)

                            1. 6

                              As someone who doesn’t use Macs anymore, I’m happy to see more cross-platform apps and less Mac-native ones :P

                              But seriously: why are these people saying that just because there was a flaw in the sandbox, the sandbox should be abandoned completely and all desktops should go back to what’s basically the X11 “security” “model”?!

                              the Mac needs the power for apps to shoot the user in the foot

                              You can do everything that could shoot the user in the foot without actually shooting them in the foot. It’s not hard to provide access-controlled APIs for all the things. And the Mac is already good at this. They’ve had the Accessibility API for years – manipulating windows and stuff requires the user to grant permission. XPC (if I remember the name correctly) for opening files and stuff is a great idea.

                              The unix world is finally catching up, with freedesktop D-Bus Portals (currently used by Flatpak). And D-Bus can also used… you guessed it – to request screenshots. The window system can display its own UI that makes it clear to the user that a screenshot is being taken.

                              1. 3

                                I agree. I found this post hard to follow. I don’t know the details of the Mac sandbox technology, but it’s quite a jump from needing to be able to do interesting, complicated things and abandoning a proper security model altogether. I think Android (or at least OnePlus’ OxygenOS version) actually has a good example of this: apps are isolated and sandboxed (I think), but things like the global sharing menu make interaction between apps very easy and seamless. Of course, there are some apps (like Facebook) that don’t use the system menus, but there are going to be some bad actors on any platform.

                                1. 1

                                  I think the core point the author is making is not that sandboxes should be dropped because of this security issue, but because the overlap of “things the sandbox allows apps to do” and “things I want my apps to do” is really small, probably too small to cover many features people want to use.

                                2. 2

                                  I think the Mac’s (relatively) recent move to cryptographically signed applications — with certificates that can be revoked by Apple — has been a win all around for security.

                                  I do love giving a corporation complete and total control over what to censor secure. Apple and their products are I think consistently harmed by the lapdogs who refuse to stand up to consumer freedom.

                                  1. 1

                                    As a developer who moved from Linux to the macOS platform, this made me think about how many non-native apps I use as replacements for the Apple version. The obvious ones I’m thinking of:

                                    • Alfred instead of Spotlight
                                    • iTerm2 instead of Terminal
                                    • Dropbox instead of iCloud
                                    • Chrome instead of Safari
                                    • Gmail instead of Mail
                                    • Google Maps instead of Maps
                                    • VLC instead of iMovie
                                    • Spotify instead of iTunes
                                    • Signal instead of Messages

                                    &c. This surely isn’t a good trend for Apple to allow to continue.

                                    1. 13

                                      That’s not what’s meant by “native” in this case. Alfred, iTerm, Dropbox, Chrome, and VLC are native. Spotify is Electron, and I’m not sure about Signal. I’m guessing it’s probably a native app that does most of its UI in a WebView.

                                      1. 5

                                        Signal for Desktops is Electron.

                                        1. 2

                                          As it might be useful to describe what is meant by native, it means something on a spectrum between “using the platform-supplied libraries and UI widgets”, i.e. Cocoa and “not a wrapped browser or Electron app”, so it’s not clear whether an application using the Qt framework would be considered “native”. It could be delivered through the App Store and subject to the sandbox restrictions, so fits the bill for a “native” app in the original post, but it would also not be using the native platform features which are presumably seen as Apple’s competitive advantage for the purpose of the same post.

                                          1. 2

                                            I’d call QT native. It doesn’t use the native widgets, but then neither do most applications that are available on multiple platforms.

                                            1. 2

                                              It may be native, but it’s not Mac-native in the sense Gruber was talking about. You will find that all three uses of “native” in his article appear as “native Cocoa apps” or “native Mac apps”. He is talking about a quite specific sense of native: apps that integrate seamlessly with all of the MacOS UI conventions (services, system-wide text substitutions, native emoji picker, drag & drop behaviours, proxy icons, and a myriad more). Qt apps do not.

                                        2. 5

                                          Why is it not a good trend? You are still using a Mac .. they sold you the hardware. Should they care about what apps you run?

                                          1. 3

                                            Apps with good experiences that aren’t available on other platforms keep users around. Third-party iOS apps do a better job of moving iPhones than anything else Apple does, because people who already have a pile of iOS apps they use generally buy new iPhones.

                                            Electron is just the latest in a long series of cross-platform app toolkits, and it has the same problems that every other one has had: look & feel, perceived inefficiency, and for the OS vendor, doesn’t provide a moat.

                                            1. 1

                                              Counterpoint, their apps have always been limited and really for people who weren’t willing to learn and use more robust tooling. I mean how many professionals use iMovie.

                                              1. 1

                                                iMovie is a good example. I’m guessing a lot of us prefer VLC.

                                            2. 1

                                              It’s good for the end user but not a good trend for their business model, part of which is to have best-in-class apps. Don’t get me wrong, I like having choice and I think they shouldn’t force you into their own app ecosystem.