@danderson Fuchsia was described to me by its lead as "Plan 9 without files", which is as comprehensible to me as "biology without life". In fairness, that expressed more of a lack of understanding of Plan 9 than a bizarre architecture. I wish it had done well, but that figure you quote worries me.

It’s been a long time coming... and it's finally here!

We’re making all the resources from Kernel Recipes available to you, from the very start (yep, there are some gems in there!). It’s still a little rough around the edges in terms of interface, but it’s totally usable: slides, videos, photos, and drawings

Plus, don’t worry – we’re keeping last year’s site online, and the current one too. So, dive in and start exploring!

Enjoy! 🚀

https://archives.kernel-recipes.org/

I am so amused by the whining from the data scraping tech bros about (GASP) the data scraping being done by other people...
https://www.404media.co/openai-furious-deepseek-might-have-stolen-all-the-data-openai-stole-from-us/

Of course we'll go from vilification, to banning, to public subsidy of the domestic tech bros in order to protect our "lead" in... whatever it is that the current type of garbage GenAI is good for.

Oh, wait, we already jumped to the last part

🥳 "'We are almost at the "write a real driver in #rust" stage now, depending on what you want to do."' 🥳

That's what @gregkh wrote in the comment for the main driver core and debugfs updates merged for #Linux 6.14, as it contained "driver core rust bindings for PCI, platform, OF, and some i/o functions"; there is also a "misc device rust bindings and a sample driver to show how to use them":

https://git.kernel.org/torvalds/c/2ab002c755bfa88777e3f2db884d531f3010736c

#LinuxKernel #kernel #rustlang

@bagder Oh crap, yes, that does work on this model! It's even buried on the spec sheet if you read it close enough. It didn't on a previous model I had, so I'll blame that reason why I never tried this out. Ok, one less cable to carry around with me when traveling now, thanks!

Scariest cable I have that I actually use. It's a USB-C to Thinkpad "adapter" that I bought to power a thinkpad that shipped with a giant 135W brick-of-a-power-supply. This cable does work, but has the tendency to "overload" many USB chargers, causing them to reset. Fun times, but good for traveling so I don't have to lug the brick around with me as well.

I presented at Everything Open @everythingopen this afternoon. 🗣️🐧

My slides are already available for anyone who'd like to check them out.

Thanks for having me - I really enjoyed the session! 🙂 ✌🏽

https://embeddedor.com/slides/2025/eo/eo2025.pdf

@alwayscurious @sima @sourcejedi That's one reason, the other one was "power just glitched, my printer better be on the same device node it was before it was turned off". Same for keyboards, mice, disks, etc.

@alwayscurious @sima "Normal" PCI hotplug systems should export this information, as the BIOS expects a user to add/remove PCI devices on a slot basis. Otherwise why would a BIOS care about exporting the slot number at all. So it's not required, and you are lucky if it shows up. good luck!

@joshbressers Linux is only #6? We better get on that to reclaim our 2nd ranked spot of last year despite only participating for 10 1/2 months, not the full 12 everyone else was able to have! :)

The short summary of if it has been worth the hassle: yeah I think so. It is now easy and fast to get new CVE IDs. We have a seat at a table where I can complain loudly on the system and what I say actually might have a (small) impact.

We have yet to deny someone else's crazy CVE attempts against curl.

#curl has been a CNA for a year now https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/

@monsieuricon I wish someone would tell me the steps for CVE repair for the kernel so we don't have to keep making them up as we go along :)

@alwayscurious @sima @sourcejedi Again, reuse of major/minor numbers was a design requirement at the time. And, you know the path / label / metadata / whatever for the block device before you mount it, so go off of that information if you don't trust the device major/minor number information.

@alwayscurious @sima PCI devices, at the bus/slot/function level do not have device nodes, so I don't understand the issue here.

They might have a specific PCI driver bound to them, at the function level, and if so, the parent of the device node for that class device (i.e. input, tty, drm, etc.) will then point to that PCI function. But PCI slots don't always match up to PCI bus and device numbers either, as that's a physical thing and many PCI systems don't expose or even know that information (i.e. the BIOS doesn't know.)

Also, PCI bus numbers can change at boot, so you can't know what is happening.

Driver probing can be deferred at any time by userspace for USB devices, and I think that was recently added for PCI devices too, look for the "trusted" device information in the documentation somewhere.

Good luck!

@aho Thanks for the info, I'll look into it when I get a chance! I've fixed my original problem for now, so odds are I'll live with it until something breaks again.

@alwayscurious @sima @sourcejedi That ship sailed decades ago as we had to support device node reuse a long time ago, it was a requirement! But obviously not your requirement :)

You have full control over device node creation in userspace, that's what udev gives you if you want (or any udev-like program). set up a whole different /dev/ with just your naming/numbering scheme. The kernel gives you the interface and the information to do this, why not take advantage of it if you need it?

@alwayscurious @sima Then do that,the kernel provides you this information through sysfs, that is what it was explicitly designed for.

But yes, the race condition of "parse the topology, determine the device node, and go to open it" when the device is removed and a different one added right between those last two steps is real. Luckily in real-hardware situations, almost extremely rare if not physically impossible due to hardware debounce times, and one that we explicitly did not care about when we created sysfs and udev (i.e. physical access trumps anything).

New year, new hardware failure, must be time for a new motherboard, any recommendations of what the "best" AMD workstation motherboard is these days?

@lanodan @sima @sourcejedi Ordering is never guaranteed stable.