pxc

I use Linux VMs on macOS mostly headless via OrbStack. If it was convenient to run an individual window from the GUI in a way that felt native and performed well, I might run Emacs and Firefox from Linux instead of on the macOS side. Then I could manage them more via NixOS mechanisms instead of the janky options available on macOS. Plus in the case of Emacs, filesystem performance is still way, way better on Linux for some common tools. Git and Magit just perform massively better.

Go to an adblock test page in Chrome and compare it to Firefox with uBlock Origin. Chrome can't block some ads, and some of the ads it can block leaves behind empty containers.

That's a really interesting point about Ancient Chinese and other ancient scripts. I'd love to learn more about that.

I'm also more curious about tokenizers for LLMs than I've ever been before, both for Chinese and English. I feel like to understand I'll need to look at some concrete examples, since sometimes tokenization can be per word or per character or sometimes chunks that are in between.

Does this affect editor integrations that use the SDK for ACP support via claude-agent-acp¹, like Zed's Claude integration and Emacs' agent-shell?

--

https://github.com/agentclientprotocol/claude-agent-acp/rele...

> Are you saying Chinese is more concise than English?

Yeah, definitely. It lacks case and verb conjugations, plus whole classes of filler words, and words themselves are on average substantially shorter. If you listen to or read a hyper-literal transliteration of Chinese speech into English (you can find fun videos of this on Chinese social media), it even resembles "caveman speech" for those reasons.

If you look at translated texts and compare the English versions to the Chinese ones, the Chinese versions are substantially shorter. Same if you compare localization strings in your favorite open-source project.

It's also part of why Chinese apps are so information-dense, and why localizing to other languages often requires reorganizing the layout itself— languages like English just aren't as information-dense, pixel for pixel.

The difference is especially profound for vernacular Chinese, which is why Chinese people often note that text which "has a machine translation flavor" is over-specified and gratuitously prolix.

Maybe some of this washes out in LLMs due to tokenization differences. But Chinese texts are typically shorter than English texts and it extends to prose as well as poetry.

But yeah this is standard stuff: Chinese is more concise and more contextual/ambiguous. More semantic work is allocated in interpretation than with English, less is allocated in the writing/speaking.

Do you speak Chinese and experience the differences between Chinese and English differently? I'm a native English speaker and only a beginner in Chinese but I've formed these views in discussion with Chinese people who know some English as well.

I was pretty interested until I got to this part:

> Another reason that a no-exceptions policy is important: If students with disabilities are permitted to use laptops and AI, a significant percentage of other students will most likely find a way to get the same allowances, rendering the ban useless. I witnessed this time and again when I was a professor—students without disabilities finding ways to use disability accommodations for their own benefit. Professors I know who are still in the classroom have told me that this remains a serious problem.

This would be a huge problem for students with severe and uncorrectable visual impairments. People with degenerative eye diseases already have to relearn how to do every single thing in their life over and over and over. What works for them today will inevitably fail, and they have to start over.

But physical impairments like this are also difficult to fake and easy to discern accurately. It's already the case that disability services at many universities only grants you accommodations that have something to do with your actual condition.

There are also some things that are just difficult to accommodate without technology. For instance, my sister physically cannot read paper. Paper is not capable of contrast ratios that work for her. The only things she can even sometimes read are OLED screens in dark mode, with absolutely black backgrounds; she requires an extremely high contrast ratio. She doesn't know braille (which most blind people don't, these days) because she was not blind as a little girl.

Committed cheaters will be able to cheat anyway; contemporary AI is great at OCR. You'll successfully punish honest disabled people with a policy like this but you won't stop serious cheaters.

If this is true, shouldn't LLMs perform way worse when working in Chinese than in English? Seems like an easy thing to study since there are so many Chinese LLMs that can work in both Cbinese and English.

Do LLMs generally perform better in verbose languages than they do in concise ones?

