Why isn't Linux embraced as the official GNU kernel?












125















While I knew for quite some time the existence of Hurd, and its mission as the official GNU Operating System kernel, I was wondering how come Linux is not embraced as the official GNU kernel over the years, seeing as it is in a much better state than the Hurd?



Linux has been, more or less, serving this role 20+ years so far, however one can see that the GNU Project is keeping its distance when it comes to Linux. Why is this happening? Is it because of a dream that Hurd will (at some point in the future) be in a production quality level? Is it because the GNU project doesn't see its mission reflected as much as it wants in Linux? Is it for other political reasons?






linux-kernel gnu hurd







share|improve this question


















  • 20





    Kind of "illegal" question here but interesting. With a bit luck it gets protected for "historical significance", given brilliant enough answers... ;-)

    – Hauke Laging
    Apr 28 '13 at 14:20






  • 2





    @HaukeLaging Thanx mate. I too feel like this is a good question, and may produce interesting answers, and can not really understand why someone would cast a close vote. I am sure this is something that a lot of people would like to know.

    – NlightNFotis
    Apr 28 '13 at 14:21






  • 1





    Oh, that's simple: Someone would just have to point at the FAQ and shout "off-topic" AND "too broad"...

    – Hauke Laging
    Apr 28 '13 at 14:24






  • 5





    @HaukeLaging You are so true, and I wish that people were more pragmatic and could recognise a question with some value instead of just pointing to the FAQ and shouting. One can easily see in S.O the most interesting questions being closed, only to wonder...

    – NlightNFotis
    Apr 28 '13 at 14:27






  • 4





    I just DID re-read the FAQ. IMHO this is on topic here. Although it is a meta-question, but the question per se relates to Linux/Unix and is quite clear.

    – Nils
    Apr 29 '13 at 13:14
















125















While I knew for quite some time the existence of Hurd, and its mission as the official GNU Operating System kernel, I was wondering how come Linux is not embraced as the official GNU kernel over the years, seeing as it is in a much better state than the Hurd?



Linux has been, more or less, serving this role 20+ years so far, however one can see that the GNU Project is keeping its distance when it comes to Linux. Why is this happening? Is it because of a dream that Hurd will (at some point in the future) be in a production quality level? Is it because the GNU project doesn't see its mission reflected as much as it wants in Linux? Is it for other political reasons?






linux-kernel gnu hurd







share|improve this question


















  • 20





    Kind of "illegal" question here but interesting. With a bit luck it gets protected for "historical significance", given brilliant enough answers... ;-)

    – Hauke Laging
    Apr 28 '13 at 14:20






  • 2





    @HaukeLaging Thanx mate. I too feel like this is a good question, and may produce interesting answers, and can not really understand why someone would cast a close vote. I am sure this is something that a lot of people would like to know.

    – NlightNFotis
    Apr 28 '13 at 14:21






  • 1





    Oh, that's simple: Someone would just have to point at the FAQ and shout "off-topic" AND "too broad"...

    – Hauke Laging
    Apr 28 '13 at 14:24






  • 5





    @HaukeLaging You are so true, and I wish that people were more pragmatic and could recognise a question with some value instead of just pointing to the FAQ and shouting. One can easily see in S.O the most interesting questions being closed, only to wonder...

    – NlightNFotis
    Apr 28 '13 at 14:27






  • 4





    I just DID re-read the FAQ. IMHO this is on topic here. Although it is a meta-question, but the question per se relates to Linux/Unix and is quite clear.

    – Nils
    Apr 29 '13 at 13:14














125












125








125


32






While I knew for quite some time the existence of Hurd, and its mission as the official GNU Operating System kernel, I was wondering how come Linux is not embraced as the official GNU kernel over the years, seeing as it is in a much better state than the Hurd?



Linux has been, more or less, serving this role 20+ years so far, however one can see that the GNU Project is keeping its distance when it comes to Linux. Why is this happening? Is it because of a dream that Hurd will (at some point in the future) be in a production quality level? Is it because the GNU project doesn't see its mission reflected as much as it wants in Linux? Is it for other political reasons?






linux-kernel gnu hurd







share|improve this question














While I knew for quite some time the existence of Hurd, and its mission as the official GNU Operating System kernel, I was wondering how come Linux is not embraced as the official GNU kernel over the years, seeing as it is in a much better state than the Hurd?



Linux has been, more or less, serving this role 20+ years so far, however one can see that the GNU Project is keeping its distance when it comes to Linux. Why is this happening? Is it because of a dream that Hurd will (at some point in the future) be in a production quality level? Is it because the GNU project doesn't see its mission reflected as much as it wants in Linux? Is it for other political reasons?






linux-kernel gnu hurd




linux-kernel gnu hurd






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Apr 28 '13 at 13:39









NlightNFotisNlightNFotis

4,55252437




4,55252437








  • 20





    Kind of "illegal" question here but interesting. With a bit luck it gets protected for "historical significance", given brilliant enough answers... ;-)

    – Hauke Laging
    Apr 28 '13 at 14:20






  • 2





    @HaukeLaging Thanx mate. I too feel like this is a good question, and may produce interesting answers, and can not really understand why someone would cast a close vote. I am sure this is something that a lot of people would like to know.

    – NlightNFotis
    Apr 28 '13 at 14:21






  • 1





    Oh, that's simple: Someone would just have to point at the FAQ and shout "off-topic" AND "too broad"...

    – Hauke Laging
    Apr 28 '13 at 14:24






  • 5





    @HaukeLaging You are so true, and I wish that people were more pragmatic and could recognise a question with some value instead of just pointing to the FAQ and shouting. One can easily see in S.O the most interesting questions being closed, only to wonder...

    – NlightNFotis
    Apr 28 '13 at 14:27






  • 4





    I just DID re-read the FAQ. IMHO this is on topic here. Although it is a meta-question, but the question per se relates to Linux/Unix and is quite clear.

    – Nils
    Apr 29 '13 at 13:14














  • 20





    Kind of "illegal" question here but interesting. With a bit luck it gets protected for "historical significance", given brilliant enough answers... ;-)

    – Hauke Laging
    Apr 28 '13 at 14:20






  • 2





    @HaukeLaging Thanx mate. I too feel like this is a good question, and may produce interesting answers, and can not really understand why someone would cast a close vote. I am sure this is something that a lot of people would like to know.

    – NlightNFotis
    Apr 28 '13 at 14:21






  • 1





    Oh, that's simple: Someone would just have to point at the FAQ and shout "off-topic" AND "too broad"...

    – Hauke Laging
    Apr 28 '13 at 14:24






  • 5





    @HaukeLaging You are so true, and I wish that people were more pragmatic and could recognise a question with some value instead of just pointing to the FAQ and shouting. One can easily see in S.O the most interesting questions being closed, only to wonder...

    – NlightNFotis
    Apr 28 '13 at 14:27






  • 4





    I just DID re-read the FAQ. IMHO this is on topic here. Although it is a meta-question, but the question per se relates to Linux/Unix and is quite clear.

    – Nils
    Apr 29 '13 at 13:14








20




20





Kind of "illegal" question here but interesting. With a bit luck it gets protected for "historical significance", given brilliant enough answers... ;-)

– Hauke Laging
Apr 28 '13 at 14:20





Kind of "illegal" question here but interesting. With a bit luck it gets protected for "historical significance", given brilliant enough answers... ;-)

– Hauke Laging
Apr 28 '13 at 14:20




2




2





@HaukeLaging Thanx mate. I too feel like this is a good question, and may produce interesting answers, and can not really understand why someone would cast a close vote. I am sure this is something that a lot of people would like to know.

– NlightNFotis
Apr 28 '13 at 14:21





@HaukeLaging Thanx mate. I too feel like this is a good question, and may produce interesting answers, and can not really understand why someone would cast a close vote. I am sure this is something that a lot of people would like to know.

– NlightNFotis
Apr 28 '13 at 14:21




1




1





Oh, that's simple: Someone would just have to point at the FAQ and shout "off-topic" AND "too broad"...

– Hauke Laging
Apr 28 '13 at 14:24





Oh, that's simple: Someone would just have to point at the FAQ and shout "off-topic" AND "too broad"...

– Hauke Laging
Apr 28 '13 at 14:24




5




5





@HaukeLaging You are so true, and I wish that people were more pragmatic and could recognise a question with some value instead of just pointing to the FAQ and shouting. One can easily see in S.O the most interesting questions being closed, only to wonder...

– NlightNFotis
Apr 28 '13 at 14:27





@HaukeLaging You are so true, and I wish that people were more pragmatic and could recognise a question with some value instead of just pointing to the FAQ and shouting. One can easily see in S.O the most interesting questions being closed, only to wonder...

– NlightNFotis
Apr 28 '13 at 14:27




4




4





I just DID re-read the FAQ. IMHO this is on topic here. Although it is a meta-question, but the question per se relates to Linux/Unix and is quite clear.

– Nils
Apr 29 '13 at 13:14





I just DID re-read the FAQ. IMHO this is on topic here. Although it is a meta-question, but the question per se relates to Linux/Unix and is quite clear.

– Nils
Apr 29 '13 at 13:14










6 Answers
6






active

oldest

votes


















148














GNU will not adopt something as a project unless the developers agree to certain stipulations which bind all official GNU projects.



Currently the Linux kernel probably does not fit these restrictions, and there is nothing for Linus Torvalds, kernel.org, et al. to gain from placing themselves under the GNU umbrella, and a lot to lose -- the aforementioned binding agreement, and the public perception that the kernel is now a GNU project, which would have a mostly negative impact. GNU's parent organization, the Free Software Foundation (FSF), is a political organization and Torvalds has made various public criticisms of it and the somewhat controversial, iconoclastic lifetime leader/founder of GNU and the FSF, Richard M. Stallman.



Further, the Linux kernel does not require the GNU userspace any more than the GNU userspace requires the Linux kernel. This independence should be considered a good thing by the basic principles of software engineering, which favour modularity and looser coupling as opposed to the opposite (monolithic things with tight coupling).



Another point against this idea is that while HURD may not be of interest to as many people as Linux, the developers and users of HURD may object to having their project effectively dustbinned in a popularity contest. And good for them; "competition" of this sort is a positive thing, whereas bowing to monopolization is not -- you end up with massive entities that stifle creativity in part because they are prone to monolithic/meglomaniacal control. The Linux Foundation already is an independent organization, it might as well stay that way.






