Announcement

Collapse
No announcement yet.

Introducing The Library Operating System For Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Introducing The Library Operating System For Linux

    Phoronix: Introducing The Library Operating System For Linux

    Announced today on the Linux kernel mailing list was the Library Operating System (LibOS) for Linux...

    http://www.phoronix.com/scan.php?pag...-Library-LibOS

  • #2
    That's a fantastic idea. With the exception of hardware interfaces, the network stack should have been in userspace from day one. Great idea. I hope someday Torvalds will force everything but hardware support out of the kernel.

    Comment


    • #3
      Originally posted by duby229 View Post
      I hope someday Torvalds will force everything but hardware support out of the kernel.
      Like a MicroKernel!!

      Comment


      • #4
        Originally posted by higuita View Post
        Like a MicroKernel!!
        Well not really. It can still be a monolithic kernel with modular architecture. I'm not talking about breaking the kernel up into function specific parts. Just saying it would be great if the kernel consisted only of hardware support. Everything else could and should be in userspace.
        Last edited by duby229; 24 March 2015, 01:53 PM.

        Comment


        • #5
          By the time GNU Hurd will be ready Linux will already be a microkernel

          Comment


          • #6
            Looks like a great item that systemd will eat next (http://devopsreactions.tumblr.com/po...systemd-evolve)

            My opinion is that even that this looks nice, it won't have a any practical use-cases. Even developers will find it hard to debug/implement new code with it.

            Comment


            • #7
              And looks like it's simply going to be integrated into User-Mode Linux: http://lkml.iu.edu/hypermail/linux/k...3.3/00252.html

              Comment


              • #8
                If we're to have a 20+ cores \ processors cellphones managed with a distributed \ parallel scheduler then I fail to see what's so wrong with a microkernel.

                Then again, it's almost a certainty that the industry will just keep on slowly hacking the Linux kernel until they'll force it to somehow work as some Frankenstein-esque monolithic x86 muti-threaded mutli-core ungodly abomination. But then again, that's what Go is for.

                *golang

                Comment


                • #9
                  Originally posted by c117152 View Post
                  If we're to have a 20+ cores \ processors cellphones managed with a distributed \ parallel scheduler then I fail to see what's so wrong with a microkernel.

                  Then again, it's almost a certainty that the industry will just keep on slowly hacking the Linux kernel until they'll force it to somehow work as some Frankenstein-esque monolithic x86 muti-threaded mutli-core ungodly abomination. But then again, that's what Go is for.

                  *golang
                  there are plenty of documents on microkernels that show their good and bad sides
                  one that i remember is that it turns out to be slower in general (not by much, but still)

                  the most popular debate is the great Tanenbaum–Torvalds flame war of the nineties


                  just to say, multi-core in C is good
                  you are probably thinking of all those applications that were programmed to use multiple cores poorly
                  but that's another topic
                  Last edited by gens; 24 March 2015, 04:11 PM.

                  Comment


                  • #10
                    I really like the idea of a monolithic kernel focused only on hardware support. Which brings us to the need for something like a "software kernel" or whatever you might want to call it. That's the part I'm not so sure of.

                    Comment

                    Working...
                    X