zamalek

Don't forget the pointless backronym.

The context is the scratch pad. LLMs have perfect recall (ignoring "lost in the middle") across the entire context, unlike humans. LLMs "think on paper."

It's because of how transformers work, especially the fact that the output layer is a bunch of weights which we quite literally do a weighted random choice from. My hunch is that diffusion models would have a higher chance of doing real reasoning - or something like a latent space for reasoning.

Thinking that LLMs are intelligent arises from an incomplete understanding of how they work or, alternatively, having shareholders to keep happy.

It does address the GP comment about math.

Other comments indicate that asking it to do long multiplication does work, but the varying results makes sense: LLMs are probabilistic, you probably rolled an unlikely result.

I used the mathematics example only because the GP did. There are many other examples of non-reasoning, including some papers (as recent as Feb).

This is special pleading.

Long multiplication is a trivial form of reasoning that is taught at elementary level. Furthermore, the LLM isn't doing things "in its head" - the headline feature of GPT LLMs is attention across all previous tokens, all of its "thoughts" are on paper. That was Opus with extended reasoning, it had all the opportunity to get it right, but didn't. There are people who can quickly multiply such numbers in their head (I am not one of them).

LLMs don't reason.

LLMs are notoriously terrible at multiplying large numbers: https://claude.ai/share/538f7dca-1c4e-4b51-b887-8eaaf7e6c7d3

> Let me calculate that. 729,278,429 × 2,969,842,939 = 2,165,878,555,365,498,631

Real answer is: https://www.wolframalpha.com/input?i=729278429*2969842939

> 2 165 842 392 930 662 831

Your example seems short enough to not pose a problem.

Pijul isn't a CRDT is it? It's theory of patches (i.e. DARCS++) alongside native conflicts.

I generally use flatpak for things that are important to keep extremely updated, e.g. my browser for vulnerability reasons.

I can completely understand how you were driven away. If you ever want to give it a go again:

> there's "Flakes" which I never quite understood

Nix never clicked for me until I started using flakes. There's a lot of internal drama surrounding them that honestly childish; that's why they are marked as experimental and not the official recommendation. You are going to have a worse time with Nix if you go with the official recommendation, flakes are significantly more intuitive. The Determinate Systems installer enables them by default, and whatever documentation they have is on the happier path (except for FlakeHub, I haven't figured that one out yet).

On the most fundamental level, flakes allow you to take /etc/nixos/nixos.nix (or whatever, it has been forever) out of /etc and into a git repository. Old-style nix may be able to do that, but I discovered flakes before trying. I did previously attempt to use git on /etc/nix, but git was falling to pieces with bizarre ownership problems.

What this means is that I could install and completely configure a machine, once booted into a nix iso, by running: nixos-install --flake https://github.com/.../repo.git. I manage all of my system config out of /home/$user/$clone

As for /home there is home-manager and, again, you are not steered towards it (the tutorial pushes you towards nix profiles/nix-env instead). Home-manager will do for your home directory what the system config does for your system, and has many program modules. You can even declare home-level systemd units and whatnot.

> manually edited /etc files.

You can use environment.etc for these files[1]. systemd.tmpfiles can be used for things outside of etc. Home-manager has the equivalent for .config, .local, .cache. [2].

[1]: https://search.nixos.org/options?channel=unstable&query=envi... [2]: https://home-manager-options.extranix.com/?query=xdg.configF...

> services.desktopManager.gnome.extraGSettingsOverrides =

You can set dconf settings more declaratively: https://tangled.org/jonathan.dickinson.id/nix/blob/7c895ada8...

Give the kid a device that is age-controlled. No need for all devices to support it.

> [Article] What works in GNOME might not work in KDE. What works in both might not work in Sway.

If you subtract GNOME from the set then things become a lot more sane. "Compositor-specific extensions" are really "everyone besides GNOME extensions." The system tray extension isn't KDE-specific. Sure, window positions might not be available at all (because they don't make sense for a TWM), or a user might not have a system tray bar (or you might be on GNOME). However, if they did have a system tray it would be the StatusNotifierItem protocol. Ideally, these should be handled like other platform features like accelerometers etc.. That may not be possible, either way a lot of them can safely noop.

> [Article] For Avalonia, this means "Wayland support" isn't one implementation, it's potentially dozens. We're not just writing a Wayland backend; we're writing a GNOME-Wayland backend, a KDE-Wayland backend, a Sway-Wayland backend,