share|improve this answer





















  • 13





    Thanx for the fantastic answer. +1 from me, and 2 notes: 1) Do not misunderstand me: I have a high opinion of the Hurd. I am a hurd developer myself. However (I believe that) it is not arguable that Linux is an a better state. 2) I can see why Linux wouldn't want to be coupled with GNU, but from what I can see it's the GNU Project that demonstrates the greatest objections to this. Could you elaborate on this?

    – NlightNFotis
    Apr 28 '13 at 14:36








  • 14





    @NlightNFotis : Are you sure it is mostly a GNU objection? Just reading this: torvalds-family.blogspot.ca/2008/11/black-and-white.html . To me it seems everyone involved is much happier without a formal relationship.

    – goldilocks
    Apr 28 '13 at 14:40











  • Thanks for this blog post. It makes more sense now. I will keep the question open for some time to see if people elaborate with more fantastic answers, and if not, yours will be selected as the "answer" to this question. Just one more last "petition". Would you mind, rephrasing if I may say, the "you may not have a high opinion of the HURD" because it makes me feel kinda uneasy and makes me feel bad about myself.

    – NlightNFotis
    Apr 28 '13 at 14:46








  • 4





    I really like the ideas behind Hurd. What just came to my mind: The ongoing trend towards virtualization might turn out to be a big help for Hurd to see at least a part of the real world. You don't need a complete OS to make someone use it. If you have a few applications which have clear advantages from running under Hurd then you may simply put them into a Hurd VM. Similar to chrooting, lxc or whatever.

    – Hauke Laging
    Apr 28 '13 at 14:48






  • 2





    @NlightNFotis rephrased :)

    – goldilocks
    Apr 28 '13 at 14:56



















76














There is much documentation and discussion on this on the net.



The short answer that there are deep ideological differences between the GNU project and the Linux kernel projects, which gets in the way of a possible unification.



The focus of the FSF, the organization behind the GNU Project, is on ideological purity with respect to the idea of free software. This largely takes its lead from the views of the FSF/GNU founder, Richard Stallman. Additionally, as goldilocks has mentioned, the FSF is now mostly a political advocacy organization. For a long time now, the FSF has not put significant resources into the GNU Project, though they do provide support infrastructure.



The Linux kernel project has a much more pragmatic stance on software freedom, again to a large extent stemming from its founder, Linus Torvalds. The Linux kernel project is primarily a free software project, consisting of software developers specializing in kernel/OS development, and in no respect a political advocacy organization.



As specific examples of how these ideologies play out in practice, consider



1) That Stallman considers as unacceptable the fact that the Debian project "advertises" non-free software by maintaining the non-free portion of its software archive. This is ironic, since the Debian project has a focus on software freedom that is quite similar to the FSF, while not so ideologically rigid.



2) That the Linux kernel allows (non-free) binary kernel modules to be used with the kernel. While the kernel developers are not enthusiastic about this, they do tolerate it, but it is hard to imagine the FSF doing so.



It is also worth noting that Stallman's attempt to name the operating systems based on the Linux kernel as GNU/Linux has probably not improved relations between the FSF and the Linux kernel community, though I have no specific data about this.



Aside from anything else, as goldilocks mentions, the FSF has various rules that a GNU project must conform to. This includes copyright assignment of all code to the FSF. This would all by itself be a deal breaker, since Linus Torvalds has never required such copyright assignment. Therefore, if the Linux kernel were to become part of the GNU project, all significant contributions to the Linux kernel would have to have their copyright assigned to the FSF. Given the age and size of the project, and the number of contributors, this is basically impossible. Far smaller and younger projects (e.g. Mercurial) have found software relicensing a daunting task.



Please note that this answer is in no way intended as criticism of either the FSF or the Linux kernel developers. Both sides have their own valid viewpoints. However, the reality of the situation is that they are to some extent incompatible viewpoints.






share|improve this answer





















  • 4





    +1 I like this answer. Solid information on the issue. I appreciate your input.

    – NlightNFotis
    Apr 28 '13 at 16:47






  • 1





    It's worth noting that in many countries in Europe the 'copyright assignment' is not legally possible. There are other possibilities (contributors agreement) but copyright assignment might be not legally possible - not only technically.

    – Maciej Piechotka
    Apr 28 '13 at 17:24






  • 1





    @FaheemMitha, not by the GNU definition because the binary blobs most certainly are part of the kernel; they are distributed in the kernel source code, and built into the kernel binaries and required for them to function.

    – psusi
    Apr 28 '13 at 18:43






  • 8





    Ahh, the proprietary drivers are another thing that GNU objects to. This was one of the reasons for GPLv3; to bar proprietary modules from being linked to free code, even at runtime, and why Linux chose to stay with GPLv2.

    – psusi
    Apr 28 '13 at 19:59






  • 1





    @vonbrand, whether you agree with it or not is irrelevant; it is the position of the FSF and because of that, Linux could never be a GNU project.

    – psusi
    Apr 29 '13 at 13:36



















32














I am quoting a comment by Richard Stallman, regarding the decision to roll with the Hurd rather than Linux.




People sometimes ask, ``Why did the FSF develop a new free kernel
instead of using Linux?'' It's a reasonable question. The answer,
briefly, is that that is not the question we faced.



When we started developing the Hurd in 1990, the question facing us
was, ``How can we get a free kernel for the GNU system?'' There was no
free Unix-like kernel then, and we knew of no other plan to write one.
The only way we could expect to have a free kernel was to write it
ourselves. So we started.



We heard about Linux after its release. At that time, the question
facing us was, ``Should we cancel the Hurd project and use Linux
instead?''



