lukasgraf

TM heavily throttles disk I/O used for backing up

That makes sense, and I usually quite like that behavior. I barely ever notice an impact when backups are running.

However, this is happening every time on one machine (Intel iMac), and semi-regularly on another one (M3 MBP), after a fresh restart, giving mds_stores some time to settle down, and the most recent backup just hours ago, with no significant changes on disk since.

In a situation like that, I would expect the "Preparing backup..." stage to just take a second to create an APFS snapshot, and maybe a minute to diff that snapshot against the remote state. But not 10+ minutes.

But thank you for the hint about that sysctl parameter! I will certainly give this a try.

I can't remember the exact phrasing, but are you talking about the error message that essentially says: "The Tardis is broken. Your backup has diverged into an entirely separate timeline, and I have no way of reconciling it. You may now sacrifice an entire weekend to do an initial backup again."?

I've been on a lucky streak for several years now, where I haven't gotten that one on any of my devices.

"Preparing backup..." taking an unreasonable amount of time is a regular occurrence, and some edge cases around adjusting TM backup size quotas aren't handled well. But other than that, TM has been working reasonably well for me to back up 10 TB over SMB to a Synology NAS.

My gripe is much more with Apple's abysmal support for SMB and NFS, especially after deprecating AFP. I've been back and forth between them over the years and over several OS versions, and their implementations for both are just terrible.

But over time SMB, for me, proved slightly more stable and performant, with the right tweaks in smb.conf, and authentication and permissions/ownership are easier to deal with than NFS, so I stuck with that.

I also yearn for the days where TM just worked, because somehow, the alternatives are even worse:

- Arq Backup does some things quite well, which is why I use it as part of my 3-2-1. But some of its bugs and implementation decisions just scream "hobby grade" to me.

- Kopia looks interesting, but it's not mature enough yet. Failed for me with absolutely cryptic error messages during repo init both times I tried it, with versions several months apart.

- Restic, Borg / Vorta: Not turnkey enough for me.

The best people I've worked with tended to go out of their way to make it as easy for me as possible to critique their ideas or implementations.

They spelled out exactly their assumptions, the gaps in their knowledge, what they have struggled with during implementation, behavior they observed but don't fully understand, etc.

Their default position was that their contribution was not worth considering unless they can sell it to the reviewer, by not assuming their change deserves to get merged because of their seniority or authority, but by making the other person understand how any why it works. Especially so if the reviewer was their junior.

When describing the architecture, they made an effort to communicate it so clearly that it became trivial for others to spot flaws, and attack their ideas. They not only provided you with ammunition to shoot down their ideas, they handed you a loaded gun, safety off, and showed you exactly where to point it.

If I see that level of humility and self-introspection in a PR, I'm not worried, regardless of whether or not an LLM was involved.

But then there's people that created PRs with changes where the stack didn't even boot / compile, because of trivial errors. They already did that before, and now they've got LLMs. Those are the contributions I'm very worried about.

So unlike people in other threads here, I don't agree at all with "If the code works, does it matter how it was produced and presented?". For me, the meta / out-of-band information about a contribution is a massive signal, today more than ever.

I never understood this argument.

The checks in those pre-commit hooks would need to be very fast - otherwise they'd be too slow to run on every commit.

Then why would it save time and money if they only get run at the pipeline stage? That would only save substantial time if the pipepline is architected in a suboptimal way: Those checks should get run immediately on push, and first in the pipeline so the make the pipeline fail fast if they don't pass. Instant Slack notification on fail.

But the fastest feedback is obviously in the editor, where such checks like linting / auto-formatting belong, IMHO. There I can see what gets changed, and react to it.

Pre-commit hooks sit in such a weird place between where I author my code (editor) and the last line of defense (CI).

This is outside the context the "Open File" dialog from your original question, but here's another tip about "navigating up":

In many application windows you can navigate the hierarchical directory structure that contains the currently open file by right-clicking on the document name/icon in the window's title bar.

E.g. in Preview, Pages, Finder, ..., hover over the file or directory name in the window's title bar. If you right click on it, a pop-out will appear with a vertical hierarchical list of that file's parent folders. Selecting one of the parent folders will open a new Finder window at that location, allowing you to quickly navigate to a file's containing folder.

