Talk:Linux kernel/Archive 6

The content below says 4.15 is EOL, but 4.15 is still maintained by Canonical, Ubuntu 18.04 will use 4.15 until the release of 18.04.2 in February 2019.^[1]

(Stone) 13:24, 3 July 2018 (UTC)

I believe the table only refers to upstream support by the Linux kernel developers, not specific vendors or distributions. If it were the latter case, we'd be listing a lot of older RHEL kernels as still supported as well. — AfroThundr ^{(u · t · c)} 17:25, 5 July 2018 (UTC)

At present, since I elect to have section headings numbered, the article's table of contents shows:

…
4.6 Development model

4.6.1 Relation with Linux distributions

4.7 Maintenance

4.7.1 Releases before 2.6.0

4.7.2 2.6.x.y releases

4.7.3 3.x.y releases

4.7.4 4.x.y releases

4.8 Revision control
…

While reading the article, a heading such as "4.7.2 2.6.x.y releases" is difficult for readers to parse accurately. Accordingly, I am renaming the subsections of 4.7 § Maintenance to Releases 2.6.x.y etc. The TOC will now show instead:

…
4.6 Development model

4.6.1 Relation with Linux distributions

4.7 Maintenance

4.7.1 Releases before 2.6.0

4.7.2 Releases 2.6.x.y

4.7.3 Releases 3.x.y

4.7.4 Releases 4.x.y

4.8 Revision control
…

This should be more readable. yoyo (talk) 21:39, 13 July 2018 (UTC)

This seems like an Essay based on WP:OR

"By this statement it is meant that evolution often does odd (and "sub-optimal") things exactly because it does incremental changes which do not break at any point. As a result, any released version of the Linux kernel is fully usable, even if, for example, device drivers do not support all features of the hardware they are written for.

The conceptual architecture of the Linux kernel has proved its success, while essential factors for this success were the provision for the organization of developers, and the provision for system extensibility. The Linux kernel's architecture was required to support many independent volunteer developers, which suggested that the system portions that require the most development‍—‌hardware device drivers, file systems, and network protocols‍—‌be implemented in an extensible fashion. The Linux kernel's architecture chose to make these systems extensible using a data abstraction technique – each hardware device driver is implemented as a separate module that supports a common interface. In this way, a single developer can add a new device driver, with minimal interaction required with other developers of the Linux kernel.

Another important extension to the Linux kernel is the addition of more supported hardware platforms. The architecture of the system supports this extensibility by separating all hardware-specific code into distinct modules within each subsystem. In this way, a small group of developers can implement a port of the Linux kernel to a new hardware architecture by re-implementing only the machine-specific portions of the kernel." ShimonChai (talk) 19:16, 7 August 2018 (UTC)

ShimonChai (talk · contribs), agreed. I made an edit that hopefully improves the situation. II | (t - c) 09:53, 19 August 2018 (UTC)

• An LWN article is a sign of notability in and by itself, as can be seen in numerous places throughout this article. Indeed, this is only to be expected as LWN is the main (and often the only) journalistic source covering the Linux kernel. It is true that this week we have been graced with the attention of New Yorker, but if the notability bar is set this high it will be nigh impossible to clear it in the future. Indeed many parts of the article are at present only documented by posts on LKML.
• The affair was discussed at length in Popov's Kernel Security Summit talk (for those worried about source count, the talk and the slides can be added as sources). Frank talk in such a formal setting is very rare, and thus notable.
• Most importantly: This affair immediately preceded (maybe even overlapped) with the recent turmoils around kernel development. As the most recent incident of such nature currently documented in the page is from 4 years ago, the STACKLEAK affair provides essential context.
• As to the word "colorful", I would venture that it is neither very original nor the fruit of much research, but alternative phrasings would be welcome.

Balmaz (talk) 20:57, 25 September 2018 (UTC)

Hi,

Sometimes in the article, the term "Linux operating system" is used to describe a system that uses Linux kernel. This could be just a misunderstanding, but, the correct use should be "[...] uses Linux as the kernel" or "[...] uses GNU/Linux distribution". But, why?

The Linux is just the kernel, although your highly importance in an operating system, it is not an OS. To be useful, an OS must use it, like the GNU. This is why Linux operating systems must be called GNU/Linux, without GNU project, we will haven't nothing what we have today, on Linux related things.

For further information, take a sneak peek on this website ^[1]

Pinto.otto (talk) 05:22, 7 January 2019 (UTC) Otto Alan

Antergos is dead. — Preceding unsigned comment added by 70.142.45.182 (talk) 23:59, 13 July 2019 (UTC)

