Slashdot Mirror

As others have answered, "several" in this context means a vague small number.

I'd like to point out that when writing up a news article, the author should have taken several minutes to look up exactly how long ago the X32 ABI was introduced.

"It was just six years ago..."

is a little bit too difficult to parse.

Here's a few human readable sources:

https://kernelnewbies.org/Linu...

https://www.phoronix.com/scan....

German: https://www.heise.de/ct/artike...

Russian: https://www.opennet.ru/opennew...

The Linux kernel finally has KASLR enabled by default in the 4.12 kernel – in July 2017 [1]

The Fine Summary is poorly written, making it sound like NetBSD is way behind the times. But the truth is it's only three months later than Linux. Not bad IMO when you consider how many people work on the NetBSD kernel versus how many work on the Linux kernel.

[1] https://kernelnewbies.org/Linu...

It's easy to criticize from the outside, but the Linux kernel has historically had kernel locks that created similar problems, such as the "big kernel lock", removed ca 2011 (ie: not ancient history).
https://kernelnewbies.org/BigK...

As noted in the article, this particular locking problem appeared in Windows 10 and wasn't present in Windows 7, so the balancing acts between the fine-grained locking mechanisms, thread performance, and backwards-compatibility are clearly challenging to maintain. Not excusing; just observing. Windows has never been known for it's ability to support massive numbers of parallel threads, so it is not surprising that previously overlooked problems can appear or become exacerbated in these situations. Many people, even here on Slashdot, laud Microsoft for the generally excellent backward- compatibility in Windows, and criticize the Linux kernel for being generally horrible at it. But here you go, a pretty nice example to illustrate that backwards-compatibility has a cost.

VMWare Workstation/Player 12.5.5 also needs some love.

VirtualBox has already been made compatible. Thanks, Oracle for keeping it up to date.

Lastly, a human readable changelog is always where you expect to find it: https://kernelnewbies.org/Linux_4.11.

TCP implementation has been refactored to make the TCP listener fast path completely lockless. During tests, a server was able to process 3,500,000 SYN packets per second on one listener and still have available CPU cycles

Thanks for the heads up!

As someone who is kind of a casual Linux system admin, I just make sure to read the Kernel Newbies on each kernel. It really helps me at least kind of keep up on what's going on.

It has been ages since the Linux kernel maintainers modified the kernel to avoid excessive buffering so that's not really a problem anymore. With small amount of ram typical of most home routers, you end up with a NAT table overflow where the device can't keep track of all of the connection and either expires old connections early, refuses to allow new ones, or in Cisco's case hard crashes. It doesn't take much to run into the limits, I have seen bittorrent bring a home router to it's knees.

For a more complete changelog:

http://kernelnewbies.org/Linux...

Good luck with that law and in which country(ies) would you apply it?

Generally women are under represented in STEM, hopefully this is changing.

You would also need to look at the changes logs for more than a single release to get a representative percentage of women contributors.
You would also need to look at the subsystem maintainers as they may not be in a purely development role for example: Sarah Sharp.

Mainlined in 3.13 / 19 Jan 2014

From kernelnewbies:

1.1. A scalable block layer for high performance SSD storage
Traditional hard disks have defined for decades the design that operating systems use to communicate applications with the storage device drivers. With the advent of modern solid-state disks (SSD), past assumptions are no longer valid. Linux had a single coarse lock design for protecting the IO request queue, which can achieve an IO submission rate of around 800.000 IOs per second, regardless of how many cores are used to submit IOs. This was more than enough for traditional magnetic hard disks, whose IO submission rate in random accesses is in the hundreds, but it has become not enough for the most advanced SSD disks, which can achieve a rate close to 1 million, and are improving fast with every new generation. It is also unfit for the modern multicore world.

This release includes a new design for the Linux block layer, based on two levels of queues: one level of per-CPU queues for submitting IO, which then funnel down into a second level of hardware submission queues. The mapping between submission queues and hardware queues might be 1:1 or N:M, depending on hardware support and configuration. Experiments shown that this design can achieve many millions of IOs per second, leveraging the new capabilities of NVM-Express or high-end PCI-E devices and multicore CPUs, while still providing the common interface and convenience features of the block layer. Note: in this release, only the virtioblk driver has been ported to this interface, other drivers will be ported in next releases.

LWN: https://lwn.net/Articles/62497...
kernelnewbies: http://kernelnewbies.org/Linux...
omgubuntu: http://www.omgubuntu.co.uk/201...

