It wound up being OK, but it had a long span of time where it was virtually unmaintained and turned out to be buggy at points. The newer NTFS driver is based off of the old read-only NTFS driver which subjectively many claim is cleaner (I honestly haven't done a head to head so idk) and they're having an easier time modernizing it with support for things like large folios. Seems like a good deal to me.
Personally: I used NTFS3 and it was alright. If anything the biggest thing I got hit by was an issue where the udisks2 mount call from Dolphin would result in NTFS-3g specific flags getting sent to it, causing the mount to fail. But in actual usage it actually worked just fine for me.
I think you are taking it a step too far. First of all, unlike film, we are not recording reality in any way, every pixel that appears on screen is there because we put it there. I'd argue a closer parallel is a cartoon. And something like cartoon inbetweening is not an example of imperfect frames. These are in fact, perfect and even carefully crafted frames.
It's one thing if the frame halfway through an animation looks a bit "funny", but is still completely logically correct. It is another if the intermediate state of the animation legitimately doesn't make any sense and is just the result of not really caring about what actually goes on during the animation. In that case I'd almost rather just not have the animation at all, or just have a simpler one.
We do this in cartoons as well. Check out this Spider-Verse animator breaking down a shot of Gwen drumming. [1] If you look at individual frames, there are all sorts of details that make no logical sense. In one frame, she actually has three hands! But it looks great if you see it in motion.
That is exactly what I'm talking about, though. This is not what is happening with buggy computer UI animations: these are not carefully crafted to look better in motion, they're actually only considered acceptable because it's kind of difficult to see the mistakes in the animation. Whereas cartoon animating, you could argue the details don't make logical sense, but that's only to someone who doesn't understand the principles of animation. You can't explain away glitchy weird UI transitions this way because they're pretty much universally not intentional. They're usually just taking the technical path of least resistance.
I think there's also a major difference between the kind of weird intermediate frames that are acceptable for a highly-stylized cartoon at 24FPS and the kind of intermediate frames that are acceptable for a UI running at 120FPS.
No one is defending outright buggy animations. OP is just saying the idea that every frame should make logical sense on its own ignores how animation actually works (and they're correct).
Look at the youtube example - it has two pieces of UI animating from from a start point to an end point, and the paths are such that they momentarily overlap. There's nothing buggy or janky about it in motion; TFA is just saying that if you ignore the motion and take a screenshot mid-transition it looks odd. Same complaint as what GP describes, and silly for the same reasons.
It's what I personally took away from it. I was also someone who had the same feeling when I first heard Wayland's "every frame is perfect" mentality. I thought, "This is probably a good idea on multiple levels."
I agree the YouTube example isn't the worst one, but also at the same time, I don't agree with you that there is nothing buggy or janky about it.
There is no logical reason for there to be two copies of the video rendered at once. The video is literally resizing into position, while all of the UI elements shift around it. Why would there be more than one copy of the thing that is resizing?
I will relent on only one thing: "If I take a screenshot of your app at any moment, it must make sense" is too strong of a statement on its own. The context that it is a screenshot of an animation is important, just like cartoon inbetween frames. However, I think if you're being generous with interpretation you can allow this to be implied.
I see what you're getting at, but I think you're focusing on the incidental. An animation is good if it's clear and intuitive in motion. It may often be the case that good animations also look nice in a screenshot halfway through, but (a) they don't always, and (b) working well in motion is obviously the more important of the two goals.
As such it makes no sense to worry about the latter thing - it's not a signal whether the animation is good or not.
Or "squash and stretch" [0] frames cartoons and 3D modeling, where people prefer the final result even though individual frames can be grotesque.
That said, I think it's fair to hold most practical UIs to a different standard. Prioritizing amusement leads to a lot of strange non-ergonomic places.
Of course, even real life can look quite grotesque if you look at it in slow motion, as things get deformed by forces [0], so it makes sense animations would need to simulate that.
Oh boy, I wouldn't use Spider-verse animation as an example. I personally hate it. When I saw the first movie I thought something was wrong and asked the staff if I had mistakenly been put in a 3D movie without the 3D glasses.
The point is that if a pixel is in a nonsensical place the only thing that is to blame for that is the code. It doesn't matter if it looks pleasing; there's no good reason for something to be wrong just because it looks acceptable.
If you can't even guarantee internally consistent state then good luck communicating your "convincing and aesthetically pleasing effapt update && apt upgradeects" successfully.
> if you have actually used unrestricted and enterprise grade versions of Claude, Mythos, GPT, and Gemini you see how far behind the open weight models are.
I really do feel like DeepSeek V4 Pro is often better than current Sonnet is, in the general case.
Opus 4.7 is a solid step above Sonnet, and Fable was a solid step above Opus 4.7. I've only had Fable for a few days, obviously, but I was decently impressed after Opus 4.8 being a downright disappointment for me (it's just too buggy; I had it go out of control 3 separate times on things Opus 4.7 never had any trouble with.) I still ran into limitations. It's not world-endingly great.
So, based on that, I think DeepSeek V4 Pro is, ignoring multi-modal capabilities, about a couple solid steps behind. Assuming model iteration will continue to decelerate, especially as Anthropic heads into IPO, I'm guessing that DeepSeek will probably be able to strike back with something further along. Of course we'll see how able and willing they are to stay open weight, but they've done well so far so, no reason to doubt them at the moment.
(There are some models that claim to be ahead of DeepSeek V4 Pro. I've tried some of them and really not been that impressed. Maybe it's a me issue.)
Now I reckon that most people just simply don't really need Mythos/Fable for most of what they do and using Mythos/Fable tokens in place of Sonnet-tier models would not make any sense. At my job we already mostly just use Sonnet as it is. I'm sure there is some cutting-edge research where you want the absolute best model available and sure, in that case, you're stuck with Anthropic for the moment.
But is that really everyone? After all, while Mythos was dominating the hype cycles, quite a lot of impressive LLM-assisted CVEs dropped that were not linked to Mythos.
Because Claude Code is literally nothing particularly special. We don't need their business model. They need their business model, and to that I say, tough shit.
> DeltaDB captures every operation in between [each commit]
No.
First of all, that feels intrusive. I would also prefer to not have a screen recorder that is running 24/7 while I work. Yes, I suppose there's nothing wrong with having my mistakes on display, but also, if I'm doing my job, all of the value I produce is captured by the commit, and it just feels significantly less intrusive that way.
Second of all, I use many different tools, and I don't really want to have to have all of them be integrated into some weird DB. What's the point of capturing everything if randomly it has to go "some external process did something"? Yes I do like that Zed can integrate so many things but that doesn't mean I will use everything integrated into Zed. Last I checked if you use Claude Code in Zed via ACP you can't even rewind and edit old messages.
Finally, personally, I think that we've already lost the plot with commits. It's clear to me that most people are just doing some arbitrary unbounded set of changes then running git commit, then the changeset is reviewed as one giant blob, and then those commits get squashed together. It isn't the end of the world, but having nice hand-crafted commits is amazing. If you've ever ran `git blame` on a project that enforces this, you will understand exactly what I am talking about. Doing stuff like DeltaDB is just going to re-enforce and solidify the practice of slopping together commits. Wonder what's going on? Now you can voyeuristically replay it and view the conversation the user had with LLMs...
And that last point is as interesting as it is frustrating. You couldn't convince someone to write documentation for their changes and the motivation behind those changes just because it's good engineering practice that helps your teammates, but everyone will happily explain it to an LLM. Sure that is in large part because it's needed for the LLM to do the work for them, but it is interesting how much work we will do to please the LLMs that we would not have done before. Suddenly a bunch of weird undocumented things are documented. In CLAUDE.md.
> While randomly closing apps, I found the culprit: the Zed editor. Apparently, an open Zed window can add latency to all my other apps even while idle in the background.
Zed definitely does funny things to KWin. It's not the only app that does, but this point in particular would be worth more investigation. I've noticed it causing weird issues with the frame pacing as well sometimes.
You know, I'm not saying I don't understand what they are doing from a business perspective, but I'm just saying: DeepSeek V4 doesn't silently sabotage you because it thinks you are trying to violate a ToS. Anthropic's clawing back a bit of a moat perhaps, with Fable being an actual improvement of sorts, but now with torching user trust they are really banking on open weight models not catching up to where they are now. I wonder if they have a good reason to believe that they won't, or are hoping for something entirely different to save them.
(P.S. Yes of course I know about model censorship, a different problem, but all of the models are censored to some degree. It happens to be less of a problem for open weight models anyhow, but I figured I'd just preempt this since it's inevitable.)
I actually kinda like DSv4 over Opus 4.7 for some tasks, although I have not figured out what the deciding factor is. (Opus 4.8 so far has not worked very well for me at all, no idea why.)
If this works and passes all of the tests, then it seems like a done deal to me. LLMs are just too good at doing ports where they have a rigorous automated test suite or oracle to compare against. They're oddly bad at following instructions like "port this mechanically, exactly" - worse than a human for sure - but they seem to do a great job of sitting there and comparing results to find bugs for hours and hours. It's hard for me to imagine a world where they aren't used to assist ports, not just writing them but especially refining them.
I suspect this won't have as big of a shit storm as the Bun port in part just due to the input/output nature of the React compiler.
That said, while I use React still, I still have never tried the React compiler... So I have no idea how important this is. But you know, very few people are ever upset over faster iteration cycles or CI builds.
Sure but it certainly seems that way. There were already thousands and this PR adds a fair bit more too.
It is possible to have thousands of tests and a lot of blind spots, but it's easier to get a grip on that using instrumentation like code coverage and indeed by using LLMs to prod at edge cases.
I am OK with trusting that it is likely the React team understands how to rigorously test based on how well-tested React itself is.
100% believe this one. The good thing about Wacom devices is that they're actually quite simple to deal with. All of the Wacom devices use a simple packet-based format that, while it varies per model, is quite well documented, what with being in the Linux kernel and several user mode tablet drivers (including OpenTabletDriver and TabletMagic.) You really don't need reverse engineering for Wacom, from old serial Graphires to the latest Intuous'. The knowledge, or at least certainly knowledge of where to look, should be baked into any frontier model.
When I was in college I had an ARM Chromebook which didn't have the Wacom driver, so I wound up trying to use the then-new Chrome USB APIs to make myself a tablet driver in a Chrome extension. This was long before LLM coding was a thing, but thanks to the Linux wacom.ko it wasn't really an obstacle.
The biggest problem I had was that while I was decoding digitizer inputs just fine I had nowhere to put them. I tried making a simple painting app in JS and it worked but without having native cursor movement it was just too jank and I gave up.
I eventually uploaded the code for posterity sake. I doubt it works at all anymore, even with the specific tablet it was hard-coded for. But it's still online, anyhow.
I may have tried this exact thing a few years ago without LLMs, though I can no longer remember if it was a ThinkPad X61 or not. I just know it was an Intel ICH that wasn't supported by Coreboot and wasn't documented at all. I tried for quite a while and getting it to output anything to the serial port was very exciting for me, but at that point I definitely hit a wall: the RAM initialization and other platform init was a complete mystery and the only way I was going to learn about it was by reverse engineering the BIOS, since it wasn't documented. Ultimately I just never found the time to get to it, so it never happened, which still to this day feels like a shame.
What a mixed blessing it is now that theoretically, especially as LLMs increase in competence, an idiot like me might actually be able to port Coreboot to an unsupported platform with some LLM-assisted reverse engineering. I mean, it's probably still a long shot without as much arcane knowledge as you gain from working in stuff like this professionally, but at this point it's probably the best shot I have since I probably won't find myself in such a scenario.
I guess I should try to find time to revisit a reverse engineering project that I haven't had time to dig deep into... It does feel like a shame that this way I'll never really improve my skills related to reversing, though.
Personally: I used NTFS3 and it was alright. If anything the biggest thing I got hit by was an issue where the udisks2 mount call from Dolphin would result in NTFS-3g specific flags getting sent to it, causing the mount to fail. But in actual usage it actually worked just fine for me.
reply