Talk:Linux kernel

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.

Linux is partly proprietary

Linux has been deblobbed by the Linux-libre project for over a decade now, which regularly removes all the in-tree blobs. By not mentioning this in the article, it is lying by omission, asserting either that Linux has no in-tree blobs, which is obviously false, or that the Linux-libre project is lying, which is also obviously false.

Past attempts to rectify this mistake were stopped and removed from the Talk page, so the article still contains falsehoods to this day.

See also: https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html

185.217.158.63 (talk) 00:40, 7 February 2022 (UTC)[reply]

To correct myself: past attempts were moved to archive 7 of the talk page.

185.217.158.63 (talk) 11:20, 7 February 2022 (UTC)[reply]

Hi 185.217.158.63,
Thank You for Your recent set of contributions!
I'm not knowledgeable enough to tell if You are right about Linux being partially proprietary, but considering that You have not yet cited any (reliable) sources, I am going to tag it as disputed for now and link to this discussion. – K4rolB (talk) 18:42, 11 February 2022 (UTC)[reply]
I'm a Linux kernel developer with about one hundred contributions (patches) in the Linux kernel (please read the public official Torvalds' repository or simply run "git log --author="Fabio M. De Francesco").
I can assure everyone that maintainers reject code that doesn't comply with the GPL-v2.
Again, unless 185.217.158.63 proves that Linus Torvalds distributes the official Linux kernel by infringing his own choice of GPL, I'm going to remove every attempt to discredit the largest and one of the most important Community of developers.
As K4rolB stated "you have not yet cited any (reliable) sources". FSF is not reliable, is biased, and it is the only source you keep on citing.
Furthermore, you are contradicting everything it is said in the article about the license. So why not change all the rest of it, every statement about the free and open source nature of Linux, in accordance to your beliefs? Please be consistent. Fabio Maria De Francesco (talk) 01:39, 11 March 2022 (UTC)[reply]
Everyone here knows that Linux development is done by submitting patches to the LKML and that developers use Git. Each patch has its own unique "Commit number" (i.e., a "hash" that unequivocally identifies each work). Thus, is anybody here able to provide at least a commit hash for one of those "proprietary binary blobs"? I'll wait a couple of days and, if nobody will be able to prove that there is at least a patch with proprietary code (identifiable by a its commit hash), I'll revert everything that states that Linux is not free and open source software. Fabio Maria De Francesco (talk) 03:33, 11 March 2022 (UTC)[reply]
Before 4.14 proprietary binary blobs were just hosted in root/firmware in the kernel source tree, now they're hosted in a separate tree, but references to (and inclusions of) those blobs are still in the kernel. --Betseg (talk) 13:31, 11 March 2022 (UTC)[reply]
You are right. That code is firmware hosted within the official Linux kernel tree.
What some people is not able to understand is that the firmware is not part of the kernel executable (vmlinux). Firmware is executed by device's controllers.
For instance, if computers have HDD, SSD, Wi-Fi adapters, and so on, they have device's controllers that execute proprietary firmware that have nothing in common with what kernels do. Even Linux-libre can't stop firmware to be run by those devices.
Linux just hosts some firmware that must be sent to devices at boot-time. Nobody can say that the kernel is not free and open-source just because it _hosts_ proprietary firmware for mere technical reasons. The kernel object that results from compilation is only made of free and open source executable code.
People who don't understand this subject should avoid to vandalize this article.
Please read the following thread at kernelnewbies.org and follow the links that are in the messages: Fabio Maria De Francesco (talk) 17:21, 11 March 2022 (UTC)[reply]
Sorry, my phone sent the message while I was still searching the link in the kernelnewbies mailing list. Unfortunately it is not yet available because the discussion is too recent. I'll provide the link as soon as possible.
In the meantime, please read the following:
https://www.kernel.org/faq.html#i-heard-that-linux-ships-with-non-free-blobs
This link has been provided by someone of the Linux Foundation who participated in the above-mentioned thread at the kernelnewbies ml. Thanks, Fabio Maria De Francesco (talk) 17:27, 11 March 2022 (UTC)[reply]
Please see <https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html> once again.
Please also see <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/appletalk/cops_ffdrv.h?h=v5.16.14> and <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/appletalk/cops_ltdrv.h?h=v5.16.14> for evidence of blobs included in Linux. This is mainline, in-tree, proprietary code which is part of the kernel and loaded into devices at runtime. A large array of bytes is not source code, therefore it is proprietary software. In order for the kernel to be 100% libre software, there must be no blobs included in the kernel, no matter whether they are executed on the CPU or some other device. Whilst *most* blobs have been moved to the separate linux-firmware repo, blobs still remain embedded in Linux, which makes it partially proprietary. Moreover, Linux-libre removes references to blobs and the blob loading machinery, both of which would be technically libre, but useless in the free world since their only purpose is to load proprietary software.
Are you implying that the FSF and Linux-libre project are lying? In that case you'd need to provide evidence.
185.217.158.63 (talk) 19:04, 11 March 2022 (UTC)[reply]
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/appletalk/cops_ffdrv.h?h=v5.16.14&id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2> and <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/appletalk/cops_ltdrv.h?h=v5.16.14&id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2> both show commit hash `1da177e4c3f41524e886b7f1b8a0c1fc7321cac2` on 2005-04-16, and these files were probably present in Linux earlier because the commit in question appears to be a very early initial import into a git project, whilst git was very young.
185.217.158.63 (talk) 01:13, 12 March 2022 (UTC)[reply]
OK, let's summarize what you said:
(1) I imply that the FSF and Linux-libre (that is backed by the same FSF) are lying and you are right (I imply exactly that!). Aside from those entities, there are no authoritative sources that affirm that "Linux is mostly free and open source".
(2) Your own words ("In order for the kernel to be 100% libre software, there must be no blobs included in the kernel, no matter whether they are executed on the CPU or some other device") make me think that you understand that those binary objects are not part of the kernel but they are necessary firmware. Still you keep on melting the two logical entities without regard for your own words.
(3) Did you read the link that I provided? Whilst I for sure imply that the FSF is lying, you instead imply that the Linux Foundation is lying. Who should we trust?
The problem here is that a very large part of what is inside any Linux distributions has nothing to do with the GNU project anymore (
Wayland, RPM and APT package managers, and much more), but those people still want that the Linux OS
should be referred to as GNU/Linux. Please notice that the Wikipedia's article about the OS is simply called "Linux" (be consistent!).
Here we have two links of the thread on the kernelnewbies mailing list thread that I was talking about:
https://lore.kernel.org/kernelnewbies/[email protected]/
https://lore.kernel.org/kernelnewbies/[email protected]/
In this thread, Konstantin Ryabitsev (of linuxfoundation.org) wrote "I doubt anyone really cares about the purity of Wikipedia articles here.". "anyone" == "kernel developers", if someone don't get it.
Paul McKenney, one of the most important kernel developer and one of the most knowledgeable person that I know in the field of concurrency and parallelism has give up since long time with writing Wikipedia's articles (please see read-copy-update). It looks like Wikipedia has a strong bias against computer scientists and software engineers. We'd better leave these subjects to better equipped people.
I have made the idea that my spare time is not worth these kind of discussions. So, if people here is happy with saying in the article that the Linux kernel is not free and open source just because it hosts some lines of proprietary firmware without which you have a pretty useless system, that Linux infringes the GPLv2 license, and other similar things, I'll give up with working on this article after about 250 edits and instead focus on volunteering on Linux development.
I mean: no more reverts of false/disputed information and no more work to improve and update this article. I'll leave the burden of this work to better suited people. Thanks, Fabio Maria De Francesco (talk) 06:03, 12 March 2022 (UTC)[reply]
1. You have still provided zero evidence that the FSF, FSFLA, or Linux-libre project is lying. In fact, you yourself have provided evidence via a link to the Kernel Newbies mailing list archive from Robert Joslyn that the Linux kernel is in fact blobbed as I have described.
2. Yes, blobs are part of the kernel no matter whether they are executed on the CPU or loaded at runtime into some other device. They are in-tree code.
3. I never implied the Linux Foundation is lying and what you describe is a false dichotomy.
Yes, the OS is GNU and Linux is just a kernel. I am shocked that you refer to Linux as a so-called "Linux OS" when you obviously know from contributing to it that Linux is just a partly proprietary kernel. Those other Wikipedia pages should be edited, but one thing at a time.
There is insufficient evidence for your claim that Wikipedia "has a strong bias against computer scientists and software engineers", and you're only saying this as a last resort because you know you're wrong about Linux not having blobs. Also, you're implying that other people editing this article or replying to this discussion are not computer scientists or software engineers, which you have zero evidence for.
"without [blobs] you have a pretty useless system" -- I use Linux-libre and it works fine aside from the non-critical components which need blobs.
I remember when I started the previous discussion about Linux being blobbed, first you denied it, then you said there are blobs but they've been moved to the linux-firmware repo, then you said the blobs I linked to were just "shellcode", and now I've met your challenge of linking to in-tree, mainline blobs and providing a specific commit hash, you threaten to stop editing! When are you going to realize that you are wrong?
Threatening to stop editing when you've been proven wrong about something is more childish than the time you started a discussion on the talk page because you were no longer the single largest contributor to this article!
185.217.158.63 (talk) 15:54, 12 March 2022 (UTC)[reply]
Your ridiculous claim on the email you linked that "fake information, mainly sponsored and backed by the FSF and by the Linux libre project (or something like that)" also has zero evidence to back it up. I am in no way affiliated with the FSF or the Linux-libre project, I just want to correct this article so that it stops stating false information, namely that Linux is "free" when it contains proprietary, binary blobs. Why are you resorting to ridiculous attempts to discredit me instead of admitting that you are wrong?
185.217.158.63 (talk) 16:05, 12 March 2022 (UTC)[reply]
I've added three citations to the article.
185.217.158.63 (talk) 16:55, 12 March 2022 (UTC)[reply]