Booting 32 bit UEFI on a 64 bit CPU has been fixed in kernel 3.15. http://kernelnewbies.org/Linux...

The Antibufferbloat draw my attention...
Maybe it will be worth using at home for my custom fw/gateway.
at the end of page

Fortunately the syntax for the new nft utility seems to be easier to understand http://kernelnewbies.org/nftables_examples

Posting as AC to preserve mod points, I searched and found http://kernelnewbies.org/Documents which you probably know. That is referenced by https://www.kernel.org/doc/Documentation/HOWTO as a resource for kernel developers. Unfortunately it looks like a dying site. The last edited date in the footer is old for many pages. The list of Up To Date Books include stuff published in 2005 or about kernel 2.6.
Probably Linux need a Linuxpedia and developers should at least explain their code there.
However there are plenty of contributors so I'm quite sure there is a way to get up to speed.

There is: http://kernelnewbies.org/

I'm so used to kernelnewbies having a great changelog that it's surprising to not see it updated for 3.12. I hope everything is going OK for the maintainers there!

I can well believe there are differences in battery performance between the OSes but we need someone to sit down with programs performing exactly the same operations on base configurations of all the OSes and then report the results. Saying they vary is one thing but far more interesting is to know why. Is it the drivers, is it the scheduler, is it the kernel, is it a better userspace or is it some combination of all of them?

My understanding is that both Linux and Windows supported timer coalescing before OS X. Linux had a tickless kernel. OS X's XNU kernel is allegedly tickless but I can't find out when this change actually took place. As for Windows it's not clear - my understanding is that Windows 8 is tickless but I can't find a clear reference only one that says Windows 8 idles more than Windows 7 so perhaps it has dynamic ticks and hence can be tickless. That last link seems to suggest that Microsoft have put a large amount of effort into trying to make Windows more battery friendly...

In addition to the above, Windows has a huge number of energy saving features: Idle detection that can control things like what processes are allowed to start, Windows 8 store apps use a "only focussed app runs" model unless it's a background task, USB suspend (Windows 7), adjustable tick rate (Windows 2000) (Windows seems to suffer from programs that push for higher resolution ticks though). It would be nice to know whether all these things are having an impact.

One of the things I noticed on OS X 10.8 though is that when the battery is near to depletion it seems to force the CPU to run at a slower rate until the machine power goes out completely. I don't know the other OSes do this or whether it's a positive impact but it could impact on results that purely go on time rather than amount of work done.

I can well believe there are differences in battery performance between the OSes but we need someone to sit down with programs performing exactly the same operations on base configurations of all the OSes and then report the results. Saying they vary is one thing but far more interesting is to know why. Is it the drivers, is it the scheduler, is it the kernel, is it a better userspace or is it some combination of all of them?

My understanding is that both Linux and Windows supported timer coalescing before OS X. Linux had a tickless kernel. OS X's XNU kernel is allegedly tickless but I can't find out when this change actually took place. As for Windows it's not clear - my understanding is that Windows 8 is tickless but I can't find a clear reference only one that says Windows 8 idles more than Windows 7 so perhaps it has dynamic ticks and hence can be tickless. That last link seems to suggest that Microsoft have put a large amount of effort into trying to make Windows more battery friendly...

In addition to the above, Windows has a huge number of energy saving features: Idle detection that can control things like what processes are allowed to start, Windows 8 store apps use a "only focussed app runs" model unless it's a background task, USB suspend (Windows 7), adjustable tick rate (Windows 2000) (Windows seems to suffer from programs that push for higher resolution ticks though). It would be nice to know whether all these things are having an impact.

One of the things I noticed on OS X 10.8 though is that when the battery is near to depletion it seems to force the CPU to run at a slower rate until the machine power goes out completely. I don't know the other OSes do this or whether it's a positive impact but it could impact on results that purely go on time rather than amount of work done.

And don't be an asshole like this guy who provided a URL that you can't click on. http://kernelnewbies.org/Linux_3.11

Some of the high visibility mainline projects may be more prone to intolerance and abuse of, for want of a better phrase, newbie errors. You could try dipping your toes in the water in one of the useful if unglamorous projects that might be less harrowing. There are various orphan projects out there, others that get little attention, and some potentially useful but incomplete ones as well. Then there are projects designed for the newcomer. You might want to take a look at this:

KernelJanitors

Do we not like Kernel Newbies anymore? I've always looked to them for a synopsis of kernel features: http://kernelnewbies.org/Linux_3.10

