lukasgraf

> To "manually verify that the block is clear" is drive by sight. The only alternative would be to walk along the whole track.

But aren't there additional systems that can detect that a block is obstructed (e.g. also by left behind carriages that got disconnected) like the electrical track circuit (Gleisstromkreis)?

Or wouldn't that have helped because we're back again to the issue that with the downgrade from LZB to PZB we lost the virtual blocks, and both trains are now occupying the same, longer, non-virtual block?

Which would mean that this block would have been indicated to the controllers as not clear - but that is exactly what they would expect to see, because they're currently deciding what instructions to give to the AVE, which they know is stopped in that block. But they have no indication that there is a second train (Iryo) in front, occupying the same block.

Hence, I assume, the protocol to resume operations with drive by sight after a LZB failure (which seems to have been ignored in this case). But why not also have the protocol demand that operations are resumed front-to-back in that situation? I suspect that "front-to-back" is not nearly as unambiguous a concept in reality as it may seem in my layman's head.

> 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

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.