-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> What's the average lifespan of a line of kernel code?
There's a fun tool called "Git of Theseus" which can answer this question! You can see some graphs of Linux code on the web page: https://github.com/erikbern/git-of-theseus
Most of those submissions die in the queue.
I'd set a 20-comment limit to the search I presented for a reason. At present, the 30 results shown go back over 7 months. That's roughly a significant submission per week.
Contrasting a search for "lwn.net" alone in submissions, the first page of results (sorted by date, again, 30 results) only goes back 3 weeks (22 days). But most of those get little activity --- some upvotes, and a few with many comments, but, in a third search sorted by popularity over the past month,
<https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...>
Ten of those meet or beat my 20-comment threshold, 20 don't. And note that 20 comments isn't especially significant, 4 submissions exceed 100 comments.
lwn SubscriberLink & > 20 comments, by date: <https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...>
All "lwn.net" for past month: <https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...>
Data:
Comments: 189 94 155 254 153 29 46 10 14 20 13 12 89 10 21 1 8 0 1 1 0 2 0 0 0 0 2 1 1 0
Points: 306 271 254 240 166 114 109 89 62 58 53 45 42 39 37 30 20 7 5 5 5 4 4 4 4 4 3 3 3 3
I'm not saying that the concern doesn't exist. But ultimately, it's LWN's to address. The constant admonishments to not share links seem to fall into tangential annoyances and generic tangents, both against HN guidelines: <https://news.ycombinator.com/newsguidelines.html>
I'd suggest leaving this to Corbet and dang.
The section about 128-bit pointers being necessary for expanded memory sizes is unconvincing -- 64 bits provides 16 EiB (16 x 1024 x 1024 x 1 GiB), which is the sort of address space you might need for byte-level addressing of a warehouse full of high-density HDDs. Memory sizes don't grow like they used to, and it's difficult to imagine what kind of new physics would let someone fit that many bytes into a machine that's practical to control with a single Linux kernel instance.
CHERI is a much more interesting case, because it expands the definition of what a "pointer" is. Most low-level programmers think of pointers as just an address, but CHERI turns it into a sort of tuple of (address, bounds, permissions) -- every pointer is bounds-checked. The CHERI folks did some cleverness to pack that all into 128 bits, and I believe their demo platform uses 128-bit registers.
The article also touches on the UNIX-y assumption that `long` is pointer-sized. This is well known (and well hated) by anyone that has to port software from UNIX to Windows, where `long` and `int` are the same size, and `long long` is pointer-sized. I'm firmly in the camp of using fixed-size integers but the Linux kernel uses `long` all over the place, and unless they plan to do a mass migration to `intptr_t` it's difficult to imagine a solution that would let the same C code support 32-, 64-, and 128-bit platforms.
(comedy option: 32-bit int, 128-bit long, and 64-bit `unsigned middle`)
The article also mentions Rust types as helpful, but Rust has its own problems with big pointers because they inadvisably merged `size_t`, `ptrdiff_t`, and `intptr_t` into the same type. They're working on adding equivalent symbols to the FFI module[0], but untangling `usize` might not be possible at this point.
[0] https://github.com/rust-lang/rust/issues/88345