HackerTrans
TopNewTrendsCommentsPastAskShowJobs

lukasgraf

no profile record

comments

lukasgraf
·قبل شهرين·discuss
> 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.
lukasgraf
·قبل شهرين·discuss
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.
lukasgraf
·قبل 4 أشهر·discuss
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.
lukasgraf
·قبل 5 أشهر·discuss
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).
lukasgraf
·قبل 11 شهرًا·discuss
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
lukasgraf
·السنة الماضية·discuss
On macOS:

  # defaults write com.google.Chrome.plist ExtensionManifestV2Availability -int 2
This will continue to allow MV2 extensions for your Chrome instance. Confirm the policy has been set by checking chrome://policy. See [1] for possible values.

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" }
You'll need to create the "External Extensions" directory, set file permissions according to docs, restart Chrome. The file name contains the extension ID to be installed, which you can verify from the submission URL of this post. Upon Chrome restart, it should notify you with a message in the top right that an extension was forcibly installed.

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...