Differences between 2.4 and 2.6 were quite big, I don't think there was another such big change in kernel releases any time later. But that was also the time when Linux was transitioning from being a hobby project (already useful for serious stuff) to being a serious professional operating system – the last moment for major refactoring.
Linux kernel is still changing and being constantly refactored, but now the changes tend to be more gradual and version numbers matter much less.
The 2.5 development only tree had a ton of behind the scenes big long projects that weren't visible to users until the stable 2.6 dropped and everything suddenly changed.
Like a complete redesign of the scheduling code especially but not exclusively for multiprocessor systems, swapping much of the networking stack, and the change from devfs to udev.
If you hold udev up next to devd and devpubd that solve similar problems on the BSDs, it's a clear leap into "Linux will do bespoke binary interfaces, and DSLs for configuration and policy, and similar traditionally un-UNIX-y things that trade accepting complex state and additional abstractions to make things faster and less brittle to misconfiguration" which is the path that the typical Linux pluming has continued down with eg. Systemd.
A lot of modern Kernel development flow is about never having that kind of divergence and sudden epoch change again.
2.6 was my first kernel I believe. As far as I know, after that the version number cycle was sped up a lot so now we get a bunch of small things every new version instead of half a new kernel between two versions.
Differences between 2.4 and 2.6 were quite big, I don't think there was another such big change in kernel releases any time later. But that was also the time when Linux was transitioning from being a hobby project (already useful for serious stuff) to being a serious professional operating system – the last moment for major refactoring.
Linux kernel is still changing and being constantly refactored, but now the changes tend to be more gradual and version numbers matter much less.
The 2.5 development only tree had a ton of behind the scenes big long projects that weren't visible to users until the stable 2.6 dropped and everything suddenly changed.
Like a complete redesign of the scheduling code especially but not exclusively for multiprocessor systems, swapping much of the networking stack, and the change from devfs to udev.
If you hold udev up next to devd and devpubd that solve similar problems on the BSDs, it's a clear leap into "Linux will do bespoke binary interfaces, and DSLs for configuration and policy, and similar traditionally un-UNIX-y things that trade accepting complex state and additional abstractions to make things faster and less brittle to misconfiguration" which is the path that the typical Linux pluming has continued down with eg. Systemd.
A lot of modern Kernel development flow is about never having that kind of divergence and sudden epoch change again.
2.6 was my first kernel I believe. As far as I know, after that the version number cycle was sped up a lot so now we get a bunch of small things every new version instead of half a new kernel between two versions.