Maybe it should be treated like on-call duty and have the load spread between existing engineers on some kind of schedule, maybe with some extra comp as incentive because it's boring and will take more effort/time in the "easy case" compared to pager duty.

Humans just don't commit the same kinds of booboos as LLMs do. My team at work recently started using LLM agents for coding and I have since seen WTFs that I know no human would ever write.

It's not all bad! It's also enormously fun. I've been able to work on things I'd been putting off forever. When I can use LLM agents, I less often feel paralyzed by perfectionism, which is probably the biggest productivity boost I get. My own code has not decreased in quality, and I think that for the truly important things, neither has that of my colleagues.

But LLMs don't make junior dev mistakes. They make "my brain has worms in it" mistakes.

Some editor integrations are a bit like this already, where during use you don't actually touch the built-in TUI even for prompting or viewing the output and approving permissions requests.

I imagine how they treat these things will be contextual and maybe inconsistent. There aren't really hard lines between what they probably want editors that integrate with them to do and generic tools that try to sit a layer above the vendors' agent TUIs.

And you can also use the long context version on their cheaper plans, where as with Anthropic it's only available to enterprise and Max customers

I feel the same way about Cisco Umbrella where I work.

The worst breakage by far is protocol breakage; basically anything that uses HTTP as a basis for building some other protocol gets broken all the time. None of the people implementing it seem aware. They buy the vendor's claim that it's "transparent", when in fact even "inspect/trace-only" modes often break all kinds of shit.

I've seen Umbrella break:

  - Git
  - RubyGems
  - `go mod`
  - OrbStack
  - Matrix
  - Cargo
  - all JDKs
  - Nix
  - Pkgsrc
  - all VMs

and probably some other things I'm forgetting. When this breakage is reported, the first round of replies is typically "I visited that domain in my enterprise-managed browser and it's not blocked". That is, of course, a useless and irrelevant test.

Often it takes hours to even fully diagnose the breakage with enough confidence to point the finger at that tool and not some other endpoint security tool.

I'm not sure if the people buying and deploying tools in this category don't know how much stuff it breaks or just don't care. But the breakage is everywhere and nobody seems prepared for it.

If they pass what closed models today can do by much, they'll be "good enough" for what I want to do with them. I imagine that's true for many people.

If you're visually impaired, you can hit it even with just a few icons on a 14" laptop. Fonts anything other than tiny + overloaded menus + even a handful of app icons means I always hit this unless I'm docked.

Hacky menu bar modification tools are basically an accessibility requirement for me, and my vision isn't even that bad. (Best corrected is 20/30 or 20/40 or so.) People with serious impairments are totally screwed by this on macOS, sometimes even with large external monitors.

It's striking to me that while the article argues that LLMs and agentic development tools will increasingly trend towards higher and higher quality, but the "pro-AI" comments in this discussion and others tend to announce a "quality doesn't matter" camp.

I'm only beginning to use "agentic" LLM tools atm because we finally gained access to them at work, and the rest of my team seems really excited about using them.

