aseipp

And what happens when they can't do that because you need the latest major version with specific features?

I don't disagree in general but in Bazel's case this path has been heavily optimized. Maybe there are limits to it but "java startup slow" is a 101-level complaint.

In fact, I don't even think the client program for Bazel is written in Java, but C++, and the Java daemon it talks to is started when you first attach to a Bazel workspace and it persists, so subsequent interactions are very fast. Just running `bazel` randomly is not truly indicative of what using it feels like, because that's not what people actually use it for. People use it inside a build workspace, that is the case that matters.

Beyond that, other build systems like Buck2 (Rust) also use the client-daemon architecture for a number of other reasons, including the fact that actually-really-large build graphs are far too large to rebuild on every invocation, so the daemon is necessary to keep the build graph and interactively analyze and incrementally invalidate it on demand. Doesn't matter if it's Rust or Java, these things are architectural. That's also one of the points of the article, of course, and why they're theorizing about server-side analysis caches and graphs, etc.

This all indicates to me that the people designing these systems actually do care about interactivity of their tool. It is not a matter of "java startup slow" to use a client-server design, though it certainly is known to help.

FWIW, the client server design is also used in Buck2, but it has other advantages than just startup time, like keeping track of the filesystem with inotify or watchman so that it already has fresh information about the state of the build graph by the time you run `build`.

To be honest, I'd rather not see Buck2 repeat the mistakes of Bazel so early on, especially when it took a lot of time before settling on bzlmod.

Frankly, I'd rather it go the other way: just have a gigantic 'buck2pkgs' repo that has everything inside of it -- literally fucking everything -- just like Nix and Nixpkgs have done. I've watched and committed to Nixpkgs for over 10 years now and I think being a monorepo has massively contributed to its success, ease of contribution, and general usability. And in practice it means 99% of projects only need one "dependency" and they are done and have everything they could want.

In theory a buck2pkgs could even be completely divorced from Meta's existing Prelude, because you can just reimplement it all yourself, without being constrained by their backwards compatibility with Buck1. That would reduce the surface area between the two projects substantially and let you do a lot of huge cleanups in the APIs.

I actually started doing this a while back but it is of course a massive amount of work. I do think it's a much better way to go, though...

I care a ton about fast and accurate build systems but one issue I think we haven't solved is that: people do not want to use other build tools for their language. "Why isn't it Cargo? Why not use NPM/Yarn? Why not use Pip? Why not CMake?" These questions are often rhetorical because they do not care about build systems. They don't care about the design. They don't care if your CI could be 5x faster. You will never make them care. It's good enough. You must have absolutely zero externalized cost (and therefore put in a lot of effort) to get over this hurdle. There's seemingly no way around it.

The reason a lot of people like Bazel is, I think, tools like Gazelle -- which reduce that whole problem back to "Run gazelle" and all the crap is taken care of for you. Dependencies, BUILD files, etc. People constantly talk about the "complexity" aspect, but very few people appreciate how complex Cargo, NPM, Yarn, Cabal, Dune, internally are. Because they just run "build", and it works. Bazel, Buck2, Mill, etc will all have this problem unless huge effort is put in.

TBH, this is one of the reasons why I think Nix has wildly succeeded in the past few years while more fine-grained and scalable systems have had adoption problems -- despite its numerous, numerous flaws. You get to Bring-Your-Own-Build-System, and Nix along with the blood of 10,000 upstream contributors keeps the juice flowing, and it's cached and hermetic so you see real savings. That greatly eases people into it. So they adopt it at all points on the curve (small, medium, huge projects), because it works with what they have at all those points. That makes them willing to get deeper and use the tool more.

Why wouldn't you just keep search for the "warning:" or "error:" anchor, like people (and editors) have been doing forever? Even if that wasn't true it's not like searching for emojis is hard anyway. If it takes longer than 2 seconds for you to open a picker then you should ask for a refund for your computer.

They work. You can use them? They haven't gone anywhere and the Linux kernel relies on them extensively, among other things.

They are quite easy to search for actually, because they are sparse and you tend to not get so many spurious results due hitting things that contain your query as a substring. Even then, the glyphs appear inline in the warning message, they are not the anchor, you could still just search for "warning:" like you or your editor have been doing for years. Every operating system comes with an emoji picker, it takes like 2 seconds to use. I'm not sympathetic, tbqh.

