Announcement

Collapse
No announcement yet.

Minoca Is A New GPLv3, General Purpose OS

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

  • Minoca Is A New GPLv3, General Purpose OS

    Phoronix: Minoca Is A New GPLv3, General Purpose OS

    Released as a Halloween treat yesterday was Minoca, a new open-source (GPLv3) operating system designed for general purpose tasks, features a POSIX-like interface, and takes a modern design approach...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Interesting NT kernel evolution (the mere directory structure under /kernel is familiar af).

    Comment


    • #3
      Minoca contains a powerful driver model between device drivers and the kernel
      The idea is that drivers can be written in a forward compatible manner, so kernel level components can be upgraded without requiring a recompilation of all device drivers.
      We’re looking at areas like power management, serviceability, and resource isolation that are critical today but weren’t even on the radar twenty years ago. Can we achieve parity with what what operating systems are used for in today’s world, but with less code, and with fewer pain points? Can we do better? We’d like to try.
      Why so little information? Is it microkernel? What's the design of it? Any benchmarks?

      I found it features a peculiar system tree:

      Z:/src/os/kernel/sp/profiler.c
      Michael: Code is available in GitLab too...

      Comment


      • #4
        It's probably not written in Rust... I don't blame the guy, Rust wasn't even around in any usable form a few years ago, but damn I'd like to see something more conventional written in Rust pop up somewhere. I don't think Redox is viable because of licensing. I'll just keep waiting...

        Comment


        • #5
          The API structure and naming is eerily similar to the Windows one. A big difference, though, is the apparent lack of asynchronous operations. The Windows is build from bottom up with those.

          Comment


          • #6
            Originally posted by andrebrait View Post
            It's probably not written in Rust... I don't blame the guy, Rust wasn't even around in any usable form a few years ago, but damn I'd like to see something more conventional written in Rust pop up somewhere. I don't think Redox is viable because of licensing. I'll just keep waiting...
            I don't see the MIT licensing of the Redox microkernel being a hindrance. Ultimately, a microkernel will not require that much source code. LLVM and Rust are much bigger projects and they are highly successful under their MIT licenses. Same goes for the entirety of the Rust ecosystem which is largely MIT'ed. Having your kernel under a MIT license doesn't prevent you from having your userspace GPL'ed.

            What Redox will allow you to do, however, is to execute Linux software natively on Redox through userspace emulation, without requiring compilation for a Redox target. That, in itself, will make Redox a powerful option when it's completed.

            Comment


            • #7
              Originally posted by mmstick View Post
              That, in itself, will make Redox a powerful option when it's completed.
              Everyone knows software is never "completed"... it just "matures".

              Comment


              • #8
                Originally posted by mmstick View Post

                I don't see the MIT licensing of the Redox microkernel being a hindrance. Ultimately, a microkernel will not require that much source code. LLVM and Rust are much bigger projects and they are highly successful under their MIT licenses. Same goes for the entirety of the Rust ecosystem which is largely MIT'ed. Having your kernel under a MIT license doesn't prevent you from having your userspace GPL'ed.

                What Redox will allow you to do, however, is to execute Linux software natively on Redox through userspace emulation, without requiring compilation for a Redox target. That, in itself, will make Redox a powerful option when it's completed.
                I don't think that OSes and compilers/programming languages fallunder the same category when it comes to licensing. While it's very weird that someone would like to build a language/compiler and "sell" it, basing on an open-source language/compiler because the target audience here are developers. An OS is much more interesting for a firm to base something on it, close the source code and never contribute back (Apple and FreeBSD, anyone?). I don't mean that Apple has never contributed back to BSD, but if they did, well, it doesn't come close to what companies contribute to the Linux kernel, does it? I mean, even with the Android thing having its own separate kernel tree, they still contribute back to the mainline kernel from time to time and they themselves have to open source their kernels. If they could just close the source code and do whatever they wanted, I doubt Linux and open-source Android projects, like Cyanogenmod, would see any contributions or even exist (in Cyanogenmod's case).

                I didn't use to be the sort of 'free software is the only way' guy until a few months ago, when I first corrected bugs and contributed upstream with some code. Then I began reading source code and identifying where the issues I had came from. Then I improved some software after the maintainer had abandoned it. Then I noticed that free software had enabled pretty much all computing in the world except for iStuff and Desktops (to some extent) and it sorta came to me... while I'm no Stallman, I really became a fan of the thing and I understood why he pushes the GPL instead of the MIT and such licenses.

                Comment


                • #9
                  Originally posted by andrebrait View Post

                  I don't think that OSes and compilers/programming languages fallunder the same category when it comes to licensing. While it's very weird that someone would like to build a language/compiler and "sell" it, basing on an open-source language/compiler because the target audience here are developers. An OS is much more interesting for a firm to base something on it, close the source code and never contribute back (Apple and FreeBSD, anyone?). I don't mean that Apple has never contributed back to BSD, but if they did, well, it doesn't come close to what companies contribute to the Linux kernel, does it? I mean, even with the Android thing having its own separate kernel tree, they still contribute back to the mainline kernel from time to time and they themselves have to open source their kernels. If they could just close the source code and do whatever they wanted, I doubt Linux and open-source Android projects, like Cyanogenmod, would see any contributions or even exist (in Cyanogenmod's case).
                  So for starters AOSP is primarily BSD licensed. Second even if we were to falsely propose that the GPL is why Cynaogenmod exists (It doesn't, it exists because AOSP is BSD Licensed, only the kernel and some userspace bits here and there are under other licenses), the part where AOSP is GPL doesn't seem to be working because the main thing preventing you from installing a random ROM onto your phone... is drivers... So something that should be falling under the scope of the GPL v2 given that ARM vendors don't have the excuse Nvidia has,, instead the response of ARM vendors has been to create license shims in order to keep their drivers proprietary. The result is I just can't take any random Android ROM and put it on any random phone. You can argue "Muh stable hardware ABI", but if things acted as proposed instead of how they actually work wouldn't those drivers be open and thus it not matter?

                  Second, the success or failure of any open source software project is more a matter of historical facts than licensing, Consider the LAMP stack for a moment, 2 of the 4 are Free Software, the other 2 are under permissive opensource licenses. The Apache Webserver is obviously licensed under the Apache License (ngnix, Apache's only serious competitor is under 2-Clause BSD), PHP is under a license that broadly resembles the original BSD license. X11 and Mesa are under MIT. While KDE is under GPL, Qt used to be proprietary and was then put under a custom open source license that the FSF considered incompatible, before finally shifting over to being LGPL.

                  Third as to companies contributing back to FreeBSD, FreeBSD gets back plenty of corporate contributions, particularly from Netflix, however the reason that Linux gets substantially more contributions back is that Linux is wildly more popular than FreeBSD is. Less users means less contributors.
                  Originally posted by andrebrait View Post
                  I didn't use to be the sort of 'free software is the only way' guy until a few months ago, when I first corrected bugs and contributed upstream with some code. Then I began reading source code and identifying where the issues I had came from. Then I improved some software after the maintainer had abandoned it. Then I noticed that free software had enabled pretty much all computing in the world except for iStuff and Desktops (to some extent) and it sorta came to me... while I'm no Stallman, I really became a fan of the thing and I understood why he pushes the GPL instead of the MIT and such licenses.
                  Except it didn't, nor did Stallman and Free Software start open source development as a thing, they simply became a subset that was there, and managed to get some of their software to be first and working well enough to not have an immediate need to be replaced and thus won in the historical context, and that it wasn't until recently that they have tried to replace them (LLVM for example). If GNU hadn't been around Berkley would have come up with their own full stack that everyone would be using instead. The original BSD patchset was a pascal compiler, do you really think that a C compiler and associated frameworks would have been beyond their grasp?

                  Comment


                  • #10
                    Originally posted by andrebrait View Post
                    An OS is much more interesting for a firm to base something on it, close the source code and never contribute back (Apple and FreeBSD, anyone?). I don't mean that Apple has never contributed back to BSD, but if they did, well, it doesn't come close to what companies contribute to the Linux kernel, does it?
                    Sigh, LLVM? Wasn't direct back-contribution to FreeBSD but it certainly helped FreeBSD a lot..


                    About main topic. Gonna be interesting..

                    Comment

                    Working...
                    X