AFAIK, the Go runtime is pretty NUMA-oblivious. The mcache helps a bit with locality of small allocations, but otherwise, you aren't going to get the same benefits (though I absolutely here you about avoiding execve overhead).
So...yes, the execve overhead is real. BUT there's still a lot you can accomplish with pure bash builtins (which don't have the execve overhead). And, if you're open to rewriting things (which would probably be required to some extent if you were to make something intended for shell to run in Go) you can port whatever you need to run into a bash builtin and bypass the execve overhead that way. In fact, doing that is EXACTLY what forkrun does, and is a big part of why it is so fast.
0. vfork (which is sometimes better than CoW fork) + execve if exec is the only outcome of the spawned child. Or, use posix_spawn where available.
1. Inner-loop hot path code {sh,c}ould be made a bash built-in after proving that it's the source of a real performance bottleneck. (Just say "no" to premature optimization.) Otherwise, rewrite the whole thing in something performant enough like C, C++, Rust, etc.
2. I'm curious about the performance is of forkrun "echo ." in a billion jobs vs. say pure C doing it in 1 thread worker per core.
> I'm curious about the performance is of forkrun "echo ." in a billion jobs vs. say pure C
Short answer: in its fastest mode, forkrun gets very close to the practical dispatch limit for this kind of workload. A tight C loop would still be faster, but at that point you're no longer comparing “parallel job dispatch”—you're comparing raw in-process execution.
Let me try and at least show what kind of performance forkrun gives here. Lets set up 1 billion newlines in a file on a tmpfs
cd /tmp
yes $'\n' | head -n 1000000000 > f1
now lets try frun echo
time { frun echo <f1 >/dev/null; }
real 0m43.779s
user 20m3.801s
sys 0m11.017s
forkrun in its "standard mode" hits about 25 million lines per second running newlines through a no-op (:), and ever so slightly less (23 million lines a second) running them through echo. The vast majority of this time is bash overhead. forkrun breaks up the lines into batches of (up to) 4096 (but for 1 billion lines the average batch size is probably 4095). Then for each batch, a worker-specific data-reading fd is advanced to the correct byte offset where the data starts, and the worker runs
mapfile -t -n $N -u $fd A # N is typically 4096 here
echo "${A[@]}"
The second command (specifically the array expansion into a long list of quoted empty args) is what is taking up the vast majority of the time. frun has a flag (-U) then causes it to replace `"${A[@]}"` with `${A[*]}`, which (in the case of all empty inputs) collapses the long string of quoted empty args into a long list of spaces -> 0 args. This considerably speeds things up when inputs are all empty.
time { frun -U echo <f1 >/dev/null; }
real 0m13.295s
user 6m0.567s
sys 0m7.267s
And now we are at 75 million lines per second. But we are still largely limited by passing data through bash....which is why forkrun also has a mode (`-s`) where it bypasses bash mapfile + array expansion all together and instead splices (via one of the forkrun loadable builtins) data directly to the stdin of whatever you are parallelizing. If you are parallelizing a bash builtin (where there is no execve cost) forkrun gets REALLY fast.
time { frun -s : < f1; }
real 0m0.985s
user 0m13.894s
sys 0m12.398s
which means it is delimiter scanning, dynamically batching and distributing (in batches of up to 4096 lines) at a rate of OVER 1 BILLION LIONES A SECOND or at a rate of ~250,000 batches per second.
At that point the bottleneck is basically just delimiter scanning and kernel-level data movement. There’s very little “scheduler overhead” left to remove—whether you write it in bash+C hybrids (like forkrun) or pure C.
That doesn't exactly limit the impact of cutting off the supply. It's a global trade market. If China buys on the global market from other places instead of Iran because that oil isn't available, that still creates a shortage for everyone and that still pushes up the price of oil for everyone.
However... higher oil prices also increase energy prices across the board, and China's energy sector is dominant in renewables. I think they're more than happy to have the competing energy sources become even more expensive.
Maybe? I wouldn't count on it. The US may be a net petro exporter, but it's about 1% of GDP. The other 99% are not going to do well with inflated energy prices. So exports might net go down.
"These chemicals are not just additives; they may be migrating from the headphones into our body," said Karolina Brabcová, chemical expert at Arnika. "Daily use—especially during exercise when heat and sweat are present—accelerates this migration directly to the skin. Although there is no immediate health risk, long-term exposures, especially vulnerable groups like teenagers, are of great concern. There is no 'safe' level for endocrine disruptors that mimic our natural hormones."
> There is no 'safe' level for endocrine disruptors that mimic our natural hormones
Can someone knowledgeable comment on this? It seems extreme to say there's no safe level.
There's a safe amount of cyanide (apple seeds), radiation (everywhere), safe speed of a bullet flying at you (if I just throw it gently at you) and so on. Even if the cyanide is technically poisoning you, the radiation from bananas is damaging you and the bullet I threw lightly grazed your skin, it's still safe in practical terms.
The lowest concentration of BPA that's been shown to be estrogenic according the second article is 0.1pMol/L which is around 230 picograms per litre of blood, or 1.1ng total for an average adult.
BPA's biological half life in humans is up to two to five hours depending on a range of factors (https://pmc.ncbi.nlm.nih.gov/articles/PMC2685842/), so taking the worst case you'd need to be continually exposed to around 2.5ng of BPA over a day.
So 'safe' as defined right now would be keeping the absorption below that 2.5ng per day threshold.
I don't know how how much BPA in plastics can transfer out per day, the research I've seen seems to indicate that unless it's a food container it's pretty minimal but I don't know enough to evaluate the quality of that research.
Your skin is also a pretty good barrier so only around 2.2% of any BPA on your skin can pass through in an ideal situation, so absorption from non-food sources is much lower (https://pmc.ncbi.nlm.nih.gov/articles/PMC9210257/)
The other problem is what do they replace BPA with? To be safer it would need at least as well studied as BPA, but often it seems like the 'safer' options are just not very well studied yet and could actually be worse.
> research I've seen seems to indicate that unless it's a food container it's pretty minimal
I use glass jars for storing food. One of the reasons is stuff like BPA leaching from the plastic to the food. Another is that it's much easier to have hundreds of identical jars to have a pretty and consistently filled kitchen cabinets. A third is that transparent plastic becomes less transparent after multiple washes with a sponge.
But what I hit "reply" for was to say that heating plays a role. So putting hot food inside a container is likely worse than putting something at room temperature in a container and then putting it in the fridge.
> 1.1 ng total for an average adult
Wow, that's so little. I wonder if malicious BPA poisoning cases have been reported. It's probably undetectable unless you search for it specifically.
> The other problem is what do they replace BPA with?
I remember reading that BPA could be replaced with BPB. Obviously it may be OK, but to a layman it's like saying "we no longer add rat shit to our food, now it's bat shit".
1.1ng is a very small amount, but the effect is really not that well understood. It’s definitely something we should minimise.
However it’s not a dangerous dose, it’s just the dose that produces detectable changes and we can detect really really small changes. The toxic dose is around 4g/kg body weight. So an average adult would need to consume over 300 grams of pure BPA to be poisoned by it.
Of course the answer is to use non-plastic containers, though the most common plastic used for food (PET - milk bottles, most soft drinks etc) don’t contain any BPA. It’s the reusable ones that do.
I have glass containers for food, though I do still use plastic ones for short term storage for things I won’t heat. Honestly this seems like the best answer, metal, wood and glass if you can.
For things you put on your skin that could be absorbed, shouldn't the limit take into account the area touching your skin? If I lay on a bed containing 10 mg/kg BPA, I would absorb a lot more than if I touch a headphone. So maybe it should be mg/kg*m^2 or something?
The article is actually IMHO overly conservative. This kind of migration is not a theoretical risk, but well established. BPA is a small molecule, not covalently bound to the plastic. It absolutely goes into the skin. Heat, water, and acidity (sweat is slightly acidic) all accelerate the absorption.
Plus absorption through the skin is worse than oral. Because when you eat it your liver breaks a lot of it down. When it goes in the skin it bypasses all that.
Good point. And diving in I realize my fear was mostly unfounded. Compared to typical background exposure (what we can infer people are getting through other sources by looking at their urine) this is insignificant, except for the very worst headphones. The headline is unsurprisingly alarmist, because by their own data 68% have acceptably very low bpa. But the very few with the worst amounts drag up the arithmetic average to something scary sounding.
To estimate how much gets into the body
https://oehha.ca.gov/sites/default/files/media/downloads/crn...
Is a good reference. Interpolating from that, a typical pair of in-ear buds works out to something like a fraction of a nanogram per kg bodyweight per day, versus 30–130 ng/kg/day from background. So totally negligible. Even the worst case - highest measured concentration, assuming over ear headphones (much more contact area), and a hot sweaty workout, you’re looking at maybe 5ng/kg/day - still in the range of dietary background, but not good.
Because the em-dashes? In a professionally typeset article, the presence of em-dashes isn't really suspicious because that's how they're supposed to be used. AI learned to use em-dashes somehow, it's not like they invented the concept.
The Guardian printed the same quote without em-dashes, and with spaces around hyphens instead. https://www.theguardian.com/technology/2026/feb/18/hazardous... And in the next paragraph of the Arnika article, they have em-dashes surrounded by spaces, in contrast to the quotation which doesn't leave any space around them. It's not clear where the style choices were made in the quote.
Doesn't matter. Under the US Court of Appeals ruling, the agreement to the terms of GPLv3 would apply, at which point all associated software would be subject to GPLv3 terms. Even if one remade everything from scratch with an AI, one would remain subject to the terms of the license.
> LLMs won't add information to context, so if the output is larger than the input then it's slop
That doesn't align with my observations. A lot of times they are able to add information to context. Sure it's information I could have added myself, but they save me the time. They also do a great job of taking relatively terse context and expanding upon it so that it is more accessible to someone who lacks context. Brevity is often preferable, but that doesn't mean larger input is necessarily slop.
Yup. The comment about the LLM generated PRs is telling. The complain is the LLM generated PRs don't describe design intent. You know how to avoid that? Tell the LLM to provide intent, and if need be, give it the intent. A PR which doesn't capture intent should be categorically rejected and the parties responsible should expect to never get a PR through without it.
I think mistercheph is right to be concerned. This bill applies to all "operating system providers", defined thusly:
(g) “Operating system provider” means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.
Regarding penalities:
1798.503. (a) A person that violates this title shall be subject to an injunction and liable for a civil penalty of not more than two thousand five hundred dollars ($2,500) per affected child for each negligent violation or not more than seven thousand five hundred dollars ($7,500) per affected child for each intentional violation, which shall be assessed and recovered only in a civil action brought in the name of the people of the State of California by the Attorney General.
>This bill applies to all "operating system providers", ...
Not really.
>...for the purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store.
So the OS has to provide an age signal to apps from a "covered application store" defined as:
e) (1) “Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers to users of a computer, a mobile device, or any other general purpose computing that can access a covered application store or can download an application.
(2) “Covered application store” does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application.
It doesn't say "only if there's a covered application store present on the system". But maybe everyone in power will interpret this non-logically in exactly the right way that this doesn't become abusive.
Wouldn’t that classification apply to Linux package managers as well?
They are publicly available online services that distribute and facilitate the download of applications from third party developers to users of a general purpose computing device.
That may not be the intent, but it seems like it would still apply. Many of the “app stores” on Linux are just front ends for the package manager in some way.
I assume the people behind this don’t know things like apt or dnf exist, so it likely wasn’t considered.
There are a large number of things that the people behind this don't know about. That doesn't mean that they screwed up. It means that the law does not apply to those things.
reply