- Preparations for a kernel panic screen as sort of like a Windows Blue Screen of Death (BSoD).
This is my favorite part.
My guess is it means this sort of recent windows feature of showing a QR code on how to search for the issue you’re experiencing
Having a QR code with a link to the error code or at least a way to search it is an excellent UX thing, especially for those who are less accustomed to dealing with Linux kernel panics
See the comments in response to mine on how this might look
I love your specific example screenshot
“Hey is this Microsoft support? Yeah, err, so I’ve got this MANUALLY_INITIATED_CRASH error, can you help?”
“Have you tried… Not initiating…a crash…?”
Lol just what I found first with a quick google, but it is funny
It doesn’t have a QR code in it’s current state AFAIK, but I believe the guy wants to add one eventually. Here’s what it might look like:
https://gitlab.com/kdj0c/panic_report/-/issues/1Also from the commits it looks like the colours are configurable at compile time (white on black default), and that exclamation Tux is already there.
Looks like this is already a thing though with [systemd-bsod]
Nah, that only handles boot errors, not kernel panics.
Ah thanks for the clarification, that’s pretty neat, I’ll update my comment
deleted by creator
Well the QR code part hasn’t even been submitted to the maintainers yet AFAIK, so there’s still time to change, and I’m sure it’ll be configurable so you either get a stack trace or a QR code.
I like it when my crashes come with a plain text explanation of what caused the crash. It just seems simpler to me than having to deal with some barcode fuckery.
One doesn’t exclude the other. And if you really hate QR codes that much I’m sure there will be a flag or you can recompile the kernel without this, it’s Linux after all
NT’SYNC
Exciting. Hopefully the linux youtubers do some comparisons so we can see if this makes a noticeable difference.
Damn that’s a huge performance increase wtf. That’s a gpu upgrade worth of performance for free.
Yeah, it almost looks like you’d be able to run things faster than natively on windows, which is why I’m suspicious (not that it’s a lie just that the numbers lack context). It doesn’t say what the numbers represent I think?
The numbers represent FPS. Now, Wine is not an emulator and the Linux architecture and it’s system calls are written in C, so it’s not uncommon to find games running better on Linux nowadays. Pretty sure all games can be optimized to be run better than on windows.
Proton+DXVK is pretty darn efficient. On average it is slightly slower than Windows, but not by much and it can also be faster in certain games.
That’s Linux free real state for you sugar pie
My lesdyxia saw NSYNC
This is the best summary I could come up with:
Barring any last minute reservations by Linus Torvalds, Linux 6.9 stable should release later today.
In turn the Linux 6.10 merge window will then open for the next two weeks and already some early pull requests have been submitted for this next kernel version.
Intel’s Neural Processing Unit is initially found with new Core Ultra “Meteor Lake” laptops.
-
The Panthor DRM driver is being merged for supporting newer Arm Mali graphics.
-
TPM bus encryption and integrity protection to precent active/passive interposer attacks that have been recently demonstrated for both Windows and Linux.
-
An Intel low-latency hint for aggressively boosting the GT frequency for GPU compute.
The original article contains 550 words, the summary contains 108 words. Saved 80%. I’m a bot and I’m open source!
-
Emulating NT synchronization primitives in Wine - Zeb Figura at Linux Plumbers Conference | https://www.youtube.com/watch?v=NjU4nyWyhU8
Futex | https://en.wikipedia.org/wiki/Futex
Lock, mutex | https://en.wikipedia.org/wiki/Lock_(computer_science)
Here is an alternative Piped link(s):
https://www.piped.video/watch?v=NjU4nyWyhU8
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
The NTSYNC driver should be merged for emulating Windows NT synchronization primitives for speeding up Windows games running on Wine / Steam Play (Proton). (Update:) But it looks like so far only the basic NTSYNC driver patches are in char-misc-next and currently not the entire complete series.
Very nice. Gaming on Linux slowly starts to be no problem at least for me.
It shouldn’t speed up anything on Proton, since it already uses f-sync, which gives the same speedup, but breaks some apps, which is why Wine wasn’t using it and ntsync was created as an alternative.
