mkozlows

The whites in Filmmaker Mode are not off. They'll look warm to you if you're used to the too-blue settings, but they're completely and measurably correct.

I'd suggest living with it for a while; if you do, you'll quickly get used to it, and then going to the "standard" (sic) setting will look too blue.

It's true that Filmmaker Mode might at some point in the future be corrupted, but in the actual world of today, if you go to a TV and set it to Filmmaker Mode, it's going to move most things to correct settings, and all things to correct settings on at least some TVs.

(The trickiest thing is actually brightness. LG originally used to set brightness to 100 nits in Filmmaker Mode for SDR, which is correct dark room behavior -- but a lot of people aren't in dark rooms and want brighter screens, so they changed it to be significantly brighter. Defensible, but it now means that if you are in a dark room, you have to look up which brightness level is close to 100 nits.)

I think you should ask yourself: If it were true that 1) these things do in fact work, 2) these things are in fact getting better... what would people be saying?

The answer is: Exactly what we are saying. This is also why people keep suggesting that you need to try them out with a more open mind, or with different techniques: Because we know with absolute first-person iron-clad certainty what is possible, and if you don't think it's possible, you're missing something.

Agree. But it's increasingly the case, IME, that for a a lot of tasks, you can start with that. If it does it well, great. If it does something stupid, it's easy enough to ask it to completely rework the stupid thing in a better way, and it can do it quickly. That's still a huge shift compared to the olden days (three months ago) where you needed to really break things down into small chunks for it to get to a success state.

Honestly, even this isn't really true anymore. With Opus 4.5 and 5.2 Codex in tools like Cursor, Claude Code, or Codex CLI, "just do the thing" is a viable strategy for a shockingly large category of tasks.

"The future is already here, it's just unevenly distributed."

At some companies, most developers already are using it in their day to day. IME, the more senior the developer is, the more likely they are to be heavily using LLMs to write all/most of their code these days. Talking to friends and former coworkers at startups and Big Tech (and my own coworkers, and of course my own experience), this isn't a "someday" thing.

People who work at more conservative companies, the kind that don't already have enterprise Cursor/Anthropic/OpenAI agreements, and are maybe still cautiously evaluating Copilot... maybe not so much.

It's because the models keep getting better! What you could do with GPT-4 was more impressive than what you could do with GPT 3.5. What you could do with Sonnet 3.5 was more impressive yet, and Sonnet 4, and Sonnet 4.5.

Some of these improvements have been minor, some of them have been big enough to feel like step changes. Sonnet 3.7 + Claude Code (they came out at the same time) was a big step change; Opus 4.5 similarly feels like a big step change.

(If you don't trust vibes, METR's task completion benchmark shows huge improvements, too.)

If you're sincerely trying these models out with the intention of seeing if you can make them work for you, and doing all the things you should do in those cases, then even if you're getting negative results somehow, you need to keep trying, because there will come a point where the negative turns positive for you.

If you're someone who's been using them productively for a while now, you need to keep changing how you use them, because what used to work is no longer optimal.

Because a) the benefits are bigger, and b) the effort is smaller. When something gets cheaper and more valuable, do more of it.

I like this. "Best practices" are always contingent on the particular constellation of technology out there; with tools that make it super-easy to write code, I can absolutely see 100% coverage paying off in a way that doesn't for human-written code -- it maximizes what LLMs are good at (cranking out code) while giving them easy targets to aim for with little judgement.

(A thing I think is under-explored is how much LLMs change where the value of tests are. Back in the artisan hand-crafted code days, unit tests were mostly useful as scaffolding: Almost all the value I got from them was during the writing of the code. If I'd deleted the unit tests before merging, I'd've gotten 90% of the value out of them. Whereas now, the AI doesn't necessarily need unit tests as scaffolding as much as I do, _but_ having them put in there makes future agentic interactions safer, because they act as reified context.)

How's that work for you on Android? Firefox on Android with uBlock is the huge win.

KOReader has built in Progress Sync, which works well for the purpose.

Valve has said it won't have console-like pricing, so.

The question is whether spherical cow research tells you anything that holds up once you introduce the complications of reality into it. In physics, it clearly does. In economics, I think it does in a lot of cases (though with limits). In software engineering... well, like I say, there are areas where I'm sure it does, but research about e.g. strong typing or unit tests or PR review or whatever just doesn't have the juice, IME.

Because it's usually not that useful. I have a friend who was software-adjacent, and would post all these exciting studies showing that this or that practice was a big deal and massively boosted productivity. And without fail, those studies were some toy experiment design that had nothing to do with actual real-world conditions, and weren't remotely strong enough to convince me to up-end opinions based on my actual experience.

I'm sure there are sub-fields where academic papers are more important -- AI research, or really anything with "research" in the name -- but if you're just building normal software, I don't think there's much there.