Again, Mr. 185.217.158.63 cannot understand the logical difference between kernels and firmware (I invite her/him to attend at least an undergraduate OS course). The kernel is 100% free and open source code, while some firmware hosted in Torvalds' tree is not.

Thus a better approach would be writing something like "while the Linux kernel (core + drivers + development tools - e.g., tracers and tests) is made of 100% free and open-source code, the official Torvalds' tree hosts also some files with proprietary firmware that are needed to initialize closed-source hardware at boot time and without which that same hardware cannot be made operational". I would also add the link that the Linux Foundation sent to me for explaining why those binaries are there (https://www.kernel.org/faq.html#i-heard-that-linux-ships-with-non-free-blobs). Why the Linux Foundation should not be considered an authoritative source compared to the FSF? Fabio Maria De Francesco (talk) 12:30, 17 March 2022 (UTC)[reply]

"The kernel is 100% free [(libre)] and open source code, while some firmware hosted in Torvalds' tree is not." -- do you not see the logical contradiction here? Firmware *is* code.
185.217.158.63 (talk) 13:39, 17 March 2022 (UTC)[reply]
That's a red herring, because "Torvald's tree" is not "The kernel". The code for the kernal is part of the code tree, but not all of it. Isn't it time for
WP:DR? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:10, 17 March 2022 (UTC)[reply
]
Firmware _is_ code. Indeed! But unfortunately you cannot understand that firmware _is_not_ part of any OS kernels. They don't share the same address space. Kernel are executed by the system CPU cores, firmware is executed by device controller. There is no overlap. The kernel, via device drivers, talks to the devices firmware by using I/O interfaces. Firmware cannot use in-kernel APIs. Again, if you cannot understand this subjects please take a course in Computer Architecture and another in Operating Systems. Fabio Maria De Francesco (talk) 06:54, 18 March 2022 (UTC)[reply]
I don't appreciate the insults, especially after I've explained numerous times that, to be a blob, it doesn't matter whether the code is executed on the CPU or loaded at runtime into another device. You are correct, firmware loaded into other devices at runtime cannot use in-kernel APIs, but you are incorrect about there being overlap; proprietary firmware blobs are embedded in in-kernel, mainline code files, and as such *are* part of the kernel. When compiled, these blobs become part of the kernel binary itself.
I have a suggestion: since we both no longer want this to be true, why don't you look at the deblob log from Linux-libre and start working on moving in-tree blobs to the Linux-firmware repository and write code for them to be requested from the filesystem at runtime? I presume you're capable of doing such a thing.
185.217.158.63 (talk) 22:59, 18 March 2022 (UTC)[reply]
When compiled, these blobs become part of the kernel binary itself. no? That's factually incorrect. They are distributed alongside the kernel but they aren't in the kernel. The blobs that are distributed alongside the kernel are located in /lib/firmware and the kernel loads them dynamically, not statically. Betseg (talk) 18:58, 19 March 2022 (UTC)[reply]
Some proprietary firmware binary blobs are loaded from /lib/firmware as you describe and are located in the linux-firmware repository, however, there still exist many proprietary firmware binary blobs embedded within code files as long sequences of hex arrays. I already linked to a couple earlier in this thread.
185.217.158.63 (talk) 05:16, 20 March 2022 (UTC)[reply]
For example, the following blob: <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/appletalk/cops_ffdrv.h?h=v5.16.14> has a proprietary license which states: "This material is licensed to you strictly for use in conjunction with the use of COPS LocalTalk adapters."
185.217.158.63 (talk) 05:20, 20 March 2022 (UTC)[reply]
Yeah, no, this is stupid. These "proprietary blobs" you're referring to are indeed in binary form, but they're still distributed under the same license as the kernel. The actual proprietary blobs are distributed in a separate tree, linux-firmware.
Just stating that "hurr durr the kernel has blobs in binary form therefore proprietary >:((" isn't enough to mark the kernel as "partly proprietary" as, again, these binary blobs are licensed under the GPL, just not the source code to the blobs. However, the blobs are free to be reverse-engineered by whoever whenever, since they're distributed under the GPL ;)
There is an argument to be made that parts of the kernel tree isn't distributed in source code form, but saying that parts of the tree isn't licensed under the GPL (or any compatible license) is flat-out false, so I'm taking the liberty to revert this change
Bonan vesperon. 81.234.98.122 (talk) 18:57, 1 August 2022 (UTC)[reply]
This is simply not true. In this conversation has been linked the cops_ffdrv.h file which is bundled in kernel tarball releases directly from the developers, along with other binary firmware (i.e. it is not all relegated to linuxfirmware). You're right that not all firmware distributed as binary with the kernel tarball is proprietary (this one includes ASM source code here), but you're wrong that all firmware is distributed as GPLv2(+) or compatible. cops_ffdrv.h specifically says in its header that it is not part of the Linux kernel, it is a separate program - however it is bundled with Linux and it is not under a GPL license. This is why I made the small change to note that while not all Linux firmware within the main tarballs is proprietary, at least one of them is. I also made the change to specify that the software is not technically part of the Linux kernel itself, so I changed it to say "included with" rather than "in Linux." Xerxespersrex (talk) 13:21, 2 August 2022 (UTC)[reply]
sigh you don't seem to understand. The binary blob you're referring to in cops_ffdrv.h is distributed under a GPL-compatible license, just not the source code for it. If you're under the impression that distribution terms for that blob violates the GPLv2, please do shoot a mail to the LKML where you remove it and such, and detail the legal arguments as to why it should be removed, not the philosophical/political arguments.
Again, there's an argument to be made that Linux doesn't ship with GPL'ed/GPL-compatible source code for stuff like the firmware blobs, but stating that the kernel is "partly proprietary" because of that is false since the blobs themselves are redistributable under the GPLv2.
Licensing is pretty fucky and hard to understand, but I hoped I explained it well enough for you to understand where I'm coming from.
Bonan vesperon. 81.234.98.122 (talk) 17:50, 2 August 2022 (UTC)[reply]
I did not claim that the firmware makes Linux partly proprietary, I was just responding to your post as I assumed you were the one to revert a change I recently made (the name of this section of the talk page is incidental). My personal opinion about free software is not the topic of discussion. I also did not claim that having this firmware in the kernel violates the GPLv2. If it did, then no Linux distro could distribute any software that was not under a GPLv2-only license with their installation media, assuming that firmware can be considered a separate program from the kernel legally like general other pieces of software can (I am not a lawyer). I'm simply interested in the fact that we have a section detailing the license of the kernel, and short of external projects there isn't a way to get the kernel directly in a tarball without also downloading non-GPLv2 firmware. So, it seems fair to mention that in the section of the infobox detailing the license of the software.
I don't really know what you're trying to say by saying that the license of this particular firmware that says in its comment that it is not GPLv2 is GPLv2. It has restrictions on its use, and any restrictions on its use other than those in the GPLv2 violates the GPLv2 (again, for this particular piece of software, not for the entire kernel). It may be redistributable with software that is GPLv2 in this particular circumstance (like how bash, GPLv3+, can be distributed with the Linux kernel on a LiveISO), but do you have an external source to back up this claim that it is, in fact, under a GPLv2 license? Xerxespersrex (talk) 12:38, 3 August 2022 (UTC)[reply]