Even Linus's release mail suggest that "As usual, I'm sure H-Online and kernelnewbies will do better writeups of the details.." :-) http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/04336.html

Do we not like Kernel Newbies anymore? I've always looked to them for a synopsis of kernel features: http://kernelnewbies.org/Linux_3.10

Linux 3.9 recently introduced a mechanism to use a SSD as cache in a deeply integrated and configurable way.
So now you could get all the benefits with any filesystem...

The dm-cache device mapper target was added to the kernel in Linux 3.9. bcache is apparently on track for 3.10

I thought we generally point to Kernel Newbies: http://kernelnewbies.org/Linux_3.9

Never heard of H Online. Is this another site we're using now?

You might want this page then:

http://kernelnewbies.org/Linux_3.6

It usually has links to http://www.h-online.com/ http://lwn.net/ and/or Wikipedia which hopefully explains it in a way you'll understand.

I think it is: http://kernelnewbies.org/Linux_3.4#head-011d0bd1a20451b0e374283b36a71d8e8f5b7ae1

To the best of my knowledge, the ath5k/madwifi drivers are the only Linux drivers to be ported from the BSDs (OpenBSD/FreeBSD) to Linux. Which other drivers out of the 56 Linux wifi drivers were ported from the BSDs to qualify the "large number of WiFi drivers were written for FreeBSD or OpenBSD and then ported to Linux" statement?

Linux has had its own 802.11 stack called mac802.11 since the 2.6.22 kernel four years ago which was developed by Devicescape. The only driver I know of that carried a (Net)BSD 802.11 stack over to Linux was madwifi which had net802.11, was never mainline and was superseded by ath5k... The madwifi driver never went mainline, nor did its net802.11 stack. Why do you think that the 802.11 stack from a BSD needs copying into a Linux driver when mac802.11 exists?

Stop whining and fix it yourself.

http://kernelnewbies.org/LinuxChanges

http://kernelnewbies.org/Linux_2_6_38 says:
> Core:
> - Add hole punching support to fallocate() (commit)

Good to see the efforts towards backward compatibility, I often wondered why punchcard support was lacking in previous releases.

Informative as usual: http://kernelnewbies.org/Linux_2_6_38

memory leaks... windows developers were taught for years that garbage collection works. In fact it was a big selling point of VB6.

It doesn't, and not all developers realize this, so some developers don't explicitly kill objects. Maybe they all do by now and they're just sloppy.

It's Too Hard(tm) to find all this stuff so the vendors tell you to reboot instead of spending the money necessary to fix their software.

Even the mighty linux can have memory leaks if the developers suck.

FWIW, I've never seen a garbage collector that actually worked 100%. We'd be better off writing good clean code instead of relying on them.

All of that being said, even on windows you can usually kill a process and reclaim the memory. Reboots are only necessary when you have a service or driver running that gets into an unkillable state. I've seen this happen with IIS and bad NIC drivers.

I've never seen software on a linux box get into the state where you couldn't kill it so until I do, I say linux never needs to be rebooted, except to replace hardware. Even in a failover situation, you can simply unplug the network cable to simulate an outage. No need to bounce the box...

However, prior to 2.6.24 kernel, linux memory manager was still being fixed and memory was subject to excessive fragmentation. Some drivers as well as other progams require contiguous pages of memory (network drivers being a prime example) and if the memory was too fragmented you could run into situations where you'd go to restart network and the NIC wouldn't come back up because there wasn't enough contiguous space to restart the driver.

See http://kernelnewbies.org/Linux_2_6_24 section 2.4 for details. There actually used to be an occasional intermittent need to reboot linux in this limited case but it was rare to need to do this and you could usually get around it by freeing up memory and restarting the troublesome driver, after which you'd bring up the other stuff running on the box. /shrug

The link in the story just points to the list post announcing a new major version of the Linux kernel. Note that the changes listed in the post are for changes from the last release candidate (-rc8) and not from the last major kernel release (2.6.36). For an overview, it's better to head over to Kernel Newbies. It even has a section which summarizes the "cool stuff", major features that the new kernel brings.

Interestingly, the overview appears to overlook what I believe is a major feature introduced in 2.6.37: power management for USB 3. I may have to do some more digging through the actual kernel changelogs. Maybe the change was reverted during the last few candidate releases, but I remember reading about it in H-Online, particularly this part:

The XHCI driver for USB 3.0 controllers now offers power management support (1, 2, 3, 4); this makes it possible to suspend and resume without temporarily having to unload the driver.

