Yup, one example that I noticed recently, RedHat backported the eBPF subsystem from Linux 6.8 to their 5.14 kernel (in RHEL 9.5):

https://docs.redhat.com/en/documentation/red_hat_enterprise_...

Blog entry: https://www.datadoghq.com/blog/ai/toto-boom-unleashed/

Yep, when you have thousands of different production apps, installed and running directly on Linux - not talking about containers or microservices here - you’ll have very little appetite to upgrade all of them to the latest and shiniest technologies every couple of years. Stability & compatibility with existing skillsets is more important.

Large corporations are full of middle-managers who do not lead anything nor produce anything (customer facing) and whose only job is to "facilitate information flow" and "pull teams together" etc. I think these roles will be replaced with AI chatbots quickly. The upside (for the company) ought to be that now the facilitation should happen very quickly and is measurable/manageable more directly. The downside (for the line employees) is that now your boss is a chatbot.

How do we know that it's these types of managers who will be replaced, instead of the ones doing the actual work?

Perhaps some companies do deeper analysis first - with AI summarizing & clustering signals from various internal systems and corporate email history. I'm not saying that this is better for everyone compared to current human-driven approaches, but the human driven approaches seem to be just about stack-ranking employees by their recent performance review ratings and drawing a red line in a spreadsheet. Amazon's recent "flattening the organization" initiative might well be using AI as one of the signals. I have no idea whether that's actually true - but then again it's 2025 and they have been a data-driven company for a long time.

Also, anything you do with enterprise (cloud) customers. People like to talk about scale a lot and data people tend to think about individual (distributed) systems that can go webscale. A single system with many users is still a single system. In enterprise you have two additional types of scale:

1) scale of application variety (10k different apps with different needs and history)

2) scale of human capability (ingenuity), this scale starts from sub-zero and can go pretty high (but not guaranteed)

Astute observation, but also CrowdStrike would like a word :-)

Hi, yep lsblk targets a wider area of functionality, like showing mountpoints, device UUIDs, while lsds focuses only on block device settings.

Maybe the latest Linux versions have lsblk versions that support these columns, but in RHEL9 at least I don't see equivalents to lsds'es WBT_LAT, QDEPTH (not the same as lsblk's RQ-SIZE), WCACHE, FUA and some others. But these 4 are which I regularly need (especially when troubleshooting a yet another slow fsync() issue etc). I did and do use lsblk all the time too, but still end up catting and grepping various additional files and correlating the results, sometimes on systems with 100+ multipath block devices.

The other reason was that I wanted a tool that shows me where it gets these values too (for myself and sometimes for explaining stuff to others).

Edit: That being said, it shouldn't be hard at all to add the said extra fields to lsblk too.

Would be worth adding this as an FAQ on the page. Great job btw.

EDIT: Would also be really cool to define what each field means, if you're gonna reimplement everything anyways, why not make it as user friendly as possible.

Thanks. Yep I have to revamp the whole 0x.tools webpage, right now it's a mix of older tools & prototypes and the "final stuff" and it's confusing what's what.

The lsds verbose option shows where in the Linux /sys fs each individual field comes from (lsds -lpv) so that's the ultimate source of what each field means. But I could pull each sysfs file's description from docs into a table on the webpage (I'm probably too lazy to create a manpage for now - help is appreciated)

Edit: Since there are not that many fields, it would be possible to add a -d option in addition to -v to get a human readable description for each field too. One of the main sources of confusion is the "queue_depth" vs. "nr_requests" fields. My ideal (which I usually don't reach) is to make these tools "explainable", so that they tell you from where they got their input data (and what basic math was applied).

Thank you for the detailed response, even if I'm reading it late! This is exactly what I was trying to learn; what this tool exposed that lsblk is missing.

I just added a little comment/errata regarding the NVME_QDEPTH column to the post (search for errata). I should probably rename that column to emphasize that (for now) it’s the Linux nvme module level max QD and not the hardware one (it’s complicated…)

Thanks! Yep I was thinking of doing that next, will be very easy as under the hood the data is stored in Python dictionaries.

Yup same here. Perhaps a better experience would be to first just reach out with a "normal human being" email and later on either side of the conversation can just CC: schedule@example.org address to the email reply.

Downside: now this (external) service knows what you're talking about

Upside: now this (external) service knows what you're talking about - and can create a meaningful name & description for your meeting request (and you'd have some searchable history etc)