If you're making per-WM backends then you've fundamentally misunderstood how extensions are supposed to work. Other Wayland client libraries do not have a independent backends for KDE, Sway, and GNOME. Maybe quirks would be needed because you're attempting to support an existing UI library - but those should be few and far between.

IIRC Avalonia supports Vulkan as a rendering backend? Wayland protocols are the same line of thinking as Vulkan extensions.

wlroot and smithay are good examples of what extensions are used in the real world.

Despite how much they would have you believe it, human rights are not a political issue. Politics are used to expand practiced rights (or abused to reduce them), just like politics are involved with providing you access to water.

This is just structured logging. Slog in go, tracing in rust, serilog in C#, etc. You should be combining this with the likes of otel or datadog, which will keep those fields structured and filterable.

I'm not sure about Claude Desktop (it must surely have CLI access?), but I think your line of thinking is correct.

That is through a ADC then DAC, at least for the previous iteration, analog direct to the drivers was not supported. You would be compounding distortion, and largely throwing away what the external DAC+Amp had on offer.

Micro-orms (mapping to parameters and from columns) are generally fine last i read. It is the general aversion to writing a SELECT that is suspect.

I'm a slight audiophile, enough to own a Schitt stack and lower-end planar magnetics, overall cost would be slightly more than the AirPods Max 2. I did try the previous generation and walked away with no emotional response either way to the quality of the sound.

The Apple tax makes me extremely skeptical that I would get $500+ worth of sound quality, however ANC upsets that equation quite a bit. For around the same cost I could get a much better set of DAC+Amp+Headphones but it would sound objectively worse in a noisy environment.

You also can't experience true lossless on any bluetooth audio output device, for what that's worth (many "true" audiophiles would fail an A/B test for AAC).

The previous generation were also REALLY bassy, and there's nothing wrong with that, bassy headphones are how to make things sound "fun" and that's why the likes of Beats make so much money. That categorically makes it not audiophile, though, because it just takes an EQ/pre-amp to achieve the same effect (which can be toggled on and off).

Ultimately, my most basic issue with these is that if you're willing to blow 500 bucks on headphones, then going modular (DAC+Amp+Headphones) will give you more room to explore something that you apparently really enjoy.

Yes, MCP instructions are a blob that is injected at the start of the context. That file is prefixed to the agent specific help[1] for the instructions (that is returned if --help is invoked with CLAUDE=1 or AGENT=1).

[1]: https://github.com/jcdickinson/ferrisfetch/blob/main/cmd/age...

That would work, and is still an option. However I think this makes deployment/installation simpler (which is also why I write my MCPs in go).

In short: JSON. Plan prose or markdown is way more token efficient than JSON. I think that responding in JSON was always a mistake in the spec; it should have been free-form text (which could then be JSON if required).

What I've done with my MCPs is turning them into a CLI, except there's still an MCP server that only has the instructions to tell the the agent about the CLI.[1] Claude and GLM-5 seem to have no problems with it.

As a bonus, the entire thing now works as a plain old CLI too - which it honestly should have from the beginning.

[1]: https://github.com/jcdickinson/ferrisfetch/blob/main/cmd/mcp...

I find that the perception of AI coding is very bimodal, and both camps have it wrong. You have the one camp who will only trust it to, at most, write a few lines of code. The other camp prompts, walks always, and pushes (or just has the AI do it).

I believe both camps it frustratingly wrong. If you haven't yet given it a chance at doing something substantial, then at least _try_ it once. On the other side of the coin, that first experience where it does something 80% right is intoxicating, but AI doesn't reason and can't get it 100% right - it can't even multiply relatively small numbers.

The former camp is going to get left behind and won't be able to compete, the latter camp is one prompt away from a disaster.

I have OTEL + Rust in production, alongside some other languages (+ OTEL), and it is by far more useful and predictable than the others. I often find myself monkey-patching in logging for other language libraries, where with Rust it just works.

(Except for this, that is: https://github.com/tokio-rs/tracing/issues/2519)

An yet people will die on the hill of "republican economics." I truly can't understand it.

> Review by a senior is one of the biggest "silver bullet" illusions managers suffer from.

My manager has been urging us to truly vibe code, just yesterday saying that "language is irrelevant because we've reached the point where it works - so you don't need to see it." This article is a godsend; I'll take this flawed silver bullet any day of the week.

From the article:

> And on nightly it also has support for try fn and gen fn.

I haven't been able to figure out what a try fn is.

I'm terrified by the notion of try fns. Are we getting exceptions (and therefore losing one of rust's greatest features)?