Milestone passed with the debut of Linux 6.14 rc1.
More lines = more attack vectors, more maintenance, more bloat.
Except the vast majority of the kernel is in driver modules.
So for an individual machine, the attack surface is not really any bigger than it needs to be.
The OS will only load modules it needs for your hardware, so the “bloat” only exists at the source code and binary size level. You are free to compile an optimized binary for your hardware. The complete kernel binary should fit in a 200MB boot partition.
As for maintenance, that’s a fair point, but the effort is at least somewhat distributed if hardware devs provide the drivers.
Easy fix. Just remove newline characters.
Time to refactor the whole kernel into a one-liner!
A single line of lambda calculus.
With about forty million parentheses.
That’s cheating. It won’t actually make the code smaller.
source?
Common sense. Just making the same code into a single line won’t change much.
that doesn’t sound right, it’s so much smaller if it’s just one line
The line will be like several quadrillion characters long though.
but if there’s a bug I’ll know exactly which line to look at
Ooo! Now I want to go run scc on the source and see how much of that is Rust.
~15k lines of actual Rust code.
@ ❯ git clone https://github.com/torvalds/linux && cd linux && tokei Cloning into 'linux'... remote: Enumerating objects: 10655741, done. remote: Counting objects: 100% (1067/1067), done. remote: Compressing objects: 100% (208/208), done. remote: Total 10655741 (delta 961), reused 859 (delta 859), pack-reused 10654674 (from 3) Receiving objects: 100% (10655741/10655741), 5.13 GiB | 13.37 MiB/s, done. Resolving deltas: 100% (8681589/8681589), done. Updating files: 100% (87840/87840), done. =============================================================================== Language Files Lines Code Comments Blanks =============================================================================== Alex 2 222 180 0 42 ASN.1 15 656 441 87 128 Assembly 10 5226 4764 0 462 GNU Style Assembly 1336 372898 271937 56600 44361 Autoconf 5 433 377 26 30 Automake 3 31 23 3 5 BASH 59 2029 1368 352 309 C 34961 24854959 18510957 2766479 3577523 C Header 25450 10090846 7834037 1503620 753189 C++ 7 2267 1946 81 240 C++ Header 2 125 59 55 11 CSS 3 295 172 69 54 Device Tree 5582 1744314 1430810 83215 230289 Gherkin (Cucumber) 1 333 199 97 37 Happy 10 6049 5332 0 717 HEX 2 173 173 0 0 INI 2 13 6 5 2 JSON 894 542554 542552 0 2 LD Script 8 377 289 29 59 Makefile 3062 81226 55970 12993 12263 Module-Definition 2 128 113 0 15 Objective-C 1 89 72 0 17 Perl 61 43843 34461 3909 5473 Python 280 84204 66996 5198 12010 RPM Specfile 1 131 111 2 18 ReStructuredText 3672 761388 577410 0 183978 Ruby 1 29 25 0 4 Shell 957 187353 130476 23721 33156 SVG 79 52122 50727 1303 92 SWIG 1 252 154 27 71 TeX 1 234 155 73 6 Plain Text 1455 134747 0 110453 24294 TOML 3 47 28 12 7 Unreal Script 5 671 415 158 98 Apache Velocity 1 15 15 0 0 Vim script 1 42 33 6 3 XSL 10 200 122 52 26 XML 24 22177 19862 1349 966 YAML 4545 512759 417504 19285 75970 ------------------------------------------------------------------------------- HTML 2 28 22 3 3 |- JavaScript 1 7 7 0 0 (Total) 35 29 3 3 ------------------------------------------------------------------------------- Markdown 1 248 0 177 71 |- BASH 1 2 2 0 0 |- C 1 20 12 6 2 (Total) 270 14 183 73 ------------------------------------------------------------------------------- Rust 91 15207 11065 2248 1894 |- Markdown 85 7773 747 5253 1773 (Total) 22980 11812 7501 3667 =============================================================================== Total 82608 39520940 29971358 4591687 4957895 ===============================================================================One cucumber 🥒 👀
is this a good thing or an issue? I just play RuneScape -~-
An awful lot of that growth is drivers. Consequence of being a monokernel.
Depends on your perspective I suppose. One good reason might be that it means more hardware is supported. A bad one might be that it increases the overall attack surface from a security point of view.
I’d like to see them hire some formal methods people to at least formally verify crucial parts of it.
It might actually also be good to analyze it with an LLM to identify any hidden problem areas.
I’m interested to hear why my idea is probably foolish as well, though.
A great deal of work is going into this area. In fact, I believe there’s quite a few parties using LLMs to look for security bugs, and the US Department of defense had a multimillion dollar competition to motivate just that.
llms have no abstract reasoning, so while they can write an okay-sounding bug report, often it’s wrong meow.
i do think the linux foundation hires security people, and almost certainly the big contributors do.
Doesn’t the new Chinese model just released actually do abstract reasoning?
DeepSeek-R1 leverages a pure RL approach, enabling it to autonomously develop chain-of-thought (CoT) reasoning, self-verification, and reflection—capabilities critical for solving complex problems.
To my untrained self, that sounds like reasoning.
With chain of thought it basically asks itself to generate related sub questions and then answers for those sub questions.
Basically it’s just the same but recursive. So, like it looks like it can tell you things, it just also looks like reasoning.
Now it may well be an improvement, but it’s still basically. “I have this word, what is statistically most likely to be the next word” over and over again.
Thanks.
Edit: Not sure who’s downvoting me for asking reasonable questions.
My opinion is this isn’t a problem. There’s a lot of hardware out there, and the vast majority of that code isn’t going to be loaded into any one kernel installation.
An issue for sure. Larger code is never good.
