I do have this experience. I've used Claude Code (with Opus mostly), and then switched to opencode (mostly with Kimi 2.6) for my personal projects; it's based on a couple months of use.
Claude Code is better. But Opencode + kimi 2.6 is workable, which is big. For bare code writing, if you know what exactly you want, most popular models are fine (deepseek, kimi, etc), it feels more or less the same as anthropic models.
At the same time, Opus seems to understand my intent way better than e.g. deepseek. I need to be much more precise with my prompts when using deepseek - it often goes in a wrong direction if I'm lazy. This results in a workflow which feels quite a lot different from Claude Code.
Kimi is in between - for me it brings back "lazy prompting" workflow, and I can trust its plans more than deepseek. It enables a workflow similar to Claude Code, it's workable, but it is a bit worse everywhere. Smaller context, a bit more errors, decisions are a bit worse, recommendations are a bit worse, debugging capabilities are a bit worse, etc.
On the usage side, $100 Claude plan is a great value actually. On paper, per-token kimi is way cheaper, but Claude subscriptions are heavily subsidized - you get much more tokens than $100 can buy you. So, in the end, opencode + kimi vs claude code could be of a similar cost, for similar usage patterns. Deepseek can be cheaper, and it has insanely cheap cached tokens, but experience may vary - depending on your habits, you may need to adjust how you work, coming from claude code.
I'd say for side projects something like $10 Opencode Go plan + $10 of extra DeepSeek v4 credits (e.g. on OpenRouter) can be very workable.
* plugin for Logic Pro to A/B mix with reference tracks, with ai-based stem splitter (e.g. isolate vocals in ref track, and compare with your vocal track)
* plugin for Logic Pro to simulate how a mix will sound on my macbook and phone (I captured real impulse responses for that, sounds very close)
* an app for spaced repetition for guitar video lessons / their parts (no idea why platforms like truefire don’t have this feature)
* workout planning/tracking app
* an app to create impulse responses for acoustic guitar, to make it sound good live
It feels insincere and manipulative, especially when I don't know upfront if the content (music, video, text) is from another human being or from AI.
AI will become good enough to write songs better than humans; it's a matter of time. But it feels like someone tries to hack my mind, exploit my human instincts, it doesn't feel like genuine art the way it was for the whole human history - people expressing themselves, creating and sharing something beautiful with each other.
The end result is an automated personalized "enjoy" button, and this is sad.
To compute accuracy, you compare the moves which are made during the game with the best moves suggested by the engine. So, the engine will evaluate itself 100%, given its settings are the same during game and during evaluation.
You get 99.9something% when you evaluate one strong engine by using another strong engine (they're mostly aligned, but may disagree in small details), or when the engine configuration during the evaluation is different from the configuration used in a game (e.g. engine is given more time to think).
I think he/she is reacting mostly to this quote from the article, not to the main article topic:
> I have a good answer: my job is to double our value-add capacity over the next three years. Essentially, to double our output without increasing spending.
> You know what? With my XP plans and the XP coaches I’ve hired, it’s totally doable. I think I’m being kind of conservative, actually.
The URL parsing in httpx is rfc3986, which is not the same as WHATWG URL living standard.
rfc3986 may reject URLs which browsers accept, or it can handle them in a different way. WHATWG URL living standard tries to put on paper the real browser behavior, so it's a much better standard if you need to parse URLs extracted from real-world web pages.
We need a better URL parser in Scrapy, for similar reasons. Speed and WHATWG standard compliance (i.e. do the same as web browsers) are the main things.
It's possible to get closer to WHATWG behavior by using urllib and some hacks. This is what https://github.com/scrapy/w3lib does, which Scrapy currently uses. But it's still not quite compliant.
Also, surprisingly, on some crawls URL parsing can take CPU amounts similar to HTML parsing.
Exit Through the Gift Shop - an amusing documentary about somebody trying to find Banksy (a street artist), and much more, supposingly directed by Banksy himself.
There is some debate if it is documentary or not (the story is almost too good), but it seems the evidence suggests it is real.
EDIT: sorry, I missed the "last 4 years" part in the question. This film is older than that.
But there is an issue if lru_cache is used on methods, like in the example given in the article:
1. When lru_cache is used on a method, `self` is used as a part of cache key. That's good, because there is a single cache for all instances, and using self as a part of the key allows not to share data between instances (it'd be incorrect in most cases).
2. But: because `self` is a part of a key, a reference to `self` is stored in the cache.
3. If there is a reference to Python object, it can't be deallocated. So, an instance can't be deallocated until the cache is deallocated (or the entry is expired) - if a lru_cache'd method is called at least once.
4. Cache itself is never deallocated (well, at least until the class is destroyed, probably at Python shutdown). So, instances are kept in memory, unless the cache is over the size limit, and all entries for this instance are purged.
I think there is a similar problem in the source code as well, e.g. https://github.com/Textualize/textual/blob/4d94df81e44b27fff... - a DirectoryTree instance won't be deallocated if its render_tree_label method is called, at least until new cache records push out all the references to this particular instance.
It may be important or not, depending on a situation, but it's good to be aware of this caveat. lru_cache is not a good fit for methods unfortunately.
Not sure about the autofocus advice; I'm pretty happy with manual focus. It requires static camera placement, and fixed distance to the person, but isn't this happening anyways? Are people really walking around the room or moving camera between calls?
Manual means there are less failure modes - slow autofocus, autofocus trying to refocus, focusing on a wrong thing, etc.
It also means the hardware can be cheaper - camera doesn't need to have good autofocus (some old DSLR is fine), you can also use manual lenses.
As I understand, the drivers (webcam utility? not sure) are built for x86. For some reason they don't work in apps which are built for M1, so the camera only works if an app which needs a video is running in emulation mode.
So, if you want to use Canon DSLR on M1 in a web browser (e.g. google meet), get a browser built for x86.
I'm using Chromium, it can be downloaded for x86. The issue is that Chromium doesn't have screen share feature. So, for screen share, I'm using Chrome, and joining the call for the second time, in "companion mode". That's 2 separate browsers to participate in a call. Maybe there is a way to get Chrome or Firefox for x86, but I was a bit too lazy when setting it up :)
Is it such a big issue? My Canon DSLR turns off every 30min, but that's only for a couple of seconds, it then turns back on. On a positive side, it's now easy to notice when 30min or 1hr meeting is running over, it's a nice reminder :)
That's interesting.. We're working on web data extraction in Zyte (former Scrapinghub); we have an Automatic Extraction product (https://docs.zyte.com/automatic-extraction-get-started.html) which combines ML and metadata to get data from websites automatically. Our learnings from building it:
1) metadata is helpful - not all of it, but some;
2) ML is obviously needed when metadata is missing, and metadata is missing very often;
2) Even when metadata is present, pure ML-based extraction often beats it in quality, with right ML models. A combination of ML+metadata fallbacks is even better.
Website creators often make mistakes providing metadata, they may misunderstand the schema and purpose of various fields, have metadata auto-generated incorrectly, etc. It is rarely about deceiving for the tasks we're working on (though it also may happen).
So, I don't see Zyte falling back to metadata analysis, ML models are already better than this human-provided metadata - but metadata is helpful, as one of the inputs.
We're going to publish product extraction benchmark soon, where, among other things, we compare automatic extraction with metadata-based extraction. In this evaluation we've got a result that ML + metadata is better than metadata not only overall (which is expected), but on precision as well.
I wonder if the reasons metadata is sometimes preferred are not related to quality, or to failure of ML approaches. If Google doesn't get data right, it is not Google's fault anymore, it is website's fault.
I'm unsure about the advice of sticking to 1440p at 27".
I have a non-retina imac 27 (1440p), external LG 27" 4K USB-C monitor and a macbook pro 13 with a real "retina", and use them all regularly.
For my eyes, scaling works fine with 4K - font rendering is significantly better than on 1440p imac.
13" screen on macbook pro is even better, and 5K 27" would be perfect, but that's a different price point. I'm quite happy with the improvement from 1440p => "4K with scaling" transition, and won't consider buying 1440p in future.
Scaled 4K may be not the best for high precision design work, but for development tasks / text reading that's an improvement, in my experience.
My son (4.5yo) became a huge fan of Moomin tales recently. Books, audio books, cartoons; he likes them more than super heroes these days. These tales are not only nostalgia material fo adults, these are still great children stories.
I wouldn't consider a high number of open issues a problem on its own. All big popular projects with a history have a high number of open issues. There are some exceptions, who may be closing isses aggressvely, but it is more about a style of managing of those issues, not about project health.
Over time an issue tracker inevitably becomes a collection of hard-to-reproduce bugs, incomplete patches, underspecified feature requests, random tracebacks, etc. Maintainers can choose to just close everything which is not actionable immediately, or be in comfort with such issues, and let them live in the bug tracker. I personally like a style when an issue is closed only if it is fixed, or if it doesn't contain useful information, or if it is a duplicate.
A better indicator is activity and responsiveness of the maintainers in the issue tracker.