It's pretty consistent. If you check out something from a Gentoo-official repo, it's going to have been created by humans without the use of LLM tooling. LLM tooling is used for the kernel, systemd, and a litany of other packages -- trying to run a "non-LLM OS" is more like a fork of the whole ecosystem than a distribution.
I can appreciate the concept that Gentoo is placing a high value on human curation. I used to be firmly against our anti-LLM policy, but honestly it's a pretty strong differentiator from other distributions -- and I'm getting more and more sick of AI tech in general.
Been using Gentoo for over 20 years and have accepted PRs to the repo.
I don't get any value from this "no LLMs" stance. In fact it's quite the opposite.
I watch extremely famous C devs at work using LLMs all day everyday working on stuff that is merged into Gentoo all the time. You guys are shooting yourselves in the foot and just wasting everyone's time and it's exhausting.
This workaround only applies to kernels with the impacted code compiled as a module. RHEL, Fedora, and Gentoo (we use a modified Fedora config) all are configured to build this in directly. Without a patch or config change (as Sam from Gentoo was alluding to), those distributions remain vulnerable.
For compiled-in kernels you can also work around it without rebooting via apparmor, seccomp or SELinux at the least, there may be eBPF or other methods too.
These categories of vulnerability are not new: https://dgl.cx/2023/09/ansi-terminal-security -- any time you take any untrusted data and do literally anything with it, you're at risk.
I used this for a while. It doesn't display HTML emails just fine. It only supports a subset of stuff which -- as a geek is awesome because it protects me -- but would be hideous to give to a normal user. Literally less than half of my emails were readable.
As someone with deep experience in MIME encoding/parts, HTML for emails, and email client support for different HTML/CSS/image content, this is a sinkhole.
The world will be better off when we fork HTML so there is one standard email-safe version that all modern email clients support natively. There’s entirely too much security surface area to put arbitrary HTML into emails and expect any 2 email clients to render it correctly / the same.
> There’s entirely too much security surface area to put arbitrary HTML into emails ...
We manage it with browsers though.
Don't get me wrong, I've never liked html in emails to begin with. It's the same issue that markdown and every other rich text system has regarding where to draw the line. HN even strips most emojis (and I think that's a good thing).
When emojis are stripped on one website, users of that website understand it’s a product limitation.
When links work on one email client but not another, that’s a huge issue for the email sender and a lot of headache to learn/study the differences between email clients and the stack they are built on.
The difference between HTML and CSS properties supported on different email clients is WILD.[1] the rendering differences are significant, as are the man hours required to get emails to mostly look predictable on the breadth of email clients in use today.
And remember that every time there is a browser engine (or even just a fork) people have to maintain it. They need to develop features, squash bugs, patch security issues, pull from upstream, coordinate with downstream forks, etc. webmail providers are SaaS but have to have intricate and accurate understanding of every browser parse / rendering bug/permutation and a deep understanding of all of the legit HTML/CSS/JavaScript/DOM/XML/images/URLs (including weird ones like data: blobs) supported by every browser.
“we manage it” is doing an insane amount of hiding the complexity there.
I never claimed email clients were uniform (that would obviously be incorrect). I responded to "too much security surface area" with "browsers seem to manage it". The security is clearly a solvable problem because we all use the solution every day.
In your analogy, different email clients equate to different products (ie websites). I agree that it's a headache for users. My point was that it's not an unsolvable security issue but rather an unsolvable lack of agreement about what should and shouldn't be included in a rich text representation, or if email should even use rich text at all for that matter.
Are you sure? You used the the Fancy HTML Viewer plugin, which uses WebkitGTK2? I never had any problems with HTML Mail rendering in Claws. Your experience must be clearly peculiar to yourself.
More reason to run your infrastructure using open source software in your own datacenter. OpenStack has been around for closing in on two decades, running clouds and being mostly governance-drama-free.
It's not surprising that a proprietary ecosystem built on open source software locked up behind a gate doesn't make a worthwhile ecosystem for building open source tooling against.
This is true, sadly -- but the documentation exists and community is friendly to those who wanna build those skills. It's extremely difficult to build something the size of OpenStack without making it so configurable that operating it needs a decoder ring. I'm doing everything I can in Ironic to make it more friendly and flexible out of the box, but it's a difficult problem to solve.
I always tell people: OpenStack can do almost anything you want... if you can configure it to do so :).
There's a reason I point out the longevity of OpenStack. As a project, it has significant corporate sponsorship and policies to ensure that one entity can't take over control of it. For instance; the OpenStack Technical Committee is never permitted to have a majority membership made up of a single entity's employees. This means that even though Red Hat, at this stage in it's development, has a majority of contribution, the project itself can never be taken over by a single entity.
People find project governance, and particularly "corporate" involvement in open source to be distasteful -- but in my experience, and OpenStack is a winning example of this -- setting up good boundaries to let companies work together has proven to be sustainable.
> This means that even though Red Hat, at this stage in it's development, has a majority of contribution, the project itself can never be taken over by a single entity.
If it's one company with the majority of contributions then they can just stop contributing (or put their efforts into a proprietary fork) and all that you're left with is the code and the name. Which is maybe better than "just the code", but not by much.
There are over 600 different people contributing to OpenStack in a given six-month release cycle. Approximately 60% of total code by commit count is from Red Hat employees. I'm one of the 600 that don't work at Red Hat, and there are a lot of us.
You should get a sense of the scale of a project before summarily declaring that it has a single point of failure.
You just said majority without any numbers in the original post. I think you'll agree that the calculus would be quite different for 60% vs 85% of effort being from a single company.
I'm saying not that OpenStack can replace LocalStack, but instead that LocalStack, by building a project on top of proprietary APIs, set themselves up to fail.
The only reason I run android over iOS is the freedom to install things I want on it. A waiting period is unacceptable as Android has proven that it can't be trusted not to tighten the grip further.
I had the same thought, as an OpenStack developer as well (TBH I don't remember if my username here identifies me or not). Yeah, we can apply as an exceptional case, but realistically us being excluded shows the criteria is very much directed towards "github style" open source.
I used to go to a members-only bar in Apex, NC (in NC, at least at the time, if >50% of your sales was alcohol, you had to be a "club"). The last time I ever went there was when someone called the bartender and "reported" a DUI checkpoint down the road and they announced it in the bar.
Why do some folks think it's OK to put other people at risk to this level?
Hard agree. I have their doorbell and some of the wifi light fixtures (that go into mains power). They integrate great with home assistant and record locally.
I can appreciate the concept that Gentoo is placing a high value on human curation. I used to be firmly against our anti-LLM policy, but honestly it's a pretty strong differentiator from other distributions -- and I'm getting more and more sick of AI tech in general.
(note: I am a Gentoo developer)
reply