jchw

I am not home at the moment but I believe the setup I got working was the Club 3D CAC-1080 Display Port to HDMI adapter. The trick, as I understand it, is that these adapters support tunneling the CEC traffic to/from Display Port AUX, and many of the Linux DRM drivers support this. It has been a while since I actually set it up, but I don't remember it being particularly hard. I have a couple different adapters that theoretically support CEC I believe but that's the one I recall working.

As for remote control - why would you want one for the monitor.

It certainly isn't strictly necessary, but it remains useful for input switching, and as a convenient backup option for power/volume. In the presence of a good fullscreen UI, I could see it being useful for basic directional input as well.

You can of course go the other way and handle input switching and all else via the PC, but that does mean if the PC isn't on nothing else works at all.

Is this person trustworthy? I struggle to believe that in the relatively short time Fable was available it has already been distilled so effectively. If this really is actually true, very impressive work.

I've seen this phrase repeated over and over again and I don't think it is true, or at least, to the degree that "benchmaxxing" claims are true, American frontier AI companies are probably about as guilty of it as Chinese AI companies are.

For both GLM 5.2 and Kimi K3 I feel the rough average of the benchmarks gives you a rough idea where they stand. GLM 5.2 was sitting somewhere behind Opus 4.8 but it didn't feel very far away. I've used Kimi K3 via OpenRouter and while I've had limited experience so far, it sure as shit feels like it's right up there with Sol and Fable to me. I am happily able to believe Fable has the edge still, but on a request by request basis it would be pretty easy to get an impression one way or another.

The existing Kimi models were already pretty good so I really just don't find this new model to be that hard to believe. Maybe I'm naive.

None of my TVs are connected to the Internet. That said, I could really do with a better open source fullscreen UI, especially since I mainly just want a web browser that works good. I'm just using KDE Plasma with a custom daemon to control the TV power state over an HDMI CEC adapter plus an old K830 keyboard.

I'm, frankly, a bit annoyed by this whole thing; I'd rather have USB adapter RF wireless because it is simpler to deal with vs Bluetooth, but actually I can't even find other Bluetooth keyboards that are as compelling as this K830 and worse yet, they don't even make the K830 anymore. I don't really mind KDE Plasma with just some minor customizations but I don't really like any of the options like Kodi. Maybe Plasma BigScreen will eventually be what I want for that. And finally, HDMI CEC is a pain in the ass. For reasons, I actually use an adapter to get CEC support on a normal PC platform, because most PC HDMI ports can't do it. And also, it's just a bizarre and overly complicated thing. I have it working reliably, but it took some time to iron out all the kinks, particularly because my TV responds quite differently depending on how recently it was powered off.

I really just want a big monitor and to basically just use DPMS... Like a computer does, but large computer monitors tend to be expensive and don't always have remote controls, which admittedly are handy.

I don't think the TLS negotiation will become meaningfully slower, as there are multiple threads being pulled on for how to make post quantum happen here with minimal regression, instead it will likely become meaningfully more complex and only slightly slower, continuing a trend that has been ratcheting for quite some time now. ECH and modern certificate revocation checking schemes are also contributing to this.

The increase in complexity is a huge problem. It is arguably justifiable but simultaneously concerning. It's already quite hard to make a correct TLS implementation as it is.

