[1] https://www.npr.org/2026/04/11/nx-s1-5778508/anthropic-proje...

> Improvement in AI models' capabilities became noticeable early 2026, said Daniel Stenberg.

> He estimates that about 1 in 10 of the reports are security vulnerabilities, the rest are mostly real bugs. Just three months into 2026, the cURL team Stenberg leads has found and fixed more vulnerabilities than each of the previous two years.

[2] https://www.linkedin.com/posts/danielstenberg_curl-activity-...

> The new #curl, AI, security reality shown with some graphs. Part of my work-in-progress presentation at foss-north on April 28.

You can also run those on smaller cards by configuring the number of layers on the GPU. That should allow you to run the Q4/Q5 version on a 4090, or on older cards.

You could also run it entirely on the CPU/in RAM if you have 32GB (or ideally 64GB) of RAM.

The more you run in RAM the slower the inference.

Type checking allows you to (outside of type casting such as in languages like C/C++ and casting to object for generic containers in Java) verify that an object is of a given type. That allows you to be sure that a well-formed program isn't doing things like putting a random object in a list.

Languages like C#, Scala, and Kotlin improve Java generics by making the generic type of a container or other interface/type part of the type system. This allows generic types of a generic type to preserve the inner type. This makes it possible to implement things like monads and mapping functions to preserve the generic type.

A similar thing is possible with union types, sealed interfaces/traits, etc. that allow you to check and verify the return type instead of defaulting it to a generic object/any type.

Likewise with other features like nullable/non-null annotations (or corresponding nullable type annotations like in Kotlin and recent C# versions).

All of these can be abused/circumvented, but if you keep your code within that framework the compiler will stop that code compiling. Likewise, these solve a limited set of bugs. For example, nullable types can't verify memory management and related bugs.

So it does seem to be specific searches where it gives up after the first 7-10 results (or decides to show you some more related results after 20-30 additional unrelated results).

I wonder if this is algorithmic. E.g. people searching for a specific "how to replace/fix ..." are not going to click on results from their recommended feed, so the algorithm could have learned to keep those results fixed. However, someone looking for a piece of entertainment (trailer, book review, etc.) may be more inclined to click on other unrelated content, so those searches are more inclined to show results from the user's recommended feed.

- `dune book review`

- `sierpinski triangle`

- `full adder` -- better results, but includes an unrelated "previously watched" section

One of the main issues I've encountered is that when searching for something you generally see:

- 7 or so relevant results

- shorts (which I'm not interested in)

- "people also watched" / "previously watched" results -- I'm not interested in that, I just want what I'm looking for

- "channels new to you" -- can include results, so maybe okay

- "explore more" -- mostly irrelevant results to what I'm looking for

- "previously watched" -- may be fine, but mostly unrelated

After the first 7-10 results it generally becomes unusable.

And the default Python XPath support is severely limited, not even a full 1.0 implementation. You can't use the Python XPath support to do things like `element[contains(@attribute, 'value')]` so you need to include an external library to implement XPath.

RDF and the related standards are still used in some areas. If the "Batteries Included" standard library ignores these then those standards will need an external library to support them.

Schema.org is used by Google and other search engines to describe content on the page such as breadcrumbs, publications, paywalled content, cinema screenings, etc. If you are generating websites then you need to produce schema.org metadata to improve the SEO.

Did you notice that a new PNG standard was released in 2025 (last year, with a working draft in 2022) adding support for APNG, HDR, and Exif metadata? Yes, it hasn't changed frequently, but it does change. So if you have PNG support in the standard library you need to update it to support those changes.

And if HTML support is optional then you will need an external library to support it. Hence a "Batteries Included" standard library being incomplete.

The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025.

The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development.

The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions.

The schema.org metadata standard [10] is under active development and is currently on version 30.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (New)

[2] https://web.dev/baseline/2025 -- popover API, plain text content editable, etc.

[3] https://web.dev/baseline/2024 -- exclusive accordions, declarative shadow root DOM

[4] https://web.dev/baseline/2023 -- inert attribute, lazy loading iframes

[5] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (Baseline 2023)

[6] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... (2020)

[7] https://en.wikipedia.org/wiki/PNG

[8] https://en.wikipedia.org/wiki/XPath

[9] https://en.wikipedia.org/wiki/Resource_Description_Framework

[10] https://schema.org/

1. They are not going to include everything. This includes things like new file formats.

2. They are going to be out of date whenever a standard changes (HTML, etc.), application changes (e.g. SQLite/PostgreSQL/etc. for SQL/ORM bindings), or API changes (DirectX, Vulcan, etc.).

3. Things like data structures, graphics APIs, etc. will have performance characteristics that may be different to your use case.

4. They can't cover all nice use cases such as the different libraries and frameworks for creating games of different genres.

For example, Python's XML DOM implementation only implements a subset of XPath and doesn't support parsing HTML.

The fact that Python, Java, and .NET have large library ecosystems proves that even if you have a "Batteries Included" approach there will always be other things to add.

For static content like documents the distinction is easy to determine. When you think about applications, widgets, and other interactive elements the line starts to blur.

Before things like flex layout, positioning content with a 100% height was hard, resulting in JavaScript being used for layout and positioning.

Positioning a dropdown menu, tooltip, or other content required JavaScript. Now you can specify the anchor position of the element via CSS properties. Determining which anchor position to use also required JavaScript, but with things like if() can now be done directly in CSS.

Implementing disclosure elements had to be done with a mix of JavaScript and CSS. Now you can use the details/summary elements and CSS to style the open/close states.

Animation effects when opening an element, on hover, etc. such as easing in colour transitions can easily be done in CSS now. Plus, with the reduced motion media query you can gate those effects to that user preference in CSS.

And there are many adults who play video games to unwind after work.

And it's not just men who play video games. There are a lot of women who play video games including Minecraft and other games, including a huge range of more casual games.

An alternative approach (such as that used by the sodium lighting on Mary Poppins) is that you create two images per frame -- the core image and a mask. The mask is a black and white image where the white pixels are the pixels to keep and the black pixels the ones to discard. Shades of gray indicate blended pixels.

For the mask approach you are filming a perfect alpha channel to apply to the footage that doesn't have the issues of greenscreen. The problem is that this requires specialist, licensed equipment and perfect filming conditions.

The new approach is to take advantage of image/video models to train a model that can produce the alpha channel mask for a given frame (and thus an entire recording) when just given greenscreen footage.

The use of CGI in the training data allows the input image and mask to be perfect without having to spend hundreds of hours creating that data. It's also easier to modify and create variations to test different cases such as reflective or soft edges.

Thus, you have the greenscreen input footage, the expected processed output and alpha channel mask. You can then apply traditional neural net training techniques on the data using the expected image/alpha channel as the target. For example, you can compute the difference on each of the alpha channel output neurons from the expected result, then apply backpropagation to compute the differences through the neural network, and then nudge the neuron weights in the computed gradient direction. Repeat that process across a distribution of the test images over multiple passes until the network no longer changes significantly between passes.

For other things like when asking questions I won't just blindly copy what the LLM is suggesting. I'll often rewrite it in a style that best fits the style of the codebase I'm working on, or to better fit it into what I'm trying to achieve. Also, if I've asked it for how to do a specific one-line query and it has rewritten a whole chunk of code, I'll only make use of that one line, or specific fix/change. -- This also helps me to understand the response from the LLM.

I'll then do testing to make sure that the code is working correctly, with unit tests where relevant.