But for me at least, a tool like Git seems pretty essential for inspecting changes and deciding which to keep, which to reroll, and which to rewrite. (I'm not particularly attached to Git but an interface like Magit and a nice CLI for inspecting and manipulating history seem important to me.)

What are you imagining VCS software doing differently that might play nicer with LLM agents?

You can disclose that you used an LLM in the process of writing code in other ways, though. You can just tell people, you can mention it in the PR, you can mention it in a ticket, etc.

F-Droid is in fact what an app store concerned about user safety looks like. Nobody gets hoodwinked into installing apps that track them or sell their data or otherwise abuse them on F-Droid.

I used WINE a lot in the 2000s, mostly for gaming. It was often pretty usable, but you often needed some hacky patches not suitable for inclusion in mainline. I played back then with Cedega and later CrossOver Games, but the games I played the most also had Mac ports so they had working OpenGL renderers.

My first memorable foray into Linux packaging was creating proper Ubuntu packages for builds of WINE that carried compatibility and performance patches for running Warcraft III and World of Warcraft.

Nowadays Proton is the distribution that includes such hacks where necessary, and there are lots of good options for managing per-game WINEPREFIXes including Wine itself. A lot of the UX around it has improved, and DirectX support has gotten really, really good.

But for me at least, WINE was genuinely useful as well as technically impressive even back then.

Less charitably, pacman is fast because it's wrong. The dependency resolver is wrong; it fails to find correct answers to dependency resolution problems even when correct answers are available.

I would guess this change builds on the existing json endpoints for package metadata but that the Ruby DSL is remaining intact.

I think how to marry the Ruby formulas and a Rust frontend is something the Homebrew devs can figure out and I'm interested to see where it goes, but I don't really care whether Ruby "goes away" from Homebrew in the end or not. It's a lovely language, so if they can keep it for their DSL but improve client performance I think that's great.

It is really coll that Homebrew provides a comprehensive enough JSON API to let people build on Homebrew in useful ways without directly running Ruby, despite everything being built in a Ruby DSL. That really does seem like a "best of both worlds" deal, and it's cool that alternative clients can take advantage of that.

I didn't know about the pending, official Rust frontend! That's very interesting.

If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.

I've been looking for something like this, especially to use only with casks now that Homebrew has removed support for not adding the quarantine bit. Looking forward to giving it a try!

My hypothesis is that generally, there's no quality floor at which security departments are "allowed" to say "actually, none of the options on the market in this category are good enough; we're not going to use any of them". The norm is to reflexively accept extreme invasiveness and always say yes to adding more software to the pile. When these norms run deeply enough in a department, it's effectively institutionally incapable of avoiding shitty security software.

Fwiw w/r/t Trivy in particular,I don't think Trivy is bad software and I use it at work. We're unaffected by this breach because we use Nix to provide our code scanning tools and we write our own Actions workflows. Our Trivy version is pinned by Nix and periodically updated manually, so we've skipped these bad releases.

The main problem I raised with the Gaokao isn't that it's biased, but that it has negative effects on the way education is conducted prior to university.

It's not difficult to find first-hand accounts of this; go browse social media posts by teachers in mainland China if you're curious.

There are similar problems of "teaching to the test" in other contexts, too.

I'm not categorically opposed to standardized testing and I never said I was.

The question is what you're measuring. You can have a test that gives you whatever distribution of scores you like. But is the thing it measures competency in the subjects it tests, general intellectual ability, familiarity with the test format, etc.? The worst negative outcome is usually subordination of learning itself to preparing for the exam, which can happen even when the gatekeeping function of an exam still works perfectly.

Chinese education is also extremely constrained by the practice of "teaching to the test" to the point that the Gaokao indirectly stands in the way of innovation and reform in education. Schools doing interesting things to improve the quality of education are historically not very competitive on the Gaokao anyway (e.g., some unusual rural schools where students historically have bad prospects anyway and parents are overburdened or indifferent) or explicitly trying to carve something out outside the college track (e.g., private tech/entrepreneurship schools created by big tech companies).

There may be some good things about the Gaokao but having spoken to some (Chinese) teachers in China, it's also a limiting factor for education prior to university in a lot of ways, limiting the freedom of teachers and driving up risk aversion in parents.

(It's also effectively graded on a regional curve, which might be a good thing but isn't meritocratic in the straightforward way you suggest.)

Are the Linux graphics drivers actually worse, though? I thought it was widely agreed that the open-source user-space drivers, e.g., in Mesa, are actually very good these days.

Idk how anyone could sustain the impression that pip was not broken unless they had basically never used anything else (including Linux package managers) long enough to have even a basic understanding of it.

And that's a big part of what's so frustrating about Python generally: it seems to be a language used by lots of people who've never used anything else and have an attitude like "why would I ever try anything else"?

Python has a culture where nominal values of user-friendliness, pragmatism, and simplicity often turn into plain old philistinism.