The reality is that for large scale AI deployment there's only one criterion that matters: what is the total cost of ownership? If TPUs are 1/30th the total perf but 1/50th the total price, then they will be bought by customers. Basically that simple.

Most places using AI hardware don't actually want to expend massive amounts of capital to procure it and then shove it into racks somewhere and then manage it over its total lifetime. Hyperscalers like Google are also far, far ahead in things like DC energy efficiency, and at really large scale those energy costs are huge and have to be factored into the TCO. The long dominant cost of this stuff is all operational expenditures. Anyone running a physical AI cluster is going to have to consider this.

The walled garden stuff doesn't matter, because places demanding large-scale AI deployments (and actually willing to spend money on it) do not really have the same priorities as HN homelabbers who want to install inefficient 5090s so they can run Ollama.

Interesting, that was just a few short months before I showed up. :)

I don't know if it's the only or original reason, but one nice consequence of the reverse hex choice is that it means change IDs and commit IDs have completely different alphabets ('0-9a-f' versus 'z-k'), so you can never have an ambiguous overlap between the two.

Jujutsu mostly doesn't care about the real "format" of a ChangeId, though. It's "really" just any arbitrary Vec<u8> and the backend itself has to define in some way and describe a little bit; the example backend has a 64-byte change ID, for example.[1] To the extent the reverse hex format matters it's mostly used in the template language for rendering things to the user. But you could also extend that with other render methods too.

[1] https://github.com/jj-vcs/jj/blob/5dc9da3c2b8f502b4f93ab336b...

Mostly because it is jarring for users that want to interact with tools which require these footers -- and the setups to apply them, like Gerrit's change-id script -- are often annoying, for example supporting Windows users but without needing stuff like bash. Now, I wrote the prototype integration between Gerrit and Jujutsu (which is not mainline, but people use it) and it applies Change-Id trailers automatically to your commit messages, for any commits you send out. It's not the worst thing in the world and it is a little fiddly bit of code.

But ignore all that: the actual _outcome_ we want is that it is just really nice to run 'jj gerrit send' and not think about anything else, and that you can pull changes back in (TBD) just as easily. I was not ever going to be happy with some solution that was like, "Do some weird git push to a special remote after you fix up all your commits or add some script to do it." That's what people do now, and it's not good enough. People hate that shit and rail at you about it. They will make a million reasons up why they hate it; it doesn't matter though. It should work out of the box and do what you expect. The current design does that now, and moving to use change-id headers will make that functionality more seamless for our users, easier to implement for us, and hopefully it will be useful to others, as well.

In the grand scheme it's a small detail, I guess. But small details matter to us.

The new p150 cards linked in the OP have 32GB GDDR6 @ 512GB/s for $1,300. Which isn't bad on paper, I guess. They're meant to be networked (quad 800GB QSFP-DD) like Nvidia GPUs, so two of them would get you 64GB of VRAM at $2600 for ~600W which is basically what you're asking for? The power usage isn't good enough yet at scale I think, but for a workstation it's quite manageable.

Real workloads remain to be seen, but if they can actually get a working build of vLLM and their cards remain actually buyable, well, they're doing better than some of the competition...

Microsoft did not push these changes. Valve (and places like Collabora) did, because it meaningfully improves performance for emulated Windows games. You should probably at least get the basics of your story straight if you're going to scare yourself silly over something you don't understand.

You've never been able to upgrade RAM on GPUs for the exact same reasons that Framework is alluding to. That's what's happening here; GPUs have lots of cores, and to keep them feed you need lots of bandwidth to go along with it. All dedicated GPUs come with dedicated memory for this exact reason. Things like traditional "iGPUs" that use DDR can get away with it exactly because they are so small and computationally weak that the limited bandwidth isn't the immediate #1 bottleneck. But Strix Halo is not intended to be a measly iGPU system, so it has different needs.

There just isn't a free lunch here, it's an inherent design tradeoff for these kinds of chips. The CPU is just along for the ride, in this case.

Well, you haven't ever been able to upgrade RAM on your GPUs, so the real question is more like: will more consumer-grade devices move towards unified memory designs with single memory pool?