And some additions to the tips in other comments:

- Dragging a file or directory from finder to the terminal will paste its path onto your shell

- iTerm has Finder integrations. Right click on a folder in Finder, Services -> New iTerm2 Window Here

And you might enjoy some of these Finder tweaks from my "dotfiles" (just run them on the shell):

  # Set Documents as the default location for new Finder windows
  # For other paths, use `PfLo` and `file:///full/path/here/`
  defaults write com.apple.finder NewWindowTarget -string "PfDo"
  defaults write com.apple.finder NewWindowTargetPath -string "file://${HOME}/Documents/"
    
  # Finder: show hidden files by default
  defaults write com.apple.finder AppleShowAllFiles -bool true
  
  # Finder: show all filename extensions
  defaults write NSGlobalDomain AppleShowAllExtensions -bool true
  
  # Finder: show status bar
  defaults write com.apple.finder ShowStatusBar -bool true
  
  # Finder: show path bar
  defaults write com.apple.finder ShowPathbar -bool true
  
  # Keep folders on top when sorting by name
  defaults write com.apple.finder _FXSortFoldersFirst -bool true
  
  # Enable spring loading for directories
  defaults write NSGlobalDomain com.apple.springing.enabled -bool true
  
  # Use list view in all Finder windows by default
  # Four-letter codes for the other view modes: `icnv`, `clmv`, `glyv`
  defaults write com.apple.finder FXPreferredViewStyle -string "Nlsv"
  
  # Show the ~/Library folder
  chflags nohidden ~/Library && xattr -p com.apple.FinderInfo ~/Library 2>/dev/null && xattr -d com.apple.FinderInfo ~/Library
  
  # Show the /Volumes folder
  sudo chflags nohidden /Volumes
  
  # Expand the following File Info panes:
  # “General”, “Open with”, and “Sharing & Permissions”
  defaults write com.apple.finder FXInfoPanesExpanded -dict \
    General -bool true \
    OpenWith -bool true \
    Privileges -bool true

Install it using an enterprise profile and enable the ExtensionManifestV2Availability flag: https://news.ycombinator.com/item?id=43340358

Still works for me to this day, but this option might get axed come June 2025.

On macOS:

  # defaults write com.google.Chrome.plist ExtensionManifestV2Availability -int 2

Now, because uBO is now disabled in the Chrome Web Store, you also need to install it as a "forced extension" (the way extensions are deployed in enterprise environments). Install the extension according to the section "Use a preferences file" in [2]:

  - Create a file named cjpalhdlnbpafiamejdnhcphjbkeiagm.json
  - Place it in ~/Library/Application Support/Google/Chrome/External Extensions/
  - With content:
  { "external_update_url": "https://clients2.google.com/service/update2/crx" }

The ExtensionManifestV2Availability definitely still works for now, but it's been a about a month since I used the preferences file way of installing the extension on a new device. YMMV.

[1] https://chromeenterprise.google/policies/#ExtensionManifestV... [2] https://developer.chrome.com/docs/extensions/how-to/distribu...

When mentoring a junior, I noticed he had an alias `gpf`, which he apparently picked up from another developer.

I had a serious conversation with him, explaining that I'm not in the habit of telling him how to configure his shell, edit or general work environment. But an alias for `git push -f`, that I cannot condone. When you're doing that, the two seconds it takes to type it out should be rather low on the list of priorities.

So we had a good talk, and he genuinely understood the point I was trying to make. When I was about to leave, he looked at me sheepishly and asked:

"So I guess you want me to remove this one too?"

gacpf - git add . && git commit --amend && git push --force

Genuine question, how do you find DxO PhotoLab lacking when compared to LR?

It's mostly their "no catalog" approach that irks me. From what I understand they use a model that doesn't use a catalog, and requires you to import photos, but instead allow you to point it at any filesystem location, and work on those photos.

Fair enough, but for me the question then immediately becomes how and where the data that I generate in PL7 is stored and managed - and I was struggling to find any comprehensive information on this.