(In the original, the parenthetical numbers are links to the kernel commits.)

Power management for USB 3 would have been the most important new feature for me. Without it, you have to resort to a number of ugly hacks to hibernate or suspend a laptop or a motherboard with USB 3 enabled. (Turning off USB 3 in the BIOS is a hardware hack that allows you to bypass the software hacks.)

Mainline Linux supports 4096 CPU cores for almost two years now.

One of the 2.6.36 patches explicitly mentions addressing poor responsiveness when doing IO on slow (e.g. USB) devices. The CentOS 4 kernel seems to be a heavily patched 2.6.9 though...

AFAIK there are only two I/O schedulers remaining in recent Linux (and if you squint you might say that RHEL 5's kernel could have been related to 2.6.34 at one point right? :) - CFQ and deadline (three if you count noop I guess). The anticipatory scheduler was removed in 2.6.33...

Assuming your SSD is detected correctly, the Linux block layer maintainer is proposing changes to improve SSD performance. The idea of waiting for requests (so as to be able to reorder them in a ladder fashion) is not used on SSD devices since 2.6.28 though.

The link I posted looks broken from here. If it is, the full text of it is: http://kernelnewbies.org/Linux_2_6_36#head-738bffb3415051b478ecdfd2eabb0294e35146a9

The 2.6.36 kernel supposedly has a fix for this issue. I haven't been able to test it yet myself, but it sounds like they finally tracked it down. See here for more information.

Always has a nice human readable summary of the changes.

I will argue that this is the feature that will get adults interested in Linux. 12.4. Input Add driver for TWL4030 vibrator device (commit) http://kernelnewbies.org/Linux_2_6_34 I'd like to see Windows support the mighty TWL4030!

The packages mostly match those in Fedora 12, which makes sense as that came out in November and FC13 isn't released yet. However, they have bumped some things. Most notably, the FC12 kernel was 2.6.31, while RHEL6 uses 2.6.32. That's not surprising given a fair number of virtualization and performance features, as well as bug fixes, happened for 2.6.32.

i'm glad that at least some kernel hackers recognise this, and 2.6.32 actually has support for new configuration method, which looks at already loaded modules and some other stuff to create trimmed down kernel config - http://kernelnewbies.org/LinuxChanges#head-11f54cdac41ad6150ef817fd68597554d9d05a5f

But "make oldconfig" is there since years.
It's not tedious at all to configure your new kernel when you have your old config file. Only the new options or the modified ones will show up.
So the tools are already there for those that build their own kernel.

i'm sorry to say, but that's not a good attitude. and i'm being polite here.

developers need testers. some arrogant assholes might claim they don't, but then they're known as ones. now, to attract testers you not only are polite to them, you also do not discourage them by breaking or ignoring things that hamper them (but might not concern casual users), you actually should build tools and other support functionality for testing.
essentially, having less testers will impact quality of the software for everybody else, so casual users also should desire for the project to have more testers.

i'm glad that at least some kernel hackers recognise this, and 2.6.32 actually has support for new configuration method, which looks at already loaded modules and some other stuff to create trimmed down kernel config - http://kernelnewbies.org/LinuxChanges#head-11f54cdac41ad6150ef817fd68597554d9d05a5f

Actually, you're not correct. Support has been included in LKDEV devices and and ioctl since 2.6.28. TRIM support (called 'discard' by the Linux kernel maintainers), is included the latest kernel builds in the ext4 filesystem (see the LKML, etc.)

I guess Ubuntu will have to cope with the other 6 releases before Windows Vista III the terminal. Ubuntu unashamedly release is timed to contain the latest Gnome, http://library.gnome.org/misc/release-notes/2.28/ of course it includes its own release notes as well http://www.ubuntu.com/getubuntu/releasenotes/910. I'm sure your probably aware of good stuff in EXT4; GRUB2; Empathy; Software Centre that have been heavily documented everywhere including serious numbers of Application Improvements in Firefox and OpenOffice. Linux itself continues on spewing greater and improved hardware support which include the usual greatness http://kernelnewbies.org/Linux26Changes Check out 2.26.28 - 2.26.31 oh and X and Mesa and... Oh is that a Win 7 cry for attention I know whats new and Better Vista don't cut it!

Far from just a punchline, the comic's content is both relevant and accurate here, as this release 2.6.31 has some news about the desktop, while supporting 4,096 CPUs is absolutely a real feature in a slightly earlier release (2.9.29).