My completely-bullshit opinion is something like "I think it's attractive for a lot of mid-range or lower end SKUs, so you'll see it more frequently." It's attractive because you save a lot of power and components with this kind of design. It would be interesting to see this kind of design (APU) in a socket-able factor too, but who knows. It's also attractive for a certain class of high-end design too (like Grace Hopper), but I think you're going to see RAM sticks for a while yet in the mid-to-very-high-range.

This is completely bullshit because it is based more on vibes and basic technical design points than any kind of market forecasting or anything like that.

CAMM will be fine on laptops and other smaller form factor devices for CPU-class memory speeds, but it does not have the bus width or lanes to match solutions like Strix Halo, Grace, Apple M-series -- the memory bandwidth being a large part of their appeal. Increasing the bus width on CAMM modules is going to compromise many of the other advantages.

The problem is that these are integrated shared-memory systems with a single RAM pool. That's nice for a lot of reasons, but GPUs need many more memory channels and larger bus widths than CPUs do in order to do work and remain fed at a reasonable power draw. It's an inherent design trade off. I don't see a CAMM style solution for GPU memory coming anytime soon except on the low end.

CAMM2 only has a 128-bit bus so it's going to severely compromise performance for workloads that want higher interconnect bandwidth, which Strix Halo is targeted at. For things like that, wider busses are always going to give much better performance/watt than upping clock speeds.

I'd be more than happy to see CAMM2 in general laptops, but it will probably always be much weaker at shared GPU/CPU designs like Strix Halo, Grace, Apple's M series, etc.

