Announcement

Collapse
No announcement yet.

Haiku's USB 3.0+ Support Is Finally In Great Shape

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

  • #11
    Originally posted by gilboa View Post
    The theoretical pros of micro-kernel based OSs are well known, so are the theoretical (and actual) cons.
    I'm not a micro/macro/hybrid kernel advocate. I'm interested in actual features. If this new kernel can deliver what I said, then it's worth it.

    1. Most of the issues you describe are Google's own doing. They chose to let Android OEMs do what they want.
    Google has no power over that. This is how any embedded device works. Android is the OS layer over the hardware vendor's SDK (which is Linux+blobs). This is true for network hardware, for industrial and any other embedded.

    No reason to believe that they won't let Fuchsia OEM do the same.
    If the entire kernel is designed from the ground up to work with blob drivers, it's much easier to get them to play by the rules. Especially if it's actually the most convenient way for them too.

    2. Most of the closed-source blobs in any Android handset is actually Google's own code and its mostly user space. You can live with an old kernel. Far hardware (if not impossible) to live with old Google and unsupported Google apps.
    I'm not sure about what this even means. Play Store updates itself, so does the "google frameworks" used by applications, as they are themselves, applications.
    The bulk of Android is actually abstracting the abstractions that abstract each stupid hardware-specific little shit way the hardware manufacturer decided to implement each feature. The media player subsystem is an example of this.

    3. While theoretically a micro-kernel OS can recover from a crashed blob GPU driver, a buggy driver will be just as bad if its run in user space.
    A buggy driver is still better than no driver at all until 7 years later (which is waaay to late for most mobile or consumer embedded), or no driver at all, period, since the manufacturer is an ass and won't release docs or firmware or whatever. This is the hard world outside x86 (or even inside x86)

    4. More-ever, you assume that you'll be able to take a GUI driver from Fuchsia 1.x and use it on a newly updates Fuchsia 2.x.
    What is a GUI driver. What is Fuchsia 1.x. What is Fuchsia 2.x. Why should Fuchsia 2.x drop stable interfaces instead of making new ones for new drivers, or place the old driver interface on top of a shim running on the new driver interface. Or whatever.

    I fully expect Fuchsia blob drivers to last more than a couple months, it's not a tall order.

    The whole reason they last a month on Linux is because Torvalds and others specifically decided to not have a stable binary interface, and this is good and fine for opensource drivers, but makes Linux the worst possible choice for blob drivers.

    Thus far, beyond RHEL (and Windows servers) I've yet to see any OS, monolithic, hybrid or micro-kernel based, that actually live up to this promise.
    Whatever, it's a worthy goal to pursue.
    Also note how projects starting now can learn from older projects and not make the same mistakes.

    Comment


    • #12
      laptop doesn't have ethernet port, haiku doesn't support my wireless chip, i tried to use android phone tethering but it doesn't work either.
      i wanted to give haiku a try but i'll wait until i can have network support.

      Comment


      • #13
        Originally posted by Vistaus View Post
        Also, BeOS was targeting multimedia workstations, but Haiku isn't. But if that's what you believe, then you probably don't use Android either considering that Android was targeting digital cameras rather than smartphones/tablets when it was conceived?
        Considering that Android doesn't let you do much besides taking photos, (and wasting time with social media) I have no reason to bother with it unless I do something directly related to it (testing or developing things).

        Comment


        • #14
          starshipeleven
          Lets see if indeed Google will develop and maintain a stable driver API that will hold beyond a single major release and if indeed Fuchsia won't be an attempt to wrench more control out of the OEM and the community hands, as opposed to both Android and ChromeOS.

          That said, given the fact that nothing really stopped Google from using a very long term kernel release (Such as RedHat does with EL7's 3.10), and use across kernel releases, essentially solving the blob drivers issue, I tend to be less optimistic than you.

          Only time will tell If you're right or not...

          - Gilboa
          DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX1080, F28/x86_64, Dell UP3216Q 4K.
          SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F28/x86_64, Dell U2711..
          BAK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F28/x86-64.
          LAP: ASUS Strix GL502V, i7-6700HQ, 32GB, 1TB+256GB, 1070M, F29/x86_64.

          Comment

          Working...
          X