Can anyone explain why the 14th is given as the release date of version 1.0, although there is actually the 13th in the cited source?--Reseletti (talk) 14:10, 3 November 2019 (UTC)

I think that "The Linux storage stack diagram" should be removed.

First, the caption misrepresents the content of the diagram that actually shows the entire I/O subsystem (I mean it's more than just the "[posisition] of the I/O schedulers").

Second, there's no discussion of the I/O subsystem in this section. Therefore that diagram is gratuitous and not within the scope of the section.

Third, if we assume that the article needs such a detailed visual description of I/O subsystem, we should also add at least a half dozen of detailed diagrams of the others fundamental kernel subsystems.

If nobody presents objections, I'm going to remove it within a couple of weeks. Fabio Maria De Francesco (talk) 16:51, 7 February 2020 (UTC)

Why remove it instead of adding some "discussion of the I/O subsystem in this section"? I am not against removing it, just curious about whether better introducing it in the text would make it better. BernardoSulzbach (talk) 17:06, 7 February 2020 (UTC)

@BernardoSulzbach:

Actually my main objection is explained in the third point of my message. I agree with you about adding a section named "The I/O subsystem (VFS, FS's, Char and block devices, I/O schedulers)" and I want to do that. I want as well add "Process and threads management and scheduling", "Memory management - SMP and NUMA", "Concurrency and Synchronization", "Inter-process communication", "Helper primitives" (I mean the data structures management primitives, such as those for lists, queues, and trees - they're used everywhere within the kernel and they are immutable quasi-standard), and maybe a few others. When it's done, for the sake of coherence, I should place detailed diagrams like the above-mentioned, one per each subsystem but I don't have them. I think that if the article have a detailed diagram of just one subsystem of many, it would let the readers that it's the most important subsystem among peers.

Furthermore, I think that there's another issue to be addressed: the "Map of the Linux kernel", that is showed in the "Architecture" section, deserves much more space. I can't understand why the "Storage stack diagram" takes a lot of more space when compared to the map of the entire Linux kernel. However that "Map of the Linux kernel" should be updated to represent the current kernel (it seems to be an old representation of Linux 2.6).

Now I have some questions for you and as well as for everybody interested to this article: 1) Do you agree that detailed diagrams should be placed into each of the subsystem section I've planned to write? 2) Does the "Map of the Linux kernel" deserves more visibility than it has now? If yes, can you or someone else help in drawing and updating those maps? I want to see this article in the list of featured articles as soon as possible Fabio Maria De Francesco (talk) 10:46, 8 February 2020 (UTC)

"I think that if the article have a detailed diagram of just one subsystem of many, it would let the readers that it's the most important subsystem among peers." Readers, yes. Most Wikipedians would probably (correctly) assume that it just happens to be so. Sometimes an active editor is more knowledgeable in one part of the whole article and the part gets overdeveloped.

Replying to "1) Do you agree that detailed diagrams should be placed into each of the subsystem section I've planned to write?": this is a 123,504 bytes article. I am not sure how much these details fit WP:GNG. Personally, I think if well summarized (even if some nice details are left out), some text about the current state of the kernel is welcome. Maybe we have to cut some less important parts of the article or split it eventually.

Replying to "2) Does the "Map of the Linux kernel" deserves more visibility than it has now? If yes, can you or someone else help in drawing and updating those maps?" It makes sense to be more visible than the more "zoomed in" maps. I can help, but I am probably not the most knowledgeable in both Linux kernel and diagramming around here. In the lack of a better contributor, I can make some time to dedicate for this. BernardoSulzbach (talk) 12:48, 8 February 2020 (UTC)

I propose moving the section § Maintenance and long-term support (or part of it) to the new article Linux kernel version history. This would help shorten the article a little bit, as @Tech201805 has suggested before. Similar articles can be found in the Category:Software version histories. --Soluvo (talk) 11:02, 13 November 2019 (UTC)

 Done. --Soluvo (talk) 13:58, 19 November 2019 (UTC)

@Soluvo: Please take a look at my reply in section 2. Thanks for your time. Fabio Maria De Francesco (talk) 08:55, 15 March 2020 (UTC)

@Fabio Maria De Francesco and Tech201805: Hi Fabio, I think this issue has already been fixed. One of the sections has been moved to Linux kernel version history. --Soluvo (talk) 19:10, 15 March 2020 (UTC)

Tech201805 (talk) 18:11, 3 November 2019 (UTC)

@Tech201805:

I totally agree with you. But, wait a moment... What are the sections that should be trimmed a bit or even removed from this article? In tech and science articles I dislike long sections about history of development, stories of conflicts within development communities, and long sections about legal issues. Ok, that's what I would cut off. I need more space for writing additional information about the architecture and especially the (current) technical features.

Please, let me ask it again. What would you cut off from the article? Fabio Maria De Francesco (talk) 08:50, 15 March 2020 (UTC)

Not sure. Even history section is too long specially when there is an article for history. Feel free to start somewhere ;-) Tech201805 (talk) 03:03, 16 March 2020 (UTC)