GNU additions

@

edit war
, let's talk before reverting more edits (and adding more GNU propaganda).

Per my edit summary, no, you don't need GNU utilities to run a program from the Linux kernel, you just need a virtual terminal manager (like getty (Unix)), and a shell (like Bourne shell). Betseg (talk) 19:24, 12 March 2022 (UTC)[reply]

Your claim that needing an OS to run programs is "GNU propaganda" is ridiculous.
I never claimed that one "need[s] GNU utilities to run a program from the Linux kernel", I am correcting the article to state that applications were run on the combination of the GNU operating system and the Linux kernel, which is factually correct and what actually happened.
Sure, you can use another OS, but what actually happened was that Linux was combined with the larger GNU system and by doing so filled in the last gap to make a 100% free OS at the time.
185.217.158.63 (talk) 19:34, 12 March 2022 (UTC)[reply]
By the way, you need a **lot** more than a kernel, getty, and shell to get an OS running. The GNU Project has been working since 1994 to write the GNU operating system, which includes a compiler (GCC), text editor (Emacs), debugger (GDB), all of which are needed to actually write, compile, and debug code respectively in the first place, as well as a bootloader (GRUB), shell (BASH), system utilities (coreutils), etc.
185.217.158.63 (talk) 19:40, 12 March 2022 (UTC)[reply]
Therefore, claiming "applications run on Linux" or referencing a so-called "Linux OS" are both ridiculous and laughable, because the GNU operating system is actually needed too, and Linux is just a kernel, one small contribution in the grand scheme of things.
185.217.158.63 (talk) 19:44, 12 March 2022 (UTC)[reply]
At this point, Linux being combined with the GNU operating system, some components of the GNU operating system in particular being Bash, GCC, and some other GNU programs:
The phrasing is weird on this sentence. I'm not a native English speaker, so maybe that's the problem, but I can't tell what you were trying to say there.
Linux in combination with the GNU operating system, could run software and applications that had been developed for Unix.
There's literally no need for a mention of GNU in this sentence. It's trying to say Linux can run UNIX programs (and OS utils), so the fact that GNU can be used alongside it is irrelevant. The same applies to the paragraph about Xorg.
[[Linux|operating systems which use the Linux kernel]]
There's a consensus on Linux that "Linux" means operating systems that use Linux as their kernels already. No need to disambiguate that.
for it could be compiled by a computer running the GNU operating system which used the same version of the Linux kernel.
Why is the fact that a computer with GNU utils can compile the kernel a necessary addition? Why couldn't it be just for it could be compiled by a computer running an operating system which uses the same version of the Linux kernel.?
because the GNU operating system is actually needed
Have you literally head of Alpine Linux or Android?
Also, can you stop editing for each paragraph and add all your comments in a single edit? It's really hard for me to reply because your edits disrupt my edits. Betseg (talk) 19:57, 12 March 2022 (UTC)[reply]
Correction: At this point, Linux was being combined with the GNU operating system, some components of the GNU operating system which were being combined in particular being Bash, GCC, and some other GNU programs:
"It's trying to say Linux can run UNIX programs (and OS utils), so the fact that GNU can be used alongside it" Linux can't "run" any applications; it's just a kernel. You need an OS to run applications, and a kernel is just one part of an OS. GNU is not run "alongside" Linux, GNU is the OS in which the Linux kernel is a small part, and GNU is the OS on which applications run.
You also seem to believe that GNU is just a collection of utilities. It is not. GNU is an OS.
"There's a consensus on Linux that "Linux" means operating systems that use Linux as their kernels already. No need to disambiguate that." Yes, there is. Linux is a kernel, not an OS. The concensus that OSs which include the Linux kernel should also be called "Linux" is a ridiculous instance of the ad populam fallacy. In reality, these systems are the combination of the GNU operating system and the Linux kernel, called GNU+Linux or GNU/Linux.
There are one or two distros which use the Linux kernel, but not the GNU operating system, such as Android and Alpine, but they are not what the article is about; the article is about the early history of the Linux kernel, when it was first being combined with the GNU system.
Why couldn't it be just for it could be compiled by a computer running an operating system which uses the same version of the Linux kernel.? That's technically true, but at the time the only operating systems that used the Linux kernel were various GNU+Linux distros; OSs which used the Linux kernel but not GNU had not been invented yet, and as such are irrelevant at that point in history.
"Also, can you stop editing for each paragraph and add all your comments in a single edit? It's really hard for me to reply because your edits disrupt my edits." We are both guilty of that.
185.217.158.63 (talk) 20:34, 12 March 2022 (UTC)[reply]
We are both guilty of that. yes, my example was bad, and I realized too late, my bad.
Linux can't "run" any applications no, it can. at boot it runs /sbin/init, which would run further programs such as putty; or it can run arbitrary binaries with the command line argument init=[executable]. If that argument is, say, the Bourne shell, that shell can be used to run further programs.
You need an OS to run applications
you need a **lot** more than a kernel, getty, and shell to get an OS running
GNU is an OS.
from the article operating system: An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs. this is Linux, and a libC. No part of this definition only includes GNU programs and excludes any non-GNU program. I don't think GNU provides an init software for Linux, so a Linux distribution can arguably be called a GNU/systemd/Linux distro.
If you're instead talking about usability, a system with just a shell is still an operating system. Not a terribly usable one, but one nonetheless.
OSs which used the Linux kernel but not GNU had not been invented yet I swear I saw a forum or a mailing list post that mentioned a person that used Linux with SysV utils but I can't find it for the life of me.
Betseg (talk) 21:19, 12 March 2022 (UTC)[reply]
An init system is not an application, it's a program which is part of the OS; at the point when the init system is executed, no useful application could run on the system. As you mentioned, running a shell at this point would be relatively pointless without first initialising the rest of the system. GNU has an init system, called Shepherd, although you can use non-GNU init systems like OpenRC if you want. If you want to call a GNU system its verbose, full name, which includes a greater number of programs installed on the system, such as GNU+Linux-libre+OpenRC+etc. then go ahead, but calling it just "Linux" is incorrect because the heart of the system is basically the GNU system with Linux added.
That article is incorrect. "OS" can also refer to the entire system, not just the kernel and libC.
As I've now explained and justified my rationale for editing the article, let's restore it to this revision <https://en.wikipedia.org/w/index.php?title=Linux_kernel&oldid=1076748452>.v
I'd also like to note that @Quetstar: rolled back changes that were irrelevant to the edit war.
185.217.158.63 (talk) 21:45, 12 March 2022 (UTC)[reply]
It's been four days; I'm going to go ahead and restore the page.
185.217.158.63 (talk) 02:54, 16 March 2022 (UTC)[reply]
And I am going to restore it back to its original state from before your changes because i disagree with them. Quetstar (talk) 21:06, 16 March 2022 (UTC)[reply]
"I disagree" is not a valid reason for doing so. Please either explain yourself or undo the revert.
185.217.158.63 (talk) 22:44, 16 March 2022 (UTC)+[reply]

