Search

Items tagged with: LinuxKernel




RT @Itsfoss: Linus Torvalds hat gerade KI eingesetzt, um einen Bug im Linux-Kernel zu beheben. Dies ist ein seltenes Ereignis. Selten, weil Torvalds nicht mehr am Linux-Kernel codet. Er prüft nur noch Code und merged Pull Requests von Contributoren. Daher ist dies ein seltener Anlass in jüngster Zeit, an dem er selbst einen Kernel-Patch erstellt hat. Und diesmal hat er sich von KI assistieren lassen. Der Bug befand sich im Intel-Xe-Grafiktreiber für Battlemage-G21-Karten. Er verursachte, dass GDM, der Display-Manager, sich endlos neu startete. Die Fehlersuche erforderte 24 Debug-Patches und 18 Kernel-Boots. Als Ursache entpuppte sich eine einzelne Zeile, in der roundup() statt rounddown() stehen sollte. Die KI „hat die Schuftarbeit für Torvalds erledigt": Debug-Instrumentierung hinzugefügt, Analysen durchgeführt und sogar die finale Commit-Nachricht verfasst. Doch es war nicht alles ein leichtes Unterfangen. Die KI sagte Linus immer wieder, dass das Problem „unmöglich und unlösbar" sei. Jedes Mal widersprach Linus und ging weiter. In seinen Worten: „Ich vermute, dass diese Dinge von Menschen trainiert wurden, die vielleicht nicht ganz so stur sind wie ich." Das ist genau das, was wir immer sagen. KI ist nur ein Werkzeug und sie ist im Wesentlichen dann nützlich, wenn ein fähiger Mensch den Prozess steuert. Überlässt man ihr ihre eigenen Schlussfolgerungen, würde sie diesen Bug als unkorrigierbar bezeichnen und sich abwenden. Aber Linus Torvalds hat Erfahrung. Er konnte verstehen, was die KI richtig oder falsch machte. Der Patch ist nun in Linux 7.3 und wurde in stabile Kernel-Zweige zur…

mehr auf Arint.info

#ArtificialIntelligence #LinusTorvalds #LinuxKernel #OpenSource #SoftwareEngineering #TechNews #arint_info

x.com/Itsfoss/status/209098348…


The media in this post is not displayed to visitors. To view it, please go to the original post.

#LinusTorvalds managed to fix a really nasty #Linux #kernel Intel GPU driver bug he was plagued with[1] using #AI, which "enormously helped by doing much of the grunt-work" – but he needed persistence and multiple debug patches as well, as the AI multiple times had told him to give up and just report the bug.

To quote git.kernel.org/torvalds/c/818b…:

""And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work.

I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it.

I suspect those things have been trained by people who may not be quite as stubborn as I am.

But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above.

This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this.""

[1] lore.kernel.org/all/CAHk-%3Dwj…

#LinuxKernel




#LinuxKernel:

Greg Kroah-Hartman zieht klare Grenze für #KI-generierten #Code

KI darf im #Linux_Kernel helfen, aber nicht überall. #Greg_Kroah_Hartman schränkt ihren Einsatz im Bereich drivers/staging jetzt deutlich ein.

Der #Maintainer „clanker“ reagiert auf eine wachsende Zahl automatisch erzeugter Patches. Nach seinen Angaben landen inzwischen immer häufiger Änderungen aus Sprachmodellen im Staging-Bereich. Diese Beiträge will er künftig grundsätzlich ablehnen.

fosstopia.de/greg-kroah-hartma…





Linus #Torvalds bezieht Stellung zur Rolle von #KI im #Linux_Kernel

#Linus_Torvalds hat seine Haltung zu #KI deutlich bekräftigt. Der #LinuxKernel bleibt offen für den Einsatz entsprechender Werkzeuge. Eine Pflicht zur Nutzung soll es dennoch nicht geben.

Dabei ging es um #Sprachmodelle und automatische #Codeprüfungen. Einige Stimmen lehnen deren Einsatz grundsätzlich ab. #Torvalds widerspricht dieser Haltung entschieden.

fosstopia.de/linus-torvalds-ki…










Seit 2017 ausnutzbar: Gefährliche #Root-Lücke im #LinuxKernel entdeckt.

Ein kleines Skript mit einer Größe von nur 732 Bytes reicht aus, um unter #Linux #Root-Rechte zu erlangen. Der #Exploit liegt bereits auf #Github.

Betroffen sind laut Informationsseite der Forscher alle gängigen #Linux- #Distributionen, die seit 2017 veröffentlicht wurden. Da der nötige Exploit-Code bereits öffentlich verfügbar ist, sollten Linux-Nutzer ihre Systeme so bald wie möglich patchen...

golem.de/news/seit-2017-ausnut…