If it doesn't have a catalog, where does it store edits I make to my photos? Does it actually modify and write down some information in RAW files (that would be a non-starter for me)? Does it litter the filesystem with XMP sidecar files next to the originals? How does it keep (and repair) associations between original RAWs and their edits/metadata if they get moved on the file system outside of PL7?

It allows to search/filter photos by metadata attributes "across your whole computer" (according to their tutorial video on organization). So it must keep some index somewhere, otherwise that would be dog slow. So how and when does that index get updated? Do I get any control over when that happens, any UI feedback when its happening and I'm potentially working with outdated metadata, etc..?

LR's catalog approach has some drawbacks, but from an engineering standpoint, it seems to me that's the much simpler and robust approach to implement this. The LR catalog is a simple SQLite DB, and backup is trivial: Backup my originals and the catalog, done. Follow the simple rule "Don't modify originals behind LR's back" and you'll be good. (Or be prepared to do it in a very systematic way, and fix references in LR afterwards).

The catalog approach definitely has its limitations and issues, but I find it very easy to reason about. No surprises. PL7's approach seems to require much more magic behind the scenes, which makes me quite uncomfortable.

In terms of denoising, I have to agree - the DxO stuff is miles ahead in terms of quality for some algorithms, and denoising is one of them. I use NikCollection (as a PS plugin) for those 1 out of a 1000 photos that deserve some serious editing.

Thank you for the recommendation! RAW Power is one that I actually didn't have on my radar, and it certainly looks very interesting.

Maybe not as feature-rich as some of the heavy hitters, but it looks to be very focused in both its feature set and its UI. And it seems to hit that sweet spot where it does both cataloging and RAW processing competently.

This is the most promising alternative I've seen so far for what I'm yearning for, so thanks again!

I am, intentionally so ;-) Because this mix is where Lightroom excels, and competing products just fall short.

As an enthusiast or professional photographer you really need both, preferrably in the same application, or at least in tightly integrated applications.

I started with Lightroom 1 beta3, and while it was dog slow, the speedup in workflow to cull and edit thousands of photos after a shoot was revolutionary at the time. In the beginning it only supported global edits, which was enough anyway for 95% of photos. But you could sync and apply these edits in bulk to other photos, and get through hundreds of them quickly.

Capture One certainly is the closest. But switching costs are huge. My catalog contains tens of thousands of images, professionals will have hundreds of thousands. If I'm to switch, I need to be certain that every single Lightroom edit is, in principle, supported too, and will be converted faithfully on import.

And their pricing is weird. In the beginning they required you to pick a RAW edition - you could have support for Canon, or Nikon, but not both. That's gone now, and as you say, I think it has come a long way. But their perpetual license now is nowhere competitive in price with the Adobe Photography Plan ($9.99/mo, infamous "Annual paid monthly", for LR+PS). The $300 for Capture One is for one major version, for the price of 2.5 years of Photoshop and Lightroom.

The big issue with Affinity Photo is that it doesn't support non-destructive editing / a non-linear workflow like Lightroom does.

It's not exactly a fair comparison, since AP directly competes with Photoshop, not Lightroom, but that was what made it an immediate non-starter for me when it comes to photography.

Affinity Photo starts you in a "Develop Persona" when you open a RAW file, and allows you to develop your RAW file. Before you can use any of the common editing tools, you need to leave that persona by committing your changes. You need to make a choice to bake these RAW adjustments into a "RAW layer (embedded)", "RAW layer (linked)" or a "Pixel layer". It's not very obvious what these are and how they work.

Most of the common editing tools then work destructively. Once you use them, you can't go back and change any of the RAW adjustments. There are some very limited tools available that can work non-destructively, but again, it's not very obvious which ones those are. And use of the wrong tool can immediately turn a "RAW layer" into a "Pixel layer" without warning.

It's all very confusing, to be honest. It may be a case of the RTFM, but I did so when I tried this a couple months ago, and came to the conclusion that AP simply isn't capable of a non-destructive editing workflow yet, except for a few very basic cases.