Your impressions are not correct. Jujutsu's creation and its Git support both predate Google's direct involvement or its anointment as the eventual successor to Fig (Google's internal fork of Mercurial). Martin just happened to work there at the time he started jj, and only later did it become his full-time job to work on it. Though the occasional Googler who isn't Martin will contribute a patch or two when they want to fix something, Google otherwise isn't really involved.

Large file handling has improved in recent versions, FWIW; large files are left untracked if they violate the size limit (no auto track), you have to selectively add them at that point. Note that you can unbloat your local copy by pruning the operation log and then running jj gc if you accidentally add blobs and stuff; though if you push the blobs somewhere you obviously can't undo that so easily, that's no different than Git.

Git's underlying storage format just isn't a very good fit for any kind of "large-ish file" storage; Git LFS is mostly just hack and it is unlikely to be supported anytime soon. Our hands are a bit tied on that front.

My impression is that most of the interest and momentum for solving the "large files problem" would preferably be invested in a native non-Git backend for Jujutsu.

It supports standard UEFI boot, Ubuntu has a WIP image you can use that has some extra patches, and with some fiddling you can get other distros, assuming you use a really recent kernel with a supported device tree and maybe you need some firmware updates and a kernel patch or two (search 'x1e' in the Linux tree to see if yours is in there.) Wifi, USB-C etc work last I checked. Not sure about BT or general sound support or anything like that.

Overall though, things "work" but as far as usable goes, it seems to remain in a pretty poor state; especially given the lack of accelerated graphics combined with no NUC/SFF options. I guess WSL2 is probably okay. But it's a shame, because the hardware does seem pretty nice.

When some NUC options come out you'll at least be able to use it in a headless form factor, I guess.

The real reason to use those languages is because they often lend themselves to using the meta-language for other purposes, like writing flexible open ended test suites, or using some forms of code generation/metaprogramming to generate parts of the design from other things. That's very useful and one of the attractive properties of systems like Amaranth or Clash, and one of the downsides (IMO) of approaches like Filament or Bluespec. That said, the most important bits about Filament and Bluespec are their high-level concepts (like guarded actions and timeline types), which could be adopted into other RTLs as well.

At the end of the day though, sometimes you just have to debug a netlist, and that probably will remain true of Filament too. (Any language with higher-order applicative concepts will eventually run into some issues with wire names, etc, that's just unavoidable.) I think the SystemVerilog or whatever is just a red herring at that point; the tools for doing netlist debugging all feel like the equivalent of having to debug compiler assembly output with no debug symbols. Making sure you need to reach for the debugger much less is a good first step, but I'm not sure how to improve this part.

For the most part, yes, it should be very achievable. Embedded Swift basically just produces an object file that looks like any object file from a C compiler. The objects mostly rely on very basic primitives like malloc/memcpy so it's pretty freestanding (you can turn off allocations, too). It also has very good support for importing C headers into Swift code so you can interop easily.

Probably the biggest roadbump for something like FreeRTOS is the asynchronous support though. Embedded Swift's async support is still extremely rudimentary and I didn't find much about how to extend it/attach it to other control loops. I think it only supports single-threaded execution right now as well.

Hashes of the tarballs are recorded in the package-lock.json of downstream dependants, so recompressing the files in place will cause the hashes to change and break everyone. It has to be done at upload time.

They're overall more prevalent in the FPGA world, I think. I've used and done several jobs with them (Clash/Haskell, Bluespec, etc) and know others who have, too. But you basically need to know someone or do it yourself. Pretty marginal overall, but IME the results have basically been good (and more fun to write, too.)

The official specs for the 5090 have been out for days on nvidia.com, and they explicitly state it's 32GB of GDDR7 with a 512-bit bus, for a total of 1.8TB/s of bandwidth.

Yes, I've been using Vector since very early on, long before Datadog acquired it, and Datadog have continued ongoing maintenance and feature additions at a slow-but-steady pace, which I think is good. Like Quickwit, Vector is very stable and already quite complete. So I'm not too unhappy.

But Vector is something that complements Datadog's offering very well, so I think that makes sense for them to be good stewards of it. Quickwit is something that somewhat actively competes against them, which is a big difference. I suspect that unlike Vector, Quickwit is probably going to stop seeing any development in pretty short order, unless the devs now can consciously go out of their way to dedicate extra hours to it.

To be clear, I think that the relicense is great, and I think it's very possible that Quickwit will be picked up/forked by someone and maintenance will continue, because it's very good, and I'd really love to see someone do metrics for it as well. So, I'm not all gloomy or anything like that.

Well, it looks like Quickwit was going to add an Enterprise license as of earlier this year (PR #5529), which I had been keeping eyes on, but this announcement says they're instead going to relicense as Apache 2.0 so the "community can continue on":

> We will be focused on building a new product with Datadog, and to ensure our open-source community can continue, we will soon release a major update of both Quickwit with a relicense to Apache License 2.0 and tantivy.

So, it looks like we'll get a more liberally licensed Quickwit, but reading between the lines suggests development of it is might otherwise be winding down? It has been pretty nice and stable in my experience, so I can't really complain much. But I was really looking forward to what else it could bring.

Congrats to the team, in any case!

The Orin series and later use UEFI and you can apparently run upstream, non-GPU enabled kernels on them. There's a user guide page documenting it. So I think it's gotten a lot better, but it's sort of moot because the non-GPU thing is because the JetPack Linux fork has a specific 'nvgpu' driver used for Tegra devices that hasn't been unforked from that tree. So, you can buy better alternatives unless you're explicitly doing the robotics+AI inference edge stuff.

But the impression I get from this device is that it's closer in spirit to the Grace Hopper/datacenter designs than it is the Tegra designs, due to both the naming, design (DGX style) and the software (DGX OS?) which goes on their workstation/server designs. They are also UEFI, and in those scenarios, you can (I believe?) use the upstream Linux kernel with the open source nvidia driver using whatever distro you like. In that case, this would be a much more "familiar" machine with a much more ordinary Linux experience. But who knows. Maybe GH200/GB200 need custom patches, too.

Time will tell, but if this is a good GPU paired with a good ARM Cortex design, and it works more like a traditional Linux box than the Jeton series, it may be a great local AI inference machine.

You're confused. You can use software that doesn't provide backups or clear exports, but attestation is not supported for any widely used websites or WebAuthn software because it defeats synchronization, something pretty much everyone widely considers to be a benefit. It would for example completely negate the ability to synchronize passkeys over something like iCloud, whether or not it had the ability to export keys in a standardized format. Attestation is basically a boondoggle solely for corporations with device management policies, so they can use a standard protocol/framework at the app layer while still enforcing stuff they already enforce.

The amount of people in this thread who don't understand the very basics of this stuff is a pretty good counterexample to the common trope they somehow "know better." I kind of doubt that when many people here can't even get the basics straight.