(Personally though, I still like post quantum encryption. It's a nice hedge in case ECC and/or RSA do fall any time soon, whether by quantum computer or simply math.)

Yes. But subjective testing by IgorC ( of HydrogenAudio ) shows it wasn't as good as Apple. It was a lot better than previous FFMPEG though. I believe we will have a few more listening test results coming out soon.

I am not claiming that objective tests are the only tests that matter, but I am guessing Lynne tweaked the codec to win in both objective measures and Lynne's own subjective tests. I don't think tweaking it to do better on more subjective tests would be impossible though, just needs more work, probably. What I'm saying is, at least as far as CBR goes, I think FFmpeg's new NMR encoder is likely going to be the best soon if it isn't already.

There is the question of VBR still, though.

iPod has over 80%+ of portable music players market share. And almost all the others shipped at the time, from Creative to other Chinese brands, car audio, TV and media player has AAC support. AAC-LC hit a sweet spot of near same MP3 hardware support while being so much better. 320Kbps MP3 still don't compete with 256Kbps AAC-LC on Apple Encoder. On the other hand, there are only a few samples where 256Kbps AAC-LC isn't transparent, barely noticeable difference but no artefacts compared to Opus in professional listening test, 95% of people wouldn't even notice. Opus do shines at 128Kbps to 160Kbps range where AAC-LC don't compete ( or dare I say wasn't even tuned ), but loses nearly all hardware compatibility.

Please note that I was talking about deploying Opus vs deploying AAC-LC, not whether you encode your personal collection to AAC-LC vs Opus or something like that. (My personal audio collection is mostly FLAC and gets Opus-transcoded on-the-fly.) I brought up my Sansa Clip+ not because PMPs are still relevant - let's be honest, they're not really relevant for anyone but us nerds - but just because it's an example of a device I personally owned that really doesn't support AAC-LC.

Still, a lot of old iPods can easily decode Opus if you run Rockbox on them as far as I know, so it's not like it isn't an option if you're a fan of PMPs still, which is pretty cool since they can be had for relatively cheap depending on what direction you go.

If we were streaming, and storing music or audio tracks with 128Kbps then Opus would have had strong advantage. But we live in a world where we could even stream uncompressed audio files with plenty of bandwidth left. The file size of audio is so small it makes it negligible in consumer settings unless you are Youtube. ( I would still prefer a 256Kbps audio codec, for me it was instantly noticeable. I think Youtube at one point switched for premium but decided to switch it back )

For web then I guess there is an argument for Opus. But I keep saying the same with Video Codec as well. There is a whole world of Video and Audio Codec usage outside the web and PC / Smartphone. We could have used AAC and called it a day. And it is not just patent unencumbered, it is patent free.

The argument for Opus in streaming is still strong on its own. If we pit 128kbps Opus against 256kbps AAC-LC, that's obviously a 50% reduction in bandwidth for similar quality.

Does it matter if we have so much bandwidth to spare? In my opinion, definitely. For people using metered data connections, which are quite common for mobile connections in the U.S., you can fit twice as much 128kbps Opus in your spare bandwidth versus 256kbps AAC-LC - around 1 megabyte every minute versus 2. The cheapest Google Fi plan has 15 GB of bandwidth per month - if you did nothing but listen to audio, I reckon that'd give you around 4 hours a day of 256kbps audio versus 8 hours a day of 128kbps audio. Since most people do more than just listen to audio, the actual difference this makes when data limit constrained is much bigger.

Does it matter if video bitrate trumps audio anyways? Yes, still. Consider the provider end of things. Obviously, YouTube isn't serving 256kbps AAC-LC, but if they were serving 256kbps AAC-LC to everyone, then assuming they have around 4 million people streaming YouTube at any given time, they would wind up saving at least over 100 petabytes of bandwidth per month. Which is probably not a huge amount relatively speaking, but it definitely would be worth doing. In actual reality, YouTube just simply won't serve 256kbps audio to everyone because it wouldn't make sense, so Opus just enables us to get quality we weren't going to get before. Similar calculus either way, though.

Why Opus and not AV1 then? Well, I think Opus and AV1 should be adopted especially where bandwidth is a question. YouTube, Netflix, really any big provider is going to want to adopt both. AV1 offers a similar magnitude of efficiency improvement over H.264 as Opus over AAC-LC. However, the great thing about Opus is that it is just super cheap to decode, so there are limited circumstances where we're limited by compute; the only cases where it would be relevant are in fact fixed function devices. AV1 and video in general is just a lot more computationally expensive to decode, so not having hardware acceleration would be a serious impediment, and even on the Internet, AV1 support is supposedly significantly less pervasive than Opus support, so you would need to fall back for a much larger percentage of users.

So the tradeoff calculus is different, IMO, for deploying AV1 and Opus. For deploying Opus, you will need to fall back for a very small percentage of users, and doing so is relatively inexpensive because you can literally just ship a software codec. For deploying AV1, you will need to fall back for more users and shipping a software codec isn't a serious option. Which leaves some potential reasoning for people to just stick to H.264 out of sheer simplicity, in spite of the efficiency cost.

The way I see it, if you were to draw two graph lines showing the prevalence of H.262 and H.264 over time, it would show of course that H.262 has lasted much longer so far just by virtue of it being older yet still in active use, but the area under the H.264 line is probably already or tracking on being much larger, depending on many factors, such as how you quantify "prevalence".

I don't see H.262 as becoming completely irrelevant any time soon, so it's clearly had a hell of a run, but I expect H.264 to wind up having a similarly long tail. I am not sure I'd bet on it being longer, but I wouldn't bet against it either. I'm only of the opinion that H.264 will have one of the longest of any video codec, but perhaps not the longest.

I was under the impression that the new FFmpeg nmr codec indeed outperforms the Apple one in every bitrate with Google's new Zimtohrli benchmark as well as ViSQOL. That would suggest Apple doesn't really have to open source anything, we should be good?

Still, I don't see the point. Unlike video, audio decoding is so cheap you can practically do it on software even on fairly constrained devices. So really only in places like Bluetooth headphones where codec complexity can have a direct impact on battery life does it actually factor in. I say for most purposes people should just be going Opus today: it is far ahead of basically anything else. In most cases, for old devices you can simply ship software codecs instead.

Hell, Wikipedia ships video software codecs in the form of ogv.js, mainly because a lot of Apple devices wouldn't expose VP8/VP9 support even on SoCs that had hardware support for it, and that works surprisingly well. So for something like Opus, obviously it is trivial even on older hardware, even in the confines of a web browser. (And of course, Wikipedia uses it for Opus as well, but my understanding is this is only necessary for 1-2% of Internet traffic since most devices/browsers support Opus these days)

That may leave some niches where AAC-LC is still a reasonable choice, like maybe old PMPs. However, I reckon that there are probably a lot of older PMPs that in fact, don't natively support AAC. For example, the trusty Sansa Clip+ from 2009 doesn't have AAC support. If you were to install third-party software such as Rockbox, well, then you'd have Opus support.

So for audio, I think barring any specific reason not to, the meta is to basically always choose Opus.

Yknow, I really didn't mind Claude Code that badly, but subjectively speaking I really do like Codex more after using it for a couple weeks. Feels a bit snappier and lighter weight. I know with OpenAI you can actually use third party tools with the subscription so there's less of a draw to using Codex, but I still find myself preferring it now.

Is this because Codex is written in Rust and not JS? I dunno. I think it's more just "lighter" in general, or it certainly feels that way. It's probably possible to make something with a similar feel in JS, just perhaps not with the big honking mess they've created.

I would hope so! Otherwise the Pareto front wouldn't have moved in ~20 years which would be rather hard to believe.

However, at the same time, h265, h266 and AV1 are all vastly more complicated, and will have less broad hardware acceleration support than h264, which, again, even if it is not optimally efficient use of compute, just doesn't require a whole lot by modern standards.

So I'd argue there is really no reason to be rushing away from h264 unless you have a compelling reason. There are some obvious compelling reasons in some cases; nobody is going to be terribly surprised that an entity like Netflix is eager to switch to codecs that will save bandwidth, because at their scale saving bytes definitely adds up, bonus points if it can increase the quality at the same time.

On the other hand, though, unless you are absolutely sure you can switch to only new codecs, you will probably want to keep some h264 encodings around to act as a fallback baseline for legacy devices. And thus, you also have to take into account the complexity brought on by needing to store and maintain multiple encodings - in many use cases, like simple <video>s thrown into website backgrounds, I can see just eating the extra bandwidth costs and keeping it all h264 as a valid strategy.

Yeah. I think h264 is coming soon, too, though. Most of the remaining known h264 patents expire next year, with only one patent extending out further.

I do believe that more modern codecs like h265 and AV1 have a lot to offer us, but having h264 be fully unencumbered by patents will be nice. By modern standards it is very well-supported in both hardware and software, computationally cheap to encode and decode, and still does a good enough job for most use cases. h264 doesn't seem like it will be displaced any time soon to the degree that h264 once displaced its own predecessors, though obviously that's not to say that we don't see or won't see more adoption of newer video codecs across the internet in general, just that I think the h264 long tail will be one of the longest long tails of a video codec.

And thanks to the availability of codecs like AV1 which are effectively not patent encumbered (seems there is no practical reason to take the threats otherwise seriously) it seems the era of patent encumbered media formats is slowly coming to a close. Good riddance.

edit: Bit of a mess but here is some source for the h264 expiration.

https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...

So it seems 2030-11-10 is the date where h264 (version 3) will become patent unencumbered world wide, a bit earlier for the U.S. The other profiles/newer versions like AVC/SVC will take a while longer.

Sure, when it comes to the big corporations I don't deny CCP's influence on their strategy. Hell, in some cases, it's easy to root for their strategy, because sometimes our tech industry sucks. Don't have to love them to occasionally agree with them.

But, in terms of individuals, of course, we're really not so different.

Well of course nobody believes that, there are a large number of great Chinese open source projects, and plenty of great Chinese contributors to open source projects. I have zero doubts that Chinese people are at least equally as capable of embracing open source as anyone else. It would be strange to suggest otherwise.

That said, though, I do have trouble believing the long-term story for open weights, anywhere. We do not need an evil government for open weight to "make sense", but I do think we need some government involvement for open weight to make sense in the long run. Otherwise, it's not 100% clear how they could be sustainable, and I don't think massive companies really can be trusted to just be philanthropic with no incentives indefinitely (or really, much at all to begin with.)

Chinese models being open weight does help them gain some Western mindshare, whereas for obvious reasons Americans would be very suspicious of running their source code and prompts through Chinese providers. (And I think that's justified, I just also think that American providers aren't really that much better in the long run, and you should prefer to not have to go through any provider for true privacy.)

Ubuntu does include it, since 24.10, but Ubuntu 24.04 doesn't. It just barely predates (an ABI stable release of) SDL3. Now that 26.04 is out, it won't take too much longer for that reason to hold off on SDL3 to disappear, but I think we'll at least have to wait until Pop!_OS rebases before it is a completely done deal.

And yeah, in the meantime, I have just been using CMake's FetchContent system for SDL3. With improvements on both CMake's end and SDL's own build system, it is quite seamless. I still wish it was a bit more elegant but I'll take "easy".

Yes, but also it depends.

For Windows and macOS, it is just a flat "yes", since obviously in that case SDL isn't a system library.

If you're installing a game on Linux via Steam or Flatpak it isn't going to use system SDL in any case. Minecraft would probably ship a binary for use with JNI as is customary.

However, when running games outside of Steam or Flatpak, especially open source games but certainly even outside of open source, it is not uncommon to use packages that adapt the game for your OS, like AUR packages or Nixpkgs derivations. And in that case, you'll likely get system SDL. This would be the tendency for emulators, games that are open source like ioquake, and so on.

Even in a case where SDL2 is statically linked, it is still possible to attempt to load SDL3 by pointing SDL_DYNAMIC_API to a copy of sdl2-compat.

I don't know what Steam does here, but I think it doesn't matter. A large amount of the commercial games you wind up playing under Linux are running under Proton anyway at which point the SDL version makes little difference if it is used at all. So I think it is still likely to see a lot of SDL stuff silently upgraded to SDL3 on Linux, though yes there are caveats to that.

Edit: Also, I wanted to make an additional note: the Ubuntu 24.04 note is still relevant even in the face of most games shipping their own SDL3. The reason for this is simple, I think to this day a lot of people (myself included) use Ubuntu 24.04 as a sort of general Linux build platform for building binaries that work pretty much anywhere. What you wind up having to do if you want SDL3 to work there is to build it, either via your build system (not so bad to do, either via vcpkg or via CMake subprojects) or just outside the program's build process altogether. It's not asking too much, especially since SDL3 compiles very quickly relative to a lot of other software, but still, it adds some complexity that you don't get when just building with and linking to SDL2 where you can install the dev files and binaries directly with apt-get.

Edit 2: It seems Steam is using both SDL_DYNAMIC_API and sdl2-compat as of Steam Linux Runtime 4, according to Google's AI overview. Take it with a grain of salt, as I didn't feel it warranted a deep investigation, but this suggests to me you're quite likely to encounter SDL3 within Steam (for native Linux games) regardless of what the game ships.

On Linux, often times you will be using SDL3 regardless, as sdl2-compat and sdl12-compat are the default implementations of SDL2 and 1.2 on some distros. This has a lot of benefits, from more apps working natively on Wayland (which gives lower latency than XWayland) to better controller support. Not sure what this meant for osu but I wouldn't be surprised if it made the actual switch less impactful for some users.

I was, however, somewhat surprised to learn Ubuntu 24.04 didn't even ship SDL3 to begin with. Turns out SDL3 is newer than I remember. This is likely part of the explanation why SDL3 adoption is lower than expected.

I can't deny this is true, but it hasn't made me hate my job. More than anything, I'm trying to figure out how to thrive in a very different environment. I've definitely realized that sitting there and handcrafting my code to try to make it perfect isn't what my employer is going to want; they want a balanced trade-off. So, I need to find a good split in the middle where I can still add value by using my experience and skills to shape good quality, maintainable code, but I also am trying to use LLMs in places where they are doing a good job. The quality of the generated code, sans the unbelievably bad English prose, has gone up a fair bit, making me wince a bit less about it.

But, the sentiment about drowning in slop, well. Yeah kind of. I am not sure the polite way to tell people they should be thinking for themselves rather than just repeating what an LLM told them.

I absolutely use LLMs to assist in reviewing my own code as well as others, but I am always using my own judgment and speaking in my own voice. I will never copy-paste an LLM comment as if I wrote it, and I don't think even with a proper disclaimer that I'll ever copy-paste an LLM comment that I don't understand enough to confirm and rephrase on my own - instead, I use the LLM insights as a starting point. If I don't understand them, I dig deeper. If I disagree with the comment, I disregard it. And finally, if I understand it fully and agree with it, then I bring it up in code review, in my own voice.

I'm a little more lax when it comes to LLM generated code. A lot of test suites are already kind of a bit pointless thanks to the flawed prioritization of code coverage as a metric (it isn't a bad one generally, but there are cases where it is tragically bad, like when the code you are testing is effectively a DSL and the assertions are restatements of the DSL's contents...) and even when it's not, LLMs are often useful for generating decent test suites. Still a good idea to read them, but I give LLM-generated tests less attention and manually exercising code more attention: it seems like a good tradeoff to get a productivity improvement from LLMs.

To me the biggest sin is using LLMs or generative AI and pretending it is your own human expression. Please use your own words. If that's too much effort, I'm afraid I don't really want you working where I work or posting where I post, just for the sake of everyone's sanity. All of your LLM-assisted blog posts read like absolute shit and I'm tired of all of the excuses for it.

Well first of all, any non-trivial use of LLMs is going to be orders of magnitude more tokens than this, usually multiple millions at minimum. Benchmarks are just benchmarks after all.

Secondly, humans vs LLMs are apples vs oranges. It makes no more sense to compare human costs vs LLM costs as it would have to compare human costs vs calculator costs. LLMs are faster and cheaper but extremely different beasts with different limitations. Humans do not one-shot SVGs of pelicans riding bicycles, and they do not charge in tokens.

Comparing LLM cost efficiency is not something that should need to be defended. It's quite straightforward and reasonable...

Monomorphized generics alone don't do it, but pervasive use of monomorphized generics definitely can make binaries huge and make compile times slow. Zig may avoid it generally, but C++ doesn't.

(Even Go's generics did slow down compile times a bit at first.)

Go's approach to generics is decent. It gets some of the benefits with some of the downsides. When coding in Rust, I am always so desperate for better compile times, especially for "clean" compilation because I make heavy use of Nix for various things and that comes into play a lot. (I don't run all of my builds in Nix, but I use Nix for virtual machine based integration testing for example, and that would involve doing a clean Nix build of the program.) So I guess while I get why some people were disappointed when Go didn't choose full monomorphization I appreciate their commitment to keeping fast compile times a priority. And it is certainly a hell of a lot nicer to be able to do proper generics at the language level on maps and slices in any case.

Uh, I would consider them to be highly related, they both ultimately come from the fact that LLMs are trained to respond in a favorable fashion to the end user, and they're both manipulative in nature.

I also object to the idea that model intelligence is the main reason why this has improved, either; to me it seems abundantly clear that the models, absent any effort to align them, can go pretty much any way you want them to go. They don't really have a "personality". Why would they? Even if we grant that next token predictors somehow gain "reasoning" capabilities (and I am saying sure, let's accept that for the sake of this discussion) I don't think anyone is suggesting that model weights somehow develop or contain a true identity or self. Given how they are trained it would be weird if they did.

I think the more obvious answer is that more work has gone into alignment and safeguards since the early days. Sycophancy is legitimately one of the things that AI companies talk about and try to stymie. If not for that, humans would obviously continue to prefer sycophantic models, and training that isn't weary of this would continue to produce them.

Meanwhile, a YouTuber may not care about you personally, but it's a very different situation. For one thing, a YouTuber obviously doesn't care about all of their viewers individually the way a parasocial fan may perceive it to be, but on the other hand, many creators very much do genuinely like their fan base and have a sort of collective relationship with the community they've created, which sometimes plays into why people like them in the first place. For another, even for creators who intentionally foster parasocial relationships in an exploitative way, its still a much less powerful illusion. It isn't personal the way a chatbot is. (If it was, it wouldn't be parasocial, after all.) As much as you can explain to people up and down that an AI model is just merely a pile of weights that can not feel, humans can't help but personify. It is a much stronger illusion.

And the model vendors are intentionally not helping. Sometimes I will ask Gemini a question about a problem I am working on and it will say something like "I love working on problems like these." Yeah sorry but I don't like that. To me, the model is being trained to act like this to seem more pleasant. I get why you would train it to act that way, and yet I also find it irresponsible.

Being deluded about reality may never be good but I'd prefer someone thought a YouTuber was like their friend than someone thought ChatGPT had feelings and cared about them. I find the former mostly harmless if annoying, the latter potentially harmless but also potentially very volatile depending on who we're talking about and what mental state they're in.

100% the latter. It is kinda nuts that you even have to ask when you had to put "act as if it cared". There's enough left to unpack from that statement to fill a calendar month of time.

I don't think AI is particularly dangerous but I absolutely think that the way AI sycophancy manipulates people is far, far more dangerous than simply any normal unhealthy relationship. The outcomes are already proving to be a lot more extreme.

Manifest v3's actual motive was so shamelessly transparent that most of us just don't allow the "safety" argument for it to really be entertained. I don't have a suspension of disbelief rich enough to pretend I don't know.

I think it might be even worse. LLMs seem to get tragically stuck on certain patterns. Maybe it's partly because a pile of weights essentially always starts from scratch in the same condition, but even within a single conversation, it will literally just latch onto words and repeat them incessantly, to the point where it becomes annoying.

So for example, current Claude models love "honest". They are always producing "honest" assessments. "The honest caveat" - I'm sorry, did you mean the caveat, period? But also, use the wrong phrasing and suddenly you can create your own word of the day for an AI model. I used the word "analytical" once, in a conversation with Gemini 3 Pro. I am pretty sure every single response from that point on had "analytical" in it at least once.

This is especially funny because system prompts and whatnot can also cause this behavior, but at least you can tweak those. You can't really do much about the model weights just having a weird affinity for a word.

I bet someone will or probably already has come up with a way to detect and prevent these problems during training or post training. I'm not saying it's an easy problem, but it has the benefit that it really should be detectable with just statistics.

This app requires Google Play. AOSP alone won't cut it.

Personally, I find LLMs really fun to work with, and the more capable they are the more fun it will get. It's one hell of a force multiplier.

It is fun in a totally different way than programming is. The "fun" or "joy" isn't coming from the sense of accomplishment of writing code or building software per se. Now it feels like it is just the joy of being able to prototype or debug or reverse engineer literally anything at a pace way beyond what you could've ever hoped to before. Have you ever dreamed of developing some software, but realized it was simply too big of a scope for one person? It might not be, anymore, even if you don't go full vibecoder.

The only real problem I ever had with this was the quality of the code. Sometimes it doesn't matter, like for pure prototypes or even reverse engineering, but sometimes it does. My heart sank a bit when I tried Fable to find that it was much better at long tasks and more ambitious in general, but I still didn't like the code much more than Opus 4.7 or 4.8. However, I'm pretty pleased with the code quality of GPT 5.6 Sol. This is a silly thing to care about but I love that by default it doesn't print code comments like a CVS receipt printer adding all kinds of pointless crap that is either apparent from context or irrelevant outside of the conversation you were having. Generally I've also found it to be super good at debugging, usually able to zero in on the actual problem with surprisingly little effort, even with not much context; I wish my debugging foo was that good. I gave Codex a spare machine to test something with real hardware and it has done a fantastic job making use of it.

Then of course there's the problem that I really don't like OpenAI or Anthropic very much. But it seems the news is good there too: even if we assume open weight Chinese models are at least less than 12 months behind on coding performance, then by next year we should have quite a lot of options for how to go about things. Evidence suggests 12 months is probably an over-estimation, and even now I use GLM 5.2 quite a lot at work since it is simply good enough. So... we're getting there too.

Obviously it's a little scary to think the world may need fewer programmers when you are one, and this is maybe not the way that I wanted programming to become accessible and democratized, but beggars can't be choosers. If the future is me being able to run an army of virtual programmers on a GPU cluster, I am interested in seeing what cool shit can be done with it. And when the hype and doom cycle finally ends, I hope everyone else will realize how fucking cool it is, too.

Fair point, although I get the feeling you may underestimate the state of disorganized chaos that my filesystems sometimes become.

Hmm. Personally, I disagree; I'd prefer to outlaw it explicitly. That's just my opinion, but I think that regulation has failed to keep up with the pace of technology and we've essentially lost the effect of some constitutional protections.

Do we genuinely, really need a mass surveillance network? Isn't the expansion of surveillance through increasing prevalence of technology already way too much? Police can real-time track almost anyone if they have a warrant as it is, thanks to the magic of modern cell phones. We didn't even have time to discuss whether that was a good status quo before it became normal. Are we really sure we want to expand this to a massive network of cameras?

I get that it helps solve crimes, but solving crime is not the end-all-be-all of improving society. If anything, it's a highly symptom-oriented solution, and we absolutely have plenty of levers we could be trying to pull if we wanted to prevent crime instead.

Forget whether one global surveillance network is more trustworthy than another global surveillance network for a minute. Do we want this at all?

Excellent quote. It's easy to draw conclusions one way or another, but the real challenge to fixing the budget is easily just as much trying to understand what the hell is going on with it.

I imagine it like if you were trying to clear hard disk space but QDirStat only gave obscure indications of what the files were and you had to go through a complex legal process to delete anything.