The heart of the system is the kernel; everything else is just add-ons. Maybe compromise and call it Linux-X.11? IMHO it's time for

WP:RFC? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:27, 16 March 2022 (UTC)[reply
]

That is misleading; being the most low-level component does not make it the most important, because the OS will not work if *any* critical component is missing, eg. without a compiler, the kernel could never have been compiled in the first place, without a bootloader, the kernel could not have been loaded in the first place, without a text editor, the kernel could not have been written in the first place, etc.
Many of my additions are irrelevant to this dispute, and so are the additions of other editors that have also been reverted. I am going to revert the page, and if you want to revert it again, please only revert the specific GNU additions so that it is clear what we are discussing. Ideally, leave it be because "I disagree" is not a valid reason, it's a personal opinion. My additions added several citations. Where are yours?
185.217.158.63 (talk) 00:34, 17 March 2022 (UTC)[reply]
So you think that the core parts of Linux, I mean the operating system, is _not_ the Linux kernel...
OK, let's assume your point for a moment.
I compile Linux with Clang and I boot it with rEFInd.
So, what has GNU got to do with them?
For what it regards to the firmware binary blobs, it still looks like you cannot understand the difference between kernels and firmware.
Why don't you write something like "the Linux kernel is 100% open source and free, but the official (Torvald's tree) also hosts proprietary firmware.".
Saying that the kernel is "mostly free" is plain false from a technical perspective. Firmware is not kernel, but, as I said, either you have something to do with FSF propaganda or you simply don't master the subject. Thanks for disrupting what was a nice article. Now it is up to you and everyone else who may care Fabio Maria De Francesco (talk) 08:02, 17 March 2022 (UTC)[reply]
The compiler does not have to use the kernel that it is compiling, and most compilers do not come from FSF. Of course, the thrust of my edit was not that FSF's claim is bogus, but rather that it is time to use on of Wikipedia's disput resolution mechanisms. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:29, 17 March 2022 (UTC)[reply]
As far as i'm aware, Linux is a fully fledged OS. GNU is just a distribution of software. In fact, Linux isn't even the project's official kernel. That distinction belongs to the
WP:DR, so I will revert them again and I expect it to be settled here. Quetstar (talk) 10:42, 17 March 2022 (UTC)[reply
]
For the bazillionth time: Linux is a kernel. GNU is an OS. Firmware is code and is part of the kernel, hence the kernel is partly proprietary.
I added references and citations and links to the blobs in Linux, yet people still make these same mistakes!
"So, what has GNU got to do with them?" you're setting up a contrived yet technically possible situation to try and distract from the fact that most OSs which use Linux, which is a kernel, are GNU. It is technically possible to use a non-GNU OS and plug in Linux as a kernel, but this is exceedingly rare aside from Android and Alpine, which this article is not about. The article is about the early history of the Linux kernel, when it was initially being plugged into the greater GNU operating system, which is why GNU is relevant.
Linux doesn't just "host" proprietary firmware on kernel.org and reference blobs located in the filesystem it can load into a device at runtime, as I have previously linked you to, it has blobs embedded within its mainline source tree, in code files. Therefore, Linux is partly made of blobs and is partly proprietary.
"either you have something to do with FSF propaganda or you simply don't master the subject." once again, the first claim is laughable and the second is a thinly-veiled insult.
"The compiler does not have to use the kernel that it is compiling, and most compilers do not come from FSF." That's true, but my edits did not say this. You're misremembering them.
"As far as i'm aware, Linux is a fully fledged OS. GNU is just a distribution of software." you are unfortunately mistaken. GNU is an OS which was initially announced in 1983 and work begun on it in 1984. Linux was released as free software about a decade later and was then plugged into the GNU operating system that Stallman and free software hackers had been writing for about a decade at that point. Unfortunately, Wikiepdia at the moment has many silly quirks that obscure this, like referring to the Linux kernel, the GNU+Linux operating system, and operating system distributions which use the Linux kernel all as "Linux", which is not only incorrect but also incredibly confusing. This is why the disambiguation is necessary. Experienced technical people might be able to work out in their heads which one is being referred to, although it is sometimes completely ambiguous. Nevertheless, non-technical people will have no chance of figuring this out and will just be confused.
185.217.158.63 (talk) 03:55, 18 March 2022 (UTC)[reply]

