Linux 7.2(igalia.com) |
But then you look at the change log, and almost everything you see added sounds really useful to someone working on this stuff. 35 years of work on this and there is still so much to be done even if you most people using it never directly feel it.
All these things are visible across the board, both from developers and end users side.
Yes, we interact with it all the time but it isn't something that the end user would notice and that is a great thing. If you are not directly poking around with that stuff, you shouldn't notice it.
That they are so seamless should be seen as a badge of honor.
Right:
> The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. There are some implementation and design deficiencies that make it unreliable for some corner cases and the feature should not be used in production, only for evaluation or testing. The power failure safety for metadata with RAID56 is not 100%.
* https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#man-b...
Didn't know that. Is it worth looking into over ZFS?
But for me, a few kinds of changes have been highly visible as a user:
- basically all filesystem changes, especially the mainstreaming of copy-on-write filesystems
- not a change, but dramatically better filesystems performance than Windows or macOS has always been noticeable
- the addition of cgroups and cgroupsv2, and later user namespaces, which enabled lots of software that I use
- all kinds of driver updates and additions, obviously
- newer virtual filesystem stuff for introspection, set to replace /proc
- addition of KVM! I remember when this was not a given, in the Xen days
In that way I've kind of felt the opposite somehow, like OS updates on proprietary operating systems feel thin and empty.
There is still a lot of work done on the background, perhaps even more than ever.
But unless you are a power user eagerly waiting for one of the things currently worked on, you wouldn't notice or care unless the interface changes (which usually only happens on visual interfaces).
But there isn't a whole lot a kernel can do in the same way. Hardware support is about as user-visible as things get for Linux.
Now it behaves more like Windows/Mac, even when 100%, my youtube/spotify tab can still run smoothly.
(Of course i think there will be hit in some areas, like my code would be built slower, there is no free meal).
You should try to compile a custom kernel for your machine and strip the unneeded things out. Good luck.
Linux has diabetes.
[0] https://www.digitalfoundry.net/news/2026/06/valves-hdmi-2-1-...
So now the HDMI Forum just doesn't really care anymore I guess.
Ok actually I "solved" this by upgrading to 128GB of RAM (before the rampocalypse), but still they should fix it.
After setting up earlyoom to gracefully start shutting stuff down at a threshold before hitting oom, robustly works all the time even under intense ram + swap pressure + 100% cpu on all cores sorta workload
What type of info do you get out of this for those who read this? So i can glance your insight?
All my monitors support DP, my GPU has more ports for DP ...
I am genuinely interested as I've never even considered using HDMI for my Desktop.
Been using it since the early nineties .
At work I use Windows Server 2025 as my desktop ( the alternative would be the dreadful AI infested Windows 11).
While Windows Server 2025 is not dreadful , the Linux experience is so much nicer .
> DRM exposes an API that user-space programs can use to send commands and data to the GPU and perform operations such as configuring the mode setting of the display.
> User-space programs can use the DRM API to command the GPU to do hardware-accelerated 3D rendering and video decoding, as well as GPGPU computing.
If FOSS drivers support HDMI 2.2 when devices start shipping with HDMI 2.2 ports then this'll be disproven, but the HDMI forum held off on allowing AMD to implement 2.1 support in their Linux drivers for years and only relented when they released HDMI 2.2. Valve with the Gabecube probably didn't have much to do with it considering how low volume it is.
I don't mean that specifically the linux kernel mattered so much to them, but in general for consumers (product makers) all up and down the line.
New filesystems and major changes to existing ones (large performance improvements, new features like adding better compression standards which I now know I can use, fixes to long-standing bugs which open new use cases).
New protocols like wireguard when it was new and exciting (still is now that I think of it). When that was mainlined, I knew I had some network rearchitecting to do.
New device drivers like amdgpu when it was massive news. Less so these days since most hardware is well supported, and I don't buy the absolute latest.
New kernel APIs which I can use in my programs — like landlock, when it was merged I knew it was time to improve sandboxing in some of my stuff.
Though LWN and kernel newbies do it best, already linked by others.
This is a well-formatted changelog of the changes that Igalia has contributed to the release, AFAICT.
KernelNewbies publishes a much more general summary of changes (it is much longer than this one).
https://lwn.net/Articles/1078068/ https://lwn.net/Articles/1078539/
https://lwn.net/Articles/1088991/ has all the relevant links. Probably somewhwere there is also a more detailed "neutral" article.
I make technology decisions at a large embedded shop that makes cars.
Content like this tells me Igalia has serious programmers and is relevant upstream. The memory sticks.
It's also informative, which makes me feel good.
They're a consultancy. It's good for business.
I install Linux on a wide variety of hardware for both work and personal reasons.
I don't read the detailed changelogs religiously but after years of paying some attention to them I can understand most of it and see where the industry is investing developer efforts, what cool new hardware is gaining support and what new security or performance features people are focusing on.
Living through that made me wonder why people would ever swap out their Broadcom or Atheros WiFi card for an Intel one.
ty for sharing
Per @sph, as Linus provide no changelog, seems like the firm is putting it together for others
I use DP too when I can. For example my main desktop is using DP.
But many devices have HDMI, not DP. For example I've got seven Raspberry Pi here: they all have HDMI and none has DP. There's, what, 100 million Raspberry Pi in the world by now? Don't know the number but: devices that do not support DP aren't rare.
And Linux runs on much more than desktop PCs.
I am using it exclusively and since many decades.
I was specifically asking for desktop usage though, because that's what I am mostly working with.
If that point didn't come across, I am sorry. English isn't my first language.
For A/V stuff: CEC and (e)ARC.
* CEC: control one device, and downstream items receive instructions so you're (ideally) not fiddling with multiple remotes.
* ARC: the TV/display can decode audio/video and pass the audio to a sound bar or other audio system.
So this is a win for couch gamers and open source in general.
You can't picture such devices or what's the holdup?
> I am genuinely interested as I've never even considered using HDMI for my Desktop.
Sorry if that didn't come across. English isn't my first language
The real problem I had was a low limit to save history. I install a lot of software, Cachy would run the snapshot every time (good), but it only kept like 5-10. And the one I needed to restore to was further back (I can't remember the exact issue), but that was more the defaults of how cachy set it up, and my use case than btrfs/snapper itself.
Whatever tool you use to snapshot btrfs, you may wish to have a custom number of saves if you install tons of software a lot...so you can avoid having too few backups available from the boot menu. I'm sure there was a way around it but I said f it and just reinstalled instead of trying to look up on my crap tablet how to get at the old files (assuming they were still there and just not accessible from the boot menu vs being completely erased).
I do not think it was btrfs that broke, to be clear.
This was like a week before the big hack on AUR, so I wonder if I got hit by a supply attack, but it was pretty shoddy, and broke my system, thus my reinstall saved me from (possibly) a lot more pain down the road.
Raid 5 is still consider unsafe.
Don't run postgresql on it.
So..... it's "very stable, unless you do this or that" state.
Whichever one of my test machines is using btrfs is doing fine, though, so on a subjective level that one's been stable enough.
I'd count my losses and move on happy that it hit front page.
This new thing is pretty cool :
=USB4STREAM for streaming data with USB4=
In addition to Thunderbolt networking, which was already supported, this release adds support for streaming data directly over a cable as well (USB4STREAM). It is very simple and basically just transfers raw packets from one host to another. The driver exposes /dev/tbstreamX devices on each side of the link that can be used to transfer data using regular filesystem operations such as read(2) and write(2):
host1 # cat /dev/tbstream0
host2 # echo hello > /dev/tbstream0
This can be useful in cases where network tooling is not available or just for existing applications like dd and cat that do not support sockets. This feature can be used at the same time with thunderbolt_net so they don't rule each other out, and it allows multiple streams to be created.But even from end-user perspective, maybe its hard to see change when you compare one year or so, but over somewhat longer period I definitely see improvements. Over say a decade or so, wifi/bluetooth/trackpad support has significantly improved. Over last 5 years, I think gaming has become huge and you can actually use Linux as gaming machine. In last 3 years or so, I think I've seen my 5k display using Thunderbolt work much better. Fractional scaling also works much nicer.
NVIDIA GPUs are not shitty to use on Linux, and AMD has been working great for slightly longer. UEFI/TPM works much better now as well, where I don't have to worry about booting in legacy mode when using GPU drivers.
I didn't have to think about any of these above. If I think harder, I can likely come up with many more.
eBPF vfs hooks based watchers are really nice.
[edit] details
- you setup a single `mount` - this is the only part that requires cap_sys_admin - then you run a single daemon, this one only needs cap_bpf, and this runs once at startup and is its own self contained program - this daemon writes events into a ringbuf referred to by a file in that bpf mount - you then read that from your standard user program (this can be done by whichever application needs to consume the events)
the events are create, mkdir, delete. renames are automatically decomposed since we hook at the vfs layer. the hook itself is practically free to run and thus there is no question of a performance impact.
This year I have installed Linux Mint on computers from people who wanted to jump from Windows to Linux. Every time I booted via USB, installed Linux and 10 minutes later everything was working. This would not have happened 10 years ago. Back then there would always be an issue with a video driver, WiFi driver or audio driver.
Of course there are still hardware issues for some special deviced, but today Linux just runs fine for most people. And that's a great accomplishment.
Funny you say that, as I was installing Ubuntu on peoples laptops and it just worked, like 15 years ago... :-)
Anything with split iGPU/dGPU was a mess no matter what and where, WiFi that was not Intel was a mess, suspend to ram and suspend to disk were a coin flip if the system would wake up again or if it would decide to wake up on its own and overheat itself to panic.
This was absolutely not everyones experience, including mine.
It's just nice when technology is not hampered by nonsense.
Dell U5226KW from 2026 only has DP1.4 (but HDMI 2.1).
I don't think I have seen anything above DP1.4 in the wild for now.
DSC is just the "card up the sleeve" for DP1.4, you can push it all the way to 4K 240hz HDR. So there is little incentive to switch to DP2.1 for OEMs.
I'd say it's usual for displays released in the 2-5 years old range. HDMI 2.1 got somewhat quick monitor support for consoles, but search for "first DP2.1 monitor" gets results from 2024
TVs.