aseipp

The original Oryon systems allowed you to boot directly into EL2 and skip Gunyah via BIOS settings. I assume this will be the same.

If you want thin client like behavior, you should look at stuff like Waypipe or just outright using RDP directly, both of which are much better at the job of "display remote graphical application on my computer" than X11's client-server design ever managed to accomplish.

If anything, the variety of alternative solutions for that today -- everything from single-app to high-res full-desktop game streaming -- are much more robust and viable on modern networks than the X approach ever was, even if it was a neat-o "freebie" thing that fell out of its design. You get what you pay for, I guess.

That whole dust up just ended up being some bugginess in their native EGL/Wayland backend, which was known, but it was amplified by some distros accidentally enabling the Wayland backend by default. A build setting triggered the default render path to use EGL, but if you just set GDK_BACKEND=x11 and force KiCad onto XWayland, everything works just fine. And those bugs have probably been sorted out in distros by now. See https://forum.kicad.info/t/not-the-selected-menu-under-wayla... for some details.

TL;DR their Wayland backend is incomplete, it accidentally got enabled for some users, run KiCad on XWayland instead until their EGL backend is ready.

For users of older window managers on newer distros where X is likely to be removed "soon-ish" (vs LTS distros), the answer is to just use Wayback. It is a different X11 server implementation that uses Wayland under the hood, and is enough to run your WM. There are already people who use it to run AwesomeWM, IceWM, etc: https://gitlab.freedesktop.org/wayback/wayback

That said, you cannot run Wayland apps this way, it is purely for X11 only. If applications/rendering toolkits remove X11 support, you're out of luck. But Wayback may actually be a reason for some of them to keep maintaining X11 backends a bit longer, anyway.

Today, no. Very simplified but the broad goal of those tools is to prevent manipulation and monitoring of the in-process state of the game. Consoles and PCs require this to varying degrees by requiring a signed boot chain at minimum. Consoles require a fully signed chain for every program, so you can't deploy a hacking tool anyway; no anti-cheat is needed. PCs can run unsigned and signed programs -- so instead they require the kernel at minimum to be signed & trusted, and then you put the anti-cheat system inside it so it cannot be interfered with. If you do not do this then there is basically no way to actually trust any claim the computer makes about its state. For PCs, the problem is you have to basically trust the anti-cheat isn't a piece of shit and thus have to trust both Microsoft and also random corporations. Also PCs are generally insecure anyway at the hardware level due to a number of factors, so it only does so much.

You could make a Linux distro with a signed boot chain and a kernel anti-cheat, then you'd mostly need to get developers on board with trusting that solution. Nobody is doing that today, even Valve.

Funny enough, macOS of all things is maybe "best" theoretical platform for all this because it does not require you to trust anyone beyond Apple. All major macOS programs are signed by their developers, so macOS as an OS knows exactly where each program came from. macOS can also attest that it is running in secure mode, and it can run a process at user-mode level such that it can't be interfered with by another process. So you could enforce a policy like this: if Battlefield6.app is launched, it cannot be examined by any other process, but likewise it may run in a full sandbox. Next, Battlefield6.app needs to login online, so it can ask macOS to provide an attestation saying it is running on genuine Apple hardware in secure mode, and then it could submit that attestation to EA which can validate it as genuine. Then the program launch is trusted. This setup requires you to only trust Apple security and that macOS is functioning correctly, not EA or whatever nor does it require actual anti-cheat mechanisms.

Yeah that's fair. 60 tok/sec on a gpt-oss-120b is certainly nice to know if you should even think about it at all. I'm quite happy with it anyway.

The pricing is definitely by far the worst part of all of this. I suspect the GB10 still has more perf left on the table, Blackwell has been a rough launch. But I'm not sure it's $2000 better if you're just looking to get a fun little AI machine to do embeddings/vision/LLMs on?

Right now I get 59 tok/sec on GPT-OSS 120B using Unsloth's dynamic 4-bit quants, via llama.cpp https://news.ycombinator.com/item?id=45881049

Unfortunately comparing tok/sec right now in a vacuum and especially across weeks of time is kind of pointless. Everything is still evolving; there were patches within days that bumped GB10 performance by double digit percentiles in some frameworks. You just kind of have to accept things are a moving target.