We heard that Linux was not at all portable (this may not be true
today, but that's what we heard then). And we heard that Linux was
architecturally on a par with the Unix kernel; our work was leading to
something much more powerful.



Given the years of work we had already put into the Hurd, we decided
to finish it rather than throw them away.



If we did face the question that people ask---if Linux were already
available, and we were considering whether to start writing another
kernel---we would not do it. Instead we would choose another project,
something to do a job that no existing free software can do.



But we did start the Hurd, back then, and now we have made it work. We
hope its superior architecture will make free operating systems more
powerful.







share|improve this answer



















  • 5





    Despite the fantastic answers provided to the question already, I will select this answer as the canonical one to the question because it demonstrates the rationale behind choice of sticking with the Hurd, straight from the creator of the GNU Project, Richard Stallman.

    – NlightNFotis
    Apr 30 '13 at 23:18






  • 9





    Note "this may not be true today" - RMS' opinion of Linux seems to be based on hearsay, not knowledge.

    – Martin Schröder
    May 1 '13 at 13:27






  • 16





    @Martin: (Late Reply, but:) When Torvalds first announced Linux, it was x86 specific, with zero plans to make it portable. In the intial thread Linus flat out said "I'd say that porting is impossible". Thus, rms had no reason to originally believe that Linux would grow into what it has today. Evidence from the mouth of the project leader is hardly hearsay.

    – Kevin Cathcart
    Aug 16 '13 at 21:33











  • @KevinCathcart: RMS/FSF should have studied the code themself instead of relying on others ("we heard").

    – Martin Schröder
    Aug 17 '13 at 7:22






  • 19





    @MartinSchröder: Why study the code when the Project Leader explicitly said it would not be portable? Anyway, Linux was announced in 1991. It took until April of 1994 (release 1.1.45) before Linux even added the folders for architecture ports. It would take longer before any ports were practical. If the FSF made their decision to continue the Hurd in 1992 or 1993, looking at the code would only have reinforced that the code was non-portable.

    – Kevin Cathcart
    Aug 19 '13 at 16:53



















4














I'm just adding my 2 cent here, I think that what it's been discussed at this point makes a lot of sense but there is one major aspect that I think can really polarize the GNU foundation and it's the fact that Linux is becoming more and more a place where large corporates are investing real money and time, the idea that linux is kind of an home-made project it's not true, not even a bit, maybe there is some random guy trying to get attention on the scene while giving a patch away, but for the large part linux it's a job for corporations.






share|improve this answer



















  • 1





    I don't think the FSF has a problem with corporate support of software projects. Their main focus is on the principles of free software.

    – Faheem Mitha
    Jun 14 '13 at 9:22













  • Corporate dominance was a big concern the GNU GPL was intended to address. Permissively licensed software was actually normal procedure at both MIT and Berkeley, but once code was commercialized it was promptly closed. So for example, I could checkout the Linux source today and all the commercially developed improvements will benefit my potential project. Or my next small personal project may use just a couple blocks, the point is that any released improvements benefit whoever works with the code next.

    – J. M. Becker
    Jan 25 '14 at 1:24





















1














Another explanation found on the FAQ of gnu.org:




Making the GNU Hurd work well enough to compete with Linux would be a
big job, and it's not clearly necessary. The only thing ethically
wrong with Linux as a kernel is its inclusion of firmware “blobs”; the
best fix for that problem is developing free replacement for the
blobs.







share|improve this answer































    -6














    Linux can not be Unix, since Linux is not conforming to Posix.



    So even without political hassle Linux can not meet the design goal for Hurd.



    Cite:
    "The Hurd is the GNU project's replacement for UNIX, a popular operating system kernel."



    Astonishing, that there is a Debian/Hurd-Projekt. But that is possibly a different story...



    BTW: Windows (since NT/XP) is based on the MACH-kernel, too.






    share|improve this answer





















    • 8





      If you are going to claim that Linux is not POSIX conformant, you're going to have to back that up a bit. Including where the FSF says they require an absolutely 100% POSIX compliant kernel. By the way, Unix is not POSIX. Unix (trademarked) is a specific proprietary OS, so it goes without saying that no other OS can be that OS.

      – psusi
      Apr 29 '13 at 13:40






    • 6





      Citation for the Windows kernel being based on MACH? Wikipedia says they share some design choices; but with MACH being the prototypical microkernel while the majority of Windows OS services run in the kernel not userland. The only major OSS component in the Windows kernel that I'm aware of was the network stack which used to be based on the BSD implementation; however it was ripped out and replaced with one that better interfaced with the rest of the os design several versions ago (IIRC in XP or 2k).

      – Dan Neely
      Apr 29 '13 at 13:59






    • 14





      But GNU's Not Unix, either.

      – Simon
      Apr 29 '13 at 16:02






    • 6





      @Nils, the question you linked contradicts your position, rather than supports it.

      – psusi
      Apr 29 '13 at 16:08






    • 8





      @Nils, the Mach nonsense is another bit of popular misconception. NT has nothing in common with mach. Its "subsystem servers" are no different than unix daemons, which do not make a microkernel. Originally the gui was implemented in user mode, and this had only a passing resemblance to a microkernel system ( though so is Xwindows, that does not make Linux a microkernel ), but this was scrapped in NT4 and moved to the kernel.

      – psusi
      Apr 29 '13 at 16:20











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f73950%2fwhy-isnt-linux-embraced-as-the-official-gnu-kernel%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    6 Answers
    6






    active

    oldest

    votes








    6 Answers
    6






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    148














    GNU will not adopt something as a project unless the developers agree to certain stipulations which bind all official GNU projects.



    Currently the Linux kernel probably does not fit these restrictions, and there is nothing for Linus Torvalds, kernel.org, et al. to gain from placing themselves under the GNU umbrella, and a lot to lose -- the aforementioned binding agreement, and the public perception that the kernel is now a GNU project, which would have a mostly negative impact. GNU's parent organization, the Free Software Foundation (FSF), is a political organization and Torvalds has made various public criticisms of it and the somewhat controversial, iconoclastic lifetime leader/founder of GNU and the FSF, Richard M. Stallman.



    Further, the Linux kernel does not require the GNU userspace any more than the GNU userspace requires the Linux kernel. This independence should be considered a good thing by the basic principles of software engineering, which favour modularity and looser coupling as opposed to the opposite (monolithic things with tight coupling).



    Another point against this idea is that while HURD may not be of interest to as many people as Linux, the developers and users of HURD may object to having their project effectively dustbinned in a popularity contest. And good for them; "competition" of this sort is a positive thing, whereas bowing to monopolization is not -- you end up with massive entities that stifle creativity in part because they are prone to monolithic/meglomaniacal control. The Linux Foundation already is an independent organization, it might as well stay that way.






    share|improve this answer





















    • 13





      Thanx for the fantastic answer. +1 from me, and 2 notes: 1) Do not misunderstand me: I have a high opinion of the Hurd. I am a hurd developer myself. However (I believe that) it is not arguable that Linux is an a better state. 2) I can see why Linux wouldn't want to be coupled with GNU, but from what I can see it's the GNU Project that demonstrates the greatest objections to this. Could you elaborate on this?

      – NlightNFotis
      Apr 28 '13 at 14:36








    • 14





      @NlightNFotis : Are you sure it is mostly a GNU objection? Just reading this: torvalds-family.blogspot.ca/2008/11/black-and-white.html . To me it seems everyone involved is much happier without a formal relationship.

      – goldilocks
      Apr 28 '13 at 14:40











    • Thanks for this blog post. It makes more sense now. I will keep the question open for some time to see if people elaborate with more fantastic answers, and if not, yours will be selected as the "answer" to this question. Just one more last "petition". Would you mind, rephrasing if I may say, the "you may not have a high opinion of the HURD" because it makes me feel kinda uneasy and makes me feel bad about myself.

      – NlightNFotis
      Apr 28 '13 at 14:46








    • 4





      I really like the ideas behind Hurd. What just came to my mind: The ongoing trend towards virtualization might turn out to be a big help for Hurd to see at least a part of the real world. You don't need a complete OS to make someone use it. If you have a few applications which have clear advantages from running under Hurd then you may simply put them into a Hurd VM. Similar to chrooting, lxc or whatever.

      – Hauke Laging
      Apr 28 '13 at 14:48






    • 2





      @NlightNFotis rephrased :)

      – goldilocks
      Apr 28 '13 at 14:56
















    148














    GNU will not adopt something as a project unless the developers agree to certain stipulations which bind all official GNU projects.



    Currently the Linux kernel probably does not fit these restrictions, and there is nothing for Linus Torvalds, kernel.org, et al. to gain from placing themselves under the GNU umbrella, and a lot to lose -- the aforementioned binding agreement, and the public perception that the kernel is now a GNU project, which would have a mostly negative impact. GNU's parent organization, the Free Software Foundation (FSF), is a political organization and Torvalds has made various public criticisms of it and the somewhat controversial, iconoclastic lifetime leader/founder of GNU and the FSF, Richard M. Stallman.



    Further, the Linux kernel does not require the GNU userspace any more than the GNU userspace requires the Linux kernel. This independence should be considered a good thing by the basic principles of software engineering, which favour modularity and looser coupling as opposed to the opposite (monolithic things with tight coupling).



    Another point against this idea is that while HURD may not be of interest to as many people as Linux, the developers and users of HURD may object to having their project effectively dustbinned in a popularity contest. And good for them; "competition" of this sort is a positive thing, whereas bowing to monopolization is not -- you end up with massive entities that stifle creativity in part because they are prone to monolithic/meglomaniacal control. The Linux Foundation already is an independent organization, it might as well stay that way.






    share|improve this answer





















    • 13





      Thanx for the fantastic answer. +1 from me, and 2 notes: 1) Do not misunderstand me: I have a high opinion of the Hurd. I am a hurd developer myself. However (I believe that) it is not arguable that Linux is an a better state. 2) I can see why Linux wouldn't want to be coupled with GNU, but from what I can see it's the GNU Project that demonstrates the greatest objections to this. Could you elaborate on this?

      – NlightNFotis
      Apr 28 '13 at 14:36








    • 14





      @NlightNFotis : Are you sure it is mostly a GNU objection? Just reading this: torvalds-family.blogspot.ca/2008/11/black-and-white.html . To me it seems everyone involved is much happier without a formal relationship.

      – goldilocks
      Apr 28 '13 at 14:40











    • Thanks for this blog post. It makes more sense now. I will keep the question open for some time to see if people elaborate with more fantastic answers, and if not, yours will be selected as the "answer" to this question. Just one more last "petition". Would you mind, rephrasing if I may say, the "you may not have a high opinion of the HURD" because it makes me feel kinda uneasy and makes me feel bad about myself.

      – NlightNFotis
      Apr 28 '13 at 14:46








    • 4





      I really like the ideas behind Hurd. What just came to my mind: The ongoing trend towards virtualization might turn out to be a big help for Hurd to see at least a part of the real world. You don't need a complete OS to make someone use it. If you have a few applications which have clear advantages from running under Hurd then you may simply put them into a Hurd VM. Similar to chrooting, lxc or whatever.

      – Hauke Laging
      Apr 28 '13 at 14:48






    • 2





      @NlightNFotis rephrased :)

      – goldilocks
      Apr 28 '13 at 14:56














    148












    148








    148







    GNU will not adopt something as a project unless the developers agree to certain stipulations which bind all official GNU projects.



    Currently the Linux kernel probably does not fit these restrictions, and there is nothing for Linus Torvalds, kernel.org, et al. to gain from placing themselves under the GNU umbrella, and a lot to lose -- the aforementioned binding agreement, and the public perception that the kernel is now a GNU project, which would have a mostly negative impact. GNU's parent organization, the Free Software Foundation (FSF), is a political organization and Torvalds has made various public criticisms of it and the somewhat controversial, iconoclastic lifetime leader/founder of GNU and the FSF, Richard M. Stallman.



    Further, the Linux kernel does not require the GNU userspace any more than the GNU userspace requires the Linux kernel. This independence should be considered a good thing by the basic principles of software engineering, which favour modularity and looser coupling as opposed to the opposite (monolithic things with tight coupling).



    Another point against this idea is that while HURD may not be of interest to as many people as Linux, the developers and users of HURD may object to having their project effectively dustbinned in a popularity contest. And good for them; "competition" of this sort is a positive thing, whereas bowing to monopolization is not -- you end up with massive entities that stifle creativity in part because they are prone to monolithic/meglomaniacal control. The Linux Foundation already is an independent organization, it might as well stay that way.






    share|improve this answer















    GNU will not adopt something as a project unless the developers agree to certain stipulations which bind all official GNU projects.



    Currently the Linux kernel probably does not fit these restrictions, and there is nothing for Linus Torvalds, kernel.org, et al. to gain from placing themselves under the GNU umbrella, and a lot to lose -- the aforementioned binding agreement, and the public perception that the kernel is now a GNU project, which would have a mostly negative impact. GNU's parent organization, the Free Software Foundation (FSF), is a political organization and Torvalds has made various public criticisms of it and the somewhat controversial, iconoclastic lifetime leader/founder of GNU and the FSF, Richard M. Stallman.



    Further, the Linux kernel does not require the GNU userspace any more than the GNU userspace requires the Linux kernel. This independence should be considered a good thing by the basic principles of software engineering, which favour modularity and looser coupling as opposed to the opposite (monolithic things with tight coupling).



    Another point against this idea is that while HURD may not be of interest to as many people as Linux, the developers and users of HURD may object to having their project effectively dustbinned in a popularity contest. And good for them; "competition" of this sort is a positive thing, whereas bowing to monopolization is not -- you end up with massive entities that stifle creativity in part because they are prone to monolithic/meglomaniacal control. The Linux Foundation already is an independent organization, it might as well stay that way.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 26 at 16:33

























    answered Apr 28 '13 at 14:32









    goldilocksgoldilocks

    62k14151210




    62k14151210








    • 13





      Thanx for the fantastic answer. +1 from me, and 2 notes: 1) Do not misunderstand me: I have a high opinion of the Hurd. I am a hurd developer myself. However (I believe that) it is not arguable that Linux is an a better state. 2) I can see why Linux wouldn't want to be coupled with GNU, but from what I can see it's the GNU Project that demonstrates the greatest objections to this. Could you elaborate on this?

      – NlightNFotis
      Apr 28 '13 at 14:36








    • 14





      @NlightNFotis : Are you sure it is mostly a GNU objection? Just reading this: torvalds-family.blogspot.ca/2008/11/black-and-white.html . To me it seems everyone involved is much happier without a formal relationship.

      – goldilocks
      Apr 28 '13 at 14:40











    • Thanks for this blog post. It makes more sense now. I will keep the question open for some time to see if people elaborate with more fantastic answers, and if not, yours will be selected as the "answer" to this question. Just one more last "petition". Would you mind, rephrasing if I may say, the "you may not have a high opinion of the HURD" because it makes me feel kinda uneasy and makes me feel bad about myself.

      – NlightNFotis
      Apr 28 '13 at 14:46








    • 4





      I really like the ideas behind Hurd. What just came to my mind: The ongoing trend towards virtualization might turn out to be a big help for Hurd to see at least a part of the real world. You don't need a complete OS to make someone use it. If you have a few applications which have clear advantages from running under Hurd then you may simply put them into a Hurd VM. Similar to chrooting, lxc or whatever.

      – Hauke Laging
      Apr 28 '13 at 14:48






    • 2





      @NlightNFotis rephrased :)

      – goldilocks
      Apr 28 '13 at 14:56














    • 13





      Thanx for the fantastic answer. +1 from me, and 2 notes: 1) Do not misunderstand me: I have a high opinion of the Hurd. I am a hurd developer myself. However (I believe that) it is not arguable that Linux is an a better state. 2) I can see why Linux wouldn't want to be coupled with GNU, but from what I can see it's the GNU Project that demonstrates the greatest objections to this. Could you elaborate on this?

      – NlightNFotis
      Apr 28 '13 at 14:36








    • 14





      @NlightNFotis : Are you sure it is mostly a GNU objection? Just reading this: torvalds-family.blogspot.ca/2008/11/black-and-white.html . To me it seems everyone involved is much happier without a formal relationship.

      – goldilocks
      Apr 28 '13 at 14:40











    • Thanks for this blog post. It makes more sense now. I will keep the question open for some time to see if people elaborate with more fantastic answers, and if not, yours will be selected as the "answer" to this question. Just one more last "petition". Would you mind, rephrasing if I may say, the "you may not have a high opinion of the HURD" because it makes me feel kinda uneasy and makes me feel bad about myself.

      – NlightNFotis
      Apr 28 '13 at 14:46








    • 4





      I really like the ideas behind Hurd. What just came to my mind: The ongoing trend towards virtualization might turn out to be a big help for Hurd to see at least a part of the real world. You don't need a complete OS to make someone use it. If you have a few applications which have clear advantages from running under Hurd then you may simply put them into a Hurd VM. Similar to chrooting, lxc or whatever.

      – Hauke Laging
      Apr 28 '13 at 14:48






    • 2





      @NlightNFotis rephrased :)

      – goldilocks
      Apr 28 '13 at 14:56








    13




    13





    Thanx for the fantastic answer. +1 from me, and 2 notes: 1) Do not misunderstand me: I have a high opinion of the Hurd. I am a hurd developer myself. However (I believe that) it is not arguable that Linux is an a better state. 2) I can see why Linux wouldn't want to be coupled with GNU, but from what I can see it's the GNU Project that demonstrates the greatest objections to this. Could you elaborate on this?

    – NlightNFotis
    Apr 28 '13 at 14:36







    Thanx for the fantastic answer. +1 from me, and 2 notes: 1) Do not misunderstand me: I have a high opinion of the Hurd. I am a hurd developer myself. However (I believe that) it is not arguable that Linux is an a better state. 2) I can see why Linux wouldn't want to be coupled with GNU, but from what I can see it's the GNU Project that demonstrates the greatest objections to this. Could you elaborate on this?

    – NlightNFotis
    Apr 28 '13 at 14:36






    14




    14





    @NlightNFotis : Are you sure it is mostly a GNU objection? Just reading this: torvalds-family.blogspot.ca/2008/11/black-and-white.html . To me it seems everyone involved is much happier without a formal relationship.

    – goldilocks
    Apr 28 '13 at 14:40





    @NlightNFotis : Are you sure it is mostly a GNU objection? Just reading this: torvalds-family.blogspot.ca/2008/11/black-and-white.html . To me it seems everyone involved is much happier without a formal relationship.

    – goldilocks
    Apr 28 '13 at 14:40













    Thanks for this blog post. It makes more sense now. I will keep the question open for some time to see if people elaborate with more fantastic answers, and if not, yours will be selected as the "answer" to this question. Just one more last "petition". Would you mind, rephrasing if I may say, the "you may not have a high opinion of the HURD" because it makes me feel kinda uneasy and makes me feel bad about myself.

    – NlightNFotis
    Apr 28 '13 at 14:46







    Thanks for this blog post. It makes more sense now. I will keep the question open for some time to see if people elaborate with more fantastic answers, and if not, yours will be selected as the "answer" to this question. Just one more last "petition". Would you mind, rephrasing if I may say, the "you may not have a high opinion of the HURD" because it makes me feel kinda uneasy and makes me feel bad about myself.

    – NlightNFotis
    Apr 28 '13 at 14:46






    4




    4





    I really like the ideas behind Hurd. What just came to my mind: The ongoing trend towards virtualization might turn out to be a big help for Hurd to see at least a part of the real world. You don't need a complete OS to make someone use it. If you have a few applications which have clear advantages from running under Hurd then you may simply put them into a Hurd VM. Similar to chrooting, lxc or whatever.

    – Hauke Laging
    Apr 28 '13 at 14:48





    I really like the ideas behind Hurd. What just came to my mind: The ongoing trend towards virtualization might turn out to be a big help for Hurd to see at least a part of the real world. You don't need a complete OS to make someone use it. If you have a few applications which have clear advantages from running under Hurd then you may simply put them into a Hurd VM. Similar to chrooting, lxc or whatever.

    – Hauke Laging
    Apr 28 '13 at 14:48




    2




    2





    @NlightNFotis rephrased :)

    – goldilocks
    Apr 28 '13 at 14:56





    @NlightNFotis rephrased :)

    – goldilocks
    Apr 28 '13 at 14:56













    76














    There is much documentation and discussion on this on the net.



    The short answer that there are deep ideological differences between the GNU project and the Linux kernel projects, which gets in the way of a possible unification.



    The focus of the FSF, the organization behind the GNU Project, is on ideological purity with respect to the idea of free software. This largely takes its lead from the views of the FSF/GNU founder, Richard Stallman. Additionally, as goldilocks has mentioned, the FSF is now mostly a political advocacy organization. For a long time now, the FSF has not put significant resources into the GNU Project, though they do provide support infrastructure.



    The Linux kernel project has a much more pragmatic stance on software freedom, again to a large extent stemming from its founder, Linus Torvalds. The Linux kernel project is primarily a free software project, consisting of software developers specializing in kernel/OS development, and in no respect a political advocacy organization.



    As specific examples of how these ideologies play out in practice, consider



    1) That Stallman considers as unacceptable the fact that the Debian project "advertises" non-free software by maintaining the non-free portion of its software archive. This is ironic, since the Debian project has a focus on software freedom that is quite similar to the FSF, while not so ideologically rigid.



    2) That the Linux kernel allows (non-free) binary kernel modules to be used with the kernel. While the kernel developers are not enthusiastic about this, they do tolerate it, but it is hard to imagine the FSF doing so.



    It is also worth noting that Stallman's attempt to name the operating systems based on the Linux kernel as GNU/Linux has probably not improved relations between the FSF and the Linux kernel community, though I have no specific data about this.



    Aside from anything else, as goldilocks mentions, the FSF has various rules that a GNU project must conform to. This includes copyright assignment of all code to the FSF. This would all by itself be a deal breaker, since Linus Torvalds has never required such copyright assignment. Therefore, if the Linux kernel were to become part of the GNU project, all significant contributions to the Linux kernel would have to have their copyright assigned to the FSF. Given the age and size of the project, and the number of contributors, this is basically impossible. Far smaller and younger projects (e.g. Mercurial) have found software relicensing a daunting task.



    Please note that this answer is in no way intended as criticism of either the FSF or the Linux kernel developers. Both sides have their own valid viewpoints. However, the reality of the situation is that they are to some extent incompatible viewpoints.






    share|improve this answer





















    • 4





      +1 I like this answer. Solid information on the issue. I appreciate your input.

      – NlightNFotis
      Apr 28 '13 at 16:47






    • 1





      It's worth noting that in many countries in Europe the 'copyright assignment' is not legally possible. There are other possibilities (contributors agreement) but copyright assignment might be not legally possible - not only technically.

      – Maciej Piechotka
      Apr 28 '13 at 17:24






    • 1





      @FaheemMitha, not by the GNU definition because the binary blobs most certainly are part of the kernel; they are distributed in the kernel source code, and built into the kernel binaries and required for them to function.

      – psusi
      Apr 28 '13 at 18:43






    • 8





      Ahh, the proprietary drivers are another thing that GNU objects to. This was one of the reasons for GPLv3; to bar proprietary modules from being linked to free code, even at runtime, and why Linux chose to stay with GPLv2.

      – psusi
      Apr 28 '13 at 19:59






    • 1





      @vonbrand, whether you agree with it or not is irrelevant; it is the position of the FSF and because of that, Linux could never be a GNU project.

      – psusi
      Apr 29 '13 at 13:36
















    76














    There is much documentation and discussion on this on the net.



    The short answer that there are deep ideological differences between the GNU project and the Linux kernel projects, which gets in the way of a possible unification.



    The focus of the FSF, the organization behind the GNU Project, is on ideological purity with respect to the idea of free software. This largely takes its lead from the views of the FSF/GNU founder, Richard Stallman. Additionally, as goldilocks has mentioned, the FSF is now mostly a political advocacy organization. For a long time now, the FSF has not put significant resources into the GNU Project, though they do provide support infrastructure.



    The Linux kernel project has a much more pragmatic stance on software freedom, again to a large extent stemming from its founder, Linus Torvalds. The Linux kernel project is primarily a free software project, consisting of software developers specializing in kernel/OS development, and in no respect a political advocacy organization.



    As specific examples of how these ideologies play out in practice, consider



    1) That Stallman considers as unacceptable the fact that the Debian project "advertises" non-free software by maintaining the non-free portion of its software archive. This is ironic, since the Debian project has a focus on software freedom that is quite similar to the FSF, while not so ideologically rigid.



    2) That the Linux kernel allows (non-free) binary kernel modules to be used with the kernel. While the kernel developers are not enthusiastic about this, they do tolerate it, but it is hard to imagine the FSF doing so.



    It is also worth noting that Stallman's attempt to name the operating systems based on the Linux kernel as GNU/Linux has probably not improved relations between the FSF and the Linux kernel community, though I have no specific data about this.



    Aside from anything else, as goldilocks mentions, the FSF has various rules that a GNU project must conform to. This includes copyright assignment of all code to the FSF. This would all by itself be a deal breaker, since Linus Torvalds has never required such copyright assignment. Therefore, if the Linux kernel were to become part of the GNU project, all significant contributions to the Linux kernel would have to have their copyright assigned to the FSF. Given the age and size of the project, and the number of contributors, this is basically impossible. Far smaller and younger projects (e.g. Mercurial) have found software relicensing a daunting task.



    Please note that this answer is in no way intended as criticism of either the FSF or the Linux kernel developers. Both sides have their own valid viewpoints. However, the reality of the situation is that they are to some extent incompatible viewpoints.






    share|improve this answer





















    • 4





      +1 I like this answer. Solid information on the issue. I appreciate your input.

      – NlightNFotis
      Apr 28 '13 at 16:47






    • 1





      It's worth noting that in many countries in Europe the 'copyright assignment' is not legally possible. There are other possibilities (contributors agreement) but copyright assignment might be not legally possible - not only technically.

      – Maciej Piechotka
      Apr 28 '13 at 17:24






    • 1





      @FaheemMitha, not by the GNU definition because the binary blobs most certainly are part of the kernel; they are distributed in the kernel source code, and built into the kernel binaries and required for them to function.

      – psusi
      Apr 28 '13 at 18:43






    • 8





      Ahh, the proprietary drivers are another thing that GNU objects to. This was one of the reasons for GPLv3; to bar proprietary modules from being linked to free code, even at runtime, and why Linux chose to stay with GPLv2.

      – psusi
      Apr 28 '13 at 19:59






    • 1





      @vonbrand, whether you agree with it or not is irrelevant; it is the position of the FSF and because of that, Linux could never be a GNU project.

      – psusi
      Apr 29 '13 at 13:36














    76












    76








    76







    There is much documentation and discussion on this on the net.



    The short answer that there are deep ideological differences between the GNU project and the Linux kernel projects, which gets in the way of a possible unification.



    The focus of the FSF, the organization behind the GNU Project, is on ideological purity with respect to the idea of free software. This largely takes its lead from the views of the FSF/GNU founder, Richard Stallman. Additionally, as goldilocks has mentioned, the FSF is now mostly a political advocacy organization. For a long time now, the FSF has not put significant resources into the GNU Project, though they do provide support infrastructure.



    The Linux kernel project has a much more pragmatic stance on software freedom, again to a large extent stemming from its founder, Linus Torvalds. The Linux kernel project is primarily a free software project, consisting of software developers specializing in kernel/OS development, and in no respect a political advocacy organization.



    As specific examples of how these ideologies play out in practice, consider



    1) That Stallman considers as unacceptable the fact that the Debian project "advertises" non-free software by maintaining the non-free portion of its software archive. This is ironic, since the Debian project has a focus on software freedom that is quite similar to the FSF, while not so ideologically rigid.



    2) That the Linux kernel allows (non-free) binary kernel modules to be used with the kernel. While the kernel developers are not enthusiastic about this, they do tolerate it, but it is hard to imagine the FSF doing so.



    It is also worth noting that Stallman's attempt to name the operating systems based on the Linux kernel as GNU/Linux has probably not improved relations between the FSF and the Linux kernel community, though I have no specific data about this.



    Aside from anything else, as goldilocks mentions, the FSF has various rules that a GNU project must conform to. This includes copyright assignment of all code to the FSF. This would all by itself be a deal breaker, since Linus Torvalds has never required such copyright assignment. Therefore, if the Linux kernel were to become part of the GNU project, all significant contributions to the Linux kernel would have to have their copyright assigned to the FSF. Given the age and size of the project, and the number of contributors, this is basically impossible. Far smaller and younger projects (e.g. Mercurial) have found software relicensing a daunting task.



    Please note that this answer is in no way intended as criticism of either the FSF or the Linux kernel developers. Both sides have their own valid viewpoints. However, the reality of the situation is that they are to some extent incompatible viewpoints.






    share|improve this answer















    There is much documentation and discussion on this on the net.



    The short answer that there are deep ideological differences between the GNU project and the Linux kernel projects, which gets in the way of a possible unification.



    The focus of the FSF, the organization behind the GNU Project, is on ideological purity with respect to the idea of free software. This largely takes its lead from the views of the FSF/GNU founder, Richard Stallman. Additionally, as goldilocks has mentioned, the FSF is now mostly a political advocacy organization. For a long time now, the FSF has not put significant resources into the GNU Project, though they do provide support infrastructure.



    The Linux kernel project has a much more pragmatic stance on software freedom, again to a large extent stemming from its founder, Linus Torvalds. The Linux kernel project is primarily a free software project, consisting of software developers specializing in kernel/OS development, and in no respect a political advocacy organization.



    As specific examples of how these ideologies play out in practice, consider



    1) That Stallman considers as unacceptable the fact that the Debian project "advertises" non-free software by maintaining the non-free portion of its software archive. This is ironic, since the Debian project has a focus on software freedom that is quite similar to the FSF, while not so ideologically rigid.



    2) That the Linux kernel allows (non-free) binary kernel modules to be used with the kernel. While the kernel developers are not enthusiastic about this, they do tolerate it, but it is hard to imagine the FSF doing so.



    It is also worth noting that Stallman's attempt to name the operating systems based on the Linux kernel as GNU/Linux has probably not improved relations between the FSF and the Linux kernel community, though I have no specific data about this.



    Aside from anything else, as goldilocks mentions, the FSF has various rules that a GNU project must conform to. This includes copyright assignment of all code to the FSF. This would all by itself be a deal breaker, since Linus Torvalds has never required such copyright assignment. Therefore, if the Linux kernel were to become part of the GNU project, all significant contributions to the Linux kernel would have to have their copyright assigned to the FSF. Given the age and size of the project, and the number of contributors, this is basically impossible. Far smaller and younger projects (e.g. Mercurial) have found software relicensing a daunting task.



    Please note that this answer is in no way intended as criticism of either the FSF or the Linux kernel developers. Both sides have their own valid viewpoints. However, the reality of the situation is that they are to some extent incompatible viewpoints.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jun 28 '15 at 5:37

























    answered Apr 28 '13 at 16:45









    Faheem MithaFaheem Mitha

    23k1880135




    23k1880135








    • 4





      +1 I like this answer. Solid information on the issue. I appreciate your input.

      – NlightNFotis
      Apr 28 '13 at 16:47






    • 1





      It's worth noting that in many countries in Europe the 'copyright assignment' is not legally possible. There are other possibilities (contributors agreement) but copyright assignment might be not legally possible - not only technically.

      – Maciej Piechotka
      Apr 28 '13 at 17:24






    • 1





      @FaheemMitha, not by the GNU definition because the binary blobs most certainly are part of the kernel; they are distributed in the kernel source code, and built into the kernel binaries and required for them to function.

      – psusi
      Apr 28 '13 at 18:43






    • 8





      Ahh, the proprietary drivers are another thing that GNU objects to. This was one of the reasons for GPLv3; to bar proprietary modules from being linked to free code, even at runtime, and why Linux chose to stay with GPLv2.

      – psusi
      Apr 28 '13 at 19:59






    • 1





      @vonbrand, whether you agree with it or not is irrelevant; it is the position of the FSF and because of that, Linux could never be a GNU project.

      – psusi
      Apr 29 '13 at 13:36














    • 4





      +1 I like this answer. Solid information on the issue. I appreciate your input.

      – NlightNFotis
      Apr 28 '13 at 16:47






    • 1





      It's worth noting that in many countries in Europe the 'copyright assignment' is not legally possible. There are other possibilities (contributors agreement) but copyright assignment might be not legally possible - not only technically.

      – Maciej Piechotka
      Apr 28 '13 at 17:24






    • 1





      @FaheemMitha, not by the GNU definition because the binary blobs most certainly are part of the kernel; they are distributed in the kernel source code, and built into the kernel binaries and required for them to function.

      – psusi
      Apr 28 '13 at 18:43






    • 8





      Ahh, the proprietary drivers are another thing that GNU objects to. This was one of the reasons for GPLv3; to bar proprietary modules from being linked to free code, even at runtime, and why Linux chose to stay with GPLv2.

      – psusi
      Apr 28 '13 at 19:59






    • 1





      @vonbrand, whether you agree with it or not is irrelevant; it is the position of the FSF and because of that, Linux could never be a GNU project.

      – psusi
      Apr 29 '13 at 13:36








    4




    4





    +1 I like this answer. Solid information on the issue. I appreciate your input.

    – NlightNFotis
    Apr 28 '13 at 16:47





    +1 I like this answer. Solid information on the issue. I appreciate your input.

    – NlightNFotis
    Apr 28 '13 at 16:47




    1




    1





    It's worth noting that in many countries in Europe the 'copyright assignment' is not legally possible. There are other possibilities (contributors agreement) but copyright assignment might be not legally possible - not only technically.

    – Maciej Piechotka
    Apr 28 '13 at 17:24





    It's worth noting that in many countries in Europe the 'copyright assignment' is not legally possible. There are other possibilities (contributors agreement) but copyright assignment might be not legally possible - not only technically.

    – Maciej Piechotka
    Apr 28 '13 at 17:24




    1




    1





    @FaheemMitha, not by the GNU definition because the binary blobs most certainly are part of the kernel; they are distributed in the kernel source code, and built into the kernel binaries and required for them to function.

    – psusi
    Apr 28 '13 at 18:43





    @FaheemMitha, not by the GNU definition because the binary blobs most certainly are part of the kernel; they are distributed in the kernel source code, and built into the kernel binaries and required for them to function.

    – psusi
    Apr 28 '13 at 18:43




    8




    8





    Ahh, the proprietary drivers are another thing that GNU objects to. This was one of the reasons for GPLv3; to bar proprietary modules from being linked to free code, even at runtime, and why Linux chose to stay with GPLv2.

    – psusi
    Apr 28 '13 at 19:59





    Ahh, the proprietary drivers are another thing that GNU objects to. This was one of the reasons for GPLv3; to bar proprietary modules from being linked to free code, even at runtime, and why Linux chose to stay with GPLv2.

    – psusi
    Apr 28 '13 at 19:59




    1




    1





    @vonbrand, whether you agree with it or not is irrelevant; it is the position of the FSF and because of that, Linux could never be a GNU project.

    – psusi
    Apr 29 '13 at 13:36





    @vonbrand, whether you agree with it or not is irrelevant; it is the position of the FSF and because of that, Linux could never be a GNU project.

    – psusi
    Apr 29 '13 at 13:36











    32














    I am quoting a comment by Richard Stallman, regarding the decision to roll with the Hurd rather than Linux.




    People sometimes ask, ``Why did the FSF develop a new free kernel
    instead of using Linux?'' It's a reasonable question. The answer,
    briefly, is that that is not the question we faced.



    When we started developing the Hurd in 1990, the question facing us
    was, ``How can we get a free kernel for the GNU system?'' There was no
    free Unix-like kernel then, and we knew of no other plan to write one.
    The only way we could expect to have a free kernel was to write it
    ourselves. So we started.



    We heard about Linux after its release. At that time, the question
    facing us was, ``Should we cancel the Hurd project and use Linux
    instead?''



    We heard that Linux was not at all portable (this may not be true
    today, but that's what we heard then). And we heard that Linux was
    architecturally on a par with the Unix kernel; our work was leading to
    something much more powerful.



    Given the years of work we had already put into the Hurd, we decided
    to finish it rather than throw them away.



    If we did face the question that people ask---if Linux were already
    available, and we were considering whether to start writing another
    kernel---we would not do it. Instead we would choose another project,
    something to do a job that no existing free software can do.



    But we did start the Hurd, back then, and now we have made it work. We
    hope its superior architecture will make free operating systems more
    powerful.







    share|improve this answer



















    • 5





      Despite the fantastic answers provided to the question already, I will select this answer as the canonical one to the question because it demonstrates the rationale behind choice of sticking with the Hurd, straight from the creator of the GNU Project, Richard Stallman.

      – NlightNFotis
      Apr 30 '13 at 23:18






    • 9





      Note "this may not be true today" - RMS' opinion of Linux seems to be based on hearsay, not knowledge.

      – Martin Schröder
      May 1 '13 at 13:27






    • 16





      @Martin: (Late Reply, but:) When Torvalds first announced Linux, it was x86 specific, with zero plans to make it portable. In the intial thread Linus flat out said "I'd say that porting is impossible". Thus, rms had no reason to originally believe that Linux would grow into what it has today. Evidence from the mouth of the project leader is hardly hearsay.

      – Kevin Cathcart
      Aug 16 '13 at 21:33











    • @KevinCathcart: RMS/FSF should have studied the code themself instead of relying on others ("we heard").

      – Martin Schröder
      Aug 17 '13 at 7:22






    • 19





      @MartinSchröder: Why study the code when the Project Leader explicitly said it would not be portable? Anyway, Linux was announced in 1991. It took until April of 1994 (release 1.1.45) before Linux even added the folders for architecture ports. It would take longer before any ports were practical. If the FSF made their decision to continue the Hurd in 1992 or 1993, looking at the code would only have reinforced that the code was non-portable.

      – Kevin Cathcart
      Aug 19 '13 at 16:53
















    32














    I am quoting a comment by Richard Stallman, regarding the decision to roll with the Hurd rather than Linux.




    People sometimes ask, ``Why did the FSF develop a new free kernel
    instead of using Linux?'' It's a reasonable question. The answer,
    briefly, is that that is not the question we faced.



    When we started developing the Hurd in 1990, the question facing us
    was, ``How can we get a free kernel for the GNU system?'' There was no
    free Unix-like kernel then, and we knew of no other plan to write one.
    The only way we could expect to have a free kernel was to write it
    ourselves. So we started.



    We heard about Linux after its release. At that time, the question
    facing us was, ``Should we cancel the Hurd project and use Linux
    instead?''



    We heard that Linux was not at all portable (this may not be true
    today, but that's what we heard then). And we heard that Linux was
    architecturally on a par with the Unix kernel; our work was leading to
    something much more powerful.



    Given the years of work we had already put into the Hurd, we decided
    to finish it rather than throw them away.



    If we did face the question that people ask---if Linux were already
    available, and we were considering whether to start writing another
    kernel---we would not do it. Instead we would choose another project,
    something to do a job that no existing free software can do.



    But we did start the Hurd, back then, and now we have made it work. We
    hope its superior architecture will make free operating systems more
    powerful.







    share|improve this answer



















    • 5





      Despite the fantastic answers provided to the question already, I will select this answer as the canonical one to the question because it demonstrates the rationale behind choice of sticking with the Hurd, straight from the creator of the GNU Project, Richard Stallman.

      – NlightNFotis
      Apr 30 '13 at 23:18






    • 9





      Note "this may not be true today" - RMS' opinion of Linux seems to be based on hearsay, not knowledge.

      – Martin Schröder
      May 1 '13 at 13:27






    • 16





      @Martin: (Late Reply, but:) When Torvalds first announced Linux, it was x86 specific, with zero plans to make it portable. In the intial thread Linus flat out said "I'd say that porting is impossible". Thus, rms had no reason to originally believe that Linux would grow into what it has today. Evidence from the mouth of the project leader is hardly hearsay.

      – Kevin Cathcart
      Aug 16 '13 at 21:33











    • @KevinCathcart: RMS/FSF should have studied the code themself instead of relying on others ("we heard").

      – Martin Schröder
      Aug 17 '13 at 7:22






    • 19





      @MartinSchröder: Why study the code when the Project Leader explicitly said it would not be portable? Anyway, Linux was announced in 1991. It took until April of 1994 (release 1.1.45) before Linux even added the folders for architecture ports. It would take longer before any ports were practical. If the FSF made their decision to continue the Hurd in 1992 or 1993, looking at the code would only have reinforced that the code was non-portable.

      – Kevin Cathcart
      Aug 19 '13 at 16:53














    32












    32








    32







    I am quoting a comment by Richard Stallman, regarding the decision to roll with the Hurd rather than Linux.




    People sometimes ask, ``Why did the FSF develop a new free kernel
    instead of using Linux?'' It's a reasonable question. The answer,
    briefly, is that that is not the question we faced.



    When we started developing the Hurd in 1990, the question facing us
    was, ``How can we get a free kernel for the GNU system?'' There was no
    free Unix-like kernel then, and we knew of no other plan to write one.
    The only way we could expect to have a free kernel was to write it
    ourselves. So we started.



    We heard about Linux after its release. At that time, the question
    facing us was, ``Should we cancel the Hurd project and use Linux
    instead?''



    We heard that Linux was not at all portable (this may not be true
    today, but that's what we heard then). And we heard that Linux was
    architecturally on a par with the Unix kernel; our work was leading to
    something much more powerful.



    Given the years of work we had already put into the Hurd, we decided
    to finish it rather than throw them away.



    If we did face the question that people ask---if Linux were already
    available, and we were considering whether to start writing another
    kernel---we would not do it. Instead we would choose another project,
    something to do a job that no existing free software can do.



    But we did start the Hurd, back then, and now we have made it work. We
    hope its superior architecture will make free operating systems more
    powerful.







    share|improve this answer













    I am quoting a comment by Richard Stallman, regarding the decision to roll with the Hurd rather than Linux.




    People sometimes ask, ``Why did the FSF develop a new free kernel
    instead of using Linux?'' It's a reasonable question. The answer,
    briefly, is that that is not the question we faced.



    When we started developing the Hurd in 1990, the question facing us
    was, ``How can we get a free kernel for the GNU system?'' There was no
    free Unix-like kernel then, and we knew of no other plan to write one.
    The only way we could expect to have a free kernel was to write it
    ourselves. So we started.



    We heard about Linux after its release. At that time, the question
    facing us was, ``Should we cancel the Hurd project and use Linux
    instead?''



    We heard that Linux was not at all portable (this may not be true
    today, but that's what we heard then). And we heard that Linux was
    architecturally on a par with the Unix kernel; our work was leading to
    something much more powerful.



    Given the years of work we had already put into the Hurd, we decided
    to finish it rather than throw them away.



    If we did face the question that people ask---if Linux were already
    available, and we were considering whether to start writing another
    kernel---we would not do it. Instead we would choose another project,
    something to do a job that no existing free software can do.



    But we did start the Hurd, back then, and now we have made it work. We
    hope its superior architecture will make free operating systems more
    powerful.








    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 30 '13 at 23:14









    NlightNFotisNlightNFotis

    4,55252437




    4,55252437








    • 5





      Despite the fantastic answers provided to the question already, I will select this answer as the canonical one to the question because it demonstrates the rationale behind choice of sticking with the Hurd, straight from the creator of the GNU Project, Richard Stallman.

      – NlightNFotis
      Apr 30 '13 at 23:18






    • 9





      Note "this may not be true today" - RMS' opinion of Linux seems to be based on hearsay, not knowledge.

      – Martin Schröder
      May 1 '13 at 13:27






    • 16





      @Martin: (Late Reply, but:) When Torvalds first announced Linux, it was x86 specific, with zero plans to make it portable. In the intial thread Linus flat out said "I'd say that porting is impossible". Thus, rms had no reason to originally believe that Linux would grow into what it has today. Evidence from the mouth of the project leader is hardly hearsay.

      – Kevin Cathcart
      Aug 16 '13 at 21:33











    • @KevinCathcart: RMS/FSF should have studied the code themself instead of relying on others ("we heard").

      – Martin Schröder
      Aug 17 '13 at 7:22






    • 19





      @MartinSchröder: Why study the code when the Project Leader explicitly said it would not be portable? Anyway, Linux was announced in 1991. It took until April of 1994 (release 1.1.45) before Linux even added the folders for architecture ports. It would take longer before any ports were practical. If the FSF made their decision to continue the Hurd in 1992 or 1993, looking at the code would only have reinforced that the code was non-portable.

      – Kevin Cathcart
      Aug 19 '13 at 16:53














    • 5





      Despite the fantastic answers provided to the question already, I will select this answer as the canonical one to the question because it demonstrates the rationale behind choice of sticking with the Hurd, straight from the creator of the GNU Project, Richard Stallman.

      – NlightNFotis
      Apr 30 '13 at 23:18






    • 9





      Note "this may not be true today" - RMS' opinion of Linux seems to be based on hearsay, not knowledge.

      – Martin Schröder
      May 1 '13 at 13:27






    • 16





      @Martin: (Late Reply, but:) When Torvalds first announced Linux, it was x86 specific, with zero plans to make it portable. In the intial thread Linus flat out said "I'd say that porting is impossible". Thus, rms had no reason to originally believe that Linux would grow into what it has today. Evidence from the mouth of the project leader is hardly hearsay.

      – Kevin Cathcart
      Aug 16 '13 at 21:33











    • @KevinCathcart: RMS/FSF should have studied the code themself instead of relying on others ("we heard").

      – Martin Schröder
      Aug 17 '13 at 7:22






    • 19





      @MartinSchröder: Why study the code when the Project Leader explicitly said it would not be portable? Anyway, Linux was announced in 1991. It took until April of 1994 (release 1.1.45) before Linux even added the folders for architecture ports. It would take longer before any ports were practical. If the FSF made their decision to continue the Hurd in 1992 or 1993, looking at the code would only have reinforced that the code was non-portable.

      – Kevin Cathcart
      Aug 19 '13 at 16:53








    5




    5





    Despite the fantastic answers provided to the question already, I will select this answer as the canonical one to the question because it demonstrates the rationale behind choice of sticking with the Hurd, straight from the creator of the GNU Project, Richard Stallman.

    – NlightNFotis
    Apr 30 '13 at 23:18





    Despite the fantastic answers provided to the question already, I will select this answer as the canonical one to the question because it demonstrates the rationale behind choice of sticking with the Hurd, straight from the creator of the GNU Project, Richard Stallman.

    – NlightNFotis
    Apr 30 '13 at 23:18




    9




    9





    Note "this may not be true today" - RMS' opinion of Linux seems to be based on hearsay, not knowledge.

    – Martin Schröder
    May 1 '13 at 13:27





    Note "this may not be true today" - RMS' opinion of Linux seems to be based on hearsay, not knowledge.

    – Martin Schröder
    May 1 '13 at 13:27




    16




    16





    @Martin: (Late Reply, but:) When Torvalds first announced Linux, it was x86 specific, with zero plans to make it portable. In the intial thread Linus flat out said "I'd say that porting is impossible". Thus, rms had no reason to originally believe that Linux would grow into what it has today. Evidence from the mouth of the project leader is hardly hearsay.

    – Kevin Cathcart
    Aug 16 '13 at 21:33





    @Martin: (Late Reply, but:) When Torvalds first announced Linux, it was x86 specific, with zero plans to make it portable. In the intial thread Linus flat out said "I'd say that porting is impossible". Thus, rms had no reason to originally believe that Linux would grow into what it has today. Evidence from the mouth of the project leader is hardly hearsay.

    – Kevin Cathcart
    Aug 16 '13 at 21:33













    @KevinCathcart: RMS/FSF should have studied the code themself instead of relying on others ("we heard").

    – Martin Schröder
    Aug 17 '13 at 7:22





    @KevinCathcart: RMS/FSF should have studied the code themself instead of relying on others ("we heard").

    – Martin Schröder
    Aug 17 '13 at 7:22




    19




    19





    @MartinSchröder: Why study the code when the Project Leader explicitly said it would not be portable? Anyway, Linux was announced in 1991. It took until April of 1994 (release 1.1.45) before Linux even added the folders for architecture ports. It would take longer before any ports were practical. If the FSF made their decision to continue the Hurd in 1992 or 1993, looking at the code would only have reinforced that the code was non-portable.

    – Kevin Cathcart
    Aug 19 '13 at 16:53





    @MartinSchröder: Why study the code when the Project Leader explicitly said it would not be portable? Anyway, Linux was announced in 1991. It took until April of 1994 (release 1.1.45) before Linux even added the folders for architecture ports. It would take longer before any ports were practical. If the FSF made their decision to continue the Hurd in 1992 or 1993, looking at the code would only have reinforced that the code was non-portable.

    – Kevin Cathcart
    Aug 19 '13 at 16:53











    4














    I'm just adding my 2 cent here, I think that what it's been discussed at this point makes a lot of sense but there is one major aspect that I think can really polarize the GNU foundation and it's the fact that Linux is becoming more and more a place where large corporates are investing real money and time, the idea that linux is kind of an home-made project it's not true, not even a bit, maybe there is some random guy trying to get attention on the scene while giving a patch away, but for the large part linux it's a job for corporations.






    share|improve this answer



















    • 1





      I don't think the FSF has a problem with corporate support of software projects. Their main focus is on the principles of free software.

      – Faheem Mitha
      Jun 14 '13 at 9:22













    • Corporate dominance was a big concern the GNU GPL was intended to address. Permissively licensed software was actually normal procedure at both MIT and Berkeley, but once code was commercialized it was promptly closed. So for example, I could checkout the Linux source today and all the commercially developed improvements will benefit my potential project. Or my next small personal project may use just a couple blocks, the point is that any released improvements benefit whoever works with the code next.

      – J. M. Becker
      Jan 25 '14 at 1:24


















    4














    I'm just adding my 2 cent here, I think that what it's been discussed at this point makes a lot of sense but there is one major aspect that I think can really polarize the GNU foundation and it's the fact that Linux is becoming more and more a place where large corporates are investing real money and time, the idea that linux is kind of an home-made project it's not true, not even a bit, maybe there is some random guy trying to get attention on the scene while giving a patch away, but for the large part linux it's a job for corporations.






    share|improve this answer



















    • 1





      I don't think the FSF has a problem with corporate support of software projects. Their main focus is on the principles of free software.

      – Faheem Mitha
      Jun 14 '13 at 9:22













    • Corporate dominance was a big concern the GNU GPL was intended to address. Permissively licensed software was actually normal procedure at both MIT and Berkeley, but once code was commercialized it was promptly closed. So for example, I could checkout the Linux source today and all the commercially developed improvements will benefit my potential project. Or my next small personal project may use just a couple blocks, the point is that any released improvements benefit whoever works with the code next.

      – J. M. Becker
      Jan 25 '14 at 1:24
















    4












    4








    4







    I'm just adding my 2 cent here, I think that what it's been discussed at this point makes a lot of sense but there is one major aspect that I think can really polarize the GNU foundation and it's the fact that Linux is becoming more and more a place where large corporates are investing real money and time, the idea that linux is kind of an home-made project it's not true, not even a bit, maybe there is some random guy trying to get attention on the scene while giving a patch away, but for the large part linux it's a job for corporations.






    share|improve this answer













    I'm just adding my 2 cent here, I think that what it's been discussed at this point makes a lot of sense but there is one major aspect that I think can really polarize the GNU foundation and it's the fact that Linux is becoming more and more a place where large corporates are investing real money and time, the idea that linux is kind of an home-made project it's not true, not even a bit, maybe there is some random guy trying to get attention on the scene while giving a patch away, but for the large part linux it's a job for corporations.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered May 27 '13 at 8:47









    user2384250user2384250

    30147




    30147








    • 1





      I don't think the FSF has a problem with corporate support of software projects. Their main focus is on the principles of free software.

      – Faheem Mitha
      Jun 14 '13 at 9:22













    • Corporate dominance was a big concern the GNU GPL was intended to address. Permissively licensed software was actually normal procedure at both MIT and Berkeley, but once code was commercialized it was promptly closed. So for example, I could checkout the Linux source today and all the commercially developed improvements will benefit my potential project. Or my next small personal project may use just a couple blocks, the point is that any released improvements benefit whoever works with the code next.

      – J. M. Becker
      Jan 25 '14 at 1:24
















    • 1





      I don't think the FSF has a problem with corporate support of software projects. Their main focus is on the principles of free software.

      – Faheem Mitha
      Jun 14 '13 at 9:22













    • Corporate dominance was a big concern the GNU GPL was intended to address. Permissively licensed software was actually normal procedure at both MIT and Berkeley, but once code was commercialized it was promptly closed. So for example, I could checkout the Linux source today and all the commercially developed improvements will benefit my potential project. Or my next small personal project may use just a couple blocks, the point is that any released improvements benefit whoever works with the code next.

      – J. M. Becker
      Jan 25 '14 at 1:24










    1




    1





    I don't think the FSF has a problem with corporate support of software projects. Their main focus is on the principles of free software.

    – Faheem Mitha
    Jun 14 '13 at 9:22







    I don't think the FSF has a problem with corporate support of software projects. Their main focus is on the principles of free software.

    – Faheem Mitha
    Jun 14 '13 at 9:22















    Corporate dominance was a big concern the GNU GPL was intended to address. Permissively licensed software was actually normal procedure at both MIT and Berkeley, but once code was commercialized it was promptly closed. So for example, I could checkout the Linux source today and all the commercially developed improvements will benefit my potential project. Or my next small personal project may use just a couple blocks, the point is that any released improvements benefit whoever works with the code next.

    – J. M. Becker
    Jan 25 '14 at 1:24







    Corporate dominance was a big concern the GNU GPL was intended to address. Permissively licensed software was actually normal procedure at both MIT and Berkeley, but once code was commercialized it was promptly closed. So for example, I could checkout the Linux source today and all the commercially developed improvements will benefit my potential project. Or my next small personal project may use just a couple blocks, the point is that any released improvements benefit whoever works with the code next.

    – J. M. Becker
    Jan 25 '14 at 1:24













    1














    Another explanation found on the FAQ of gnu.org:




    Making the GNU Hurd work well enough to compete with Linux would be a
    big job, and it's not clearly necessary. The only thing ethically
    wrong with Linux as a kernel is its inclusion of firmware “blobs”; the
    best fix for that problem is developing free replacement for the
    blobs.







    share|improve this answer




























      1














      Another explanation found on the FAQ of gnu.org:




      Making the GNU Hurd work well enough to compete with Linux would be a
      big job, and it's not clearly necessary. The only thing ethically
      wrong with Linux as a kernel is its inclusion of firmware “blobs”; the
      best fix for that problem is developing free replacement for the
      blobs.







      share|improve this answer


























        1












        1








        1







        Another explanation found on the FAQ of gnu.org:




        Making the GNU Hurd work well enough to compete with Linux would be a
        big job, and it's not clearly necessary. The only thing ethically
        wrong with Linux as a kernel is its inclusion of firmware “blobs”; the
        best fix for that problem is developing free replacement for the
        blobs.







        share|improve this answer













        Another explanation found on the FAQ of gnu.org:




        Making the GNU Hurd work well enough to compete with Linux would be a
        big job, and it's not clearly necessary. The only thing ethically
        wrong with Linux as a kernel is its inclusion of firmware “blobs”; the
        best fix for that problem is developing free replacement for the
        blobs.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 26 at 12:12









        The QuarkThe Quark

        113




        113























            -6














            Linux can not be Unix, since Linux is not conforming to Posix.



            So even without political hassle Linux can not meet the design goal for Hurd.



            Cite:
            "The Hurd is the GNU project's replacement for UNIX, a popular operating system kernel."



            Astonishing, that there is a Debian/Hurd-Projekt. But that is possibly a different story...



            BTW: Windows (since NT/XP) is based on the MACH-kernel, too.






            share|improve this answer





















            • 8





              If you are going to claim that Linux is not POSIX conformant, you're going to have to back that up a bit. Including where the FSF says they require an absolutely 100% POSIX compliant kernel. By the way, Unix is not POSIX. Unix (trademarked) is a specific proprietary OS, so it goes without saying that no other OS can be that OS.

              – psusi
              Apr 29 '13 at 13:40






            • 6





              Citation for the Windows kernel being based on MACH? Wikipedia says they share some design choices; but with MACH being the prototypical microkernel while the majority of Windows OS services run in the kernel not userland. The only major OSS component in the Windows kernel that I'm aware of was the network stack which used to be based on the BSD implementation; however it was ripped out and replaced with one that better interfaced with the rest of the os design several versions ago (IIRC in XP or 2k).

              – Dan Neely
              Apr 29 '13 at 13:59






            • 14





              But GNU's Not Unix, either.

              – Simon
              Apr 29 '13 at 16:02






            • 6





              @Nils, the question you linked contradicts your position, rather than supports it.

              – psusi
              Apr 29 '13 at 16:08






            • 8





              @Nils, the Mach nonsense is another bit of popular misconception. NT has nothing in common with mach. Its "subsystem servers" are no different than unix daemons, which do not make a microkernel. Originally the gui was implemented in user mode, and this had only a passing resemblance to a microkernel system ( though so is Xwindows, that does not make Linux a microkernel ), but this was scrapped in NT4 and moved to the kernel.

              – psusi
              Apr 29 '13 at 16:20
















            -6














            Linux can not be Unix, since Linux is not conforming to Posix.



            So even without political hassle Linux can not meet the design goal for Hurd.



            Cite:
            "The Hurd is the GNU project's replacement for UNIX, a popular operating system kernel."



            Astonishing, that there is a Debian/Hurd-Projekt. But that is possibly a different story...



            BTW: Windows (since NT/XP) is based on the MACH-kernel, too.






            share|improve this answer





















            • 8





              If you are going to claim that Linux is not POSIX conformant, you're going to have to back that up a bit. Including where the FSF says they require an absolutely 100% POSIX compliant kernel. By the way, Unix is not POSIX. Unix (trademarked) is a specific proprietary OS, so it goes without saying that no other OS can be that OS.

              – psusi
              Apr 29 '13 at 13:40






            • 6





              Citation for the Windows kernel being based on MACH? Wikipedia says they share some design choices; but with MACH being the prototypical microkernel while the majority of Windows OS services run in the kernel not userland. The only major OSS component in the Windows kernel that I'm aware of was the network stack which used to be based on the BSD implementation; however it was ripped out and replaced with one that better interfaced with the rest of the os design several versions ago (IIRC in XP or 2k).

              – Dan Neely
              Apr 29 '13 at 13:59






            • 14





              But GNU's Not Unix, either.

              – Simon
              Apr 29 '13 at 16:02






            • 6





              @Nils, the question you linked contradicts your position, rather than supports it.

              – psusi
              Apr 29 '13 at 16:08






            • 8





              @Nils, the Mach nonsense is another bit of popular misconception. NT has nothing in common with mach. Its "subsystem servers" are no different than unix daemons, which do not make a microkernel. Originally the gui was implemented in user mode, and this had only a passing resemblance to a microkernel system ( though so is Xwindows, that does not make Linux a microkernel ), but this was scrapped in NT4 and moved to the kernel.

              – psusi
              Apr 29 '13 at 16:20














            -6












            -6








            -6







            Linux can not be Unix, since Linux is not conforming to Posix.



            So even without political hassle Linux can not meet the design goal for Hurd.



            Cite:
            "The Hurd is the GNU project's replacement for UNIX, a popular operating system kernel."



            Astonishing, that there is a Debian/Hurd-Projekt. But that is possibly a different story...



            BTW: Windows (since NT/XP) is based on the MACH-kernel, too.






            share|improve this answer















            Linux can not be Unix, since Linux is not conforming to Posix.



            So even without political hassle Linux can not meet the design goal for Hurd.



            Cite:
            "The Hurd is the GNU project's replacement for UNIX, a popular operating system kernel."



            Astonishing, that there is a Debian/Hurd-Projekt. But that is possibly a different story...



            BTW: Windows (since NT/XP) is based on the MACH-kernel, too.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 13 '17 at 12:36









            Community♦

            1




            1










            answered Apr 29 '13 at 13:10









            NilsNils

            12.6k73670




            12.6k73670








            • 8





              If you are going to claim that Linux is not POSIX conformant, you're going to have to back that up a bit. Including where the FSF says they require an absolutely 100% POSIX compliant kernel. By the way, Unix is not POSIX. Unix (trademarked) is a specific proprietary OS, so it goes without saying that no other OS can be that OS.

              – psusi
              Apr 29 '13 at 13:40






            • 6





              Citation for the Windows kernel being based on MACH? Wikipedia says they share some design choices; but with MACH being the prototypical microkernel while the majority of Windows OS services run in the kernel not userland. The only major OSS component in the Windows kernel that I'm aware of was the network stack which used to be based on the BSD implementation; however it was ripped out and replaced with one that better interfaced with the rest of the os design several versions ago (IIRC in XP or 2k).

              – Dan Neely
              Apr 29 '13 at 13:59






            • 14





              But GNU's Not Unix, either.

              – Simon
              Apr 29 '13 at 16:02






            • 6





              @Nils, the question you linked contradicts your position, rather than supports it.

              – psusi
              Apr 29 '13 at 16:08






            • 8





              @Nils, the Mach nonsense is another bit of popular misconception. NT has nothing in common with mach. Its "subsystem servers" are no different than unix daemons, which do not make a microkernel. Originally the gui was implemented in user mode, and this had only a passing resemblance to a microkernel system ( though so is Xwindows, that does not make Linux a microkernel ), but this was scrapped in NT4 and moved to the kernel.

              – psusi
              Apr 29 '13 at 16:20














            • 8





              If you are going to claim that Linux is not POSIX conformant, you're going to have to back that up a bit. Including where the FSF says they require an absolutely 100% POSIX compliant kernel. By the way, Unix is not POSIX. Unix (trademarked) is a specific proprietary OS, so it goes without saying that no other OS can be that OS.

              – psusi
              Apr 29 '13 at 13:40






            • 6





              Citation for the Windows kernel being based on MACH? Wikipedia says they share some design choices; but with MACH being the prototypical microkernel while the majority of Windows OS services run in the kernel not userland. The only major OSS component in the Windows kernel that I'm aware of was the network stack which used to be based on the BSD implementation; however it was ripped out and replaced with one that better interfaced with the rest of the os design several versions ago (IIRC in XP or 2k).

              – Dan Neely
              Apr 29 '13 at 13:59






            • 14





              But GNU's Not Unix, either.

              – Simon
              Apr 29 '13 at 16:02






            • 6





              @Nils, the question you linked contradicts your position, rather than supports it.

              – psusi
              Apr 29 '13 at 16:08






            • 8





              @Nils, the Mach nonsense is another bit of popular misconception. NT has nothing in common with mach. Its "subsystem servers" are no different than unix daemons, which do not make a microkernel. Originally the gui was implemented in user mode, and this had only a passing resemblance to a microkernel system ( though so is Xwindows, that does not make Linux a microkernel ), but this was scrapped in NT4 and moved to the kernel.

              – psusi
              Apr 29 '13 at 16:20








            8




            8





            If you are going to claim that Linux is not POSIX conformant, you're going to have to back that up a bit. Including where the FSF says they require an absolutely 100% POSIX compliant kernel. By the way, Unix is not POSIX. Unix (trademarked) is a specific proprietary OS, so it goes without saying that no other OS can be that OS.

            – psusi
            Apr 29 '13 at 13:40





            If you are going to claim that Linux is not POSIX conformant, you're going to have to back that up a bit. Including where the FSF says they require an absolutely 100% POSIX compliant kernel. By the way, Unix is not POSIX. Unix (trademarked) is a specific proprietary OS, so it goes without saying that no other OS can be that OS.

            – psusi
            Apr 29 '13 at 13:40




            6




            6





            Citation for the Windows kernel being based on MACH? Wikipedia says they share some design choices; but with MACH being the prototypical microkernel while the majority of Windows OS services run in the kernel not userland. The only major OSS component in the Windows kernel that I'm aware of was the network stack which used to be based on the BSD implementation; however it was ripped out and replaced with one that better interfaced with the rest of the os design several versions ago (IIRC in XP or 2k).

            – Dan Neely
            Apr 29 '13 at 13:59





            Citation for the Windows kernel being based on MACH? Wikipedia says they share some design choices; but with MACH being the prototypical microkernel while the majority of Windows OS services run in the kernel not userland. The only major OSS component in the Windows kernel that I'm aware of was the network stack which used to be based on the BSD implementation; however it was ripped out and replaced with one that better interfaced with the rest of the os design several versions ago (IIRC in XP or 2k).

            – Dan Neely
            Apr 29 '13 at 13:59




            14




            14





            But GNU's Not Unix, either.

            – Simon
            Apr 29 '13 at 16:02





            But GNU's Not Unix, either.

            – Simon
            Apr 29 '13 at 16:02




            6




            6





            @Nils, the question you linked contradicts your position, rather than supports it.

            – psusi
            Apr 29 '13 at 16:08





            @Nils, the question you linked contradicts your position, rather than supports it.

            – psusi
            Apr 29 '13 at 16:08




            8




            8





            @Nils, the Mach nonsense is another bit of popular misconception. NT has nothing in common with mach. Its "subsystem servers" are no different than unix daemons, which do not make a microkernel. Originally the gui was implemented in user mode, and this had only a passing resemblance to a microkernel system ( though so is Xwindows, that does not make Linux a microkernel ), but this was scrapped in NT4 and moved to the kernel.

            – psusi
            Apr 29 '13 at 16:20





            @Nils, the Mach nonsense is another bit of popular misconception. NT has nothing in common with mach. Its "subsystem servers" are no different than unix daemons, which do not make a microkernel. Originally the gui was implemented in user mode, and this had only a passing resemblance to a microkernel system ( though so is Xwindows, that does not make Linux a microkernel ), but this was scrapped in NT4 and moved to the kernel.

            – psusi
            Apr 29 '13 at 16:20


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid …



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f73950%2fwhy-isnt-linux-embraced-as-the-official-gnu-kernel%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            -

            Popular posts from this blog

            How to make a Squid Proxy server?

            Image
            1 I want to set up squid proxy server for monitoring user activity in a network and Internet Web URL filtering for user. I also want to configure the user login, user log, user access group, and block unwanted web sites in my network. Please help me and guide me the full process to do this. server proxy squid share | improve this question edited Jul 31 '12 at 14:45 Jorge Castro 37.1k 107 422 617 asked Jul 31 '12 at 5:16 Goivind Tiwari Goivind Tiwari
            Read more

            Is this a new Fibonacci Identity?

            Image
            6 1 $begingroup$ I have found the following Fibonacci Identity (and proved it). If $F_n$ denotes the nth Fibonacci Number, we have the following identity begin{equation} F_{n-r+h}F_{n+k+g+1} - F_{n-r+g}F_{n+k+h+1} = (-1)^{n+r+h+1} F_{g-h}F_{k+r+1} end{equation} where $F_1 = F_2 = 1$ , $r leq n$ , $h leq g$ , and $n, g, k in mathbb{N}$ . It is not too hard to show that this identity subsumes Cassini's Identity, Catalan's Identity, Vajda's Idenity, and d'Ocagne's identity to name a few. I have done a pretty thorough literature review, and I have not found anything like this, but I am still wondering if anyone has seen this identity before? I found this by accident after noticing some patterns in some analysis work I was doing, so if this is already known I would be curious to see w
            Read more

            19世紀

            Image
            この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。 （ 2012年3月 ） 千年紀: 2千年紀 世紀: 18世紀 - 19世紀 - 20世紀 十年紀: 1800年代 1810年代 1820年代 1830年代 1840年代 1850年代 1860年代 1870年代 1880年代 1890年代 19世紀に君臨した大英帝国。 19世紀 （じゅうきゅうせいき）は、西暦1801年から西暦1900年までの100年間を指す世紀。 目次 1 19世紀の歴史 1.1 国民国家の成立 1.2 帝国主義の興隆 1.3 列強の植民地争奪戦 2 できごと 2.1 1800年代 2.2 1810年代 2.3 1820年代 2.4 1830年代 2.5 1840年代 2.6 1850年代 2.7 1860年代 2.8 1870年代 2.9 1880年代 2.10 1890年代 2.11 1900年代 3 文化 3.1 文学 3.2 音楽 3.3 思想 3.4 科学 3.5 技術 4 人物 4.1 ヨーロッパ 4.1.1 政治家・王族 4.1.1.1 フランス 4.1.1.2 オーストリア＝ハンガリー 4.1.1.3 ロシア 4.1.1.4 イギリス 4.1.1.5 ドイツ（プロイセンほかドイツ領邦を含む） 4.1.1.6 北欧 4.1.1.7 イタリア 4.1.1.8 スペイン 4.1.1.9 ベルギー 4.1.1.10 ギリシア 4.1.2 軍人 4.1.3 実業家 4.1.4 科学と技術 4.1.5 思想と哲学・人文諸学 4.1.6 宗教 4.1.7 文学 4.1.8 美術 4.1.9 音楽 4.1.10 社会事業家 4.1.11 探検家・旅行家 4.1.12 料
            Read more