But the bundle price was worth it for me for Designer and Publisher alone. So I hope in due time they'll launch a fourth product to compete with Lightroom, on photo cataloging, culling and a non-destructive workflow.

The current commercial alternatives for Lightroom unfortunately are still lacking, last time I looked at them (Capture One, DxO Photo Lab). And the open source ones (darktable, digiKam) are ... not good. I'm keeping my eye on "Ansel" though (darktable fork by an ex-dev, anger-driven development), the author's rants sum up very wrong what's wrong with darktable, and why its community is so dysfunctional.

I agree.

A 30% overlap allows be to basically never have an automatic pano merge fail in LR. Though I rarely shoot panos full handheld, usually still from a tripod with at least a ballhead.

Even better, LR allows you to merge a HDR pano in a single action - which has become an important part of my workflow, because it works so well, and results in a nearly RAW quality DNG that can be edited non-destructively.

With one exception: Multi-row panos with 3 rows, where the top row is mostly sky. Even with lots of overlap, LR usually can't figure this out. But the workflow using tools like Hugin or PTGui is so involved (and requires baking the RAW files first) that I usually just avoid this situation. Besides the fact that it's often not the most interesting composition.

It depends. For some applications, sure.

But especially when you're doing multi-row panoramas with long exposure times, preparation is key, and so is execution time.

I often do multi-row HDR panos. With brackets of 3 exposures each, the time for a single frame can quickly add up to 45s or more. In a 3 row, 5 column pano that adds up to a total exposure time of 11.25 minutes - net. This doesn't include the time between frames needed to pan to the next column (or worse, next row and 1st column), making sure you get enough overlap, align everything and finally tighten the tripod head knobs/clamps again.

Depending on the season, the usable blue hour may be as short as 15 minutes. That mean's you essentially get one shot at this.

So any gear that allows you to do that reliably and quickly, for example a panoramic rotator head with indexed degree stops [1], helps immensly with getting good results.

This is an example of a 2x5 "pano" with a 3x exposure bracket (20s, 6s, 2s) I took:

https://commons.wikimedia.org/wiki/File:Federal_Palace_of_Sw... (Warning: Full res image is huge)

With 20s as the longest exposure, the chance of a car or bus driving right through my shot was huge, so I had to retake many of the frames, some even several times.

[1] For example the Nodal Ninja RD16-II Advanced Panoramic Rotator

Fellow map nerds might also enjoy these:

The new "Light Base Map":

https://www.swisstopo.admin.ch/en/web-maps-light-base-map

Demo (Light Base Map):

https://cms.geo.admin.ch/fmc/lbm.html

This is a modernized version of a base map (used to overlay topical maps over it) that they have been working on for the past few years. Available as vector tile. It's very clean and crisp, and IMHO much more readable than e.g. the Google Maps style, or OSM.

---

Highly customizable 3D map viewer (under development). Performance is a bit choppy, and navigation feels somewhat clunky. But you can overlay any of the hundreds of topical maps (pick from geocatalog menu, or search via search bar).

Example with hiking trails overlay: https://test.map.geo.admin.ch/#/map?lang=en&sr=3857&center=8...

It's actually open data: https://shop.swisstopo.admin.ch/en/free-geodata

  > New conditions of use apply to swisstopo's official geodata.
  > The geodata may be used free of charge, in particular also for commercial purposes.
  > Reference to the source when publishing the data is the only condition.
  > Authorizations and licenses are therefore no longer required.

One of the (IMHO) most interesting datasets is the extremely detailed digital elevation model / DSM (swissSURFACE3D):

https://www.swisstopo.admin.ch/en/height-model-swisssurface3...

Lidar scanned terrain model, with a grid size of 0.5m and vertical resolution of ~10cm. Available as a tiled raster or the "raw" classified point cloud (ground, vegetation, water, ...).

Raster:

https://www.swisstopo.admin.ch/en/height-model-swisssurface3...

Point Cloud:

https://www.swisstopo.admin.ch/en/height-model-swisssurface3...

Demo (Shaded Relief based on that surface model. Those stair step patterns are not artifacts, but the natural terracing of vineyards):

https://map.geo.admin.ch/?lang=en&topic=ech&bgLayer=ch.swiss...

