Linux version 4.0 and clockpocalypse are coming
A new numbering system is on the cards for Linux, but an even bigger issue is at hand: the year 2038 is set to be a disaster if we don’t act now, with an event similar to the Y2K bug on the horizon.
Linux kernel-master Linus Torvalds has taken to Google+ for a public poll about moving to the next numbering pattern for Linux, with the majority voting in favour of a jump to Linux version 4.0.
However, unlike the usual breaking change or major update that a level up in numbers might symbolise, Torvalds was quick to point out that the team doesn’t break compatibility, adding that they “haven’t done feature-based releases since basically forever”:
On an actual technical side, this was a *fairly* small release. By modern standards, that is. It’s certainly noticeably smaller than some recent kernels have been, although we’re talking ~9k non-merge commits rather than 10-11k, so it’s not like it’s that huge of a difference.
Other changes include patching, support for IBM’s new Z13 mainframe, Intel’s Quark system-on-a-chip, support for the the OASIS VirtIO 1.0 spec and a good amount of graphics enhancements. Torvalds assures us that the changes won’t be that noticeable, just completed with smaller numbers “so that I can do releases without having to take off my socks again”.
The Clockpocalypse Cometh
In other Linux news, the year 2038 should be marked in your calendars as the year that a longstanding deficiency in the way computers record time values is due to wreak havoc, says LWN.net editor and longtime Linux kernel chronicler Jon Corbet.
Affecting all manner of software, the “Year 2038 problem” as its affectionately known, was raised by Corbet at the Linux Foundation Collaboration Summit in California last week, who advised participants that it was “time to start worrying” about the issue.
The year 2038 brings the end of time for 32bit architectures, with the furthest time that a signed 32-bit integer can represent in the Unix time format set at 03:14:07 UTC on Tuesday, 19 January 2038. Many punters are hoping to solve the problem by upgrading to 64bit systems, however Linux developer John Stultz is wary of this approach:
However, 32bit processors are still being produced today in extremely high volumes, and many of those systems are being used in commercial, industrial and medical environments, where these systems may be quite literally embedded into the walls and machinery and are expected to run for 25 years or more. As these small systems become more and more pervasive, the risks of major trouble in 2038 grow.
Because of the impact, Stultz believes that the upgrade solution isn’t very sufficient, and a transition plan needs to be put into place “which will allow 32bit CPUs being sold today and in the future to function correctly past 2038”.
Corbet was concerned with programmers and their interaction with the bug, noting that each year developers produce software that doesn’t take 2038 into account only compounds the problem. He said that if the community continues to “distribute software that has this problem in it, we are setting up problems for the future”.
Linux updates are progressively addressing the issue, with the 3.17 kernel including a batch of internal work toward an eventual solution to the 2038 dilemma.