On Tuesday, January 13, 2025 there will be happening 5th Mobile Hackday in Prague.

The event focuses on Linux on mobile devices, kernel development, and practical hacking around mobile platforms.

The day will include short lightning talks on topics such as:
* sending Linux kernel patches using b4 #LinuxKernel
* what makes a high-quality commit (in the kernel and beyond) #QA
* a NixOS Mobile demo #NixOS

1/2


There are two things I really only started appreciating enough since I found NixOS (or it found me, or whatever).

One of them is the Linux kernel itself, and the other is systemd.

When I think about the operating system on my computer, the first image that comes to mind is the kernel and/or systemd, depending on what the last thing I just got done working on was. This is not, in fact, because I have a high number of hours under my belt with respect to either of those things; as compared to a lot of people, I really don't. It is, instead, the way that both of those things integrate seamlessly into the rest of the config, which is to say the exact same file that's been there since day 1, that declares the rest of the operating system as well. Having the entire setup declared like this actually, properly makes both the kernel and systemd subjectively FEEL like they are crucial pieces of the operating system. They are objectively that, whether they feel that way or not, of course. So the feeling is more accurate, in other words. It takes most of the mental overhead away, too, at least for me. You are at this point, quite literally, making low level changes at a high level of abstraction. There's nothing that feels like it's in your way. It feels like you have total control over software that runs on your hardware, and at that, at a level far deeper than anything other than NixOS ever would, or ever could present in such a tangible way. It feels that way because that's what it is.

This is why I not only don't say I use Linux without putting GNU in front of it, but also why I don't call it at all, that even with GNU in front of it: I never have felt directly connected to the GNU core utils, and I still don't. I also know that that feeling would be lost if, hypothetically of course, I were to ditch NixOS in favor of anything else—be that Windows, Mac OS, or any other Linux distribution I've ever heard of while we're at it. I have almost no time on any BSD, but I don't count that anyway, because it's a completely different kernel and it also lacks systemd, and if we're going all the way back then it predates anything else I can honestly, technically say I've "used."

I literally just tell people the meme that's directly copied from the other meme: I use NixOS, btw.

It's its own thing entirely, by design.

#Linux #LinuxKernel #systemd #NixOS #Random



The media in this post is not displayed to visitors. To view it, please go to the original post.

Writing a VTL Linux Kernel Module for fun [?]

Anyways, realized my SysFS approach was misguided, and migrating to ConfigFS for creating/destroying kernel objects like SCSI Hosts.

Man oh man is there a lot of boiler plate to get ConfigFS up and running, but I think that I've sticklebricked it together correctly at last.

You can create SCSI hosts by making dirs in /config/cvtl/hosts which have the id and enabled attributes (the full SCSI Host object to come soon). If you write a '1' to your host's enabled file it will register it with the SCSI Midlayer, which you can see near the end as it creates SysFS objects in /sys/class/scsi_host/hostX

So when you want to make a virtual tape library you can just make some directories, and echo the values you want to their underlying files and then enable the host with the targets and LUNs you want. Seems like a very friendly interface.

#linux #kernel #linuxkernel #nix #nixos #rust #c #clang #vtl #tapelibrary





The media in this post is not displayed to visitors. To view it, please go to the original post.

Wondering when's the best time to prevent #LinuxKernel regressions from hitting #Fedora #Linux?

It's now, as the first pre-release of #kernel 6.18 is out – which leaves plenty of time to find, report, debug, and fix any problems that Fedora might encounter when it will switch to 6.18.y in about eleven weeks. And testing is not even hard: just use the mainline-wo-mergew copr (copr.fedorainfracloud.org/copr…).

In case you want to play it a bit safer, then testing in two or three weeks is still great! But you really should be testing 6.18-rc6 (five weeks from now), as Linus by then wants all regressions fixed. But at the same time there is still enough time to report, debug, and fix many problems before they reach Fedora – or Arch Linux and openSUSE Tumbleweed, that just like Fedora regularly switch to the latest upstream series.

Testing a newer kernel series only one or two weeks before it enters Fedora[1] is way too late: most bugs can't be fixed anymore before Fedora has to switch to the new series, as the previous series by then is usually obsolete and unsupported upstream.

[1] e.g., either as part of a "kernel testing week" or through the "updates-testing" repos – this is how the update to 6.17.y will soon be prepared for #Fedora 41 and 42, which right now are still on 6.16.y, which was EOLed yesterday.


We’re hiring on the Red Hat Bootloader team! Work on GRUB2, shim, the Linux kernel, and core bootloader toolchains — the foundation of every Red Hat system.

Location: Brno, Czech Republic 🇨🇿
Apply here : redhat.wd5.myworkdayjobs.com/J…

#RedHat #Bootloader #GRUB2 #Shim #LinuxKernel #OpenSource #Hiring #Fedora