Building Elixir from source segfaults on macOS on Apple Silicon while compiling | Hacker News Reader

Building Elixir from source segfaults on macOS on Apple Silicon while compiling

groups.google.com

113 pointsshadykiller169 comments

Related: ongoing compatibility table compiled by the Homebrew team: https://github.com/Homebrew/brew/issues/7857. (Please respect the team and refrain from polluting the thread. If in doubt check the comments marked off topic.)

No GCC support if I read that correctly and the effort is expected to take months of full time work. I wonder what that'd break or is Clang significantly more common on OSX now?

Well, for one, this means that Apple Silicon has no Fortran compiler, which breaks a decent chunk of the scientific computing ecosystem.

is there not an flang project? Is it any good?

There's several! We tried all of them without much luck :(. The most complete seems to be the old flang, which was basically an open sourced version of the PGI compiler hacked up to generate LLVM IR by concating strings to generate textual LLVM IR. However, that project is basically abandoned and also depends on LLVM 7, while you probably want at least LLVM 10 to generate good code for Apple Silicon, so somebody would have to do that porting work, which doesn't seem like a worthwhile investment.

Hopefully apple will do something about it as they did advertise their new system would be great for machine learning and all, which seem to be moot without many popular numeric libraries that directly or indirectly use fortran. Would be great if clang/llvm suddenly gain a great open source fortran compiler just because apple moves to arm.

Does anyone in the scientific computing ecosystem use Macs?

I can't think of...any program abyss dynare adios2 eccodes apache-arrow ensmallen apache-arrow-glib fastme arcade-learning-environment fftw armadillo field3d arpack flann arss fobis astrometry-net gdal asymptote gdcm aubio gmic augustus gmsh biosig gmt boost-mpi gmt@5 bsponmpi gnuradio caffe gr-osmosdr calceph grace cdo graph-tool ceres-solver gromacs cgns gwyddion clp hackrf coinutils hdf5 cp2k hdf5-mpi cpl hdf5@1.10 csound hdf5@1.8 dartsim hypre datetime-fortran imake dlib imgproxy dungeon inspectrum dvc ipopt 147 formulae.

Edit: Forgot to libtorrent-rasterbar made front The thing with Arch updates is OR >turns out the person compiled in that sphere that aren't Windows or Linux?

Lots of students have Mac notebooks, but want to run julia/scientific python/etc.

Yes, that would be me, and half if not most of my colleagues.

Very much yes

Sadly, yes. I've clients who still prefer to work on their Mac laptop and desktops. Large runs still go to Linux clusters, but small, debugging runs occur locally.

Per the parent, the lack of Fortran compiler causes an issue because some BLAS/LAPACK libraries align their symbols with whatever a Fortran compiler would do. As such, unless there's been a recent change, things like CMake need the compiler to determine the name for linear algebra routines.

I phrased the above as "sadly, yes" because supporting macos has been a pain and costs a fair amount of labor. In my case, Homebrew is required and there a bunch of specialized quirks in the build and packaging system that I'll contend are more difficult to deal with on macos than on Linux and Windows. Lastly, the requirement that macos be virtualized only on mac hardware complicates automating the build and test system since those processes must be relegated to a macos machine and I'd really rather not do primary development on a mac. Frankly, I'd pay Apple a not small amount of money to virtualize macos legally on non-mac hardware.

BLAS/LAPACK isn't that much of an issue, since Apple probably will need to ship their own implementation of this for Apple Silicon to get reasonable performance, and they can implement this in C, assembly, or whatever they want.

If they don't do that, then you can just use any "generic" C BLAS/LAPACK implementation, performance will be poor, but that's pretty much the only option if your hardware vendor doesn't support BLAS.

I guess people can write their own BLAS as well, but if you want to re-implement BLAS in 2020, then Fortran is probably not the best language to do that.

Apple's copy of LAPACK has not been keeping up with upstream and is missing some of the newer methods and bug fixes. Also while those are certainly the big two dependencies they are by far not the only ones.

Sure, lots.

I see the opposite from you: Mac laptops, crunching under Linux, very rarely see windows in the wild. I know windows sales are still robust so this is what I see but am not sure how far it can be extrapolated.

A huge chunk of scientific and numerical libraries rely on Fortran, for which 64-bit support is seriously lacking on Windows.

Doing this work is significantly easier out-of-the-box on Mac/Linux device.

Data Science is my main job and the first thing I did at my last job was ask if I could wipe windows and put Linux on the desktop they gave me.

> A huge chunk of scientific and numerical libraries rely on Fortran, for which 64-bit support is seriously lacking on Windows.

How so? mingw-64 exists, and so does Intel Fortran (with good integration with the VS IDE as well).

Intel and PGI Fortran work just fine on Windows, with VS integration as pointed by others already.

Yes. Most people in my lab have a MacBook (Pro) where we do most of our coding, and we ssh into a Linux cluster to run most of the compute. We have desktops but these are all Windows/Linux dual boots. We all practically need to use PowerPoint as well, so Mac is nice to have here since it can’t go on Linux laptops, and nobody wants to constantly reboot all the time.

Walking down the hallway in my physics department (pre-covid lockdown), I see almost all Macs. Some of them run windows, but most are apple hardware and software. Windows is quite rare when it comes to professors. It's more common among the grad students though, about tied with MacOS.

It was like this in my previous department as well.

