Recently posted comments [LWN.net]

negative-order folios

Posted May 11, 2026 21:10 UTC (Mon) by willy (subscriber, #9762)
In reply to: negative-order folios by david.hildenbrand
Parent article: Providing 64KB base pages with 4KB kernels, two different ways

I think that was me. I talked about it a bit here:

https://lore.kernel.org/linux-mm/afIYFtL6KrBs38rT@casper....

but I wouldn't propose a negative order folio for a couple of reasons. I understand why our overworked scribe recorded it that way though; I'm sure my spoken words weren't perfectly clear.

First, folios are always >= PAGE_SIZE. As long as we want to be able to mmap things, they have to be PAGE_SIZE.

Second, allowing negative orders to the page allocator could never be more than a hack. That's just an unreasonable mental workload to any user. Instead, introduce a new interface that allows allocation of memory in units of 512 (rather than units of PAGE_SIZE) and reimplement alloc_page() as a wrapper around it.

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 21:09 UTC (Mon) by rgmoore (✭ supporter ✭, #75)
In reply to: "Reproducible" sounds like a yes/no question but it's not by marcH
Parent article: Debian to require reproducible builds

What I meant was that people don't care if the build can be reproduced by jumping through enough hoops; they want to know if they can do it through some easy to implement process on their own machine. As I understand it, that's what Debian is aiming for. The long-term goal is for reproducibility to be a standard part of the process. Anyone who builds the same source package using the same tools should get the same output except the cryptographic signature. The point of the caveat in the announcement is that they have taken an important step but haven't reached that long-term goal yet.

Is that not the LLM guy?

Posted May 11, 2026 20:55 UTC (Mon) by mirabilos (subscriber, #84359)
In reply to: Is that not the LLM guy? by farnz
Parent article: killswitch for short-term emergency vulnerability mitigation

> The last I saw, the US Copyright Office had said that the AI cannot be a
> copyright holder on an AI generated work

That, yes (that much is obvious, it has to be human creativity), but they did NOT rule out that copyright from authors of “training data” applies.

Toss legacy stuff to VMs?

Posted May 11, 2026 20:48 UTC (Mon) by mathstuf (subscriber, #69389)
In reply to: Toss legacy stuff to VMs? by DemiMarie
Parent article: Providing 64KB base pages with 4KB kernels, two different ways

Some kind of `binfmt_misc` with QEMU mediating perhaps?

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 20:39 UTC (Mon) by marcH (subscriber, #57642)
In reply to: "Reproducible" sounds like a yes/no question but it's not by rgmoore
Parent article: Debian to require reproducible builds

> whether a build is theoretically reproducible but...

Define "theoretically reproducible".

Best of luck.

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 20:33 UTC (Mon) by rgmoore (✭ supporter ✭, #75)
In reply to: "Reproducible" sounds like a yes/no question but it's not by farnz
Parent article: Debian to require reproducible builds

I think a better way of saying it is that the question most people care about isn't whether a build is theoretically reproducible but whether they can reproduce it themselves. As I understand it, Debian's long-term goal with reproducible builds isn't just to let them reproduce builds on their build farm; it's to let any user build a bit-for-bit identical version of the distribution package on their local system. They definitely haven't reached that goal yet.

Is that not the LLM guy?

Posted May 11, 2026 20:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Is that not the LLM guy? by JoeBuck
Parent article: killswitch for short-term emergency vulnerability mitigation

It's likely that we'll see the protection applied to the _prompt_.

So if you ask the LLM to "fix this issue", then the result is not going to be copyrightable. But if you provide a detailed step-by-step spec for the fix, the result might be protected.

Is that not the LLM guy?

Posted May 11, 2026 20:28 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Is that not the LLM guy? by JoeBuck
Parent article: killswitch for short-term emergency vulnerability mitigation

Have you a link for this?

The last I saw, the US Copyright Office had said that the AI cannot be a copyright holder on an AI generated work, and thus that where the attempt at registering a work explicitly states that the AI is the sole author, there is no copyright.

However, this does not mean that AI generated works aren't protected by copyright; where the AI is used as a tool by a human, there's room for the human input to be enough to reach the bar needed to make the work protected by copyright.

It's essentially, in law, the same position as Emacs; if you claim that the work is purely produced by Emacs, then it can't be protected by copyright (since Emacs is a tool, not a human), but if you claim that the work is produced with Emacs driven by a human being, the resulting work can be protected by copyright. Substitute "AI" for "Emacs", and you get the answer the US Copyright Office came to, last time I looked.

Is that not the LLM guy?

Posted May 11, 2026 20:13 UTC (Mon) by JoeBuck (subscriber, #2330)
In reply to: Is that not the LLM guy? by mirabilos
Parent article: killswitch for short-term emergency vulnerability mitigation

Are you sure? The US Copyright Offfice has said that AI generated works aren't protected by copyright, which basically means public domain. So if a patch is partly AI-generated and partly human-written, and the human contributor wants to use GPL 2.0, then the combined work is GPL plus public domain code. So, legal to distribute under the GPL.

Of course, IANAL.

Toss legacy stuff to VMs?

Posted May 11, 2026 19:25 UTC (Mon) by DemiMarie (subscriber, #164188)
Parent article: Providing 64KB base pages with 4KB kernels, two different ways

Can legacy stuff be made to run in legacy VMs, while the modern stuff that fetches page size at runtime gets to run natively?

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 18:44 UTC (Mon) by farnz (subscriber, #17727)
In reply to: "Reproducible" sounds like a yes/no question but it's not by marcH
Parent article: Debian to require reproducible builds

Again, no such thing as a binary question given the restrictions you put on it.

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 18:37 UTC (Mon) by marcH (subscriber, #57642)
In reply to: "Reproducible" sounds like a yes/no question but it's not by farnz
Parent article: Debian to require reproducible builds

> because enough of it...

Again: not binary.

rseq vs load_acquire then store_release

Posted May 11, 2026 18:36 UTC (Mon) by anton (subscriber, #25547)
In reply to: rseq vs load_acquire then store_release by farnz
Parent article: Restartable sequences, TCMalloc, and Hyrum's Law

They certainly had their share of bugs in TSX instructions, but it makes no sense to leave them enabled in large Xeons if they have not fixed the bugs.

My guess is that TSX is disabled completely in the consumer and small Xeon CPUs because it provides a high-bandwidth speculative side channel attack opportunity. For the larger Xeons, Intel did not completely disable it because SAP HANA uses it, but I expect that only Xeons that run only trusted users will have it enabled, and the others will disable it in the BIOS or so.

Now to test the tests

Posted May 11, 2026 18:34 UTC (Mon) by jd (guest, #26381)
In reply to: Now to test the tests by epa
Parent article: Stenberg: Mythos finds a curl vulnerability

This may well spur people into introducing contract-based programming into C and C++.

In languages like SPARK, you specify at the head of a function what must be true at the start and end of the function, and the compiler verifies that these constraints will always hold.

It's not perfect, you can write non-secure code in SPARK, but beyond advising and assisting static checkers, you cannot make code impervious to skillful corruption. I'm going to say that probably about the best you can do is place constraints on the damage that can be done.

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 17:08 UTC (Mon) by farnz (subscriber, #17727)
In reply to: "Reproducible" sounds like a yes/no question but it's not by iabervon
Parent article: Debian to require reproducible builds

If the process isn't recorded, you can't "follow the same process", because you don't know what the process is - and this goes doubly for builds with things like timestamps in, where part of "the process" is "ensure that your build system's timekeeping matches the original build host perfectly"/

A reproducible build is one where you can follow the same process, because enough of it is recorded/documented that you can do the same thing and get the same output.

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 17:05 UTC (Mon) by iabervon (subscriber, #722)
In reply to: "Reproducible" sounds like a yes/no question but it's not by farnz
Parent article: Debian to require reproducible builds

Every build is reproducible, if you "follow the same process" closely enough. It's all a matter of allowing the process to be slightly different ("your RNG doesn't have to produce the same values mine did", "your clock could be different from what mine was in each step", "your username/hostname/directory could be anything you want") and still getting the same output. Exactly what needs to be able to vary is where the shades of meaning come in, and containers allow for specifying things to be part of the process that would traditionally not be reasonable to specify (e.g., "in order to reproduce this build, build in a container where the hostname is the hostname of the physical machine that did the build the first time"), but that isn't necessarily fair game for everyone.

Pardon the naive question...

Posted May 11, 2026 16:57 UTC (Mon) by tuig (guest, #183721)
In reply to: Pardon the naive question... by cypherpunks2
Parent article: More stable kernels with partial Dirty Frag fixes

Verifying checksums with the package is useful after filesystems somehow got damaged. It's not useful as a way to detect ownage. Querying the box itself for ownage is pointless. "Nothing to see here, pinky promise!"

Flatten and rebuild is better and even that might not be enough when the box itself can reprogram an eeprom. This is why hardware freedom has become at least as important as software freedom. Easier to audit, inspect and generally reason with.

"Reproducible" sounds like a yes/no question but it's not

Posted May 11, 2026 16:57 UTC (Mon) by farnz (subscriber, #17727)
In reply to: "Reproducible" sounds like a yes/no question but it's not by marcH
Parent article: Debian to require reproducible builds

Defining "same process" is simple - it's the process that the person claiming you can reproduce their build says you need to use to get the same binary.

And by your definition, there is no such thing as a yes/no question - even something like "are you in France?" is not a yes/no question, let alone something like "is it possible to travel from Paris to Lille?".

The base question of "is it possible to reproduce a binary build" is yes/no; but, like any other "yes/no" question, there's a whole bunch of detail that comes into "how easy is it to reproduce a build".

Now to test the tests

Posted May 11, 2026 16:50 UTC (Mon) by hailfinger (subscriber, #76962)
In reply to: Now to test the tests by epa
Parent article: Stenberg: Mythos finds a curl vulnerability

We already had something similar a few years ago. It's called the the Underhanded C Contest: https://www.underhanded-c.org/

Respect?

Posted May 11, 2026 16:31 UTC (Mon) by karath (subscriber, #19025)
In reply to: Is that not the LLM guy? by mirabilos
Parent article: killswitch for short-term emergency vulnerability mitigation

When I read this kind of comment, I feel that the author is accusing me of being a torturer.

LLMs should not get a free pass just because they are new and shiny.
* Some of the LLM creators appear to have stolen copyrighted materials (by downloading torrents of copyrighted materials that were not freely available). I would love to see one or more of those culprits bankrupted after being found guilty.
* Many of the LLM creators or their agents have ignored robots.txt and brought the servers of freely available copyrighted materials to their knees (and non copyrighted material too). It seems that none of the culprits will face any noticeable consequences.
* Some LLM creators have fed so many duplicated copies of copyrighted materials into their training that, with careful prompting, the LLM can regurgitate derivative material. However some of that prompting likely would be considered entrapment if done by police authorities to a human.
* Many people believe that LLMs deprive us all of reasonably priced water and/or electricity and that they create massive pollution. Honestly, I’m sceptical of many of these claims. I believe that there is massive overbuilding of datacentres, however it’s not clear that these datacenters are all built for AI. Much of the overbuilding seems to be speculative by 3rd parties that hope to get AI or cloud customers.
* Many people worry that AI will take their job, and I think that some will. However the consensus in the thoughtful press seems to be that the current wave of redundancies is driven by the consequences of overhiring during the COVID period. Of course, CEOs would prefer to have it known that it was AI rather than their mismanagement,

On the other hand, the only case ruling on the copyright status of LLM output that I know about seems to have carefully crafted to state that the specific LLM was not capable being a copyright holder, while allowing that a future tool might be.

Governments and courts in Europe, China, and the USA, largely seem to support the concept that the output of an LLM should be held to the same burden of proof for copyright infringement as a human person. That is: can the output be shown to infringe the expression of a specific work rather than the concepts and ideas.

In summary, I’d request that the virulently anti-LLM commenters treat others with respect and specifically not tag me as a monster because I start from a different place than you.