1. 20
  1. 12

    My personal wishlist:

    • Allow OSX to be run on non-Mac hardware for CI purposes, or bring back rackmount Mac hardware. Otherwise you’re paying a lot for hardware you don’t need in a build farm, which makes it harder to ship good software.
    • Support a way to create .dmg installers without granting TCC permissions (which can’t be done in an automated way, by design).
    • In general, better support the “automatically scaled and deployed build farm” approach to software development.
    1. 5

      You can rent Macs on AWS now, but the minimum reservation time is 24 hours, presumably to make it more expensive than just buying a Mac mini.

      1. 5

        Allow OSX to be run on non-Mac hardware for CI purposes,

        The M1 would make a fantastic ARM server in general. I wonder why no company buys Mac Minis, puts a bunch of logic boards in a 1U case and sells them as an ARM server. The Mac Mini starts at ~675 Euro here in NL, from the competition you get paltry development boards for that price. An additional icing on the cake is that the neural engine + AMX would also make it great for hosting inference servers.

        Or as a simpler variation, make some a 1U case that you can put multiple Mac Minis in with reasonable connectivity and cooling.

        1. 2

          People make 1U cases for Mac Minis, like this one from Sonnet.

          1. 1

            The reason is that it would make them more expensive than just buying direct from Apple.

            You could do some interesting stuff with the power management systems though, add in a cluster KVM (like the iDRAC in a Dell blade chassis) and it begins to look compelling.

            But what is the price premium you’d be willing to pay, and with what features?

            1. 1

              Here you go. I used to rent a PowerPC Mac Mini from them back in the day. They don’t put them in a 1U case, they keep them in their original enclosures but have custom racks designed to host Mac Minis.

              1. 1

                But that’s not really the same as selling Mac-based ARM rack servers. You can also get Mac instances from AWS and others.

            2. 3

              Allow OSX to be run on non-Mac hardware for CI purposes, or bring back rackmount Mac hardware. Otherwise you’re paying a lot for hardware you don’t need in a build farm, which makes it harder to ship good software.

              Both CircleCI and AWS Codebuild support MacOS for CI, does that solve this problem?

              1. 2

                So do Azure Pipelines and GitHub Actions but they both run in a dedicated pool of Mac hardware. This means that they’re a lot less flexible than Linux / Windows. The free runners are a bit more powerful than the VMs but if you need more disk than the provided 14 GiB allocation (e.g. if you’re doing CI of something that needs a debug build of LLVM, which takes about 70 GiB on a Mac) then you have a problem.

                If Apple would license macOS to cloud providers for CI workloads then it would be easy to just provision the size of pool that you need.

                AWS appears to let you actually rent Macs from them, but since you need to rent them by the day that’s not ideal for Mac CI unless your CI machines are fully loaded. My CI pipelines are idle 90% of the time, which is why it’s nice to use cloud VMs and pay for them only 10% of the time.

              2. 3

                They brought back rack mounted macs in the latest 19” tall Mac pro.

                1. 1

                  Ah cool, didn’t realize that. You’re still paying for a wifi chipset, bluetooth, and graphics card, but I guess it’s better than nothing.

                  1. 3

                    They are really meant for professional audio people who use racks too, not for data centers though

              3. 10

                I cannot agree about Xcode. Xcode always has one or two really irritating bugs, but it does work. It doesn’t take minutes to create an empty project. Interface Builder works. Playgrounds hardly ever work, nor does @IBInspectable or other dynamic features which probably are never dogfooded by Apple developers themselves. But Xcode works for its intended use, an is a refreshing experience if you’ve dealt for a while with the everything-and-the-kitchen-sink, all-keys-bound-to-twelve-different-functions approach of Jetbrains IDEs.

                1. 5

                  I miss Project Builder from NeXTStep, but I’m extremely old.

                  1. 3

                    Seeing Interface Builder for the first time was life-changing.

                    1. 1

                      100%

                      It blew my mind when I first got my hands on a NeXT Pizza Box in the late 90s.

                      1. 2

                        Chicago had bought tons of Next hardware in the late ’80s, right before I arrived, and so I got to work with them a lot in the CS lab. By the time I left, I was able to take a Cube home and I used it for a decade or so as my primary. Wonderful computers, particularly after I “liberated” a Next Dimension board from the dead machine storage.

                2. 10

                  I think the docker desktop license thing is grossly overstated. if you are rocking in a year a 5,000 dollar a month license for all of the max hypothetical 249 employees at the max business rate of 21 dollars each is not all that compelling considering it’s “business-critical software” per them. the real scenario is one of the lower tier licenses probably work and it’s more than likely way lower than 250 employees that use it. if you have 250 employees it’s more than likely you are pulling in a lot too.

                  1. 6

                    For what it’s worth, I use nix-darwin to manage nearly my entire system, including Homebrew (plus DNS, cli tools & dotfiles, fonts, network services, macOS system settings, and more).

                    If anything happens with a Homebrew package / application upgrade, I can just roll back to a prior generation, everything works again, and I can try again at my leisure.

                    I personally wish I didn’t have to do some of these things (it’d be nice if macOS had its own solution), but it does let me set up a Mac with just a couple of commands.

                    1. 2

                      What does macOS give you over NixOS at this rate?

                      1. 6

                        Nicer UI, non-developer tools like Affinity, UI developer tools like Dash/Proxyman. Even if some tools have equivalent on NixOS, these are often not as ergonomic as on macOS.

                        1. 2

                          I’ve been running this on an early 2013 MacBook Pro (retina), and it has been my only personal computer since 2013.

                          I’ve tried running NixOS in VMs, but I’ve always had a hard time with it (except for the demo). My latest effort was was to do something similar to the founder of Hashicorp (he’s big on Nix) where he has his dev environment in NixOS through a VM on macOS, but I couldn’t get it working well enough to be useful.

                          If I ever get a Framework laptop or anything that isn’t by Apple, I’ll try NixOS again in a heartbeat, but while I’m on macOS for personal and work, this is where I am.

                      2. 5

                        About

                        Podman for the Mac

                        There is lima that expose nerdctl toolkit.

                        1. 15

                          You lost me at “the great work from homebrew”

                          Ignoring UNIX security best practices of the last. I dunno, 30, 40 years, and then actively preventing people from using the tool in any fashion that might be more secure, and refusing to acknowledge any such concerns is hardly “great work”.

                          I could go on about their abysmal dependency resolution logic, but really if the security shit show wasn’t enough to convince you, the other failings won’t either.

                          But also - suggesting Apple ship a first party container management tool because “other solutions use a VM”, suggests that either you think a lot of people want macOS containers (I’m pretty sure they don’t) or that you don’t understand what a container is/how it works.

                          The “WSL is great because now I don’t need a VM” is either ridiculously good sarcasm, or yet again, evidence that you don’t know how something works. (For those unaware, WSL2 is just a VM. Yes it’s prettied up to make it more seamless, but it’s a VM.).

                          1. 23

                            I don’t know what’s SO wrong about Homebrew that every time it’s mentioned someone has to come and say that it sucks.

                            For the use case of a personal computer, Homebrew is great. The packages are simple, it’s possible and easy to install packages locally (I install mine in ~/.Homebrew) and all my dependencies are always up to date. What would a « proper » package manager do better than Homebrew that I care about? Be specific please because I have no idea what you’re talking about in terms of security « shit show » or « abysmal » dependency resolution.

                            1. 12
                              • A proper package manager wouldn’t allow unauthenticated installs into a global (from a $PATH perspective) location.
                              • A proper package manager wouldn’t actively prevent the user from removing the “WTF DILIGAF” permissions Homebrew sets and requiring authenticated installs.
                              • A proper package manager that has some form of “install binaries from source” would support and actively encourage building as an untrusted user, and requiring authentication to install.
                              • A proper package manager would resolve dynamic dependencies at install time not at build time.
                              • A proper open source community wouldn’t close down any conversation that dares to criticise their shit.
                              1. 11

                                Literally none of those things have ever had any impact on me after what, like a decade of using Homebrew? I’m sorry if you’ve run into problems in the past, but it’s never a good idea to project your experience onto an entire community of people. That way lies frustration.

                                1. 5

                                  Who knew that people would have different experiences using software.

                                  it’s never a good idea to project your experience onto an entire community of people

                                  You should take your own advice. The things I stated are objective facts. I didn’t comment on how they will affect you as an individual, I stated what the core underlying issue is.

                                  1. 6

                                    You summarized your opinion on “proper” package managers and presented it as an authoritative standpoint. I don’t see objectiveness anywhere.

                                2. 3

                                  I don’t really understand the fuss about point 1. The vast majority of developer machines are single user systems. If an attacker manages to get into the user account it barely matters if they can or cannot install packages since they can already read your bank passwords, SSH keys and so on. Mandatory relevant xkcd.

                                  Surely, having the package manager require root to install packages would be useful in many scenarios but most users of Homebrew rightfully don’t care.

                                3. 8

                                  As an occasional Python developer, I dislike that Homebrew breaks old versions of Python, including old virtualenvs, when a new version comes out. I get that the system is designed to always get you the latest version of stuff and have it all work together, but in the case of Python, Node, Ruby, etc. it should really be designed that it gets you the latest point releases, but leaves the 3.X versions to be installed side by side, since too much breaks from 3.6 to 3.7 or whatever.

                                  1. 8

                                    In my opinion for languages that can break between minor releases you should use a version manager (python seems to have pyenv). That’s what I do with node: I use Homebrew to install nvm and I use nvm to manage my node versions. For Go in comparison I just use the latest version from Homebrew because I know their goal is retro compatibility.

                                    1. 5

                                      Yeah, I eventually switched to Pyenv, but like, why? Homebrew is a package manager. Pyenv is a package manager… just for Python. Why can’t homebrew just do this for me instead of requiring me to use another tool?

                                      1. 1

                                        Or you could use asdf for managing python and node.

                                      2. 7

                                        FWIW I treat Homebrew’s Python as a dependency for other apps installed via Homebrew. I avoid using it for my own projects. I can’t speak on behalf of Homebrew officially, but that’s generally how Homebrew treats the compilers and runtimes. That is, you can use what Homebrew installs if you’re willing to accept that Homebrew is a rolling package manager that strives always to be up-to-date with the latest releases.

                                        If you’re building software that needs to support a version of Python that is not Homebrew’s favored version, you’re best off using pyenv with brew install pyenv or a similar tool. Getting my teams at work off of brewed Python and onto pyenv-managed Python was a short work that’s saved a good bit of troubleshooting time.

                                        1. 2

                                          This is how I have started treating Homebrew as well, but I wish it were different and suitable for use as pyenv replacement.

                                          1. 2

                                            asdf is another decent option too.

                                          2. 5

                                            I’m a Python developer, and I use virtual environments, and I use Homebrew, and I understand how this could theoretically happen… yet I’ve literally never experienced it.

                                            it should really be designed that it gets you the latest point releases, but leaves the 3.X versions to be installed side by side, since too much breaks from 3.6 to 3.7 or whatever.

                                            Yep, that’s what it does. Install python@3.7 and you’ve got Python 3.7.x forever.

                                            1. 1

                                              Maybe I’m just holding it wrong. :-/

                                            2. 3

                                              I found this article helpful that was floating around a few months ago: https://justinmayer.com/posts/homebrew-python-is-not-for-you/

                                              I use macports btw where I have python 3.8, 3.9 and 3.10 installed side by side and it works reasonably well.

                                              For node I gave up (only need it for small things) and I use nvm now.

                                            3. 8

                                              Homebrew is decent, but Nix for Darwin is usually available. There are in-depth comparisons between them, but in ten words or less: atomic upgrade and rollback; also, reproducibility by default.

                                              1. 9

                                                And Apple causes tons of grief for the Nix team every macOS release. It would be nice if they stopped doing that.

                                                1. 2

                                                  I stopped using Nix on macOS after it is required to create an separate unencrypted volume just for Nix. Fortunately, NixOS works great on VM.

                                                  1. 2

                                                    It seems to work on an encrypted volume now at least!

                                              2. 4

                                                I really really hate how homebrew never ask me for confirmation. If I run brew upgrade it just does it. I have zero control over it.

                                                I come from zypper and dnf, which are both great examples of really good UX. I guess if all you know is homebrew or .dmg files, homebrew is amazing. Compared to other package managers, it might even be worse than winget….

                                                1. 2

                                                  If I run brew upgrade it just does it

                                                  … yeah? Can we agree that this is a weird criticism or is it just me?

                                                2. 2

                                                  Overall I like it a lot and I’m very grateful brew exists. It’s smooth sailing the vast majority of the time.

                                                  The only downside I get is: upgrades are not perfectly reliable. I’ve seen it break software on upgrades, with nasty dynamic linker errors.

                                                  Aside from that it works great. IME it works very reliably if I install all the applications I want in one go from a clean slate and then don’t poke brew again.

                                                3. 4

                                                  you think a lot of people want macOS containers (I’m pretty sure they don’t)

                                                  I would LOVE macOS containers! Right now, in order to run a build on a macOS in CI I have to accept whatever the machine I’m given has installed (and the version of the OS) and just hope that’s good enough, or I have to script a bunch of install / configuration stuff (and I still can’t change the OS version) that has to run every single time.

                                                  Basically, I’d love to be able to use macOS containers in the exact same way I use Linux containers for CI.

                                                  1. 1

                                                    Yes!!

                                                    1. Headless macos would be wonderful
                                                    2. Containers would be fantastic. Even without the docker-like incremental builds, something like FreeBSD jails or LXC containers would be very empowering for build environments, dev servers, etc
                                                    1. 1

                                                      Containers would be fantastic. Even without the docker-like incremental builds, something like FreeBSD jails or LXC containers would be very empowering for build environments, dev servers, etc

                                                      These days, Docker (well, Moby) delegates to containerd for managing both isolation environments and image management.

                                                      Docker originally used a union filesystem abstraction and tried to emulate that everywhere. Containerd provides a snapshot abstraction and tries to emulate that everywhere. This works a lot better because you can trivially implement snapshots with union mounts (each snapshot is a separate directory that you union mount on top of another one) but the converse is hard. APFS has ZFS-like snapshot support and so adding an APFS snapshotter to containerd is ‘just work’ - it doesn’t require anything else.

                                                      If the OS provides a filesystem with snapshotting and a isolation mechanism then it’s relatively easy to add a containerd snapshotter and shim to use them (at least, in comparison with writing a container management system from scratch).

                                                      Even without a shared-kernel virtualisation system, you could probably use xhyve[1] to run macOS VMs for each container. As far as I recall, the macOS EULA allows you to run as many macOS VMs on Apple hardware as you want.

                                                      [1] xhyve is a port of FreeBSD’s bhyve to run on top of the XNU hypervisor framework, which is used by the Mac version of Docker to run Linux VMs.

                                                  2. 2

                                                    Ignoring which particular bits of Unix security practices is problematic? There are functionally no Macs in use today that are multi-user systems.

                                                    1. 3

                                                      All of my macs and my families macs are multi-user.

                                                      1. 2

                                                        The different services in OS are running as different users. It is in general good thing to run different services with minimal required privileges, different OS provided services run with different privileges, different Homebrew services run with different privileges, etc. So reducing the blast radius, even if there is only one human user is a pro, as there are often more users at once, just not all users are meatbags.

                                                      2. 1

                                                        I’ve been a homebrew user since my latest mac (2018) but my previous one (2011) I used macports, given you seem to have more of an understanding of what a package manager should do than I have, do you have any thoughts on macports?

                                                        1. 4

                                                          I believe MacPorts does a better job of things, but I can’t speak to it specifically, as I haven’t used it in a very long time.

                                                          1. 1

                                                            Thanks for the response, it does seem like it’s lost its popularity and I’m not quite sure why. I went with brew simply because it seemed to be what most articles/docs I looked at were using.

                                                            1. 3

                                                              I went with brew simply because it seemed to be what most articles/docs I looked at were using.

                                                              Pretty much this reason. Homebrew came out when macports was still source-only installs and had some other subtle gotchas. Since then, those have been cleared up but homebrew had already snowballed into “it’s what my friends are all using”

                                                              I will always install MP on every Mac I use, but I’ve known I’ve been in the minority for quite awhile.

                                                              1. 1

                                                                Do you find the number of packages to be comparable to brew? I don’t have a good enough reason to switch but would potentially use it again when I get another mac in the future.

                                                                1. 3

                                                                  I’ve usually been able to find something unless it’s extremely new, obscure, or has bulky dependencies like gtk/qt or specific versions of llvm/gcc. The other nice thing is that if the build is relatively standard, uses ‘configure’ or fits into an existing PortGroup, it’s usually pretty quick to whip up a local Portfile(which are TCL-based so it’s easy to copy a similar package config and modify to fit).

                                                                  Disclaimer: I don’t work on web frontends so I usually don’t deal with node or JS/TS-specific tools.

                                                                  1. 3

                                                                    On MacPorts vs Homebrew I usually blame popularity first and irrational fear of the term ‘Ports’ as in “BSD Ports System”, second. On the second cause, a lot of people just don’t seem to know that what started off as a way to have ‘configure; make; make install’ more maintainable across multiple machines has turned into a binary package creation system. I don’t anything about Homebrew so I can’t comment there.

                                                        2. 4

                                                          Agree with XCode being a disaster.

                                                          The other thing I’d love to see would be fixing dtrace (without requiring turning off System Integrity Protection). It’s miserable to try to debug software on an OS on which the syscall tracer doesn’t work.

                                                          I don’t actually want a 1st-party Apple supplied package manager to replace brew because it would be very surprising if it was better rather than worse.

                                                          1. 1

                                                            The other thing I’d love to see would be fixing dtrace (without requiring turning off System Integrity Protection). It’s miserable to try to debug software on an OS on which the syscall tracer doesn’t work.

                                                            You do not need to disable SIP for tracing software running in user-space that is installed outside of SIP protected directories.

                                                            1. 1

                                                              I need to trace through things like /bin/sh because real programs invoke that in the middle of doing stuff.

                                                              Generally, IME dtruss just does not work at all on OSX. The fact that it demands root is also a disaster.

                                                              On freebsd I can just ftrace some-program .... On Linux I can just strace some-program .... Both work without root or requiring me to mess around with the system.

                                                              If you have a guide to using dtrace or dtruss on MacOS that actually works I would love to read it, please.

                                                          2. 3

                                                            I think people have a tendency to value what they work with directly as the obvious default thing. For example, the container thing smacks of “value my specific workflow” (as someone whose developer doesn’t use containers). I don’t think anyone would really care about a package manager or VSC-like editor, considering people already have preferences, there’s rich third party alternatives, and would almost certainly complain that Apple doesn’t fully care about that thing.

                                                            That said, I wouldn’t say no to more Quick Look formats….

                                                            1. 3

                                                              I also wish apple would stop soldering at least ram and hard drives.

                                                              I understand this is a vendor lockin strategy, a blow that is softened by the trade-in program. I also trust they more efficiently breakdown/recycle parts. It still feels wasteful as a consumer to invest 2000$ only to have it limited to the lifespan of an SSD.

                                                              1. 2

                                                                It is more about making more compact hardware and not needing to deal with users complaints about degraded performance when someone replace the provided hardware with something that is not compatible/not performant enough.

                                                                1. 5

                                                                  Has any user, ever, on any system, complained about degraded performance when they themselves choose to replace parts, and then blame their slow disk speed on the original vendor rather than on their new disk?

                                                                  Because I’ve never heard of that happening at all. And if you’re concerned about that you might as well be concerned about people hitting their screen with a hammer and then complain that Apple makes screens with annoying broken glass and stuck lines of pixels.

                                                                  1. 1

                                                                    Considering how fast SSDs Apple put in their machines, I think many users who installed a normal consumer-grade SSD in their Macs would complain about it being slow, without realising the cause.

                                                                    That doesn’t imply I like the fact that they’re soldered down; ideally Apple should sell Apple-certified replacements.

                                                              2. 3

                                                                the rise of containerization has really reduced the appeal of Macs for developers, as frankly you just don’t use the base OS UNIX tooling as much as you used to.

                                                                I think this trend will turn.

                                                                We never develop with containers. They are strictly for deployment.

                                                                1. 3

                                                                  I’ve seen a lot of folks do the converse. Using a container means that you can set up a development environment for a new hire in a single click and you can deploy the same development environment to your laptop and a beefy cloud VM or desktop, and point VS Code at whichever is more convenient.

                                                                2. 3

                                                                  There needs to be better integration and support for higher level scripting in macOS. I should not have to learn Swift, Xcode, and a bunch of low level stuff just to make a button.

                                                                  1. 7

                                                                    I used Automator a while ago to make a little graphical frontend to ffmpeg for my partner who had to do some repetitive video processing. It was much easier and worked way better than I expected it to.

                                                                    1. 2

                                                                      Automator is (was?) a great starting frontend. Apple is a trillion dollar company – they could and should be doing so much more on this kind of thing!

                                                                    2. 5

                                                                      There is Automator, Shortcuts, and good old reliable AppleScript. If that doesn’t solve your problem, you can still script using unix-inspired scripting languages and still send AppleEvents back and forth. Or do you mean some other form of scripting? Maybe I misunderstood you.

                                                                      1. 3

                                                                        There’s a lot to respond with but I’ll try not to ramble on too much.

                                                                        What I’m trying to convey is less about “solving problems” than it is presenting “users” with an environment that lets them know they can manipulate it in meaningful ways – and thereby, possibly (and easily), solve their own problems.

                                                                        Automator and Applescript are great starts, but Apple has clearly not given them enough love. I cannot recall seeing any Applescript segment in any broadcasted keynote (if you know of one, please send). This even though the company is more than willing to devote elaborate segments to other highly technical features (new processors etc). Neither Applescript nor Automator are featured on Apples main website. This is one way that tells me that such scriptability of their system is a far afterthought.

                                                                        If Apple wanted to take that kind of malleability seriously, they could start with the less intensive and top-level, front-facing UI of macOS. For example, there is no technical reason that the Finder shouldn’t just be made up of components that are inspectible, and whose underlying implementation is just Applescript. That should have happened a long time ago. There should be a whole unit at the company that is writing and perfecting user-facing system level Applescripts. This ensures that the necessary technical infrastructure for Applescript to have as wide a reach as possible is given priority, but also that users have a rich literature of scripts to learn from.

                                                                        Applescript Studio was cool and it got axed. There should be a primitive interface builder that lets power users quickly and easily draft simple UIs that can integrate with the rest of the system, and which they can script in Applescript. There’s no good reason not to have this. And again, the Finder should be written and implemented this way – it should be the Ur-example. If a basic macOS button is not inspectible, it should be an exception and should definitely be something not written by Apple.

                                                                        Apple has a lot of leverage they could use to make this better. For example, imagine if the reduced app store costs for vendors that provided rich Applescript dictionaries and integrations with their software. To me that’s a no-brainer.

                                                                        Again, they are a trillion dollar company. Instead of giving users what they want – which is an easy way to make money, no doubt – they should be educating users on what is possible by giving them a rich environment to work in. What’s worse is that they have historically proven that such things are viable with things like Hypercard. SK8 is one of the more interesting research projects ever at the company. What might system level scripting and authorship look like if Apple dedicated a rounding-error of financial resources to it?

                                                                    3. 0

                                                                      Just install Linux on your MacBook Pro?

                                                                      1. 2

                                                                        That’s not been an option for a while. (Since ~touchbar) Asahi is getting there again, but it’s still not a viable daily driver for a lot of use cases.

                                                                        1. 1

                                                                          Bummer. I honestly hadn’t tried since I had an iBook G3.