How a Linux kernel developer sees the free+open source vs. proprietary debate

I'm a Linux developer since April 2021. While still a newcomer I've been working literally across all its subsystems. I've been one of the most prolific contributor for the v5.19. At LWN I am ranked 12th of 2086 contributors per lines of code: https://lwn.net/Articles/902854/

"Linux" from now on explicitly refers to the kernel of several operating systems. This discussion has nothing to do with an unrelated debate about the most suited names those OS.

Let's go on to the core of my intervention...

Everybody knows that the official Linux is released by Mr. Linux Torvalds. His repository can be easily reached at kernel.org. Users can use "git-clone" to download git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ in their working space. Users can read, change, and submit their signed patches to the kernel to the relevant maintainers and lists. Good practice wants to always also Cc the LKML.

The fundamental information many are still missing is that the code of Linux is only a subset of what people clone from Torvalds tree.

This is not a minor detail. Linux is only a subset of whatever is hosted in Torvalds tree. ./torvalds/linux.git contains much more than Linux. For example, it contains several user space tools, tests, scripts for helping with development, static analyzers, documentation, firmware, code examples, and many other things.

To summarize: ./git/torvalds/linux.git != Linux. ("!=" is a C operator which means "not equal").

Whoever affirms that ./git/torvalds/linux.git == Linux is ill informed, at best.