For comparison, as of right now, I can run GPT-OSS 120b @ 59 tok/sec, using llama.cpp (revision 395e286bc) and Unsloth dynamic 4-bit quantized models.[1] GPT-OSS 20b @ 88 tok/sec [2]. The MXFP4 variant comes in the same, at ~89 tok/sec[3]. It's probably faster on other frameworks, llama.cpp is known to not be the fastest. I don't know what LM Studio backend they used. All of these numbers put the GB10 well ahead of Strix Halo, if only going by the numbers we see here.

If the AMD software wasn't also comparatively optimized by the same amount in the same timeframe, then the GB10 would be faster, now. Maybe it was optimized just as much; I don't have a Strix Halo part to compare. But my point is, don't just compare numbers from two various points in time, it's going to be very misleading.

[1]: https://huggingface.co/unsloth/gpt-oss-120b-GGUF/tree/main/U... [2]: https://huggingface.co/unsloth/gpt-oss-20b-GGUF/resolve/main... [3]: https://huggingface.co/unsloth/gpt-oss-20b-GGUF/resolve/main...

It's a bit ambiguous but I can't edit now, sorry. What I meant to say was that it boots using the same mechanism as x86 machines that you are familiar with, not that it is an x86 machine itself.

That was also my experience with their Jetson series [1], but my understanding is that these DGX kernels are not maintained by Nvidia but by Canonical, so they operate directly out of their package repos and on Canonicals' release and support schedule (e.g. 24.04 supported until 2029.) You can already get 6.14 from the package repos, and 6.17 can be built from source and is regularly updated if you follow the Git repositories. It's also not like the system is unusable without patches, and I suspect most will go upstream.

Based on my experience it feels quite different and much closer to a normal x86 machine, probably intentional. Maybe it helped that Nvidia did not design the full CPU complex, Mediatek did that.

[1] They even claim that Thor is now fully SBSA compliant (Xavier had UEFI, Orin had better UEFI, and now this) -- which would imply it has full UEFI + ACPI like the Spark. But when I looked at the kernel in their Thor L4T release, it looked like it was still loaded with Jetson-specific SOC drivers on top of a heavy fork of the PREEMPT_RT patch series for Linux 6.8; I did not look too hard, but it still didn't seem ideal. Maybe you can probably boot a "normal" OS missing most of the actual Jetson-specific peripherals, I guess.

It's just Ubuntu with precanned Nvidia software, otherwise it's a "normal" UEFI + ACPI booting machine, just like any x86 desktop. People have already installed NixOS and Fedora 43, and you can even go ahead and then install CUDA and it will work, too. (You might be able to forgo the nvidia modules and run upstream Mesa+NVK, even.) It's very different from Jetson and much more like a normal x86 desktop.

The kernel is patched (and maintained by Canonical, not Nvidia) but the patches hanging off their 6.17-next branch didn't look outrageous to me. The main hitch right now is that upstream doesn't have a Realtek r8127 driver for the ethernet controller. There were also some mediatek-related patches that were probably relevant as they designed the CPU die.

Overall it feels close to full upstream support (to be clear: you CAN boot this system with a fully upstream kernel, today). And booting with UEFI means you can just use the nvidia patches on $YOUR_FAVORITE_DISTRO and reboot, no need to fiddle with or inject the proper device trees or whatever.

It's very, very good as an ARM Linux development machine; the Cortex-X925s are Zen5 class (with per-core L2 caches twice as big, even!) and it has a lot of them; the small cores aren't slouches either (around Apple M1 levels of perf IIRC?) GB10 might legitimately be the best high-performance Linux-compatible ARM workstation you can buy right now, and as a bonus it comes with a decent GPU.

Golf course water usage vastly dwarfs data center water usage. Google used something like 1 billion gallons a year for their DCs. Single golf courses in arid regions can use upwards of a hundred million gallons a year, and in those areas there can be dozens of courses. It's not even close in terms of water usage.

I'm not yet using mine for ML stuff because there are still a lot of various issues like this post outlined. But I am using mine as an ARM dev system in the meantime, and as a "workstation" it's actually quite good. The Cortex-X925 cores are Zen5 class in performance and it is overall an absolute unit for its size, I'm very impressed that a standard ARM core is pushing this level of performance for a desktop-class machine. I thought about buying a new Linux desktop recently, and this is good enough I might just plug it into a monitor and use it instead.