If what you want is a queue, Kafka might be overkill for your needs. It's a great tool, but it definitely has a lot of complexity relative to a straightforward queue system.

There are apparently are some semi-experimental FFB drivers out there for a few wheels... but yeah, most hardware has a zero percent chance of working, because it's a niche of a niche. And then if you're doing online racing, they all(?) have anti-cheat stuff that won't work for you anyway.

If games transition to SteamOS/Linux in general, I think this niche is going to be one of the slower ones to move, but never say never.

Shiftall Meganex 8K is out, and Pimax Dream Air is upcoming. But those are PCVR headsets, not... whatever the AVP is.

The xReal ones are extremely workable. Like, you wouldn't want to do it by preference if a good monitor was available, but easily good enough for a situation where you don't want to use a monitor or don't have one.

"Not any better than Blu-ray" is the same as saying "much better than streaming."

I really wish I could like this term, because I agree the world needs a pithy, memorable one for what you're describing. But alas, I don't think this is it, either.

And what makes the one streaming service stay good, with no competitors?

Samsung has owned Harman Kardon and its stable of brands for a long time, and they've been mostly fine. Mainly, I think Samsung doesn't care about them except as names to license in "exclusive" partnerships with automakers.

Try something like a Sinc: https://keeb.io/products/sinc-rev-4-split-staggered-75-keybo...

It's still mechanical, it's still split, it's still QMK programmable, it's got hotswap sockets so you can try different switches... but it's also an extremely normal staggered layout with function keys and everything.

I think it's worth trying the ortho 'n' layers approach, because it has real wins to it; but if you've tried it and don't like it, this is one step closer to normalcy, while still keeping many of the wins.

It is! If you want a keyboard that you never think about, a programmable wacky layout keyboard is not for you.

But if you use your keyboard a lot, keyboard hobbyism can be rewarding to a certain point.

So a) that seems like a nightmare to me no matter what keyboard I'm on, but b) if you have frequently-used shortcuts that are a pita to get to, you can put them on a layer where you just use them.

Like, I legitimately don't know anymore how you take a screenshot on MacOS, but I know that I hit the modifier key and then this one other key, and that takes a screenshot. Also don't know what you press to move from virtual screen to virtual screen, but mod-m and mod-comma go left and right for me. And in a browser, mod-s and mod-f do ctrl-shift-tab and ctrl-tab.

It's a terrible idea to do this for rarely-used shortcuts, as you'll never remember them; but for ones you use frequently, it's better-than-native, because you can put them on convenient keys that are easy to hit, rather than whatever contortions you'd need to do to hit Ctrl-Shift-F12.

The strong sense I got from reading this is that they don't believe it's possible to safely do this sort of thing right now, and they want to warn people away from Perplexity etc. so they can avoid losing market share while also not launching a not-yet-ready product.

(The more interesting question will be whether they have any means to eventually make it safe. I'm pretty skeptical about it in the near term.)

I'm old enough to have been using Perl with CGI in the waning years of the old millennium. I loved it then, but it's not just hype cycles that caused people to move on to different solutions: Modern stuff is better in a bunch of very real ways.

That's a thing I've experienced, but not remotely at 80% levels.

Modern ChatGPT will (typically on its own; always if you instruct it to) provide inline links to back up its answers. You can click on those if it seems dubious or if it's important, or trust it if it seems reasonably true and/or doesn't matter much.

The fact that it provides those relevant links is what allows it to replace Google for a lot of purposes.

(For context, I've conducted hundreds of system design interviews and trained a dozen other people on how to do them at my company. Other interviewers may do things differently or care about other things, but I think what I'm saying here isn't too far off normal.)

I think three things about what you're saying:

1. The answers you're giving don't provide a lot of signal (the queue one being the exception). The question that's implicitly being asked is not just what you would choose, but why you would choose it. What factors would drive you to a particular decision? What are you thinking about when you provide an answer? You're not really verbalizing your considerations here.

A good interviewer will pry at you to get the signal they need to make a decision. So if you say that back-pressure isn't worth worrying about here, they'll ask you when it would be, and what you'd do in that situation. But not all interviewers are good interviewers, and sometimes they'll just say "I wasn't able to get much information out of the candidate" and the absence of a yes is a no. As an interviewee, you want to make the interviewer's job easy, not hard.

2. Even if the interviewer is good and does pry the information out of you, they're probably going to write down something like "the candidate was able to explain sensibly why they'd choose a particular technology, but it took a lot of prodding and prying to get the information out of them -- communications are a negative." As an interviewee, you want to communicate all the information your interviewer is looking for proactively, not grudgingly and reluctantly. (This is also true when you're not interviewing.)

3. I pretty much just disagree on that SQL/NoSQL answer. Team expertise is one factor, but those technologies have significant differences; depending on what you need to do, one of them might be way better than the other for a particular scenario. Your answer there is just going to get dinged for indicating that you don't have experience in enough scenarios to recognize this.