matja

> This is a bit like saying stop using Ubuntu, use Debian instead.

Not really, because Ubuntu has always acknowledged Debian and explicitly documented the dependency:

> Debian is the rock on which Ubuntu is built.

> Ubuntu builds on the Debian architecture and infrastructure and collaborates widely with Debian developers, but there are important differences. Ubuntu has a distinctive user interface, a separate developer community (though many developers participate in both projects) and a different release process.

Source: https://ubuntu.com/community/docs/governance/debian

Ollama never has for llama.cpp. That's all that's being asked for, a credit.

If you think files are easier than a database, check out https://danluu.com/file-consistency/

What if the "slug" was a prefix for the API key revocation URL, so the API key was actually a valid URL that revoked itself if fetched/clicked? :)

I suppose there could be two checksums, or two hashes: the public spec that can be used by API key scanners on the client side to detect leaks, and an internal hash with a secret nonce that is used to validate that the API key is potentially valid before needing to look it up in the database.

That lets clients detect leaks, but malicious clients cant generate lots of valid-looking keys to spam your API endpoint and generate database load for just looking up API keys.

Does Nvidia need to support Wayland, or does Wayland need to support Nvidia? I.e., what is the support at the API boundary which is missing?

I'm running Gemma 4 with the llama.cpp web UI.

https://unsloth.ai/docs/models/gemma-4 > Gemma 4 GGUFs > "Use this model" > llama.cpp > llama-server -hf unsloth/gemma-4-31B-it-GGUF:Q8_0

If you already have llama.cpp you might need to update it to support Gemma 4.

That's a good point that I hadn't considered. I've never had a laptop with Nvidia, I probably subconsciously avoided those dual GPU setups as they sounded hacky and I never really needed fast 3D on a laptop.

The "Nvidia on Linux compatibility" issues are something I wonder if I have side-stepped somehow either by lucky choice of GPUs, or lucky choice of Linux distros.

Was/is this a distro thing, or an actual issue?

Every Nvidia I've used [1] has worked perfectly, from the change for Xfree86 to Xorg, through the Compiz desktop wobbly window craze, to the introduction of GPGPU APIs like CUDA/OpenCL and recently Vulkan.

I do recall once helping a friend setup a Debian and a Ubuntu machine with Nvidia (which I never used before) and it took some figuring-out of how to install non-free drivers, so maybe my choices of Gentoo and Arch (not being as conservative towards non-free licenses as Debian/Ubuntu) always made it a non-issue?

[1] 6800 Ultra, 7800 GTX , 7900 GTX, 8800 GTX, GTX 280, GTX 480, GTX 680, GTX 760 Ti, RTX 2080, RTX 4080... probably missed some.

I'm nowhere near qualified to say if the design is not safe, but I'm suprised the article doesn't mention that some heat shields are designed to indeed, blow chunks: https://en.wikipedia.org/wiki/Atmospheric_entry#Ablative

Yeah 80GB/s total I/O bandwidth is a lot for a Mac, but desktop PCs have been doing 1TB/s (128x PCIe5) for years (Threadripper etc).

That sounds like the best way if keeping the filesystem is an option. In my case I wanted to also change filesystems and apply FDE, which is possible to do if the original filesystem supports online shrinking but many do not.

I totally missed part 2/3, thanks for linking!

> How do you unmount your OS’s disk while keeping the OS running to be able to overwrite itself?

I went down a similar rabbit-hole myself, with the goal of safely replacing the Linux installation on a disk that a machine is already running from (e.g. replace a VPS's setup image with one of your own) without needing a KVM-style remote access tool to the console.

The problem there is if you directly modify the disk when a filesystem is mounted on that disk then all bets are off in terms of corruption of the filesystem that's already on there and also the filesystem(s) you're writing over the top.

My solution was to kexec into a new kernel+initramfs which has a DHCP client and cURL in it - that effectively stops any filesystem access while the image is being written over the disk, then to just reboot.

How have you measured the power usage/cost? That seems like a incredibly high price for electricity, similar to a 600W constant load in my part of the world.

In distributed databases I've worked with, there's usually something like a B-tree per key range, but there can be thousands of key ranges distributed over all the nodes in the cluster in parallel, each handling modifications in a LSM. The goal there is to distribute the storage and processing over all nodes equally, and that's why predictable/clustered IDs fail to do so well. That's different to the Postgres/MySQL scenario where you have one large B-tree per index.

To minimize the storage space while having a URL-safe representation, yeah you'd want to serialise/deserialise on the boundary of presenting it to API consumers. I think the same for any ID that has an efficient binary representation as well as needing to represent it in ASCII.

> UUID versions 1, 2, 3, 4, 5 are already outdated.

Interesting comment, since v4 is the only version that provides the maximal random bits and is recommended for use as a primary key for non-correlated rows in several distributed databases to counter hot-spotting and privacy issues.

Edit: Context links for reference, these recommend UUIDv4:

https://www.cockroachlabs.com/docs/stable/uuid

https://docs.cloud.google.com/spanner/docs/schema-design#uui...

You aren't supposed to store the hyphens, and that's the same for all versions.

Doesn't sell as well as a beautiful citrus blush milled aluminium case.

I have a machine with a 6 year uptime that was slowly accumulating single bit error corrections. The EDAC counter mysteriously stopped at 308 last year, and hasn't changed since, so I wonder if a bitflip in the counter circuit made it stop...

You can only detect what you measure. Are these big-data analytics processes running multiple times to detect differences?

The actual RAM chips on a ECC DIMM are exactly the same as a non-ECC DIMM, there's just an extra 1/2/4 chips to extend to 72 bit words.

The main reason ECC RAM is slower is because it's not (by default) overclocked to the point of stability - the JEDEC standard speeds are used.

The other much smaller factors are:

* The tREFi parameter (refresh interval) is usually double the frequency on ECC RAM, so that it handles high-temperature operation. * Register chip buffers the command/address/control/clock signals, adding a clock of latency the every command (<1ns, much smaller than the typical memory latency you'd measure from the memory controller) * ECC calculation (AMD states 2 UMC cycles, <1ns).

I think it is still more likely that a project can be improved if everyone has access to the source code vs not having access to any source code. Are there counterexamples to that?

Intel seem to be deliberately hiding the clock frequency of this thing, the xeon-6-plus-product-deck.pdf has no mention of clock frequency or how LLC is shared.

Did you try adding a Cache-Control response header?

> it took 5–10 minutes just to open a file

Yeah, I don't think the architecture is going to help a bad storage/network setup too much. I'd be troubleshooting that before jumping machines/OSs.

> As it occured to me, gRPC could optionally just serve those .proto files in the initial h2 handshake on the wire

Do you mean the reflection protocol, or some other .proto files?

Did macOS support that at some time in the past?

I've used Linux as my daily OS for 20 years and got so used to alt-right resize and alt-left drag that the macOS and Windows way of actually needing to move my mouse to the corner or edge of a window feel almost barbaric in comparison.

I still have found no way free equivalent on macOS.

I like this theory - I can totally imagine some big spreadsheet of processor model names where someone copy/pastes the model name to some janky firmware-programming utility running on an off-the-shelf mini PC on the manufacturing floor, implemented as a "temporary fix" 5 years ago, every time the production line changes CPU model.

Windows 11 24H2 added a dependency on the POPCNT instruction, causing CPUs that don't have it - which were otherwise fine, to fail to even boot Windows.

What will be the next instruction/ISA extension that is only supported since Intel 11th Gen that there will be a hard dependency on? Any bets?