Linux is free and open source and furthermore it provides a very complex but exhaustive means to enable / disable thousands of features before users build the executable kernel object, according to their particular needs and preferences and also to explicitly avoid the inclusion of non proprietary binaries into the kernel image.

Whoever distributes binary kernel images must disable the inclusion of non free and open source code, otherwise they infringe the laws. The international laws don't allow the distribution of proprietary code in the same executable built with GPL-v2-only code. It would be a serious infringement and I'm not aware of any major distributions which is willing to take that legal risk.

However, the kbuild infrastructure has several options which developers and users (those who won't redistribute their customized kernel images) may enable or disable to change how the kernel handles firmware (regardless it being a binary blob or free and open source).

Before going on, don't forget that, from a logical point of view, a "firmware" is a different class of software with respect to a "kernel", it serves other purposes and it is not a subsystem of any kernel, including proprietary kernels. The kernel merely sends the firmware to the devices controllers that need and run them.

They don't share the same address space and can't request services each others if not via standard API in the relevant device drivers. Therefore, if device drivers are open source we know that they can't manipulate or leak user and kernel data. No device drivers in Linux are proprietary. We have the code and we can check what they send to the device controllers or viceversa.

For due completeness...

Linux provides an option to build firmware blobs into the kernel or forbid that build. The option is called CONFIG_EXTRA_FIRMWARE and if users need a .bin file into the kernel image they must explicitly name that binary before building the kernel.

The following paragraphs are copy-pasted from the online help of the Kbuild infrastructure which is responsible of kernel configuration:

"[] For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy the usb8388.bin file into /lib/firmware, and build the kernel. Then any request_firmware("usb8388.bin") will be satisfied internally inside the kernel without ever looking at your filesystem at runtime. WARNING: If you include additional firmware files into your binary kernel image that are not available under the terms of the GPL, then it may be a violation of the GPL to distribute the resulting image since it combines both GPL and non-GPL work. You should consult a lawyer of your own before distributing such an image.".

Users who don't need firmware built into the kernel may instead enable the CONFIG_FW_LOADER which loads firmware at runtime from specific user space directories, or they may also rely on CONFIG_FW_UPLOAD which, when enabled, allows device drivers, which instead are indeed a logical part of a kernel, to expose a persistent sysfs interface that allows firmware updates to be initiated from power users at will. Fabio Maria De Francesco (talk) 05:30, 20 September 2022 (UTC)[reply]

Rust language

Rust is mentioned in the infobox, but nowhere in the article text, specifically § Programming language and coding style. This probably should be addressed. ☆ Bri (talk) 16:33, 27 February 2023 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Linux_kernel&oldid=1208192613"