It is also a standard UEFI+ACPI system; one Reddit user even reported that they were able to boot up Fedora 42 and install the open kernel modules no problem. The overall delta/number of specific patches for the Canonical 6.17-nvidia tree is pretty small when I looked (the current kernel is 6.11). That and the likelihood the consumer variant will support Windows hopefully bodes well for its upstream Linux compatibility, I hope.

To be fair, most of this also true of Strix Halo from what I can tell (most benchmarks put the DGX furthest ahead at prompt processing and a bit ahead at raw token output. But the software is still buggy and Blackwell is still a bumpy ride overall, so it might get better). But I think it's mostly the pricing that is holding it back. I'm curious what the consumer variant will be priced at.

Nick Wellnhofer did not create libxml2 or libxslt, David Veillard did. Nick has been the primary contributor since about 2015, though.

What? Intel has been doing large scale production runs of their 10nm node for years now. If you're talking about Raptor Lake failures, that was one generation of products on that note, there has also never been any indication AFAIK that e.g. Emerald Rapids suffered the same oxidization/voltage failures the consumer line did despite being on the same process node. They're already moving on from all this, really.

Chrome is not a good counter example a priori. It is a project that has hundreds of engineers assigned to it, some of them world-class security engineers, so they can potentially accept the burden of hardening their code and handling security issues with a regular toolchain. They've may have even evaluated such solutions already.

I think an important issue is that for performative sensitive C++ stuff and related domains, it's somewhat all or nothing with a lot of these tools. Like, a CAD program is ideally highly performant, but I also don't want it to own my machine if I load a malicious file. I think that's the hardest thing and there isn't any easy lift-and-shift solution for that, I believe.

I think some C++ projects probably could actually accept a 2x slowdown, honestly. Like I'm not sure if LibrePCB taking 2x as long in cycles would really matter. Maybe it would.

I think it's just the nature of the beast, in this case. Serious "industrial" implementations of a programming language might stick around for a long time, and breaking things a lot can mar the appeal; getting it right the first time pays off in that case.

I think the acceptance threshold can be much lower in other kinds of tooling. "It is what it is", so to speak.

Yes, a GUI for settings is nice if only for one thing: so there can be a search box that you can use to search over all the settings to find what you need in a pinch. It's a lot friendlier if I can do something like "Open Settings > Ctrl+F > 'Font'" or whatever than having to go find the manual and look it up.

I don't care about the configuration language so much personally (though JSON is of course pretty lame in a lot of ways for that task.)

U-Boot is implementing ACPI, yes, there was something at FOSDEM this year about it for ARM64 machines. QEMU can apparently now boot an arm64 virt machine with only ACPI tables and no device tree. This is all very recent. When I was working on a vague equivalent of systemd-stub last year as a fun exercise in UEFI development, I settled on U-Boot for UEFI and QEMU (but with virtualized device tree). I can't remember the specifics of what's unsupported by RuntimeServices when I was working on it. I'm like 99% certain it's not enough for SBSA compliance, at least.

Honestly, my opinion after all this was that UEFI is pretty convenient and nice, and I'm glad U-Boot has its own implementation, even if it isn't fully grown yet; UEFI for the executable spec with a DTB for bringing up the SOC with nothing else was nicer than a lot of embedded boot flows I've handled.

You have this commit graph

    B --> X --> Y (main) --> Z --> @
     \
      --> G --> H

B is a base; yesterday the name "main" pointed to it, and today "main" points to Y. Z is a commit you wrote that you haven't published yet. "@" means "Working copy", which is a way of saying "what your filesystem looks like." So, at this time, you see the changes from B, X, Y, Z, but not G or H.

You want to rebase G --> H from B to Y. But unfortunately, G conflicts with X. H does not conflict with anything. When you run this rebase in Git, you will actually have to immediately fix the conflict between G and X in order for the rebase to continue. If you do not solve it right then, the entire rebase fails. Git's rebase is actually an algorithm represented by a state machine; you must solve the conflict to proceed from "conflicted state" and `git rebase --continue` the rebase algorithm. (If you imagine what you would need to do to actually implement 'git rebase' as it works today in your own code, this state machine model makes immediate sense.)