@Tech201805:

@Soluvo:

I use to move very cautiously whenever it comes to remove contents of other editors, unless the information can be easily proved wrong and/or no reliable source can be provided. In cases where I cannot follow the above-mentioned rules I'd like to gain some consensus.

Having said that I would start with removing the following text, but not before hearing other interested users and editors. This is where I'd like to start shortening the "History" section removing the following text:

"Tanenbaum argued that microkernels were superior to monolithic kernels and that therefore Linux was obsolete. Unlike traditional monolithic kernels, device drivers in Linux are easily configured as loadable kernel modules and are loaded or unloaded while running the system. This subject was revisited on 9 May 2006,[22] and on 12 May 2006 Tanenbaum wrote a position statement.[23]"

One reason for removing such details is due to the existence of the "Tanenbaum–Torvalds debate" article, which is referenced in the same section, just before the text I'd like to cut. What do you think about it? Fabio Maria De Francesco (talk) 09:01, 16 March 2020 (UTC)

Furthermore, in the text there's a statement regarding LKMs and it can cause some confusion to layman readers: LKMs (when loaded) share the same address space of the kernel and so they run in privileged mode (ring 0). A monolithic kernel able to load and link modules while running is still a monolithic kernel. Conversely micro-kernels are split in a series of processes running in diffent address spaces and communicate each other through some IPC mechanism of the micro-kernel. What I mean is that talking of LKMs in that context is out of the intended diffent points o of views advocating monolithic kernel vs microkernel architectures. Fabio Maria De Francesco (talk) 09:29, 16 March 2020 (UTC)

LoC graph looks like the number of lines of code in Linux has stabilised after 5.0 release, but it is grossly misleading.

I took pains to calculate the times between releases mentioned in the graph:

• 1.0.0: 14 Mar 1994 ... 812 days to
• 2.0.0: 9 Jun 1996 ... 113 days to
• 2.1.0: 30 Sep 1996 ... 848 days to
• 2.2.0: 26 Jan 1999 ... 104 days to
• 2.3.0 11 May 1999 ... 604 days to
• 2.4.0: 4 Jan 2001 ... 323 days to
• 2.5.0: 23 Nov 2001 ... 754 days to
• 2.6.0: 17 Dec 2003 ... 2772 days to
• 3.0: 21 Jul 2011 ... 1361 days to
• 4.0: 12 Apr 2015 ... 1421 days to
• 5.0: 3 March 2019 ... 392 days to
• 5.6: 29 March 2020 ... 27 (!!!) days to
• 5.7-rc3: 26 Apr 2020

So a bar chart is a terrible representation of this data, not even mentioning that 2.1/2.3/2.5 development branches ought not to be placed in the same chart as stable ones. MikhailGusarov (talk) 08:54, 27 May 2020 (UTC)

@MikhailGusarov:

I think this article is of vital importance for Wikipedia and I'm looking forward to having it among the featured ones as soon as possible. As far as I know, the Linux kernel is one of the most widespread software in the world and, at the same time, has gathered the most heterogeneous group of stakeholders contributing to its development (Microsoft and IBM had been for decades on opposite sides of the barricades, just to name a couple of historic competitors pushing their own OS's)

Having said that, I welcome any improvement in the right direction.

Unfortunately I'm not sure to understand how you'd like to improve the article, in particular the loc graph.

Can you please elaborate further? Which changes do you want to do?

Fabio Maria De Francesco (talk) 01:56, 10 June 2020 (UTC)

It can be improved in two ways: 1) do not use a bar chart, line chart or any other kind of chart that implies that the bars are evenly spaced; 2) keep the bar chart, but select the versions that are evenly spaced (e.g. choose versions that were released approximately one year from each other) MikhailGusarov (talk) 20:37, 11 June 2020 (UTC)

@MikhailGusarov:

Thank you for your answer. Unfortunately I am unable to work on this issue. Are you able to solve this problem yourself? I would really appreciate it.

Fabio Maria De Francesco (talk) 21:33, 11 June 2020 (UTC)