Announcement

Collapse
No announcement yet.

GCC Patch To Support Google's Fuchsia OS

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

  • GCC Patch To Support Google's Fuchsia OS

    Phoronix: GCC Patch To Support Google's Fuchsia OS

    It's been a while since last hearing anything of Google's experimental Fuchsia OS but it looks like things are moving along as they are now looking to merge support for it into the GCC compiler...

    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
    The end is near, folks. It has been an honor to serve by your side.

    I am usually optimistic, but this project has the potential to snowball once it reaches a certain critical mass. I wouldn't worry at all if it wasn't for the departure from a GPLed kernel.
    On the upside, it should be more or less compatible with Linux in the userspace. For now, that is.

    I still hope to be able to use GNU Hurd after the civilization ends in fire. I keep a rms picture in my bunker for this very reason. (xkcd reference, if you didn't get it)

    Comment


    • #3
      Originally posted by M@yeulC View Post
      The end is near, folks. It has been an honor to serve by your side.

      I am usually optimistic, but this project has the potential to snowball once it reaches a certain critical mass.
      Everything can snowball if it reaches a certain critical mass.

      The question is, can it? Sure most hardware manufacturers would love a non-GPL kernel, but will the switch be worth the effort after they have invested in Linux development (in the sense of targeting linux with their blobs and SDKs, not necessarily about open source contributions) all these years?

      I mean *BSDs always had a non-GPL kernel, yet everyone and their dog is using Linux in embedded, so I don't think license alone will change anything.

      Besides, I have strong suspicions that any such project would end up in a Unix Wars all over again and eventually self-destruct as I doubt the manufacturers can stay put, they have this strong urge to add bullshit to their own fork to make it not compatible with the others.

      Comment


      • #4
        unapproved post above for @M@yeulC

        Comment


        • #5
          Originally posted by starshipeleven View Post
          Everything can snowball if it reaches a certain critical mass.

          The question is, can it? Sure most hardware manufacturers would love a non-GPL kernel, but will the switch be worth the effort after they have invested in Linux development (in the sense of targeting linux with their blobs and SDKs, not necessarily about open source contributions) all these years?
          Well, while I agree on the first sentence, google here seems to aim at kernel compatibility in userspace, at least initially. So those efforts are not wasted anyway. As for the kernel-side of their blobs, the target is a moving one, anyway. Plus, it wouldn't surprise me if google was to implement various Linux shims or helpers if they are serious about their OS.

          Originally posted by starshipeleven View Post
          I mean *BSDs always had a non-GPL kernel, yet everyone and their dog is using Linux in embedded, so I don't think license alone will change anything.

          Besides, I have strong suspicions that any such project would end up in a Unix Wars all over again and eventually self-destruct as I doubt the manufacturers can stay put, they have this strong urge to add bullshit to their own fork to make it not compatible with the others.
          Now, that's a very fair point. I can really see that happen as well.

          On (open) drivers:
          For now, the main advantage Linux seems to have is superior HW compatibility, which draws manufacturers towards it, and they improve HW compatibility even further as a result.

          If HW manufacturers are smart enough, they will want to make their drivers a commodity, to maximize their potential market. On one side, a microkernel is an opportunity to stabilize the interfaces. On the other hand, if various manufacturers or integrators start to fork it, there is no guarantee that a precompiled driver will work on another platform, so they would have to open it up in the end (or more likely, provide the source under NDAs).
          What's funny here is that I fully expect integrators to completely break the microkernels paradigms if they start using it, in order to speed up their development, "make it faster" or whatever. And building a more and more monolithic kernel as they reuse their code year after year

          Comment


          • #6
            Originally posted by M@yeulC View Post
            Well, while I agree on the first sentence, google here seems to aim at kernel compatibility in userspace, at least initially. So those efforts are not wasted anyway. As for the kernel-side of their blobs, the target is a moving one, anyway. Plus, it wouldn't surprise me if google was to implement various Linux shims or helpers if they are serious about their OS.
            Yeah, if it didn't have at least a modicum of POSIX compatibility if not full linuxy-like it's plain DOA, I knew that.
            Kernel-side is a moving target but usually it's for good reasons (increasing performance or compatibility or whatever, not just at random) so even if they need to alter their drivers they have good reasons to do so, and anyway it happens at their leisure as they update the kernel in the SDK whenever they feel like it.
            Adding shims will degrade performance, unless it is so great and highly performing on its own I doubt they will be taken seriously.

            On (open) drivers:
            For now, the main advantage Linux seems to have is superior HW compatibility, which draws manufacturers towards it, and they improve HW compatibility even further as a result.
            Companies already on open drivers (like say Intel or AMD for the non-GPU parts) have exactly 0% to gain from Fucsia, really.
            But the overwhelming majority of embedded device manufacturers are using blobs and/or non-opensourced modifications, which is why I'm mostly talking of these.

            What's funny here is that I fully expect integrators to completely break the microkernels paradigms if they start using it, in order to speed up their development, "make it faster" or whatever. And building a more and more monolithic kernel as they reuse their code year after year
            Agree.
            Imho it's 100% likely to go the same as with Linux. They take whatever kernel they find (linux or Fuchsia) and add their blobs and hacks and make a kernel/baseOS that works only on a specific platform (SoC or SoC family), then ship it with their SDK to OEMs that make the device firmwares by adding some stuff on top.

            The only reason they didn't pull this with windows is because Microsoft has an iron fist and can give them orders on what to do to conform to Windows so they are granted the privilege of selling their hardware to people using Windows, not because it is a micro/monolithic/my-little-pony kernel.

            An opensource OS cannot force them to not act like idiots, so the type of kernel per-se isn't a major attraction. That's why I'm wondering if Fucsia can really add something to the table to get all manufacturers jumping on it the same as they did for Android.

            So far the only things it could add are better performance and maybe stabler interfaces if that is a so big issue currently (I doubt it) and.... nothing more.

            Comment


            • #7
              The fuchsia microkernel seems to replace all current google devices. In short replacing the kernel and integrated stuff in android, chrome os and smartdevices ranging from tv's to speakers and anyt minimal embedded os, etc.

              Seems like a critical mass on release day.

              Hate to start over with any new OS, but would be nice to have a microkernel, wouldn't mind spending less time on integration stuff. Really dislike certain choices in Linux.

              Comment


              • #8
                Originally posted by tmpdir View Post
                The fuchsia microkernel seems to replace all current google devices. In short replacing the kernel and integrated stuff in android, chrome os and smartdevices ranging from tv's to speakers and anyt minimal embedded os, etc.
                FYI: when an OEM (device manufacturer) buys a batch of chips to make an embedded device they will get also a SDK (software development kit) that contains the kernel + blobs ready to accept an userspace.
                If Google decides to ship his devices with whatever kernel won't change the fact that most OEMs will still get an SDK with a linux kernel because that's what the chip manufacturer offers.
                To get embedded devices on a different kernel you need to convince the hardware manufacturers, not the OEMs.
                I'm quite frankly wondering how Google plans to make his new kernel work at all on hardware whose drivers are mostly blobs for linux, as they don't have any power over hardware manufacturers.

                ChromeOS is managed like Windows, OEMs can't touch it and all firmwares are made by Google, so it won't matter much, again.

                Hate to start over with any new OS, but would be nice to have a microkernel, wouldn't mind spending less time on integration stuff. Really dislike certain choices in Linux.
                As said above, microkernel is going to be irrelevant given the default attitude of hardware manufacturers. You will still get a hacked kernel with a bunch of blobs that won't work outside of it.
                It will be a firmware, not a true OS.

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  FYI: when an OEM (device manufacturer) buys a batch of chips to make an embedded device they will get also a SDK (software development kit) that contains the kernel + blobs ready to accept an userspace.
                  If Google decides to ship his devices with whatever kernel won't change the fact that most OEMs will still get an SDK with a linux kernel because that's what the chip manufacturer offers.
                  To get embedded devices on a different kernel you need to convince the hardware manufacturers, not the OEMs.
                  I'm quite frankly wondering how Google plans to make his new kernel work at all on hardware whose drivers are mostly blobs for linux, as they don't have any power over hardware manufacturers.

                  ChromeOS is managed like Windows, OEMs can't touch it and all firmwares are made by Google, so it won't matter much, again.

                  As said above, microkernel is going to be irrelevant given the default attitude of hardware manufacturers. You will still get a hacked kernel with a bunch of blobs that won't work outside of it.
                  It will be a firmware, not a true OS.
                  I don't see any argument against a successfull launch also having the most populair mobile OS and the second most (or is it third most) populair desktop os is quit a bit of leverage (read: power).

                  microkernel architecture is very relevant, certainly now mobile and embedded is so populair today in relation to when windows and linux where created, althoug tanenbaun already though a microkernel would be an swell idea ; )

                  Comment


                  • #10
                    Originally posted by tmpdir View Post
                    I don't see any argument against a successfull launch also having the most populair mobile OS and the second most (or is it third most) populair desktop os is quit a bit of leverage (read: power).
                    It would be if Android used by OEMs wasn't a fork (i.e. NOT under Google's control in any way).
                    You probably missed the cluserfuck of Android security updates (i.e. Google updates their devices, everyone else does not give a shit)

                    And let's not post bs about ChromeOS, if all firmwares come from Google anyway, where is the adoption?

                    microkernel architecture is very relevant, certainly now mobile and embedded is so populair today in relation to when windows and linux where created, althoug tanenbaun already though a microkernel would be an swell idea ; )
                    As said above, microkernel is going to be irrelevant given the default attitude of hardware manufacturers. You will still get a hacked kernel with a bunch of blobs that won't work outside of it.
                    It will be a firmware, not a true OS.

                    Comment

                    Working...
                    X