But in general I would think 4 times about installing any AUR package no longer reasonable reviewable in the parts not either in official packages or the upstream source (including patches, dependencies, etc.).

Sometimes throwing something into an untrusted OCI image you run in a VM (instead of lightweight containers) is just the better option... sadly, also often still painful to setup.

it happens all the time

Just not always on this scale and doesn't always end up on HN.

Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN.

In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. (As in: Most packages are a small amount of glue between pacman and a upstream source.)

As consequence AUR packages with AUR dependencies are in general "uh..., lets not do it" cases for me, as on one hand the review overhead can be a pain and on the other hand it's easy to make a mistake overlooking a change in AUR dependencies.

Still the policy which allows relatively easy adoption of orphaned packages is IMHO a problem. A adoption should be treated as a new package which just happen to have the same name. (It can be fine to not have that if arch maintainers "bless" the adoption, but IMHO that would only matter for a view very widely used packages which are candidates to be included in the official repo but aren't for e.g. license reasons.)

through the message does allow an additional display name (like `display name `) which has it's own rules.

Is correct, you can have quoted local parts and (I guess?) theoretically "foo"@mail and foo@mail should even be treated the same.

But practically this is a dead feature and probably should be treated as non existing.

AFIK `[Also interestingly the `[..]` syntax has a generic extension hook, and that hook allows usage of @ characters. So technically a `foo@[custom:@@@@@@@@]` is a valid mail address, just no one knows how to deliver it ;). (And `custom` must be registered with IANA, theoretically).

the funny part is this is only half true

The true part: Punycode has never be standardized for the localpart and as such taking a email address with non us-ascii characters in the local part and punycode encoding it is fundamentally wrong.

But: Nothing prevents you to have a local part which "happens" to look like punycode and especially in the early SMTPUTF8 days many providers which did allow non-us-ascii email local parts automatically created an "alias" email address where the local part was punycode encoded. Nothing in the standard prevents this and as consequence punycode encoding a local part _might_ just happen to work for some subset of non-us-ascii emails.

like think about it it's pretty much a tool which intentionally silently sabotages you if you try to compete with the tool maker

It is like selling a hammer but putting in the TOS that you must not use it to build a hammer factory and if you do the hammer silently will sabotage you...

Or image Microsoft would add a window kernel job which sometimes crashes Steam "to make it less efficient to use windows to "compete with the MS app store".

it clearly (enough, kinda) communicated

1. what data they keep/collect

2. what they do with it (and that there is a reason to have it)

3. with whom they share it

4. how long they keep it

---

GDPR might require data minimalism, but that doesn't mean you can't keep "all" conversations/data. It just means you have to have a reason of why exactly need all of it (they have), only keep it as long as strictly necessary (they do) and not use it for other purposes (they claim to do that).

Also from a legal POV you can't really argue that collecting all conversations for detecting abuse patterns is "unreasonable"/"unnecessary" or similar, as to some degree the AI Act requires exactly that for "high risk" AIs/use cases. And while by the definition of the AI Act AWS Bedrock likely doesn't fall under "high risk" they can argue that some people could (against TOS) use it for "high risk" or "illegal" AI use cases which is part of the "misuse detection" thing for which they keep conversations for a month.

Lastly GDRP deletion requests still apply. But need to be processed within ... 1 month (wich AFIK in a generic duration context you can treat as 30 days, even through there is a single shorter month). So they "auto comply" with this, too.

think about it, it would be absurd if you had to redefine deceptive, misleading or negligent business practices for every single kind of product anew.

So instead they define it once, in a generic way. But companies tend to try to knowingly stretch and often outright breach this generic definitions in hope to lawyer bs themself out of it. And sadly they do too often succeed to at least avoid keeping to the law during the initial marked capture :(. This is a huge problem, but not suing and nit picking regulating everything again and again and again for each new kind of product would make this problem _way_ worse.

This doesn't mean that regulations which "clarify" what this means for a specific field/product would not be desirable. They are a very desired improvement IMHO. But not because companies would then keep to the law, they make more money by ignoring it, but to cut down cost/time when suing for a breach ...

Or to put it differently, most countries do require companies to act non-negligent _as most fundamental baseline_ (through many different laws/regulations), if you very clearly do act negligent or even malicious/deceptive then you can't complain if they sue.

and a lot of "smooth" aerodynamic surfaces have "microscopic"/"very small" surface patterns to make the surface less perfect smooth as if it is too perfect smooth the air kinda "sticks" to it increasing drag (to say it in a very unscientific way)

but also on the other hand in Germany problems with allergies are very common and a pretty big deal for many people, it's just that we got used to it

but also while Germany has not-very-diverse "tree farms" for a very long time, the level of monoculture got way worse in the last 70-100 years AFIK, especially after WW2 the only way to cope with the extreme high demand was to mostly plant very fast growing trees. I.e. mostly spruce and pine.

Idk. if allergies got worse due to this and we just didn't notice because of having so much bigger problems (like many cities lying in ashes) or if Germany always had similar bad allergy problems. But this WW2 induced increase in monoculture is still a huge problem even ignoring allergies as this made German forests especially susceptible to things like pests and adding stress from climate change has lead to mass dying of trees in some regions.

It seems to be more about:

1. auto grouping duplicate security reports

2. auto validating if they are likely viable or likely nonsense

3. auto checking if they have recently been patched

4. auto assessing if they likely "invalide" for other reasons (e.g. they are for a very old long time no longer maintained Linux version, out of tree drivers, etc.)

I mean practically all of that isn't trivial to get working in a way appropriate for the Linux security mailing list and comes with many not so obvious complications. But also non of that is vibe coding and in most cases this is is more about AI doing a per-assemsment of send security issues to speed up the review of them, then it is about the AI doing the final decision.

it's just that in the past people most times didn't find security vulnerabilities independently of each other without knowing about the others en mass

worse it's non trivial to dedup on the submitter side, nor on the receiver site (as long as we stay with a classical mailing list format)

and while this might be fixable with an AI auto grouping duplicates etc. getting that right is _hard_ especially if we consider that there can be a lot to gain for an adversary to use prompt injection and similar to cause an effective "hiding" of "useful" security issues (e.g. by wrongly causing them being labeling as duplicate).

In addition to all the technical problems this causes some other problems: 1.) additional cost you can intentional (maliciously) increase 2.) dependence on some LLM provider 3.) trust problem wrt. the used LLM provider. Some of this can be avoided by running open models on sponsored owned hardware, but at the cost of often outdated LLM tech, higher cost, now needing to maintain additional hardware etc.

- what all studies show is some vague "craving" for something generic, e.g. the link between iron deficiency and craving for ice

- but what you see in autists is often a far stronger effect and not just for eating something, but also against eating most other food. A craving for chocolate does not remove appetite and willingness to eat other food. It just makes you really want to eat chocolate.

- more important the way autistic people get fixated on a monotonous diet is far more specific then any effects we have observed from gut bacteria or other similar sources AFIK. Like lets say your gut bacteria might make you crave fish. You autism on the other hand might make you crave dino formed fish sticks with a specific texture. And there is just no way gut bacteria care about your fish sticks being dino formed or the specific texture of them... But a autistic person often does care, quite a bit even.

autists have often a much much stronger need for habits and avoidance of change. This includes a change of, or a less repeting/habitual diet. The effect if applified due to autism being commonly comorbid with ADHD and hyper fixation on specific foods being a very common thing (not (mainly) caused by gut bacteria as the effect is too strong and too specific to be "just" a preference caused by gut bacteria)

but this can lead to a imbalance of gut bacteria and that can have an reinforcing effect on wanting a even more monotonous diet, but in the end this is AFIK "just" a secondary reinforcing reason not the root cause

> reduce autism symptoms

> chronic gastrointestinal issues are a harsh reality

> boosting microbial diversity

> when [...] treat those gastrointestinal problems, their behavior improves

Through my opinionated take is:

- gastrointestinal issue are a common comorbidity of autism

- fixing that help autistic people to mask better/easier

- which makes a lot of sense as gastrointestinal issue are very stressful and so is masking. It's quite common that autistic people under stress have a harder time masking

- and masking is removing many of the "symptoms" of autism at cost of stress and other risks (e.g. depression), and society(^1) is conditioning(^2) children to mask autism subconsciously all the time

(^1): Pretty much any society out there.

(^2): Both intentional and accidental. For most autistic people masking isn't a conscious choice, but something through live so strongly reinforced that it's done unconsciously even if they don't want to in any situation except a private one with at most some very trusted people around.

---

Through a much more disturbing implication from this article is that at least in US/Arizona children with gastrointestinal issues commonly do not get appropriate treatment... Or else they couldn't have done the test as they wouldn't have found a non highly selection biased sample of autistic children.

Like treating of gastrointestinal issues shouldn't be a thing you do to reduce autistic symptoms, but something you do anyway. Even if not for quality of live, then for the reason of such issues often causing much more server long term issues if they stay untreated for years.

which is somewhat close to what their port produced...

like their goal was from the get to go to have a mostly exactly the same as zig "just in rust" which implies mostly unsafe rust and all the soundness/memory issues zig has (plus probably some more due to AI based port instead of a tool like c2ruts)

the thing is if you don't keep things mostly 1:1 with all the problems that has there is absolutely no way to review that PR or catch the AI going rogue with hallucinations etc. With a mostly 1:1 port you can at least check if things seem mostly the same.

but it also means this is just step 1 of very many, with the other being incrementally fixing soundness, removing unsafe and (hopefully) making the code more idiomatic...

(to got to the actual question of why?, I think the answer is doing this port using AI is likely way easier/faster then first writing a tool which need in depth understanding of the languages, especially given that some features in zig do not map 1:1 in rust and fuzzily mapping is what LLMs are good at and human hand written tools tend to be very bad at).

they didn't,

actually the port is trying to be mostly 1:1 and in turn is mostly unsafe rust, which means no benefits initially

but also doing the 1:1 port to mostly unsafe rust is also only the first step of a full port, you then incrementally go through it fixing issues and remove "unsafe" usage. (And long term likely also doing some refactoring to using more idiomatic rust, but that has less priority).

The problem is there was no blog port describing the whole thing to someone without contextual knowledge. Instead just linked PRs which is in this case somewhat close to a "as if nearly all people only read the HN headline" case :/

Like a more context giving version of the first HN post would have something on the line of `Show HN: Bun is porting to safe rust (PR link), starting with an AI based automatized port to mostly unsafe rust which once it behaves mostly the same as Bun in the test suite will likely be merged. But must be followed up with incremental PRs to remove unsafeness, and likely also a lot of unsoundness related to the way it's ported (some explanation about why this port will have unsoundness).`

not relevant IMHO

we don't live anymore in a time where you can trust that local apps do not misbehave, and in such a context LPE is pretty bad even in a single user system

just thing about all the supply chain problems of recent times

so not really useful for 3rd party ROMs