Search
320 results for “kernellogger”
-
Open Source Summit.
Europe.YouTube.
Sched.So, how does anyone take this event, and with it, @linuxfoundation, serious?
-
#Linux #kernel patches to allow enabling #PREEMPT_RT (aka proper #realtime support) for x86, ARM64, and Risc-V were posted for review:
https://lore.kernel.org/lkml/202409061[email protected]/
"The printk bits required for PREEMPT_RT are sitting in linux-next. This was the last known roadblock for PREEMPT_RT. The RT queue has additionally the "atomic console" for the 8250 UART which is not yet in linux-next.[…]"
See also these earlier other related toots:
https://fosstodon.org/@kernellogger/113084762433941141
https://fosstodon.org/@kernellogger/113085326251565367 -
John posted v4 of the patch-set "threaded console printing as well as some other minor pieces" which "provides the remaining pieces of the #printk rework." -- e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #Linux #Kernel. But note, "this series does *not* provide an nbcon console driver. That will come in a follow-up series."
https://lore.kernel.org/all/2024082704[email protected]/
This comes hot on the heels of the "write_atomic() printing" entering -next: https://fosstodon.org/@kernellogger/113003819326920850
-
John posted v4 of the patch-set "threaded console printing as well as some other minor pieces" which "provides the remaining pieces of the #printk rework." -- e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #Linux #Kernel. But note, "this series does *not* provide an nbcon console driver. That will come in a follow-up series."
https://lore.kernel.org/all/2024082704[email protected]/
This comes hot on the heels of the "write_atomic() printing" entering -next: https://fosstodon.org/@kernellogger/113003819326920850
-
John posted v4 of the patch-set "threaded console printing as well as some other minor pieces" which "provides the remaining pieces of the #printk rework." -- e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #Linux #Kernel. But note, "this series does *not* provide an nbcon console driver. That will come in a follow-up series."
https://lore.kernel.org/all/2024082704[email protected]/
This comes hot on the heels of the "write_atomic() printing" entering -next: https://fosstodon.org/@kernellogger/113003819326920850
-
John posted v4 of the patch-set "threaded console printing as well as some other minor pieces" which "provides the remaining pieces of the #printk rework." -- e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #Linux #Kernel. But note, "this series does *not* provide an nbcon console driver. That will come in a follow-up series."
https://lore.kernel.org/all/2024082704[email protected]/
This comes hot on the heels of the "write_atomic() printing" entering -next: https://fosstodon.org/@kernellogger/113003819326920850
-
John posted v4 of the patch-set "threaded console printing as well as some other minor pieces" which "provides the remaining pieces of the #printk rework." -- e.g. the last big missing piece for #Realtime support through #PREEMPT_RT in the mainline #Linux #Kernel. But note, "this series does *not* provide an nbcon console driver. That will come in a follow-up series."
https://lore.kernel.org/all/2024082704[email protected]/
This comes hot on the heels of the "write_atomic() printing" entering -next: https://fosstodon.org/@kernellogger/113003819326920850
-
After Linus statement ~10 days ago[1] it looked like #BPF extensible scheduler class aka the #sched_ext (SCX) patchset would be merged for #Linux 6.11. Now there are discussions to change a few things before merging it; as of now it's unclear if that will happen and/or delay things: https://lore.kernel.org/all/CAHk-=wg3R[email protected]/t/#u
Side note: Tejun a few days ago posted v7 of the patchset and created a korg tree to coordinate development: https://lore.kernel.org/all/2024061821[email protected]/
-
@kernellogger and use "journalctl -k -b-1" to see the Kernel messages of the previous boot.
Replace "-1" with any of the boot IDs provided by "journalctl --list-boots" (requires the journal to be configured as Storage=persistent in /etc/systemd/journald.conf)
-
@kernellogger good to see HPE's GXP SoC support getting merged. Progress towards an upstream #OpenBMC port!
-
-
Ich würde gern eine neue Konsole nutzen, die besser GDB-tui unterstuzt. Wisst jemand ob #kmscon funktioniert mit GDB besser? Leider bietet Debian kmscon bisher nicht an. Ja, konnte ich selbst diese Anwendung verpacken . . .
Vielen Dank, @kernelloggerhttps://www.heise.de/news/Epochaler-Wandel-bei-Textkonsolen-von-Linux-im-Werden-11155044.html
-
-
-
-
-
-
Ich würde gern eine neue Konsole nutzen, die besser GDB-tui unterstuzt. Wisst jemand ob #kmscon funktioniert mit GDB besser? Leider bietet Debian kmscon bisher nicht an. Ja, konnte ich selbst diese Anwendung verpacken . . .
Vielen Dank, @kernelloggerhttps://www.heise.de/news/Epochaler-Wandel-bei-Textkonsolen-von-Linux-im-Werden-11155044.html
-
Ich würde gern eine neue Konsole nutzen, die besser GDB-tui unterstuzt. Wisst jemand ob #kmscon funktioniert mit GDB besser? Leider bietet Debian kmscon bisher nicht an. Ja, konnte ich selbst diese Anwendung verpacken . . .
Vielen Dank, @kernelloggerhttps://www.heise.de/news/Epochaler-Wandel-bei-Textkonsolen-von-Linux-im-Werden-11155044.html
-
Ich würde gern eine neue Konsole nutzen, die besser GDB-tui unterstuzt. Wisst jemand ob #kmscon funktioniert mit GDB besser? Leider bietet Debian kmscon bisher nicht an. Ja, konnte ich selbst diese Anwendung verpacken . . .
Vielen Dank, @kernelloggerhttps://www.heise.de/news/Epochaler-Wandel-bei-Textkonsolen-von-Linux-im-Werden-11155044.html
-
Ich würde gern eine neue Konsole nutzen, die besser GDB-tui unterstuzt. Wisst jemand ob #kmscon funktioniert mit GDB besser? Leider bietet Debian kmscon bisher nicht an. Ja, konnte ich selbst diese Anwendung verpacken . . .
Vielen Dank, @kernelloggerhttps://www.heise.de/news/Epochaler-Wandel-bei-Textkonsolen-von-Linux-im-Werden-11155044.html
-
RE: https://hachyderm.io/@kernellogger/115898435262936250
Not even halfway through the article and this already hit hard:
"[A]n overall increase in interest in Linux and free software will be driven by a combination of surveillance concerns, forced upgrades, unwanted AI features, and increasing hardware prices."
This is a flag that almost 20 years back was already being raised in the free software communities. I remember similar discussions at FISL (Porto Alegre's old Free Software Forum) panels, which were met with dismissive statements from most of the tech professionals at the time.
We already had trust issues after everything Microsoft did in the 90's and early 2000's, but it was clear that it was not a Microsoft-specific issue, that it would be pervasive and widespread in the computing ecosystem as soon as the adoption of IT was ubiquitous. The free software community called it, and thanks to the immense efforts from communities (and some corporate entities who saw value in it, obviously) we avoided being in a hopeless position.
#foss #linux #FISL #GuessIShouldAlsoMentionGNUOtherwiseStallmanWillHauntMe
-
RE: https://hachyderm.io/@kernellogger/115898435262936250
Not even halfway through the article and this already hit hard:
"[A]n overall increase in interest in Linux and free software will be driven by a combination of surveillance concerns, forced upgrades, unwanted AI features, and increasing hardware prices."
This is a flag that almost 20 years back was already being raised in the free software communities. I remember similar discussions at FISL (Porto Alegre's old Free Software Forum) panels, which were met with dismissive statements from most of the tech professionals at the time.
We already had trust issues after everything Microsoft did in the 90's and early 2000's, but it was clear that it was not a Microsoft-specific issue, that it would be pervasive and widespread in the computing ecosystem as soon as the adoption of IT was ubiquitous. The free software community called it, and thanks to the immense efforts from communities (and some corporate entities who saw value in it, obviously) we avoided being in a hopeless position.
#foss #linux #FISL #GuessIShouldAlsoMentionGNUOtherwiseStallmanWillHauntMe
-
RE: https://hachyderm.io/@kernellogger/115898435262936250
Not even halfway through the article and this already hit hard:
"[A]n overall increase in interest in Linux and free software will be driven by a combination of surveillance concerns, forced upgrades, unwanted AI features, and increasing hardware prices."
This is a flag that almost 20 years back was already being raised in the free software communities. I remember similar discussions at FISL (Porto Alegre's old Free Software Forum) panels, which were met with dismissive statements from most of the tech professionals at the time.
We already had trust issues after everything Microsoft did in the 90's and early 2000's, but it was clear that it was not a Microsoft-specific issue, that it would be pervasive and widespread in the computing ecosystem as soon as the adoption of IT was ubiquitous. The free software community called it, and thanks to the immense efforts from communities (and some corporate entities who saw value in it, obviously) we avoided being in a hopeless position.
#foss #linux #FISL #GuessIShouldAlsoMentionGNUOtherwiseStallmanWillHauntMe
-
#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:
* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412cThing is: it seems that the fix might have some problems, so a fix for the fix is in the works:
* https://lore.kernel.org/all/2026051008[email protected]/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/ -
#Linux 7.1-rc3 is out:
https://lore.kernel.org/lkml/CAHk-=wgC[email protected]/
Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""
-
Quick reminder in light of the recent #LinuxKernel vulnerabilities:
In case you want to protect yourself against vulnerabilities in #Linux #Kernel modules you don't need, disable module loading completely by running:
echo 1 | sudo tee /proc/sys/kernel/modules_disabled
Of course you want to load all modules you need before running that command, as otherwise you will have to reboot to load them. 😄
More details on this:
* https://dfir.ch/posts/today_i_learned_lkm_kernel.modules_disabled/
* https://linux-audit.com/kernel/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/
* https://www.heise.de/select/ct/2020/1/1577462303523965 [German] -
RE: https://fedi.lwn.net/@lwn/116538328401421358
The patch to fix the second half of #DirtyFrag is at its third iteration now: https://lore.kernel.org/all/af2kdW2F1gJ9U-Gg@v4bel/
-
@thelinuxcast this post from https://who-t.blogspot.com/2016/01/xorg-project-vs-xorg-foundation.html is old, but explain the different things that X.org can mean (the foundation, the project) and how they relate to #Wayland (and other things around GPU drivers).
Maybe @whot should re-publish it yearly. 😄
Sadly the post does not mention that #Xorg (without a Dot after the X!) is something different (it's the older and once widespread of two popular X-Servers the X.org project publishes these days; the other one is #Xwayland).
-
@thelinuxcast this post from https://who-t.blogspot.com/2016/01/xorg-project-vs-xorg-foundation.html is old, but explain the different things that X.org can mean (the foundation, the project) and how they relate to #Wayland (and other things around GPU drivers).
Maybe @whot should re-publish it yearly. 😄
Sadly the post does not mention that #Xorg (without a Dot after the X!) is something different (it's the older and once widespread of two popular X-Servers the X.org project publishes these days; the other one is #Xwayland).