This is a 30min talk that I keep coming back to:

Python, Linkers, and Virtual Memory by Brandon Rhodes (Python core dev)

https://www.youtube.com/watch?v=twQKAoq2OPE

(Most of the content is not actually specific to Python)

He beautifully pulls back the curtain on so many lower level concepts like virtual memory management, dynamic linking, heap/stack, fork(), copy-on-write.

The talk is broad in nature, not deep. It takes you just below the surface of many magic black boxes, and, as you put it, enhances your proximity with those topics.

For me, so many things clicked in this single talk:

- How virtual memory works (incl. paging in/out, swapping)

- Why there's those discrepancies between RSS / PSS

- What segfaults and page faults are

- What actually happens when I get errors related to dynamically linked libraries, either at build time or runtime

- Actually understanding the output of top / ps

I saw David Weinberger's talk at Google [1] some 15 years ago, where he presented the ideas from his book (and bought the book afterwards). This is one of those videos I rewatch regularly, because the ideas hold up so well, even today.

His critique of the Dewey Decimal system was the first thing that came to mind when I read Johnny Decimal. And indeed, it is flawed the same way.

[1] https://www.youtube.com/watch?v=x3wOhXsjPYM

CityEngine [1] does that.

It's a procedural city generation engine first presented at SIGGRAPH 2001, by Procedural Inc., an ETH Zürich spinoff that was later acquired by ESRI (ArcGIS).

At its core is a shape grammar based on L-Systems [2] that is used to define how a road network is subvided into lots, then buildings etc.. with increasing level of detail and contextual constraints.

You give it a vector road network and the grammar rules, and it subdivides it spacially into e.g.

  Lots
    > Buildings
      > Roofs
      > Stories
        > Facades
          > Windows
            > Frame
            > Glass pane
            > Ledge

The original paper and presentation at SIGGRAPH described the simplicity of the core idea quite beautifully, but I'm having a hard time finding them now. This old tech demo video [3] should give an idea of how it works though.

[1] https://en.wikipedia.org/wiki/CityEngine

[2] https://en.wikipedia.org/wiki/L-system

[3] https://www.youtube.com/watch?v=SxyOTUzm2qw

Not a podcast, but a Stanford MOOC (massive open online course): https://www.youtube.com/watch?v=o1Fyn_h6LKU&list=PLGvhNIiu1u...

The basic operation of a GNSS with ~30m accuracy is literally explained on one slide in lecture 1.2, and from then on the rest of the course is about implementation specifics, and enhancing performance.

The basic concept at its core is so elegant and beautiful, but no less interesting are all the ways this system is augmented with different techniques to improve the accuracy down to ~1cm.

This is one of those resources I've downloaded and made sure to have backed up, because it's so invaluable to me.

Version control can be a big help.

Look through closed tickets in the issue tracker, and try to find a change (bugfix or new feature) that must have, given its nature, touched the functionality you're looking for. Then try to find the changeset(s) where that ticket's change was implemented.

With some luck, the changeset will include a modification to the part of the codebase you've been looking for.

Still worked for me yesterday. Temporarily "switched" to a yearly (paid monthly) InCopy subscription, and was able to cancel that about 5min later.

If you don't get the "do you want to switch instead of cancelling?" retainer dialog, you may have already declined it. Clearing cookies and local storage did the trick for me in that case.

I tend to agree.

Obviously automatic normalisation is the correct thing to do when doing arithmetic that crosses DST-rollover boundaries (this is what the Python stdlib gets wrong), but I don't think it should be done (by default) upon creation with a location-based TZ specification:

pendulum.create(2016, 10, 30, 2, 30, 00, 0, 'Europe/Paris') is ambiguous, and pendulum.create(2016, 3, 27, 2, 30, 00, 0, 'Europe/Paris') is non-existent. pytz raises AmbiguousTimeError or NonExistentTimeError respectively in cases where you try to construct local times like that and specifiy is_dst=None: http://pytz.sourceforge.net/#problems-with-localtime

With pendulum I don't see a possibility to enforce a "strict mode" that turns of those automatic assumptions.