#lkml — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #lkml, aggregated by home.social.
-
That moment when old #lkml mails of yourself appear on screen.
:blobeyes:
-
That moment when old #lkml mails of yourself appear on screen.
:blobeyes:
-
That moment when old #lkml mails of yourself appear on screen.
:blobeyes:
-
That moment when old #lkml mails of yourself appear on screen.
:blobeyes:
-
That moment when old #lkml mails of yourself appear on screen.
:blobeyes:
-
""The #Linux rule for regressions is basically based on the philosophical question of "If a tree falls in the forest, and nobody is around to hear it, does it make a sound?".""
Linus wrote that today on #lkml while detesting the whole notion of "ABI changes": https://lore.kernel.org/all/CAHk-%3Dwga8Qu0-OSE9VZbviq9GuqwhPhLUXeAt-S7_9%[email protected]/
To quote more: ""Pretty much any change can be an ABI change - even totally new interfaces change behavior in that something that didn't use to do anything now does something.
[…]
So I absolutely detest the whole notion of "ABI changes". It's a meaningless concept, and I hate it with a passion, because it then results in the "opposite" situation where some projects seem to think that ABI changes are perfectly fine as long as they go along with version number changes.
[…]
So the only thing that matters is if something breaks user-*conscious* behavior.""
And when that happens, the distinction between "bug fix" and "new feature" and "ABI change" matters not one whit, and the change needs to be done differently.
-
""The #Linux rule for regressions is basically based on the philosophical question of "If a tree falls in the forest, and nobody is around to hear it, does it make a sound?".""
Linus wrote that today on #lkml while detesting the whole notion of "ABI changes": https://lore.kernel.org/all/CAHk-%3Dwga8Qu0-OSE9VZbviq9GuqwhPhLUXeAt-S7_9%[email protected]/
To quote more: ""Pretty much any change can be an ABI change - even totally new interfaces change behavior in that something that didn't use to do anything now does something.
[…]
So I absolutely detest the whole notion of "ABI changes". It's a meaningless concept, and I hate it with a passion, because it then results in the "opposite" situation where some projects seem to think that ABI changes are perfectly fine as long as they go along with version number changes.
[…]
So the only thing that matters is if something breaks user-*conscious* behavior.""
And when that happens, the distinction between "bug fix" and "new feature" and "ABI change" matters not one whit, and the change needs to be done differently.
-
""The #Linux rule for regressions is basically based on the philosophical question of "If a tree falls in the forest, and nobody is around to hear it, does it make a sound?".""
Linus wrote that today on #lkml while detesting the whole notion of "ABI changes": https://lore.kernel.org/all/CAHk-%3Dwga8Qu0-OSE9VZbviq9GuqwhPhLUXeAt-S7_9%[email protected]/
To quote more: ""Pretty much any change can be an ABI change - even totally new interfaces change behavior in that something that didn't use to do anything now does something.
[…]
So I absolutely detest the whole notion of "ABI changes". It's a meaningless concept, and I hate it with a passion, because it then results in the "opposite" situation where some projects seem to think that ABI changes are perfectly fine as long as they go along with version number changes.
[…]
So the only thing that matters is if something breaks user-*conscious* behavior.""
And when that happens, the distinction between "bug fix" and "new feature" and "ABI change" matters not one whit, and the change needs to be done differently.
-
""The #Linux rule for regressions is basically based on the philosophical question of "If a tree falls in the forest, and nobody is around to hear it, does it make a sound?".""
Linus wrote that today on #lkml while detesting the whole notion of "ABI changes": https://lore.kernel.org/all/CAHk-%3Dwga8Qu0-OSE9VZbviq9GuqwhPhLUXeAt-S7_9%[email protected]/
To quote more: ""Pretty much any change can be an ABI change - even totally new interfaces change behavior in that something that didn't use to do anything now does something.
[…]
So I absolutely detest the whole notion of "ABI changes". It's a meaningless concept, and I hate it with a passion, because it then results in the "opposite" situation where some projects seem to think that ABI changes are perfectly fine as long as they go along with version number changes.
[…]
So the only thing that matters is if something breaks user-*conscious* behavior.""
And when that happens, the distinction between "bug fix" and "new feature" and "ABI change" matters not one whit, and the change needs to be done differently.
-
""The #Linux rule for regressions is basically based on the philosophical question of "If a tree falls in the forest, and nobody is around to hear it, does it make a sound?".""
Linus wrote that today on #lkml while detesting the whole notion of "ABI changes": https://lore.kernel.org/all/CAHk-%3Dwga8Qu0-OSE9VZbviq9GuqwhPhLUXeAt-S7_9%[email protected]/
To quote more: ""Pretty much any change can be an ABI change - even totally new interfaces change behavior in that something that didn't use to do anything now does something.
[…]
So I absolutely detest the whole notion of "ABI changes". It's a meaningless concept, and I hate it with a passion, because it then results in the "opposite" situation where some projects seem to think that ABI changes are perfectly fine as long as they go along with version number changes.
[…]
So the only thing that matters is if something breaks user-*conscious* behavior.""
And when that happens, the distinction between "bug fix" and "new feature" and "ABI change" matters not one whit, and the change needs to be done differently.
-
My new favourite Rust hack: you can trick rustfmt into formatting imports with one symbol per line. Found this gem in LKML. It's perfect for large import lists!
-
My new favourite Rust hack: you can trick rustfmt into formatting imports with one symbol per line. Found this gem in LKML. It's perfect for large import lists!
-
My new favourite Rust hack: you can trick rustfmt into formatting imports with one symbol per line. Found this gem in LKML. It's perfect for large import lists!
-
My new favourite Rust hack: you can trick rustfmt into formatting imports with one symbol per line. Found this gem in LKML. It's perfect for large import lists!
-
Linus today on #LKML in reply to "A formal request for process clarifications" regarding the non-merge of the TSEM LSM – a Linus Security Module which provides a framework for generic security modeling:
""I already think we have too many of those pointless things. There's a fine line between diversity and "too much confusion because everybody thinks they know best". And the linux security modules passed that line years ago.
So my suggestion is to standardize on normal existing security models instead of thinking that you can do better by making yet another one. Or at least work with the existing people instead of trying to bypass them and ignoring what they tell you.
Yes, I know that security people always think they know best, and they all disagree with each other, which is why we already have tons of security modules. Ask ten people what model is the right one, and you get fifteen different answers.
I'm not in the least interested in becoming some kind of arbiter or voice of sanity in this.
Linus""
https://lore.kernel.org/all/CAHk-=whqz[email protected]/T/#u
-
Linus today on #LKML in reply to "A formal request for process clarifications" regarding the non-merge of the TSEM LSM – a Linus Security Module which provides a framework for generic security modeling:
""I already think we have too many of those pointless things. There's a fine line between diversity and "too much confusion because everybody thinks they know best". And the linux security modules passed that line years ago.
So my suggestion is to standardize on normal existing security models instead of thinking that you can do better by making yet another one. Or at least work with the existing people instead of trying to bypass them and ignoring what they tell you.
Yes, I know that security people always think they know best, and they all disagree with each other, which is why we already have tons of security modules. Ask ten people what model is the right one, and you get fifteen different answers.
I'm not in the least interested in becoming some kind of arbiter or voice of sanity in this.
Linus""
https://lore.kernel.org/all/CAHk-=whqz[email protected]/T/#u
-
Linus today on #LKML in reply to "A formal request for process clarifications" regarding the non-merge of the TSEM LSM – a Linus Security Module which provides a framework for generic security modeling:
""I already think we have too many of those pointless things. There's a fine line between diversity and "too much confusion because everybody thinks they know best". And the linux security modules passed that line years ago.
So my suggestion is to standardize on normal existing security models instead of thinking that you can do better by making yet another one. Or at least work with the existing people instead of trying to bypass them and ignoring what they tell you.
Yes, I know that security people always think they know best, and they all disagree with each other, which is why we already have tons of security modules. Ask ten people what model is the right one, and you get fifteen different answers.
I'm not in the least interested in becoming some kind of arbiter or voice of sanity in this.
Linus""
https://lore.kernel.org/all/CAHk-=whqz[email protected]/T/#u
-
Linus today on #LKML in reply to "A formal request for process clarifications" regarding the non-merge of the TSEM LSM – a Linus Security Module which provides a framework for generic security modeling:
""I already think we have too many of those pointless things. There's a fine line between diversity and "too much confusion because everybody thinks they know best". And the linux security modules passed that line years ago.
So my suggestion is to standardize on normal existing security models instead of thinking that you can do better by making yet another one. Or at least work with the existing people instead of trying to bypass them and ignoring what they tell you.
Yes, I know that security people always think they know best, and they all disagree with each other, which is why we already have tons of security modules. Ask ten people what model is the right one, and you get fifteen different answers.
I'm not in the least interested in becoming some kind of arbiter or voice of sanity in this.
Linus""
https://lore.kernel.org/all/CAHk-=whqz[email protected]/T/#u
-
Linus today on #LKML in reply to "A formal request for process clarifications" regarding the non-merge of the TSEM LSM – a Linus Security Module which provides a framework for generic security modeling:
""I already think we have too many of those pointless things. There's a fine line between diversity and "too much confusion because everybody thinks they know best". And the linux security modules passed that line years ago.
So my suggestion is to standardize on normal existing security models instead of thinking that you can do better by making yet another one. Or at least work with the existing people instead of trying to bypass them and ignoring what they tell you.
Yes, I know that security people always think they know best, and they all disagree with each other, which is why we already have tons of security modules. Ask ten people what model is the right one, and you get fifteen different answers.
I'm not in the least interested in becoming some kind of arbiter or voice of sanity in this.
Linus""
https://lore.kernel.org/all/CAHk-=whqz[email protected]/T/#u
-
Now THAT looks like a tutorial I wanted to have: https://blog.gnoack.org/post/lei/
#publicinbox #lkml #plaintextemail #plaintext #email #gitsendemail
-
Now THAT looks like a tutorial I wanted to have: https://blog.gnoack.org/post/lei/
#publicinbox #lkml #plaintextemail #plaintext #email #gitsendemail
-
Now THAT looks like a tutorial I wanted to have: https://blog.gnoack.org/post/lei/
#publicinbox #lkml #plaintextemail #plaintext #email #gitsendemail
-
Now THAT looks like a tutorial I wanted to have: https://blog.gnoack.org/post/lei/
#publicinbox #lkml #plaintextemail #plaintext #email #gitsendemail
-
Now THAT looks like a tutorial I wanted to have: https://blog.gnoack.org/post/lei/
#publicinbox #lkml #plaintextemail #plaintext #email #gitsendemail
-
Every goto in the Linux kernel / Just another day on the linux-kernel mailing list: https://www.youtube.com/watch?v=v1Mfirg2-Z8
> Visualization of every goto statement in the Linux 6.17 source code.Commentary from a 2003 linux-kernel mailing list discussion about the use of goto. #lkml #data #music #visualisation
-
Every goto in the Linux kernel / Just another day on the linux-kernel mailing list: https://www.youtube.com/watch?v=v1Mfirg2-Z8
> Visualization of every goto statement in the Linux 6.17 source code.Commentary from a 2003 linux-kernel mailing list discussion about the use of goto. #lkml #data #music #visualisation
-
Every goto in the Linux kernel / Just another day on the linux-kernel mailing list: https://www.youtube.com/watch?v=v1Mfirg2-Z8
> Visualization of every goto statement in the Linux 6.17 source code.Commentary from a 2003 linux-kernel mailing list discussion about the use of goto. #lkml #data #music #visualisation
-
Every goto in the Linux kernel / Just another day on the linux-kernel mailing list: https://www.youtube.com/watch?v=v1Mfirg2-Z8
> Visualization of every goto statement in the Linux 6.17 source code.Commentary from a 2003 linux-kernel mailing list discussion about the use of goto. #lkml #data #music #visualisation
-
Every goto in the Linux kernel / Just another day on the linux-kernel mailing list: https://www.youtube.com/watch?v=v1Mfirg2-Z8
> Visualization of every goto statement in the Linux 6.17 source code.Commentary from a 2003 linux-kernel mailing list discussion about the use of goto. #lkml #data #music #visualisation
-
Coming from software engineering, I can't stand this legislative practice of lumping tons of disparate things in one body and pushing them through legislature as one. Specifically #UK
#CrimeAndPolicingBill *is* a series of 190+ *PATCHES* to many laws, wrapped into a single text document with chapters and paragraphs. Look at #LKML and tell me more about your problems, making you lump together adding powers to breach anyone's data integrity, and updating rules on HAVING SEX WITH A CORPSE. -
Coming from software engineering, I can't stand this legislative practice of lumping tons of disparate things in one body and pushing them through legislature as one. Specifically #UK
#CrimeAndPolicingBill *is* a series of 190+ *PATCHES* to many laws, wrapped into a single text document with chapters and paragraphs. Look at #LKML and tell me more about your problems, making you lump together adding powers to breach anyone's data integrity, and updating rules on HAVING SEX WITH A CORPSE. -
Coming from software engineering, I can't stand this legislative practice of lumping tons of disparate things in one body and pushing them through legislature as one. Specifically #UK
#CrimeAndPolicingBill *is* a series of 190+ *PATCHES* to many laws, wrapped into a single text document with chapters and paragraphs. Look at #LKML and tell me more about your problems, making you lump together adding powers to breach anyone's data integrity, and updating rules on HAVING SEX WITH A CORPSE. -
Coming from software engineering, I can't stand this legislative practice of lumping tons of disparate things in one body and pushing them through legislature as one. Specifically #UK
#CrimeAndPolicingBill *is* a series of 190+ *PATCHES* to many laws, wrapped into a single text document with chapters and paragraphs. Look at #LKML and tell me more about your problems, making you lump together adding powers to breach anyone's data integrity, and updating rules on HAVING SEX WITH A CORPSE. -
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Does anyone have a good way to read kernel mailing list threads on mobile (Android)?
K-9/Thunerbird are better than Gmail at threading and can use fixed font size but it's often not good enough. Lore is an awesome resource but the web view is not great for reading long threads.
Maybe the only way is to use a terminal app to access mutt remotely?
-
Does anyone have a good way to read kernel mailing list threads on mobile (Android)?
K-9/Thunerbird are better than Gmail at threading and can use fixed font size but it's often not good enough. Lore is an awesome resource but the web view is not great for reading long threads.
Maybe the only way is to use a terminal app to access mutt remotely?
