I think they meant in terms of karma/reputation for the individual, and the project. Traditionally open source is heavily based on these social currencies.
You don't really have to guess. The guy told us the AI didn't suggest this specific change:
> The change to zero memory was my idea and my change. It was a reaction to a security report I got which caused use of an element past the end of an array. By zeroing the allocation I could ensure that misuse of that memory if a similar bug came up in the future could only cause a null ptr deref, which is better than the chance of a valid pointer.
It got a claude co-authored tag on it as I got it to do some tidy ups of a series of commits, and that is just what it does when it makes any modification. It doesn't mean the change was written by claude. It was written by me.
How does that prevent reading past the end of the buffer? Or change how bytes outside the buffer are used? Are these arrays of pointers so that the “null ptr deref” comment makes sense?
Or am I the bozo and don’t know what’s happening here?
It doesn’t. It’s just that dereferencing a zeroed pointer reliably crashes the program (unless you specifically do funky things with mmap) but dereferencing garbage memory as a pointer could do a lot more insidious damage.
Haven't looked at the code, but the allocated memory could be larger than necessary to make "off-by-one" or "off-by-a-few" errors less deadly. Then zeroing it out makes it even less so. Defense in depth.
Or it's an allocation for an arena? The zeroing might help trigger 0 derefs earlier if the overrun happens for the object that are then allocated in the arena (and not by allocating more objects than the arena can provide)
The code is part of a function called expand item list. It looks like it over allocates memory and uses a bump pointer for internal allocation, only expanding the allocation when necessary. Thus OOB writes to the list would hit the allocated memory.
You’re not a bozo but it is helpful to read the code.
okay I had not read this or any discussions there (except the one linked in the post), but this looks weirder. the comment you linked is a dev responding to what is very clearly a bot comment. I am sure they have good intentions and I have no reason to believe otherwise as I have no connection to the project whatsoever, but the original commit being 4-5 lines long (what did claude do then?) and the revert description is almost certainly written by an LLM makes in my mind the slop argument stronger.
I hope if this doesn't come across as unkind towards the dev who gives their time and energy to the project. Grateful for that.
I think we're past beginning to warn, we've now reached the point of accepting Linux needs to remove drivers and features, because the maintainers just can't keep up.
This is not helped by everyone using the same LLMs to find the same vulnerabilities and flooding maintainers with duplicate reports to be the first to get that CVE and branded vuln on their resume.
Not really - it changes how the lines are drawn between components, rather than removing any of them.
The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.
The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.
Behind my question was another one: is there too much in the source tree that doesn't _strictly_ need to be?
Maybe not?
I just got the impression that there are a _lot_ of obscure drivers that have to be carried, and are eventually removed causing annoyance. An ABI for the people who cared about that random driver might localise the maintenance burden.
> An ABI for the people who cared about that random driver might localise the maintenance burden.
Yes, but one key reason that a stable ABI isn't provided for drivers is to help encourage companies that ship drivers to make their drivers open source. The idea being, if a driver is mainlined into the Linux kernel, the Linux developers will help maintain support for that driver, in exchange for it being released with an open source licence. There are companies (like NVIDIA) that ship closed source drivers for their devices, but they rely on a kernel-side shim that interacts with the userspace driver, and this is seen as second best compared to mainlining the driver in the kernel.
There are numerous advantages of microkernels over monoliths, but even if Linux were a microkernel it wouldn't necessarily change the review pressure that the above commenter is talking about, because you still have the same number of components (filesystem, networking, drivers, etc) to develop and review patches for (although you do have more well-defined interfaces between components, which eases security).
> Everything thinks they are special, actually no one is.
That sounds very nice, but isn't true. Most of the people I know, myself included, don't consider themselves special broadly. They're special in their own community, but not globally.
"Oh what peril we are in where I must get rich by killing all of you" Is a statement that should make you disregard anyone saying it at any time. Either they are liars, or they are so morally bankrupt that they are willing to sacrifice the species for short term satisfaction. Either option makes them more fit for a mental hospital than a stage.
I think you agree with the OP. In this way, the tool has no ethical problem (there are plenty around how they were trained and such, but that's besides the point), the problems are with how it's used. The ethical problem is how people are behaving and how they are abusing each other, not the tool they are using to exert that abuse.
I suppose it's a little bit of a "guns don't kill people" argument.
The tools have different ranges of uses. A knife can be used to cut things. But while humans are among the things you can cut with it, there is a staggering array of other options which are genuinely useful in everyday life.
A gun can be used to, uh, make small but deep perforations at a distance, by throwing apx. 7 grams of copper-encased lead at high velocity at the target, with somewhat poor precision. Oh, and such an impact does stress/shatter the material around the made perforation quite a lot. So... this thing really can't be used for much anything except for killing animals without getting into contact with them, due to the peculiar way the life is sustained in the animal organisms. This, too, can be useful in everyday life although I personally would advise you, if you find yourself in such a situation, to try and move to somewhere nicer.
It's comforting to blame it on "MBAs", but i think it's pretty clear that silicon valley has been entirely captured by the "hardcore grindset" segment of the manosphere.
But he's also not recommending 40 hours, he's recommending 150% of that. Even then, I'd assume that when he says "sweet spot" he's also talking about a median, meaning you'll have to put in additional hours sometimes.
Well the GPL (which rsync is licensed under) says: "This program comes with ABSOLUTELY NO WARRANTY" so actually nobody is responsible for anything.
reply