In Jujutsu, rebase is a non-stop operation and it always succeeds. There is no state machine. It will update the commit graph to look like this:

    B --> X --> Y (main) --> Z --> @
                 \
                   --> G --> H
                       C     C

Now G and H are marked as "conflicted". If any commit is marked as conflicted, then all (transitive) children are marked as conflicted, too. If you "switch over" to working on G, then you can solve the conflict and commit the solution. That will solve the conflict in G, and also H as well.

But you don't have to do anything. In the above graph, G and H are conflicted, but because they are not a parent of `@`, then it does not matter. They exist in a parallel universe that does not influence your own. You can keep compiling code as usual. If you "switched over" to G, then the conflict is "materialized" in your working copy (filesystem) by putting conflict markers in the files, and so you have to solve it to keep compiling.

In short, Jujutsu separates conflict computation (do patches X,Y have a conflict?) from conflict materialization (make the conflict appear with markers in a file), and materialization of conflicts is "lazy" -- it only happens if a conflict exists transitively in the history of your working copy. Resolution is then done at your leisure.

A more brainiac way of thinking about it is that Jujutsu is a tool for manipulating _commit graphs_, and that is a purely computational notion; adding edges, removing edges, etc are all just basic algorithms. The graph's nodes contain "content" and states like "conflicts" are just defined as a relationship C(X,Y) on nodes in the graph. But all of this is "purely computational." Imagine implementing Jujutsu's rebase command; it is just a trivial reparenting of some graph nodes, something an amateur programmer could do. Calculating the relationship `C` is a bit more involved, but not complete black magic. But none of this involves "reading files from disk" or whatever. The side effect of "update the files on your filesystem to look like state XYZ in the graph" is just that: a side effect that the tool does when it is needed. Git, in contrast, only works through "side effects" in that it tends to only operate on the working copy, and never the "holistic commit graph". And so Jujutsu works at a higher, more "pure" level.

-----

Fun fact: in some cases, you do not actually have to "switch over" to G in order to solve this conflict, either. It is actually possible to craft a "solution" to the conflict in G while on top of Z. Then you can do `jj squash --from @ --into G` and you can "teleport" the resolution into the conflicted commit, solving both G and H, without ever making it appear in the working copy. This happens in cases like "G modified a file named readme.txt that was deleted by commit X"; all you have to do is "re-delete" the file inside commit G and it is trivially solved. This is something that is, quite literally, impossible to do in Git.

Yes. I have one repository, which is a fork of an OSS project, with a 7-way octopus merge of various patches I carry, and another 2-way merge on top of that one. Every week or two I pull the latest changes from upstream and I rebase all 9+ branches in a single command. If there are conflicts on any one of the parallel streams of work, I can trivially fix each conflict individually in any order I want.

Jujutsu does not treat merge commits any more or less special than non-merge "1-parent" commits. (We used to do this, actually, and occasionally special case merges, but most users found it very confusing.) This regularity means most commands work fine on merges. 'jj new X' is a new commit on top of X. 'jj new X Y' is a merge commit with X and Y as parents. 'jj new X Y Z...' is a 3-way merge, and so on and so forth for any number of commits. Similarly, 'jj rebase' can handle moving commits and preserving the graph structure no matter how many edges are involved in particular, and can add or remove parents from a given commit. This means that conceptually the jj commit graph is merely a simple, ordinary DAG, and operations are transformations on the DAG like you expect.

Actually, this exact workflow is beloved by many community members, and I guess I can take responsibility for popularizing it originally, the "Mega Merge" technique. Instant, easy rebase is an essential part of making this technique viable.

- https://ofcr.se/jujutsu-merge-workflow - https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...

If I understand you correctly, then you can use `jj interdiff --from name-of-branch@remote --to name-of-branch@git` in order to recover the diff between the remote branch commit and your local version of it; you could then turn that invocation into a Git .patch file and reapply it with patch(1). This only works for one commit.

The more general solution you're looking for I guess is some kind of "split based on interdiff" or something like that. I don't believe there's any way to accomplish this in a single stroke, though.

