I would add that, at least historically, a reputable photojournalist wouldn't likely build a very successful career on faked photos. It's heavily disincentivized. The time and effort required to build the necessary skills and clout won't casually be wasted by a professional. And if and when it does happen that a photojournalist is caught in a lie, the rest are quick to reject it, because it damages their own reputations and livelihoods.
But now, there's little to stop anyone from producing images depicting anything, and we've seen how systems that are blind to ethics can be manipulated into disseminating such images at a speed and scale that far outpaces fact-checking. Professional standards and traditional gatekeeping have no power against it.
I sometimes battle perfectionism for various reasons. Someone pointed out that it can’t be perfect if it isn’t even finished, so why not add “done” to what it means to be “perfect.” Somehow that tweaked my perspective in a helpful way. Edit: on reflection, possibly because it doesn’t imply a compromise of my standards, but actually strengthens them, so I don’t have the feeling of giving up or giving less.
Also very much believe in doing some kind of planning, any kind being better than none at all. Otherwise you put yourself in a tunnel but you don’t give yourself a light at the end. The plan can change and it will, but if you have none, you might end up digging forever
One of my early frustrations with Microsoft's "To-do" app was that it discarded my "today" tasks every day. But now I love that it does this, for the reasons the author describes.
I was used to apps like Asana that would just let things sit there and accumulate and fester. It made me hate how much I wasn't getting done every day. One or two tasks a day piling up over the course of many days just grows into a mountain of shame, and as the author says, it builds this "UGH field" around it that makes me not want to look at it at all, much less try to wade through it. The system was hurting more than helping, really.
I started using To-Do because we recently switched to Microsoft at work, and I'm trying to embrace the ecosystem or whatever. And what was an annoying deficiency (why can't this crappy MS app do what I want) has become a huge relief.
Automatically having my day reset every day has helped me feel more like I can actually get through most of what I realistically intend to do in a day. I take a minute in the morning to throw stuff on the list, MS does helpfully suggest some things (presumably using something they now call "AI"), and then I start working down it. At the end of the day, anything I didn't get to -- honestly, anything that wasn't as important as I thought it would be that day -- is gone. The next day, I start fresh. Re-focus, re-prioritize, and start executing. Everything still gets done, but my focus is on the day ahead rather than days past. And no "ugh field."
I would note that my approach to projects with teams is different, of course. All of those tasks will eventually need to get done, so it's not helpful to let things disappear. But where this does apply is in how much a given contributor wants to bite off in a day. The backlog on a project is the backlog, no getting around it, but a tighter focus each day on whatever's realistic, 3-5 tasks probably, relieves a lot of tension that helps work be more effective, I find.
Last comment, I love that the author also puts things on the list just to scratch them off. I picked up this habit somewhere long ago. It seems silly to do something, then put it on the list, then just scratch it right off, but it has the real effect of notching another task done. Helps limit the days where you feel like you didn't actually do anything, those yak-shaving days. You can look at the "completed" tab and see that no, you did actually do stuff. Another source of shame neutralized.
> One of my early frustrations with Microsoft's "To-do" app was that it discarded my "today" tasks every day. But now I love that it does this, for the reasons the author describes.
To-do is surprisingly great. It's my GTD tool of choice at the moment.
They change things, though, and you can't switch a setting. For some time they stopped adding tasks with due date on the current day to the "My day" smart list.
It makes sense if you think about it in terms of what they wanted "My day" to be. Adding things to "My day" should be a conscious choice.
But it was a change, and it's very nice to have due tasks automatically added. They changed it back after a few weeks, thankfully.
I really like "To-do" and am so glad it's integrated into Outlook's Mac client now. I wish there was a way to show all tasks, regardless of their list/categorization.
As it stands, this really stops me from using separate lists for timebound tasks. I only use them for long-term planning/blue sky stuff.
This was a fascinating and ... detailed ... story. I appreciate that it went a little further into the history of Apple's involvement ARM than the recent spate of blog posts that didn't go back past Newton.
The first time I saw the pulsating rainbow screens as a second-grader, it blew my mind. I'm not sure my experience with The Print Shop didn't set me on the path toward my early career in publishing. If you needed me after school, you'd find me in the computer lab waiting on a banner.
Favorite border: The one with the square loops in the corners.
With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.
Anyone know why Homebrew overtook MacPorts? I only have a vague recollection of a Rails colleague pushing me to switch circa 2013 or so and haven't given it much thought since, but it (MacPorts) seemed to be similarly ubiquitous prior.
When I started using a Mac in 2009, MacPorts, Fink (and I think there was another I can't recall the name) simply wouldn't work for me. They would take very long to build what I wanted, there weren't nearly as many packages as was in Debian/Ubuntu, and many were old versions. Worse, many build attempts would just fail.
In that scenario, brew worked like a charm. It was quick, had most or even more packages than Debian/Ubuntu and they were newer. Failure to install was rare.
Then, Apple started yearly release of OS X, and that both broke brew and my system hard, so I started investigating and found out about the many "shortcuts" that brew took and how it violated systems components. I was dismayed, and abandoned brew for good.
So, I stood a period where I would use many of my tools inside a Ubuntu VM, until probably 2013-2014, when for some reason I tried again MacPorts, and I don't know why, but that time it was much more reliable, and because of Apple's insane atm SSDs with 2 GB/s bandwidth, install became quick enough. Packages were still somewhat lagging behind in available versions, but the variety of them kinda reached the levels of what was in Debian/Ubuntu, so it was good enough for me.
Then, the killer feature, I found out about macports variants and selectors, which I find the most awesome thing to this date in package managers (I haven't tried nix, still, it might be magnitude better in that regard). No needing to use rvm, pyenv, custom installs of gcc messing with make/autotools, and the only sane way of compiling various Haskell projects (before haskell-stack).
I don't know when they introduced it, but I believe MacPorts will build the common variants of the more-used packages. So, if you install a package with the default variants, you'll get a binary download instead of building from source.
But indeed; fast SSDs, parallel compilation, and modern CPUs really help!
MacPorts was slower (bringing in its own dependencies for everything meant longer build steps) and required sudo more. There were some annoying fiddly parts that made it seem like the homebrew users around you were having more fun exploring packages.
It was also exciting how many packages and casks were in homebrew and it was easy to make your own.
Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.
Then so many projects started to publish brew install links as a way to get started; homebrew felt like a default.
Now, with our faster computers, more space, and more packages installed, and macports shipping more binaries and using its own normal user, macports' duplication of dependencies looks more like an advantage than a disadvantage. And because homebrew taught so many people how to use package managers, macports is not their first so easier to start using.
> Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.
I suppose it was almost 15 years ago now but this is what I recall. Homebrew was easier, snappier, and the general friction coefficient felt smaller.
It's a little funny reading this and then wonder... Why did I leave MacPorts behind? I don't think I put much thought into it at the time and rather went by feel. I was still somewhat new to this stuff having started my career more in design than development.
- it has always had a strong emphasis on presenting a simple, clean, pleasant, pretty, playful UI and executed that well
- when it came out, source-based package managers for macOS generally didn't have any binary caching mechanisms, so compile time mattered
- Homebrew's embrace of the base system as opposed to bringing its own dependencies bought it greater reuse at the cost of robustness, driving down total time to install many packages
- the language that `brew` and its packages were written in was trendy at thw time as well as pre-installed on macOS, which made them instantly accessible to huge numbers of web developers
- the older macOS package managers generally drew on traditions and tooling from the Linux world (e.g., Fink, with Debian tooling) or the wider Unix world (e.g., MacPorts and various *BSD ports systems and packages written in some Tcl IIRC).
The type of person with the experience that would lead them to prefer tools and conventions like one sees in Fink, MacPorts, and Pkgsrc, or to contribute to those projects, has likely always been dismayed, if not repulsed, by a number of Homebrewisms. I think we can therefore conclude that Homebrew didn't win the package availability race by converting MacPorts contributors— Homebrew succeeded in attracting a largely untapped pool of new contributors. Eventually there followed the majority of non-contributor users who just want to use whatever already offers the software they want to run.
At the point I switched from MacPorts to Homebrew, homebrew just worked more reliably in my experience. It installed things quicker and with fewer build/install failures. i don't know enough about what was going on under the hood to have any theory as to why this was my experience; I don't want to know what's going on under the hood, I just want to type `install whatever`, and have it work.
I guess MacPorts was (and is) geared more towards users with some proper UNIX or BSD background, e.g. people coming from FreeBSD.
Whereas Homebrew targets the typical Mac user who might need a CLI application occasionally, i.e. someone looking for simplicity, without being too technically savvy.
The latter group certainly makes up a much bigger share of users on macOS, especially nowadays.
When you installed a port with macports the idea was to use as much of the macports for build and runtime dependencies. Over time that became greater and so port install would be slow until you built enough dependancies. It also consumed more storage.
When you installed a port with brew it used as much of the OSX, X11, and XCode installed utilities as possible so it was faster and used less storage. But then you would install an update from Apple and things would break cause of that reliance, things like /usr/bin/perl.
People like beer but also Homebrew had a cute site and made ports simpler than MacPorts. Turns out complexity was maybe not unwarranted. I was among first adopters of brew but now I port for years
this was a while back, in the Gentoo Linux heyday, so it was popular to compile things, except that this was when computers were slow, so that meant waiting for compiles. the problem with macports was that (iirc, it's been a while) it compiled its own version of Python instead of just using the system python, which also broke sometimes. and then you had to compile all that shit again. brew won out because it was faster, and didn't duplicate redundant shit for no perceived reasom.
Switch to MacPorts. It supports precompiled packages, doesn’t take over the world and force anything on you the same way Homebrew does.
I’m really disappointed in how Homebrew took a lot of attention away from the existing package managers, made a bunch of terrible decisions related to packaging and flexibility and genera Unix philosophy, and then ate the world.
The Joyent folks leveraged it to allow their customers, who were perhaps not as familiar with Solaris/SmartOS, a larger pool of packages. Pkgsrc was running on Solaris before Joyent, Joyent built on top of it.
When I've had to use a Mac, I've used nix to good success. I'm actually surprised how well it worked; I was able to basically just use the same config I use on Linux, removing just the few Linux-specific packages.
Do you not use many packages and only strictly use FOSS tooling? I have a large and growing list of packages that have to be managed in Homebrew still because the package is one of the following:
1. Not available at all in nixpkgs (e.g. Docker Desktop, BetterTouchTool, etc)
2. In nixpkgs, but completely broken or missing some architecture support (e.g. Firefox)
3. Actually available and somewhat functional in nixpkgs, but some significant features don't work because of code signing requirements and needing to be managed in the Applications folder (e.g. 1Password)
Quite a few tools do in fact work well with nix on Mac. Especially if it's FOSS and/or a cli-only based tool. And for FOSS tooling such as Firefox, there is often a convoluted workaround (I'm currently using `github:bandithedoge/nixpkgs-firefox-darwin`). And of course you can always package it yourself by doing things The Hard Way.
But the platform is still quite a ways away from being able to be used as a daily driver on Mac without Homebrew.
Huh, interesting. I did primarily use FOSS and CLI applications. It's been a couple years, so I don't remember what exactly I used it for. I probably installed Docker Desktop via whatever method docker recommends, and I'm not sure about Firefox.
For alacrity, I remember it being annoying to integrate into Mac's launcher, but it otherwise worked.
Pretty much everything else was programming-related and just worked.
If you want graphical apps to be handled by nix on macos, you might be interested in <https://github.com/BatteredBunny/brew-nix>. nixpkgs does not package macos sandboxed apps AFAIK, that means typically only cli utilities, libraries and development tools only work.
Tried this when it was released on HN. It does not work out of the box. There is some problem with launching apps from outside of the applications folder. The trampoline Mac-app-útil approach does not work. Though in theory it probably should for most applications. I don’t know enough about the code signing process to be able to debug what is wrong with it.
I recently tried out mac-app-util¹, which fixes some of the usual pain with GUI apps. In conjunction with brew-nix², it looks like it might be most of what I'll need to move away from having Nix manage Homebrew for me.
I don't use very many GUI apps so now that the installation piece is taken care of, I can just package everything I use if it really comes down to it. That'd be worth it for me just to get rid of the painfully slow `brew` invocations that lurk in my activation scripts.
I tried this exact combination but it did not work out of the box for the apps I tried. For gui apps bundled with brew-nix they will panic due to something about how the code signing keys are copied with brew-nix. The Mac-app-util trampoline launcher does work with the regular way that brew is managed with nix (which under the hood just shells out to brew) though. So the problem is likely related to brew-nix installing apps outside of the Applications folder.
I hacked around a bit trying a few different approaches before giving up and switching back to the regular nix-Darwin homebrew approach. But the issue is probably solvable by someone who knows a lot more about how the code signing process works with Macs and the Applications folder
Ugh! How annoying. Which apps did you try that with? I just gave it a try with a couple random ones. I tried Marta, CyberDuck, IINA, KeePassXC, and CotEditor and they all worked.
(Spotify didn't build because the Brew package doesn't have a hash, and Karabiner Elements didn't build bc idk why, but that's actually in Nixpkgs already and that version works fine.)
I did double-check that I have SIP enabled and everything. I'd be interested in trying to repro!
Aside: that mac-app-util works so nicely for the macOS apps that are already in Nixpkgs makes it feel much more worth it to me to package GUI apps for macOS, if that'll mean I can get rid of `brew` entirely. I wonder if this will spur others to also package more GUI apps this way.
1Password and docker desktop are two good test subjects. 1Password especially is the one I mentioned above as being a problem child in general with nix setups on Mac
VScode in particular was the one that broke for me, though that is actually available and mostly functional in nixpkgs so that one is not a showstopper.but might be a good test case to repro
I just tried 1Password and it refused to start not being in `/Applications`. I've seen this happen with one other app (Secretive), although it doesn't quite refuse to run. I can't remember all the details, but I think it has to do with a limitation in newer versions of macOS, where apps that try to register launchd services can only do so if they live in /Applications rather than ~/Applications. The problem with launching those background services from binaries that live in ~/Applications disappears if you disable SIP. When I first encountered it, it made me wonder if ~/Applications is not really supported on modern macOS. I wish I could find the issue for that but I didn't, when I looked just now. :-\
1Password definitely acts weird for me, to where I kind of wonder if the .app folder is malformed somehow. The version installed in the Nix store actually works fine-- but not if I double-click it or open it with the `open` command. In that case it kinda acts like something is going to launch but then it never comes up. But if I manually invoke `/Applications/Nix\ Apps/1Password.app/Contents/MacOS/1Password` from my terminal, it starts up fine! But when I directly launch that executable from Finder, the application does not start and I see that same message about not living in /Applications printed in the terminal. Idk why 1Password refuses to run from anywhere other than /Applications but that seems to be it's message rather than the operating system's.
It's a shame 1Password's Mac app can't run from the Nix store. They clearly have at least one Nixer at the company because they have cool integrations like this:
I couldn't even get the Docker Desktop package to build from `brew-nix`. OrbStack in the Nix store died on signature errors, but when I visited Security & Privacy in System Preferences after that, there was a little notice that OrbStack had been blocked from running because it was from an unrecognized developer, with the option to allow it. After being allowed, it seemed to work as normal. Same for Podman Desktop.
Why do the signatures for those apps end up getting replaced with this setup anyway?
As for your first question, about why 1Password refuses to run outside of Applications, I’m pretty sure it’s security. There is something special about Applications on MacOS that apparently AgileBits views as an attack vector when run outside of it.
I was curious about your final question as well, but I know little about how this works. The error when I tried vscode looked to be that the signature had gotten malformed somehow during brew-nix’s copy operation but since I had no idea what a correct signature should even look like I got stumped there.
I've been using pkgin and pkgsrc for years on macOS. Occasionally, I still need a small brew prefix when a dependency is missing or difficult to build. Molten-vk was the last such package.
pkgsrc is by far the most KISS package manager for macOS, I like it.
Here in Houston as well, dew point is as important as temperature and %PoP. Apple Weather suffices for now but I hope it gets richer with the various types of data that are of greater relevance in different regions.
reply