Would it would work under Rosetta 2 (Apple's x64 emulation/translation layer) until the aarch64/darwin ABI can be ported to GCC? Or is there a reason to assume it might not?

Yes, it works mostly fine under Rosetta. However, it is also precisely the area where you don't really want a translation layer, because you're spending a lot of time doing heavy compute.

That makes sense. I'm hoping it's going to be an early adopter problem that'll have been solved by the time the transition is deemed complete.

Many compute heavy tasks are using Metal and those should continue to function at the full speed of the hardware.

I doubt GCC is, or even could be, using Metal.

I am referring to modern HPC like workloads, they will be using the GPU. Not saying GCC is using Metal in any way whatsoever.

HPC on macOS? Using Metal instead of CUDA/OpenCL? Sounds extremely rare.

Not sure if it's changed, but last i checked a few years back, most of the BLAS/LAPACK etc. stuff was f77, which should 'do' with f2c (albeit, perhaps not as fast) and is at least partly why f2c was hosted at netlib..

I had no idea, that explains so much! I was wondering how these open source numerical systems were building fortran code "so well", as in not a huge operational burden. My understanding is that the OSS fortran compilers are used for dev/debug, but when it comes to production, commercial Fortran compilers for your platform vendor offer much better performance.

Won’t this work? https://lfortran.org/

I just did a quick google search for it. I know nothing more than that it is FORTRAN compiler for LLVM. (It claims to be an alpha release)

Perhaps! It's one of the two candidates that might actually work in the near term. It didn't quite seem to work out of the box and given the newness of the project, we are a bit cautious, but there's some folks looking into it, to see if they can work through the issues.

This is incorrect, the LLVM project has an official Fortran compiler in tree called flang: https://github.com/llvm/llvm-project/tree/master/flang

It is quite hard to write portable Fortran code, but code that at least compiles with PGI should compile with that as well.

I wonder why this is allowed to persist? Have there been any studies across benchmark suites relative to compiler and platform? What was the spread? Was this general purpose, it works well enough speed or was this I need to get 1.75% better on task x or my super computer budget is blown?

I find the whole Fortran ecosystem and lineage fascinating for some reason. Like an alternative universe where integers are only used for loop counters.

If you actually read the code, it turns out that said compiler is not yet capable of generating LLVM IR let alone binaries.

Wait what? We were using the old flang project just fine. I thought they just moved it in tree and keept developing it.

There was old flang which was basically just the PGI compiler stripped of its backend and with a piece bolted on that converted the compiler's internal IR to LLVM by basically dumping out strings and then parsing them back in. Many people in the LLVM community thought that this was not a maintainable long term strategy for a Fortran frontend, and after much debate, the flang team decided to start over on Greenfield compiler called f18, which was to be architected more like clang. Then Chris released MLIR and said team decided to target that rather than LLVM directly. The only thing that was kept from old flang were some of the runtime libraries. f18 was recently merged into the llvm-project repository whereupon it was renamed flang. Old flang is dead, but the terminology is a bit confusing now. Additionally there are two external LLVM Fortran compiler efforts: lfortran out of the US national labs (which also paid PGI for flang) and fc, which I don't believe is currently open source, but is being developed by as compiler consulting shop on India called CompilerTree (not sure who's footing the bill for that one). Anyway, long story short, none of them seem to work. Old flang generates binaries, but is abandonware at this point, so not the correct foundation to build on. New flang doesn't even generate LLVM IR yet. FC doesn't seem public yet as I said. Lfortran may work, but the authors say it's very alpha and it certainly didn't work out of the box. I know some folks are looking into it to see what would be required.

Apple sucks for scientific computing. It does not let you even load your own generated shared files, because Apple determines it is too dangerous for the health my own purchased computer. I have never had that problem on Windows or Linux. That said, you can get gfortran by as simple as typing brew install gcc-9, or some similar command (requires brew installation).

By Homebrew policy, anything requiring a C/C++ compiler but doesn't compile with clang is out. So gcc not working shouldn't disrupt the overall Homebrew ecosystem too much. The biggest problem is gfortran, which is what the great majority of gcc dependents use it for (just `rg 'depends_on "gcc"'` in homebrew-core and all the "# for gfortran" comments should make this obvious).

Btw, here's the list turned up by a dependent search in core:

  $ brew uses --recursive gcc itk                             numpy                           qrupdate itpp                            numpy@1.16                      r jags                            nwchem                          ratfor joplin                          octave                          rawtoaces json-fortran                    ola                             raxml-ng kahip                           ompl                            reprepro kallisto                        open-mpi                        root kim-api                         openblas                        scalapack lammps                          opencoarrays                    scipy lapack                          opencv                          shogun libbi                           opencv@2                        simple-tiles libmatio                        opencv@3                        siril libxc                           openfast                        skymaker liquid-dsp                      openkim-models                  sratoolkit luaradio                        osi                             suite-sparse mapnik                          osm2pgrouting                   sundials mapserver                       otf2                            superlu minimodem                       packmol                         synfig mlpack                          pcl                             urh mpdviz                          pdal                            veclibfort mpi4py                          petsc                           vips mpich                           petsc-complex                   virtualpg mvtools                         pgplot                          visp ncmpcpp                         pgrouting                       vtk nco                             plplot                          waon ncview                          pnetcdf                         wxpython nest                            points2grid                     zita-convolver netcdf                          postgis networkit                       proteinortho ngspice                         qd --include-build. That would add 4:
  boost-python3 btfs libtorrent-rasterbar openimageio page today btw...

Weird to see wxPython on the list..

Any numpy (which uses gfortran) dependent is on that list. I suspect some could partially work by sacrificing some functionality, or maybe just run slower (disclaimer: I have no idea of numpy internals).

does numpy leverage blas?

yes

Yes. https://github.com/numpy/numpy/blob/62fa23c44fb49c1d238e1de4...

well, that's probably where the fortran dependency could creep in, no?

Wouldn't that entail swapping out all the underlying Fortran that makes NumPy so lovely?

Interestingly at WWDC Apple said that they are contributing patches to NumPy to get it to work on Apple Silicon

GCC supports ARM targets and the macos platform. It took a couple of hours to add support for the new target triple to Rust, so it should take about the same work to add support to it for each of the GCC frontends (10x couple of hours ~ couple of days, maybe a week).You don't need to implement neither hardware support nor OS support, just combine the two things that are already implemented, and fix a couple of incompatibilities, but not many (some parts of OS support will be x86 only and these would need fixing, but fixing these should be trivial since you can c&p from the arm+iOS code).
Why would it take months to add support for this to GCC? GCC's architecture would need to be really flawed for this to be true, i.e. , requiring you to re-implement a big chunk of hardware support for each OS, or full OS support for each new hardware. Given how many architectures and OSes GCC supports I just can't imagine this being true.
Unless by this work taking months, you mean "not doing anything the first 99% of the days, and doing all the work in the last couple of days". In that case, sure, this can take as long as you want.

Yeah, I was surprised by that statement too, but then again, I know nothing about how GCC is architected. I'm hoping somebody will come along and just fix it in a few days, but who knows.

https://developer.apple.com/library/archive/documentation/Xc...

Starting to feel vindicated by my refusal to use Homebrew when I migrated to macOS recently. It felt like bringing a whole lot of baggage along.All I need is working golang and Python 3. The rest I can do on a box in AWS.

It's nice to have a setup that lets you get stuff done with a remote machine without needing a lot of parts strung together - I had this at a previous role. I've also had roles with very little support, and being able to spin up all the utilities I needed on a work computer was helpful.

IMO Apple should be sponsoring that work.

IMO Mac OS X should come with its own integrated package manager and corresponding central repository for distribution of various open source software packages. A package manager that worked well with the App Store and Xcode.

This is their only real chance to keep Devs from migrating to Windows 10 with WSL2 or baremetal Linux. I couldn't believe they didn't announce any thing for Big Sur, I could have sworn they would if they really cared about non-macOS/ipadOS/iOS devs. Especially that they're also dropping Perl/Python/Ruby frameworks.If anything, they could have just low-key embrace brew and take it from there. They didn't, and I think that sends a message: they've given up.

During the ARM announcement they said they would be contributing support to open source projects, and Homebrew was on the slide, along with a dozen or so other major projects (though Homebrew itself represents hundreds). I do not know what form that assistance will come in.

Apple has been dropping lots of balls in this way.They should support open source in an official way.  They should support other languages besides swift.  They should support virtualization/containers.  They should embrace techies, scientists and engineers.  But it seems they're closing down these areas of their ecosystem.

The first comment on that thread is from the creator of Elixir:> Elixir doesn’t compile any native code. Therefore these errors mean that you were able to compile the Erlang VM but either the code or the compiler has bugs and the VM is seg faulting.

I’ve run into errors compiling the Erlang VM before (just doing some Linux package management). If I casually ran into these types of issues on x86, I’m skeptical this really has anything to do with Apple Silicon, which is ARM after all.

Erlang compiles and runs fine on ARM architectures in general. It is used extensively on IoT platforms like https://www.nerves-project.org/

Probably not super well tested with a bleeding edge clang compiler though (and even for non-bleeding-edge versions, I'd suspect mostly tested with GCC). Triggering compiler bugs or exposing technically undefined behavior would not be entirely surprising.

True. IIRC Erlang only supports GCC as the build system. I  helped fixing a race in the BEAM a while back that only occurred on the latest GCC.

> IIRC Erlang only supports GCC as the build system.Since gcc doesn't work on Apple Silicon, I assumed the OP must be using clang :).

gcc certainly compiles for ARM and understands Darwin/mach-o. It can probably target iOS. What would the major barrier be for gcc to work?

Given that Apple silicon is pretty new my guess it porting and testing , I would also add not all ARM chips are exactly the same , there will be some minor nuances for sure .Perhaps it is also some funding and access to the kits and dev time , updating gcc is not a full time job for most of the contributors after all.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168.

This is a great thread, thanks!  (And I see that your name is in the thread.)I gather from there that previous efforts to target iOS are outdated, there is substantial work to handle the Apple ABI, and that it's not been seriously looked at yet.

That's not true. GCC, Clang and MSVC are supported.http://erlang.org/doc/installation_guide/INSTALL.html

Does it support aarch64? AFAIK, the Apple SoCs these days don't support 32bit ARM anymore.

But in this case the Erlang VM was already compiled and running. It was compiling Elixir (using the Erlang VM) that crashed.

not every application sees every part of the beam VM.  I wouldn't be surprised if test coverage on some new systems (like the new process group registry system) that depend on NIFs (C ABI FFI) isn't complete.

I compiled Erlang and Elixir on a Raspberry Pi 3. It's OK on that ARM chip. Maybe the compiler doesn't fully support the new Apple chip yet.

Why is this news? Thousands of projects are in this position where they are porting to a new platform. This is normal.

I'm not seeing this as newsworthy either.All porting involves some changes and instability. This is "Water is wet" style news.
Are we learning something new from this being widely reported? (very little from what I can see)
Should be infer that there's something inherently wrong with Apple Silicon in that Elixir has an issue? (doubtful - its just new. no surprises multiple projects will need various bugfixes or code changes)
Perhaps that this is insurmountable? (unlikely)
Is this a case where large numbers of eyeballs being focused on it is somehow worthwhile or there are wide implications, eg its a major security incident? (no, unlikely)
Is there some technical quirk that sparks interest? (not particularly)
I don't understand how this is news.

The words Apple and Elixir are both involved, two topics that many HN readers like to read about (including me).Even so, as you suggest, there are likely thousands of projects going through this transition right now. It's certain that the first retail Macs will lack some support for some things.

How interesting this might be depends on why it crashed. It's likely the compiler that compiled the Beam VM not producing the correct code for Apple silicon. If it turns out to be in the Apple ARM OS or possibly hardware, then it gets more interesting. Also, many top posts on HN these days I don't find newsworthy but I wouldn't say so categorically, just to me.

If it was caused by an underlying hardware problem with the chip not properly implementing arm then it would be very interesting but it seems like without that conclusively being the cause, its likely some other complex but much less interesting issue.

I tried to use clang to compile some NDK code on Android and the resulting binary segfaulted. I tracked it down to what appeared to be a bug with register spilling. The fix was to use gcc and hope the clang bug was eventually fixed.These things happen.
https://groups.google.com/forum/m/#!topic/google-breakpad-di...

I guess this was a while ago, given that GCC support has been dropped since a couple of releases.

Yes about two years ago, but the bug wasn’t fixed till April this year and it looks like the fix was a work-around:https://chromium.googlesource.com/linux-syscall-support/+/be...

The elixir compiler runs jobs in parallel so it could be triggering a concurrency issue due to differences in the memory model between x86 and ARM. I’ve peered at the Erlang VM code and it looks like they are using primitives that are aware of the differences but they might not have covered everything.Until recently there was a concurrency bug in the VM that would trigger on elixir compiles that would cause compilation to hang on both x86 and ARM.

Honest question, why go through this transition with macOS as a developer instead of Linux or Windows? Is there something that macOS provides developers that other operating systems don't?

As a user of all three OS’es...macOS generates the fewest admin headaches.
I’ve slowly been moving more to Linux though

A relatively smooth desktop experience and nice client apps, baseline security at the hardware level, and still the ability to get under the hood to a shell.Windows does this now with WSL2 especially, but the desktop experience still has a lot of cruft left over.
I do look with envy at the choice of hardware on the Windows side though. Especially on the desktop side.

Been using OSX since just after xmas (work issued the new macbook pro) alongside Fedora (all my machines) and there really isn't any difference in terms of a "smooth desktop experience" which is a credit to Fedora and Cinnamon really.There are things I like about both platforms and things I dislike but I'm productive as a developer on either and mostly they feel the same.
At home if I want to do some dev I'm more likely to reach for my thinkpad though because I prefer the keyboard and it runs a lot cooler on my knee.

From experience I wouldn't call macOS a smooth experience personally, especially not 10.13, but I realize it depends if you ran into bugs personally or not.

You seem to be quite unhappy with it. Why do you use it at all?  There are plenty of programming domains where other systems rule.

Not by choice. I do sometimes have to use it at work as MacBooks is what they provide. Luckily, I didn't need to use a macOS machine for a couple of months now thanks to lockdown and us being allowed to use own hardware at home.

It has a linuxy backend with a good gui frontend. And the hardware is usually very good. I just don't really like flapping about trying to get everything working well in linux.

Looks more like BSD to me.

Yes, the ability to develop mac, iPad and iPhone apps.That and people may just generally prefer using the actual OS over the other two.
I can't stand using Windows for anything other than playing games, for example. I've also never been won over by Linux for anything other than working on the command line only.
Also the way macOS handles 'spaces' (i.e. multiple desktops) especially when connected to extra monitors is unmatched on any OS with a decent gui

On top of that, every mobile developer I know uses a mac because even if you're an exclusive android developer, at some point you will likely be asked to look into writing code for ios, or be asked to work on a cross platform solution which still requires access to xcode.

Not sure if the topmost model is able to keep Android Studio and Gradle happy though.

For me, the fact that it's enterprise Unix, basically. It's polished, smooth, well-supported, the hardware it runs on is spectacular, and it Just Works™.I do like Linux for server computing and for command-line/batch computing, but I don't like the state of the Linux Desktop and thus don't consider it seriously as a primary machine.
Windows is just a nightmare and even with WSL2, it still feels like it's bolted on. I only keep a Windows desktop around for gaming. I don't and won't do any productive work on Windows anymore.

Enterprise indeed, including charging premium for features that should come by default.As someone who has to use a Mac at work, it still baffles me how macOS doesn't even ship with a serious file manager by default in 2020 and every decent alternative costs decent amount of money.

Interesting. I've never had an issue with the features of Finder. I'm a pretty light user of a file manager, though. What types of things does it not do that you want it to do?

It seems like Finder was designed to hide the filesystem. In a normal file manager you start in your home directory and have a toolbar at the top allowing you to easily change your current path, see where exactly on the actual filesystem hierarchy your are etc.Finder seems to like to show you what seem like various 'views' of things but these views aren't actual folders or at lest usually don't contain what you would think the folder would or it doesn't initially open where you'd expect it to, if you want to go to an actual particular folder, (once you even figure out where you are if you have any amount of complexity to your FS hierarchy), it has to be done via a nested menu item, (Go=>Go to folder), where it should be front and center, most managers have it under or as part of the menubar itself.
The search doesn't seem to work much of the time, unless one uses Spotlight for everything, no dual pane support & tab support is very, very recent.
Not to mention it doesn't seem to remember my view/display preferences for any length of time, doesn't have sane right click options, (it didn't even have copy paste last time I bothered to check).
I am probably forgetting a bunch of things since I long switched to alternatives like Path Finder & Forklift, but of course you can't even remove it from the dock if you don't use it.

> In a normal file manager you start in your home directoryA new Finder window opens to the Documents folder by default, though this is configurable in preferences. You can set it to your home directory
> Finder seems to like to show you what seem like various 'views' of things but these views aren't actual folders or at lest usually don't contain what you would think the folder would
I've... never seen this. Are you talking about tags maybe? Or having an active search?
> (once you even figure out where you are if you have any amount of complexity to your FS hierarchy)
If you right click the folder name in title bar you get a list of path segments. You can also turn on 'Show Path Bar' and get a breadcrumb-style control.
> it has to be done via a nested menu item, (Go=>Go to folder)
There's a shortcut, cmd-shift-G, listed on that menu item.
> The search doesn't seem to work much of the time
Haven't had a problem with it, though I usually use find and grep on the command line.
> no dual pane support
You can tile two finder windows side-by-side.
> tab support is very, very recent.
Tab support is seven years old.
> (it didn't even have copy paste last time I bothered to check).
It does. It doesn't have cut and paste though, but drag and drop works to move.

It actually does have cut-paste/move: Command-c Command+Option-v

> You can also turn on 'Show Path Bar' and get a breadcrumb-style control.a.) Why is it not on by default?
b.) I want to type in a full path in one go, not click on individual segments of one - maybe that's not really common but I tend to memorize my FS structure.
> There's a shortcut, cmd-shift-G, listed on that menu item.
Am aware of the shortcut, it's not quite the same, it's an extra step you have to do vs not having to do, but it's probably just a "getting used to thing".
> You can tile two finder windows side-by-side.
That's like saying in a browser without tabs you can just open another window. Sure you can, it takes another second or two to get it the same size, probably won't open in the same directory as the old one, the other one will loose focus as you interact with the other etc.
> Tab support is seven years old.
Fair. Linux had it for 2 decades, I still remember  the WWDC keynote where they announced it, which is probably why in my mind it was more recent.

Finder is, by default, designed for your grandparents. That’s fine, a few configuration changes fixes enough of these concealments, combined with memorising a few keyboard shortcuts.If I want to deal with the file system in a technical way I use the terminal. And whenever I want to bring these two worlds together, I’ll just type:
  open .

Why not have the option of both? It seems to be fairly normal on Linux.

What do you mean "option of both"? I have both. I have Finder and I have Terminal. I have ways to jump from Terminal to Finder and from Finder to Terminal. I don't need or want a Termider or Finderminal.

> The search doesn't seem to work much of the time, unless one uses Spotlight for everythingI’d say spotlights file search interface isn’t that great but the finder’s own file search (I presume uses the same md database) seems pretty good to me.
>  it didn't even have copy paste last time I bothered to check
Actually it does, which surprises me.  That’s more of a Windowsism where you select a subject and then select a verb to apply. The Mac interface has from the beginning been more about direct manipulation. I.e: when you want to move something you just grab it and move it where you want to be.

>  when you want to move something you just grab it and move it where you want to beIn that case am really surprised Finder still doesn't support dual pane. Wouldn't this philosophy directly benefit?

You can open a new window...

Which isn't equivalent to dual-pane, especially considering macOS doesn't even support proper window snapping out of the box.

I mean, the Mac did invent copy and paste!

> Enterprise indeed, including charging premium for features that should come by default.This doesn't make any sense. Apple has long shipped MacOS with everything included. Compared to the 12! Windows 10 editions (Home, Pro, Pro for Workstations, Enterprise, ...) MacOS is a cakewalk, particularly since Apple ditched charging for upgrades years ago.
> serious file manager
Huh? Finder is decent, pretty much anything it can't handle is probably best served with a proper scripting language from the command line regardless. I'm not even sure what alternatives to Finder are out there.

There's plenty of alternatives, Forklift and Path Finder are some of my favorites, but rather pricey for what I get on Linux for free.Last time I checked Finder didn't support dual pane, (thankfully tabs were finally added very recently). It has insane context menu default, (like assigning tags is there, but Copy+Paste is not?) and to navigate to a specific folder directly, it is a nested menu item, (or a 3-key shortcut you have to remember), rather than being right in the toolbar bellow the menu as most other managers do it.
But of course if one wants to do something the way Apple has not specifically said it should be used they're "holding it wrong". Don't worry, I get it.
As for shipping with everything that's needed, it doesn't even have a 1st party package manager, (congrats even MS beat them to it) and homebrew isn't that great.
I get it, dark mode was probably also stupid until Apple decided to finally implement it.
P.S. Not a Windows fan either, so no need to spell out the various editions here.

Commander One is decent alternative, and has a free version.

That's nice, didn't know that one.Worth noting that you don't get things like " built-in FTP client; ability to mount MTP and iOS devices; RAR, TBZ, TGZ, 7z formats support; Dropbox integration; Terminal emulator"
These are all things Linux FMs have for free, but it's a good first step for sure.

None of this jives with your above comment that Apple is “charging premium for features that should come by default”. They aren’t charging for any of this, they just don’t offer some features you want out of the box.

> None of this jives with your above comment that Apple is “charging premium for features that should come by default”. They aren’t charging for any of this, they just don’t offer some features you want out of the box.Your comment doesn't make sense. I am saying they're not offering features that come standard, free with other OSes so you end up being charged for this by having to go to a paid 3rd party alternative offering functionality that is typical on other OSes as default.
Even window snapping isn't a thing without 3rd party tools.

> and to navigate to a specific folder directly, it is a nested menu itemCmd+G  - G for Go, and I agree that having to go to the menu bar item called "Go" is not super discoverable, but I found it once, and been using Cmd+G since then. I guess users that don't use shortcuts have more problems with these.
> Copy+Paste is not?
Cmd+C Cmd+V ? I am not sure this really needs an icon. I mean, if you go to the "Edit" menu, you see the shortcuts for Copy, Paste, and Cut, which are the same as on Windows or Linux, but using Cmd instead of Ctrl (which is consistent with the rest of the OS).
> tabs were finally added very recently
Tabs were added a long while ago, 5 years at least. But you don't even need tabs for this. I just do Cmd+Shift+Left to tile one finder window to the left of the screen, and Cmd+Shift+Right to tile another window to the right, and that's it: two windows, side by side.
I mean, it's not i3 or sway, but works fine.

Sure it works fine (enough), however it's not some class in smoothness, excellence or discoverable, friendly UX design, which is what is often being claimed macOS is when compared to Linux.Not saying Linux is superior on the UX front, but it definitely can be as good if not more productive, it has its issues but they all have, I simply haven't found macOS to be this above and beyond experience that is often being claimed and there was a period I gave it a serious try as it sounded so good. But...it's not really there. I get kernel panics, (haven't seen one on Linux in over a decade), UI freezes, (seen them often on all 3 OSes), clunky behavior, (no window snapping, wtf macOS).

> clunky behavior, (no window snapping)my windows snap, tile, etc. when I drag a window to a part of the screen, it snaps there.
I haven't see a kernel panic on MacOSX in the 15 years that I've been using it, and I haven't seen one on Linux either, but maybe my workload is just different.

Having used various file managers for >10 years (NC, MC, WC, TC), a lack of good alternatives seemed painful when I switched to Mac. It turned out that Finder is actually pretty decent.

The lack of dual pane support, no tabs for a long time as well and not having "Go to anywhere" prominently on the toolbar itself killed it for me. Also it seems to like to throw me into Recent by default rather than the home directory.I've since switched to Forklift and occasionally I'd open Path Finder but these are both not that cheap for a basic file manager.

> it still baffles me how macOS doesn't even ship with a serious file manager by default in 2020Serious question: what do you use it for?  I rarely use the finder at all; when I do it’s for pretty trivial things that it handles just fine. Generally ls, cd, open, tar etc are enough for me.
I understand a lot of people consider the Finder broken so I assume it lacks “power user” features, at least. But aren’t the power users by definition a couple of sigma out so are better served by a paid product?
For example I don’t use apple’s calendar app but paid $50 for a different calendar. I wouldn’t recommend that most people do this: apple calendar is fine for the bulk of users. I just happened to have some special needs.  Could your case be the same?

> But aren’t the power users by definition a couple of sigma out so are better served by a paid productMy point was that on Linux you get the features that on macOS are paid and considered for power users for free and as standard.

What features are you talking about?

At least Finder is still better than Windows Explorer. I have no idea how anyone can get work done with that thing.

I feel the same.

Solaris and HP-UX are enterprise UNIX, on NeXTSTEP and OS X, UNIX was always seen as a means to embrace and extend with Objective-C frameworks.

> Solaris and HP-UX are enterprise UNIX,By "enterprise" a lot of people understand native Outlook, Powerpoint, Word, Excel, ... Adobe tools, ..., etc. support. On HP-UX and Solaris you get none of these.

You get them as Web apps.As for enterprise desktop UNIX, I bet Red-Hat has more enterprise integration points with IT infrastructure than OS X.

> You get them as Web apps.Microsoft web apps suck. The outlook webapp does not even support smart folders, and dozens of other "basic" features that the native apps do support. Same for Word, excel, powerpoint, etc.
This might be an option in the future, but right now, paying microsoft for their webapps is just a waste of money.

Well, SharePoint is also enterprise, so.

These questions often ignore the investment (both in time and money) people have made in a particular platform. Even if you assume each platform is equivalent (which isn't true), there's still switching costs incurred moving from one to the other. For many people those switching costs will outweigh any costs incurred from the chip transition.

I used Linux as a daily driver for about a decade until a few weeks before I started university in fall 2017. That’s when I bought my first Mac in well over a decade.Why did I switch just before school? Because I didn’t want the stress of trying to troubleshoot breakage from updates when I was in the middle of assignments and midterms etc. During all of that decade of using Linux daily, there was never a time when I felt like things wouldn’t randomly break (usually from an update) to the point where X wouldn’t even start at boot, requiring a deep dive into display manager configuration, drivers, initial ramdisks, kernels, and everything in between.
Macs just work. The trackpad support is unbeatable. Ditto for battery life. And the terminal ecosystem is fine with homebrew. I’m not one of those people who insists on having the GNU version of all the basic tools, so I don’t mind the old BSD versions of most things.

> Why did I switch just before school? Because I didn’t want the stress of trying to troubleshoot breakage from updates when I was in the middle of assignments and midterms etc.I am certain your experience was as your describe but I do wonder if the community is making a mistake by continuing to recommend Ubuntu or the like as I've always heard most stories of this nature from there.
Which is kind of funny considering Arch is generally considered not stable, but I am was able to depend on it during my uni years as well as now when I am a full-time software dev, running close to a decade without major issues in fact.

To add a data point, I upgraded Ubuntu from 19.10 to 20.04 a week ago. It was 99% uneventful maybe for the first time in 10 years. I didn't have to reconfigure even the dozen Gnome Shell extensions I use. The missing 1% is the new openssl. It didn't let me connect to a few servers with old ciphers. I had to google how to enable them again. Hardly Ubuntu's fault and I don't have control on those servers or I would have upgraded them too and solved the problem in the right way.

I would tend to agree. I think the issue is the LTS model, it's great for servers, but not so much for users.As the LTS version gets older, most of your software starts to get seriously out of date, so every time you need something newer, it's easy to make a mess because you will have multiple versions of the same thing, as well as the dependencies and so on.
Upgrades are also quite scary, and often results in broken systems.
Rolling releases like Arch are much more user friendly in that regard, and breakage are uncommon. Installing older versions of already installed software is also much less frequent, and with the AUR it's really easy (at least compared to PPAs).

I deliberately omitted the distribution from my comment in order to avoid having the discussion head down this path. Now that I see that it was unavoidable, I will mention that Arch was my distribution of choice throughout the bulk of my time with Linux (it’s still installed on my desktop), apart from some brief forays into NixOS.I think this is just more evidence of the problem. There is so much infighting between the distributions that the community is unable to come together to create a solution. Linux is a tool for developers, not users, and its values put the convenience of developers ahead of the needs of users.

The only reason I mentioned Arch specifically is because from personal experience it plays nicer with more hardware than other distros I've tried, probably because of bleeding edge components and I generally had success with it when things didn't work otherwise.> I think this is just more evidence of the problem. There is so much infighting between the distributions that the community is unable to come together to create a solution.
With all due respect, but I think this completely misses the mark, the various distros do in fact do things in different ways, I know to Windows/macOS users this may seem baffling but even if we were to come together and create a single distro I think many Linux users, myself included, would reject that.
You see, there's a certain philosophy that is behind most major distros and is whichever philosophy you sync up most with, that's the distro you tend to sick with. Windows/macOS suffer from the lowest common denominator problem for many power users and that's fine as long as there's an out for them, like Linux provides right now.
If you're just going to have a single distro, you recreated exactly the same problems current Linux users ran away from originally. I don't know why everybody has to conform to a singular interface or vision, it seems wrong to me.
If Linux is just for developers because of that, fine. Developers are users too and if they're not well served by the proprietary platforms, I think it's pretty legitimate for Linux to be what primarily speaks to them. I do have plenty of stories of non-developers, (even digital artists), being happy with Linux, but that's for another time.
As for "the community is unable to come together to create a solution", looking at major cross distro projects like GNOME, KDE, GNU etc. nothing can be further from the truth. There's a great amount of cross-distro collaboration happening there.
That does not mean one cannot compare or contrast the distros, that's not immediately 'infighting'. For example even if I prefer Arch, I do use CentOS on some of my server deployments and I certainly appreciate it and by extension what the Fedora folks are doing.
This push to be uniform everywhere, in terms of interfaces, opinions, consensus etc. is not healthy nor sophisticated in my opinion.
If you look at the world of politics, all that gets you is two parties who both agree to launch offensive wars. Some healthy, principled differences aren't a bad thing per se.

Windows and macOS make allowances for power users who aren’t developers. To the Linux community this makes no sense. That is the difference.The term “power user”, from the perspective of the Linux philosophy, is synonymous with a person who customizes every aspect of their workflow, often writing lots of code and scripts, to arrive at something unique and specific to them.
This is not what a typical Mac or Windows power user does. Instead, on those platforms, being a power user can also be marked by being a user of powerful productivity software, whether it be graphics or audio or video production, or even advanced usage of business productivity software such as Excel.
These users do not typically customize their workflow very much. They insist that their computer be as powerful, low latency, and reliable as possible. They have neither the knowledge nor inclination to delve into the operating system internals in order to troubleshoot issues of latency or performance or reliability. Yet they get far more out of their computers than a typical user, who merely use them for browsing and social media. Linux users do not consider these users to be power users but Apple and Microsoft do.
This is what I meant when I said that “Linux is a tool for developers, not users, and its values put the convenience of developers ahead of the needs of users.”

As I said there's plenty of non-developer power users on Linux too, I know several digital artists who swear by Krita, which started as has the best version out on Linux. There's a hefty chunk of Blender artists who are on Linux. There's scientists running simulations, (not developers mind you), who are on Linux.Or do these not count because they don't have an active Adobe CC subscription?
The actual issue at play here is that most laptops you can buy come with Windows or macOS preinstalled so you need to go out of your way to install Linux. Most people are not going to do that as they probably barely know it's even an option.
So instead as they grow up with Windows/macOS and morph more into power users, they're going to stick with that.
The GNU/Linux community view is just that you generally can't audit Windows/macOS and therefore even be sure that the OS is working (just for) you in a sense. That's the additional dimension of power Linux gives you, higher confidence that you're in fact truly in charge of your machine. Take it or leave it, but that is a legitimate segment that needs to be served.
Another is that on Windows/macOS, (more so), you're subject to those allowances changing or not being allowances enough, the company changing focus etc. With Linux you don't need to rely on tricke down allowances graciously granted to you by a faceless corporation and thus be subjected to their whims, (or "vision").

That's the additional dimension of power Linux gives you, higher confidence that you're in fact truly in charge of your machine.And yet my stated reason for giving up on Linux after a decade of use was just the opposite: the feeling that I was not in charge of my machine, that the Arch maintainers were instead, when they knowingly pushed updates that broke things to the point where I needed to make a deep dive into configuration files while booted from the console, just to be able to get back to my graphical login screen so I could continue using my computer. This has never happened to me on macOS. Not once! Yet it happened many times over the years on Linux.

Never happened to me on Arch, on the other hand I had many kernel panics on macOS. simply to follow the news section.I guess it depends quite a bit on your hardware and experience. On Arch I can install anything I want in seconds, configure things exactly how I want, including whether I want a DE or a tilling VM etc. write services for anything using a very straightforward declarative syntax, (not XML or Apple Scipt), to wire up pretty much anything as a managed service or a cron, flying around the system.
On a Mac I constantly have to fight it not letting me do this or that or SIP preventing this other thing, you couldn't even snap windows for a long time, maybe you still can't - I installed some 3rd party, (again paid, of course) utility to do such a basic thing and it looks like Windows is going to beat it, (Unix-based OS), to an official package manager.
But I guess am not the target.

During those years I did all of that stuff. I used Xmonad and had a very large config. I did deep dives into both vim and emacs configuration.When I got accepted into school, I realized that all had to change. I couldn't spend hours configuring things anymore. I had to focus on getting work done quickly. The Mac gives that to me with minimum fuss.
I think you are definitely not the target. The Mac is not designed for people to treat their own computer as a hobby, the way I did with Linux for a decade. It's designed for getting work done and being as seamless and unobtrusive as possible, for as many people as possible.

> When I got accepted into school, I realized that all had to change. I couldn't spend hours configuring things anymore. I had to focus on getting work done quickly.I both started and sucesfully completed my CS degree on Arch. I didn't have to spend hours to configure anything. I now work as a full-time software dev on Arch every day, 8 hours a day. This is an often repeated myth but I haven't experienced it. Am not sure Linux, (any distro at this point), is the problem.

I do like Arch and use it on my desktop, but the fact is there are so many great productivity apps on OSX that I'm not willing to give it up. Eg; Things.

That's fair. Coincidentally I just saw this article about using org-mode + mobile apps for task management [1].1 - https://lwn.net/SubscriberLink/825837/068043ae2c5657be

>  why go through this transition with macOS as a developer instead of Linux or Windows?With everything still in beta/ pre-release, it's impossible to know how big a transition this is going to be for me personally. By the time I get my next computer most of this will likely be resolved.
> Is there something that macOS provides developers that other operating systems don't?
I prefer MacOS to Windows. In my experience the platform just has less bullshit to deal with. That said, Windows has gotten quite a bit better for Web Developers over the past 10 years or so, so it might be worth revisiting, but I suspect the headache of migrating to Windows will be just as bad for me as the headache of migrating to MacOS ARM (or worse).
If you are a Mobile developer, the transition is almost a no-brainer. Running iPhone apps native is a pretty slam dunk feature. For Web Devs, it's a bit less clear, particularly if you use VMs or Docker as part of your workflow.
It's really a huge unknown right now and until they start shipping hardware to end users, I suspect we won't really know what the whole picture looks like.

I do mostly iOS and some Android work. ARM will likely make things easier for me long term. Occasionally need to do some web dev too, but if I was still just doing web I’d maybe consider linux again.

You need an arm desktop system and those are currently few and far between.The arm windows systems are most robust but they lack a tonne of software - whereas the big name apps already work on Mac/arm (^h^h^hApple Silicon) already.
Coupled with native support for iOS apps (because nothing sounds as awesome as running a phone app on my laptop) I wouldn't be surprised for Macs to become the most common arm pc fairly quickly.

Stupid question time -Where are these folks getting Apple silicon? Is there a dev MacOS distribution for iPad? Or is it likely they have preview hardware?

You can buy it from Apple.

Note, that it's more like a rental. You are required to return the equipment at the end of the beta period.

There is a Developer Transition Kit machine -- a Mac mini with an iPad CPU in it. https://developer.apple.com/programs/universal/

> Developer Transition Kit (DTK)https://developer.apple.com/programs/universal/

They're renting a developer transition kit that's basically a mac mini with an ipad pro chip until the end of the year for $500

Are there any 4k page size expectations built into the VM? From wwdc the DTKs have 16k pages?

I expect that we'll see a lot of this. At least it's getting caught before it gets to consumers? But not entirely impressed with the work Apple is making developers shoulder.

Is there any alternative though (other than not switching to ARM?)?I guess Apple could go out and try to preemptively fix all software, but that seems excessive to expect. :-)

They're actually actively contributing to a number of major open-source projects to fix ARM issues: https://twitter.com/wongmjane/status/1275177255681982464

If anyone out there is reading this and wondering whether the switch to ARM is part of some plan to eventually lock down macOS to the same level as iOS, they need only click the above link. Why would Apple dedicate engineers to fixing up all these open source projects if they were planning to lock them out?I think this very clearly demonstrates Apple’s commitment to supporting open source, user-installed software on Macs, outside of the Mac App Store.

Yes, developers need to be able to run arbitrary code. But that's not inconsistent with macOS being locked down by default and requiring a developer certificate to run unapproved software.Of course, moving to ARM is orthogonal to that; Apple could just as easily impose restrictions on x86 Macs. The only immediate downside to ARM is the loss of the ability to boot other OSes, which has apparently been getting more difficult anyway due to custom hardware like the T2 chip.

Click the link. Not all of those are developer tools. Blender being a prominent example. Apple's contribution to Blender is inconsistent with a goal of "requiring a developer certificate to run unapproved software."No, I think Apple will always keep the Mac as a platform where end users can run unapproved software with appropriate warnings. The Mac is a serious tool for many different roles, not just development, and not every tool fits into Apple's App Store ecosystem. This is Apple's tacit acknowledgement of that fact.

Not all of those are developer tools. Blender being a prominent example."Sure, and Blender could be in the app store. (There are possible issues with the GPL, but Apple could fix that if they cared to).
No, I think Apple will always keep the Mac as a platform where end users can run unapproved software with appropriate warnings.
Well, if you believe Apple's messaging, then using an iPad for real work is not only possible but often better than a traditional computer, and also it's too dangerous to allow unapproved software on it even if users had to explicitly opt in. I think it's entirely possible (although far from certain) that Apple could decide that the App Store is good enough for 80% of users, and everyone else can either pay for developer/pro access or go away. I don't think moving to ARM makes that more likely, but nor do I think contributing open source fixes makes it less likely.

The message has been clear for years now. It was re-iterated in WWDC videos and various interviews.The Mac is the Mac. It has been and will continue to be the machine where you can install software not approved by Apple, turn off security, and otherwise poke at the system. You can still create your own kext caches and mount the root filesystem as read-write on Apple Silicon. The procedure has changed but the ability to do it has not.
I really honestly don't know how much clearer it can be.

It wouldn't make sense for them to do otherwise. The Mac has its market and a large proportion of that market demands those abilities. Why turn the Mac into iPadOS when they have iPadOS already?What they are accomplishing by going to their own silicon is eliminating the need to maintain the Mac as a completely different hardware and driver line. Now the Mac is just a bigger higher specced clamshell iPad with MacOS, and MacOS is the same kernel and mostly the same drivers as iPadOS and iOS but different security policies and a somewhat different user space. It's sort of like a different Linux distribution with a different window manager and different defaults.
I think this will make the Mac better because now it can benefit from all the product dev and R&D being done for iDevices, and vice versa. All those neat features in the high end iPad can now be considered for the Mac.
It would not shock me if they someday allowed the Mac to run iPadOS either if the user so chooses, or vice versa, via some reinstall process.

You don't have to pay to use XCode to run something on iPad.

Tell that to Raymond Chen :-)

Ha, good response!

>a new architecture has some bugs the thing with BSD make instead of gmake

Always use gmake.

Reply on news.ycombinator.com