@ljs I'd need a generic structure that gets built up from intervals, potentially overlapping. after that enumerate the intervals. the tricky part is the merging, I had similar sketches for the cases as you on the whiteboard for my (unfinished) prototype. the maple tree has a single value key, so the merging is still left as an exercise. The linux.git/include/interval_tree.h is close but IIRC not doing what I wanted.
1
0
0
kdave
repeated
repeated
being picky about quality IS part of kernel culture, it does vary quite a bit (some parts of the kernel are much better than others), and it did originate from Linus, but most interactions with Linus are perfectly civil.
If you stop fucking confirmation biasing and look at his usual interactions (oh whoops - that'd require actual understanding of what's being discussed) you'd see that it's usually civil but with the same adherence to caring about quality at least to a reasonable degree that is a part of the culture.
Comparing it to software where there is literally no attempt whatsoever to control quality and saying 'because Linus is an arsehole based on .01% of his emails' is you know - fucking stupid really isn't it? It's just not true.
But you don't get to sound as 'special' if you say this kind of thing. If you say 'yes yes look at this cherry picked email - this is how linux is and that's why the code isn't as awful as [insert random project here]'.
No. Shut up.
If you stop fucking confirmation biasing and look at his usual interactions (oh whoops - that'd require actual understanding of what's being discussed) you'd see that it's usually civil but with the same adherence to caring about quality at least to a reasonable degree that is a part of the culture.
Comparing it to software where there is literally no attempt whatsoever to control quality and saying 'because Linus is an arsehole based on .01% of his emails' is you know - fucking stupid really isn't it? It's just not true.
But you don't get to sound as 'special' if you say this kind of thing. If you say 'yes yes look at this cherry picked email - this is how linux is and that's why the code isn't as awful as [insert random project here]'.
No. Shut up.
1
2
3
kdave
repeated
repeated
Saw a bit of a video where somebody did the 'Linus is mean but that is why Linux is good quality' thing that a lot of people believe and not sure my eyes could roll any further.
Like do you guys think Linus controls every bit of code going in?
Do you think the sweary emails he used to send are representative? And even at his worse, who did he send them to? And how often?
The desire to excuse arseholeness by people who quote memeable stuff with usually zero understanding of the discussion is just so fucking frustrating.
How about asking people actually involved in the kernel? There's a kind of bloody arrogance with it that somebody reads a couple of these (from *checks notes* 11 years ago) and speaks as if they're an authortiy.
You're fucking not, shut up.
Like do you guys think Linus controls every bit of code going in?
Do you think the sweary emails he used to send are representative? And even at his worse, who did he send them to? And how often?
The desire to excuse arseholeness by people who quote memeable stuff with usually zero understanding of the discussion is just so fucking frustrating.
How about asking people actually involved in the kernel? There's a kind of bloody arrogance with it that somebody reads a couple of these (from *checks notes* 11 years ago) and speaks as if they're an authortiy.
You're fucking not, shut up.
1
2
4
The Command-R+ (104B) gives a good answer, 10% and an explanation. Quoted in full below.
Show content
"10%. The text provided contains highly technical content and specialized terminology related to software development and file systems. It discusses specific changes made in a codebase or project log, including performance optimizations, lock scope adjustments, API conversions, error handling improvements, thread management, and various core modifications. This level of detail suggests that the writer has expertise in low-level programming concepts and is familiar with the inner workings of operating system processes.
While AI language models have made significant advancements in generating human-like text on a variety of topics, they typically struggle to produce content requiring deep domain knowledge or highly technical understanding without specific training data related to these complex subjects. The depth of software development expertise displayed here would be challenging for an LLM like ChatGPT unless specifically trained and fine-tuned with extensive data from the field of file systems and low-level programming.
Therefore, it is unlikely that this text was generated solely by AI without significant human input or a highly specialized training dataset tailored to such technical content generation tasks in software development domains."
While AI language models have made significant advancements in generating human-like text on a variety of topics, they typically struggle to produce content requiring deep domain knowledge or highly technical understanding without specific training data related to these complex subjects. The depth of software development expertise displayed here would be challenging for an LLM like ChatGPT unless specifically trained and fine-tuned with extensive data from the field of file systems and low-level programming.
Therefore, it is unlikely that this text was generated solely by AI without significant human input or a highly specialized training dataset tailored to such technical content generation tasks in software development domains."
0
0
1
kdave
kdave
For fun I've asked llama3.1:8B to evaluate my 6.12 pull request summary how likely it was written by AI (LLM, ChatGPT). It's a weaker model but I'm still not sure if I should be mad because of "I would assign a probability that it was written by an AI as 95%", or pleased by "I wouldn't rule out the possibility of a skilled human developer having written it.".
Anyway, llama3.1:70B says it's 20% written by AI. Both don't like formal tone and enumerated lists, while acknowledging technical and specific context of linux kernel where AI can "struggle".
Anyway, llama3.1:70B says it's 20% written by AI. Both don't like formal tone and enumerated lists, while acknowledging technical and specific context of linux kernel where AI can "struggle".
1
1
3
kdave
kdaveWhen One Door Bug Closes Another Opens, But Often We Look So Long Upon the Closed Door Bug That We Do Not See the Open Door Bug
0
0
1
kdave
kdave
I've been looking around for projects with similar potential as xz. Unsurprisingly lots of GNU projects, they do the groundwork, are direct or indirect dependencies everywhere, were feature complete years ago, no new development, one last guardian of the code with credentials to ftp.gnu.org.
There's one hurdle that could raise the difficulty of infiltration though, the FSF copyright assignment paperwork.
There's one hurdle that could raise the difficulty of infiltration though, the FSF copyright assignment paperwork.
0
1
2
kdave
kdave
Collatz conjecture of programming: assuming there are N bugs, when it's odd your patch will reduce the number to N/2, otherwise bug count will be 3N+1. 🔢
0
1
2
kdave
kdave
I'll shed some tears for removing ia64 from linux, but well it's about time.
Show content
Also let us not forget about *cough*sparc, alpha, hppa*cough*
0
0
1
kdave
kdave
@monsieuricon The btrfs wiki is actively used and not everyhthing has been moved to btrfs.read-the-docs. I think some quick sync to the RTD sources can be done and reformatted properly later so hopefully the archived version won't confuse people once it becomes obsolete.
2
0
0
@jann @kernellogger Nice. A static list of already known bad addresses (or patterns) plus a run time check that can remove newly found ones but at this point it's dangerous to use such system. I used to patch my 2.x kernels with BadRAM (http://rick.vanrein.org/linux/badram/index.html), crazy times.
1
0
2
@brauner I haven't found anything else than https://github.com/mafintosh/fuse-block-device which is a bit hacky
0
0
0
kdave
kdave
I have a few ideas what to implement with the ublk. It's like FUSE for block devices (though BUSE exists, it's not maintained), the kernel/userspace separation makes it really convenient for experimenting.
0
3
4