The problem is it can be subjective. Some people really like the “smooth motion” effect, especially if they never got used to watching 24fps films back in the day. Others, like me, think seeing stuff at higher refresh rates just looks off. It may be a generational thing. Same goes for “vivid color” mode and those crazy high contrast colors. People just like it more.
On the other hand, things that are objective like color calibration, can be hard to “push down” to each TV because they might vary from set to set. Apple TV has a cool feature where you can calibrate the output using your phone camera, it’s really nifty. Lots of people comment on how good the picture on my TV looks, it’s just because it’s calibrated. It makes a big difference.
Anyways, while I am on my soap box, one reason I don’t have a Netflix account any more is because you need the highest tier to get 4k/hdr content. Other services like Apple TV and Prime give everyone 4k. I feel like that should be the standard now. It’s funny to see this thread of suggestions for people to get better picture, when many viewers probably can’t even get 4k/hdr.
I feel like I’ve figured out a good workflow with AI coding tools now. I use it in “Planning mode” to describe the feature or whatever I am working on and break it down into phases. I iterate on the planning doc until it matches what I want to build.
Then, I ask it to execute each phase from the doc one at a time. I review all the code it writes or sometimes just write it myself. When it is done it updates the plan with what was accomplished and what needs to be done next.
This has worked for me because:
- it forces the planning part to happen before coding. A lot of Claude’s “wtf” moments can be caught in this phase before it write a ton of gobbledygook code that I then have to clean up
- the code is written in small chunks, usually one or two functions at a time. It’s small enough that I can review all the code and understand before I click accept. There’s no blindly accepting junk code.
- the only context is the planning doc. Claude captures everything it needs there, and it’s able to pick right up from a new chat and keep working.
- it helps my distraction-prone brain make plans and keep track of what I was doing. Even without Claude writing any code, this alone is a huge productivity boost for me. It’s like have a magic notebook that keeps track of where I was in my projects so I can pick them up again easily.
A nice practice that I try to follow it to always spell out what any Three Letter Acronyms (TLAs) the first time they are used. Then from that point onwards the simple TLA can be used.
In this case, BPF (shorthand for eBPF), stands for Extended Berkley Packet Filter. It’s a relatively new feature in the kernel that allows attaching small programs at certain “hook points” in the kernel (for example, when some syscall is called). These programs can pass information into userspace (like who is calling the syscall), and make decisions (whether to allow the call to proceed).
We do try to spell things out and/or link them in LWN articles to make the context available, but some things we just have to assume.
Additionally, spelling out "Berkeley Packet Filter" is not going to help any readers here; BPF is far removed from the days when its sole job was filtering packets, and that name will not tell readers anything about why BPF is important in the Linux kernel.
The same problem actually already exists for non-drone planes, because they must be able to operate in poor visibility conditions. FAA issues notams for construction cranes if they pose a risk to nearby airports. One solution for drones would be to extend these notams to all cranes/other obstacles, and the drones must subscribe to these notams to operate in the airspace.
I would tend to agree, I think dev time is better spent supporting Proton. I have even seen benchmarks where Proton on Linux outperforms Windows. As a Steam Deck owner, Proton is fantastic.
Yeah I’m not seeing any evidence that this actually works. I would’ve like to see some testing where they intentionally introduce a bug (ideally a tricky bug in a part of code that isn’t directly changed by the diff) and see if Claude catches it.
A good middle ground could be to allow the diff to land once the “AI quick check” passed, then keep the full test suite running in the background. If they run them side by side for a while and see that the AI quick check caught the failing test every time, I’d be convinced.
I swear I read in a text book once that Fourier discovered this while a boat. He looked out at the waves on the ocean and saw how there were many different sized waves combining to make up the larger waves. I could never find it again, but that visual helped me understand how the Fourier transform works.
The annoying thing is the official Swift extension can sometimes flag errors in perfectly fine code with zero problem in Xcode. So I’m forced to live with persistent “errors” when editing in VS Code/Cursor.
I’m building my first iOS app ever so I know it has much more to do with me not understanding Xcode but getting builds to succeed after making changes with Claude code has been a nightmare. If you or anyone have any tips, guides, prayers, incantations for how to get changes in one to not clobber the other and leave me in xproj symlink hell I would be so grateful.
> any tips, guides, prayers, incantations for how to get changes in one to not clobber the other
One caveman way:
1. Start your project using Xcode, use it to commit to GitHub, GitLab, whereever. In terminal, change into the dir that has the .git in it and launch claude.
2. Teach Claude Code your own system's path and preferred simulator for build testing. From then on it will build-test every change, so teach it to only commit after build passes. (By teach, I mean, just tell it, then from time to time, tell it to propose updates to claude.md in your project.)
3. Make sure before a PR or push that the project still builds in Xcode, if it doesn't, you can eyeball the changes in Xcode's staged changes viewer and undo them. If you change files via IDE, when you're back in Claude just say: I changed [specific/file, or "a lot of files"].
No xproj or symlinks get harmed in the making of your .swifts.
On the other hand, things that are objective like color calibration, can be hard to “push down” to each TV because they might vary from set to set. Apple TV has a cool feature where you can calibrate the output using your phone camera, it’s really nifty. Lots of people comment on how good the picture on my TV looks, it’s just because it’s calibrated. It makes a big difference.
Anyways, while I am on my soap box, one reason I don’t have a Netflix account any more is because you need the highest tier to get 4k/hdr content. Other services like Apple TV and Prime give everyone 4k. I feel like that should be the standard now. It’s funny to see this thread of suggestions for people to get better picture, when many viewers probably can’t even get 4k/hdr.
reply