If you are already a heavy Magit user, then most of the basic ideas will probably be appealing and jj will let you bring those ideas to the command line. It will let you do some acrobatics you thought weren't possible before, ones that many users have come to love -- like rebasing a 5-way octopus merge with 2 extra leaves that result in conflicts you don't have to solve yet. (This is a technique known and popularized as "Mega Merge", which I suppose I am responsible for "inventing" along with its semi-silly name.)

I think Magit is an interesting parallel to jj. You say the "magic of git", but for both of them I think most of the "magic" has less to do with Git and more to do with the "design language" exposed to users, and by that I mean the tools that allow you to manipulate, navigate, and arrange commits (and diffs!) Git is more like a physical storage layer for both Magit and jj, but beyond that a lot of the special sauce is unique to their algorithms, their UX, and their "nouns and verbs".

In my experience, Magit users are generally harder to sell because for them jj isn't so revolutionary; die-hard Git powerusers who have been exclusively slugging it out on the command line to perform 10-stack rebases for the last 5+ years tend to be very easy to sell, in comparison. But all these users tend to understand and appreciate the power of a well-designed set of tools for commit graph manipulation. Git powerusers tend to be some of our most hardcore converts and advocates, really.

Full disclosure but I'm one of the jj maintainers and my opinion is that it's pretty good. Maybe try it out for a few days (perhaps without using Magit, if you can :)

ReadySet is basically "incremental view maintenance" but applied to arbitrary SQL queries. It acts like a caching proxy for your database, but it simultaneously ingests the replication log from the system in order to see things happen. Then it uses that information to perform "incremental" updates of data it has cached, so that if you requery something, it is much faster.

Naive example: let's say you had a query that was a table scan and it computed the average age of all users in the users table. If you insert a new row into the users table and then rerun the query, you'd expect another table scan, so it will grow over time. In a traditional setup, you might cache this query and only update it "every once in a while." Instead, ReadySet can decompose this query into an "incremental program", run it, cache the result -- and then when it sees the insert into the table it incrementally updates the underlying data cache. That means the second run would actually be fast, and the cost to update the cache is only proportional to the underlying change, not the size of the table.

ReadySet is derived from research on Noira, whose paper is here: https://www.usenix.org/conference/osdi18/presentation/gjengs...

OK and the vast majority of people excluding you and them probably have a very close-or-nearly-identical idea about what should happen. So everyone can be happy, there's nothing being lost here.

You'll live.

FoundationDB development has not stalled; v8 is still on the way. If anything, it's mostly just been stable for a while now, and it has now been developed as open source longer than it existed as closed source.

> Hardware performance is more important than software performance if the algorithm is likely to be implemented in hardware

I don't think that's necessarily a given at all, but I grant that's mostly a matter of opinion I guess.

> Given that the purpose of the competition was to replace SHA2 if/when it is weakened

I think the dirty secret hiding there is that I see very few actual expectations SHA2 will ever be broken. Assuming it can be and picking a different secure construction, of course, is a good idea. But even the designers of BLAKE have admitted such and so did NIST.

Performance is an evolving target. Meta reported they spend ~0.05% (1 out of every 2000 CPU cycles) on X25519 key exchange within the last year, which is quite significant. If that can be brought down, that's worthwhile. And ongoing research and deployment of PQC will make key exchange even more expensive.

> If there is not some novel, brand new algorithm that is being employed, the answer is because it is insecure.

Lol that is just not true at all. A major point of discussion when NIST announced the SHA3 finalist being Keccak back in ~2012(?) was that BLAKE1 at the time offered significantly better software performance, which was considered an important practical reality, and was faster than SHA-2 at a higher (but insignificantly so) security margin; their own report admitted as much. The BLAKE1 family is still considered secure today, its internal HAIFA design is very close to existing known designs like Merkle–Damgård, it isn't some radically new thing.

So why did they pick Keccak? Because they figured that SHA-2 was plenty good and already deployed widely, so "SHA-2 but a little faster" was not as compelling as a standard that complimented it in hardware; they also liked Keccak's unique sponge design that was new and novel at the time and allowed AEAD, domain separation, etc. They admit ultimately any finalist including BLAKE would have been a good pick. You can go read all of this yourself. The Keccak team even has new work on more performant sponge-inspired designs, such as their work on Farfalle and deck functions.

The reality is that some standards are chosen for a bunch of reasons and performance is only one of them, though very important. But there's plenty of room for non-standard things, too.