| IRC (libera, oftc) | sam_ |
| GitHub | https://github.com/thesamesam |
| Website | https://cmpct.info/~sam |
@rose There isn't a "Linux" installkernel. The kernel Makefiles call installkernel as a hook mechanism. Debian's installkernel is part of debianutils.
We also forked it to make our own changes: https://github.com/projg2/installkernel-gentoo (gh because our gitweb is being swamped still)
In practice, you can swap out the systemd impl with our one without any issues. I think the only problem was with systemd-boot vs unmerged-usr, which could be fixed but didn't seem worth it.
(This means I don't see much point in using kernel-install either, as swapping out hasn't been problematic for us at all.)
finding myself repeating "fuzzers are stochastic, with enough cpu time you will always find a bug, results are a usually demonstration of resources not algorithms"
like, hacking, along with spam and fraud are the sorts of activities where things only need to work 0.1% of the time to be successful
it isn't a demonstration of clever code or tooling but the uncompromising effectiveness of sheer brute force heh
@tante This unfairly discriminates against the French, though ;)
I've never seen French Canadians do this which I don't understand.
My recent favorite read. Despite what people around me are shifting to my contributions will remain 100% LLM-free.
> […] I didn’t talk of quality per se. I don’t think there’s a point in doing that. I believe that LLMs sometimes spit quality slop, and sometimes they don’t. […] That’s beside the point.
The point is, however you look at it, LLMs are unethical.
Over past few weeks `gcc` from `master` was crashing on all sorts of `c++` projects with suspiciously similar backtraces: `SIGSEGV` in `ggc_set_mark() / gt_ggc_mx_lang_tree_node()`.
Took me some time to find the culprit and have a workaround to stop the crashes.
Guess where the fix hides!
Spoiler: https://trofi.github.io/posts/347-another-memory-corruption-case.html
@lanodan @mid_kid I did try to focus on practical technical measures and I think I killed the conversation, but nobody has complained (and several have supported) what we've done with Perl.
One of those things where sometimes having the discussion is useful in that there's no clear wrong (or right) answer, so you have some licence to go ahead.
@mid_kid @lanodan See the discussion at https://public-inbox.gentoo.org/gentoo-dev/[email protected]/
I don't think we have a clear plan or rule yet, though e.g. a bunch of Perl modules have newer versions masked because they're now nearly "autonomously developed", some Python libraries are in package.deprecated or last-rited, ...
@mid_kid @lanodan I do think Vim has always been a bit of a rough situation at least since the huge numbers of CVEs started, because you'd end up being nudged to upgrade quickly and there'd be various regressions.
This just means there's more regressions. It's not uncommon to move more slowly with such upstreams or to stick to an older version.
For this reason, we have (for as long as I've paid any attention to packaging) not rushed to update Vim, often being behind by quite a bit, because of how much broke even pre-LLMs.
tef
Mike Yuan
Sergei Trofimovich