kmike84

omlx is quite similar to LM Studio, so there are "options like LM Studio" which are open source

You care if you run it on a laptop. It's getting hot, fans are spinning, and you may want to use laptop for other things while the agent is working.

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.

Go for it! It's very satisfying :)

* 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

I'm not sure I want AI to touch me emotionally.

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.

whereas the best engines average 99.something%?

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.

TBH, this part felt off to me as well.

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.

A great initiative!

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.

Ada / can_ada look very promising!

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.

No.

The advice to use lru_cache is good.

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.

Hm, I haven't noticed any increased latency when using a DSLR as a webcam.

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.

The approach is very different from Dragnet. AutoExtract uses neural networks. CSS and HTML can only get you so far; we actually process screenshots as pixels (like humans do), it is not just shallow features like in Dragnet.

Speed of the AutoExtract ML part is not a concern (many pages per second on GPU) - the bottleneck is in the browser rendering.

Firefox Reader View uses https://github.com/mozilla/readability; if I'm not mistaken, it should be an algorithm which is similar to the one implemented in python-readability.

Not sure about fulltime career, and also about your current life circumstances; the best way may depend a lot on them. This is what worked for me:

1. University, some time after it. No much obligations. Take low-effort job to sustain yourself (maybe freelance), spend the rest of the time contributing to open source. Treat it as a time to learn. The main goal is to become good. You can learn very different things by contributing to OSS packages, as compared to working for some outdated local company. Try to internalize how popular software is organized, how people review code, etc. Find people you respect, work with them. You don't need to have a shiny CV and pass technical interviews to work with great people you can learn from, developing great real-world technology, solving hard problems.

2. You need a real job. Try to find one which allows you to spend some time doing Open Source; have it as an important criteria for choosing a job, among salary, work environment, etc.

For me two types of companies worked as a "real job" which allows OSS contributions.

First, some small startups / companies. They often don't mind if you open source a few libraries from the codebase you've created, because usually it is not the code itself which is important for startups; they're trying to find product-market fit. For them a benefit is that code become organized better (after an idea fails, code can be reused for the next idea), and developers are happier, so it can be win-win. You won't be working on open source full time, but you'll be able to create something useful, and spend significant amount of time on it.

Second, there are companies which are built around open source, or contributing a lot to open source. Often there is a company behind a popular OSS software (e.g. Elasticsearch for Elasticsearch, or Scrapinghub for Scrapy). Sometimes company's github has many actively developing OSS projects, which is a good sign. Look for such companies, apply. There is a higher chance to be able to work on open source if you join such company. It is not given you'll be allocated to work on OSS, but a previous experience maintaining Open Source and contributing to it helps. That's good to be proactive here - use your experience gained from unpaid OSS work or small startup OSS work, start contributing without being asked.

According to my experience, working full time, having family and having significant Open Source contributions is very hard, unless an employer supports it, or unless the job is not really a full time job.

There are "rockstars" which are able to sustain themselves just by working on their own OSS projects, but I think currently they are outliers, not a norm. It may be possible to do this, but I've personally seen way more opportunities to do sustainable OSS work as a part of day job, as compared to donations or a new business.

The API is quite simple - you need to implement a script which takes 3 arguments, writes a result of a merge to a file, and exits with non-zero status code in case of merge error. Quote from https://git-scm.com/docs/gitattributes#_defining_a_custom_me...:

To define a custom merge driver filfre, add a section to your $GIT_DIR/config file (or $HOME/.gitconfig file) like this

  [merge "filfre"]
    name = feel-free merge driver
    driver = filfre %O %A %B %L %P
    recursive = binary

The merge.?.driver variable’s value is used to construct a command to run to merge ancestor’s version (%O), current version (%A) and the other branches' version (%B). These three tokens are replaced with the names of temporary files that hold the contents of these versions when the command line is built. Additionally, %L will be replaced with the conflict marker size (see below).

The merge driver is expected to leave the result of the merge in the file named with %A by overwriting it, and exit with zero status if it managed to merge them cleanly, or non-zero if there were conflicts.

We looked into it, but it seems to be solving a different problem - how to handle large data. Does it solve merging of structured data?

E.g. a json file is chanaged on 2 machines, and you need to merge the changes. Sometimes you can merge (e.g. 2 different entries in an array where people are adding annotations), sometimes you need to raise an error - e.g. changes in a single record, but for different fields - depending on a problem, you may disallow it, to keep the record consistent.

We needed to solve a similar problem - version control & synchronize .json files from different machines (annotations for ML models).

Writing a custom git merge driver was quite painless - a cmdline script (written in Python), which has task-specific logic on how to merge data from these .json files. Load these files, parse them, decide how to combine, detect unresolvable conflicts, etc.

It seems one may need custom logic to merge structured data, there is not a single best solution. This could make creation of a generic tool harder.

git is not a bad base technology for this. I'm not sure what other things are we missing (e.g. better diffs for structured data?), because .json is still text; it is just merges which are unreliable if you treat .json as text. There are also caveats - e.g. you can't install a custom merge driver on github, so "merge" button becomes dangerous. But overall for .json this approach works fine.

A data point: I've been involved in Open Source for 10+ years, developing projects myself, helping to maintain very popular projects, contributing, and I don't see a trend like this. I've interacted with hundreds of people over the years, and the vibes are overwhelmingly positive; I haven't noticed any hatred or rudeness towards myself. I can't think of a single time interaction with OSS people afected me negatively, but there were a lot of positive (or neutral) interactions.

Over time projects I'm contributing to were changing, and so I was exposed to several different communities (Python web development, data science, web scraping), and all of them turn out to be awesome. Maybe that's just luck, but not all OSS maintainers have it hard - no idea why :)

+1 to recharge the batteries!

Regarding "very simple" - as I recall from some book, first bug-free implementation appeared only after several years after invention / initial description of the algorithm. From wikipedia: "A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks" (https://en.wikipedia.org/wiki/Binary_search_algorithm).

The blog post mentions WHATWG URL spec and RFC 3986 - what is libcurl's URL parser implementing, what is its goal?

By the way, parsing of URLs is a large-ish task; it'd be nice to have URL API in a separate library, which libcurl depends on, and which can be used without libcurl.