Does anyone have an output style nailed down that actually works? If so, please share!
118 karma · joined May 10, 2011
Does anyone have an output style nailed down that actually works? If so, please share!
Any tips on how to avoid that would be highly appreciated!
I’ve found it to be a good balance for letting Claude loose in a VM running the commands it wants while having all my local MCPs and tools still available.
This feels disingenuous. Tart has unattended setup support as well, and it's based on the same VNC + OCR technique as Lume. In fact Tart had it first, and your approach seems to be heavily inspired by it. In addition the boot command instructions you're using came from https://github.com/cirruslabs/macos-image-templates/
The only material difference is whether it's built-in or integrated via Packer.
The FAQ states you back up the originals as plain images files in YYYY/MM/DD format, which is great for integration with other tools. What about metadata? Is it in a format that lends to integration with other tools, say if you stop developing/supporting your app for some reason?
We've tweaked our styles to take the new design metrics into account, and fixed or worked around issues where we've seen them. We don't integrate with NSGlassEffectView and friends yet. If you find any issues in recently released version of Qt 6.10, 6.8 or 6.5, please report them upstream, thanks!
Glad to see I'm not the only one at least, and hopefully this will be possible to fix as a software update, rather than having to replace the AirPods.
One thing you don't touch upon (yet) is that the diff soup may lead people to prefer the squash merge strategy, to get rid of the "noise" of the fixup commits, which throws away the "good" initial 3 atomic commits as well.
With interdiff review style you're left with the initial 3 commits, and the choice of whether to land them individually or squash them is based entirely on the commits themselves and how atomic they really are.
As an outside contributor, with a fork of the repository, your three PRs will incrementally contain change A, A+B, and A+B+C, making the review of the last two PRs harder, because you need to review diffs for code you're already reviewed in another PR.
-lswift_Backtracing also works, but dunno if that's "public API"
$ codesign --force --sign - --entitlements entitlements.plist foo
https://github.com/apple/swift/blob/main/docs/Backtracing.rs...
$ SWIFT_BACKTRACE="enable=yes" ./foo
Very cool!
If Debian supports its releases for longer than the upstream projects do, then that's a (perfectly valid) choice of Debian, but I'm assuming that involves maintaining those projects as well, to the standards of Debian's support policies.
https://wiki.qt.io/QtReleasing
(Disclaimer: I work for the Qt company)
See https://news.ycombinator.com/item?id=25434191 for prior discussion about my experience.
I’ve even paid for Dash to get that feature, but no longer use it due to some UI changes in the latest version that add extra clicks for each search query, making the UI inefficient.
Zeal seems to have be inspired by the old and efficient Dash UI, but I can’t have both that and the Apple docs from what I can tell.