4 ms·

It's awesome that Google is doing this and in public too https://fuchsia.googlesource.com/ https://fuchsia.googlesource.com/ Unfortunately, the hard part of an

by vii 10y ago

It's awesome that Google is doing this and in public too https://fuchsia.googlesource.com/ https://fuchsia.googlesource.com/ Unfortunately, the hard part of an operating system isn't in a cool API and a rendering demo. It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads. People don't like dropped frames when they plug in USB :) Writing device drivers for demanding hardware is much harder than saving registers and switching process context. The Linux kernel has an incredible agglomeration of years of effort and experience behind it - and the social ability to scale to support diverse contributors with different agendas. Microsoft, with its dominant position on the desktop, famously changed the 'preferred' APIs for UI development on a regular cadence. Only Microsoft applications kept up and looked up to date. Now Google has such a commanding share of the phone market - Android is over 80% and growing http://www.idc.com/promo/smartphone-market-share/os http://www.idc.com/promo/smartphone-market-share/os - they have a huge temptation to follow suit. Each time that Microsoft introduced a new technology (e.g. https://en.wikipedia.org/wiki/Windows_Presentation_Foundation https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio... WPF) they had to skirt a fine line between making it simple and making sure that it would be hard for competitors to produce emulation layers for. Otherwise, you could run those apps on your Mac :) There are many things to improve (and simplify) in the Android APIs. It would be delightful to add first class support for C++ and Python, etc. A project this large will be a monster to ship so hopefully we'll soon (a few years) see the main bits integrated into more mainstream platforms like Android/Linux - hopefully without too much ecosystem churn

empath75 10y ago
it doesn't need to be a general purpose OS and is probably going to target mobile devices and laptops. I don't think supporting a wide range of hardware is even on the road map.
- deleted 10y ago
  [deleted]
xiaoma 10y ago
Given that it's Google, I wonder if it will support the languages favored by bootstrappers and small startups—Obj C, Ruby, JavaScript and more recently Swift and Elixir. I get the distinct impression that they're heavily optimizing large team productivity and aren't a fan of functional or highly expressive languages. It's too bad, given how much nicer their app approval process, etc is than Apple's that the Android dev experience has been so much worse all these years.
- RyanZAG 10y ago
  Well going off common sense, it seems likely that Obj C and Swift definitely would not be supported on purpose.
  - leadingthenet 10y ago
    I wouldn't write Swift off yet.
  - xiaoma 10y ago
    How is that common sense? Both are open source and Google is happy to lure iOS devs, presumably.
jpfr 10y ago
Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1]. And on mobile devices, many hardware component vendors provide custom drivers (with binary blobs) anyways. It will not be hard to convince them to support Fuchsia for new hardware releases. If they loose access to Android otherwise... [1] https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Rump_kernel
- leoc 10y ago
  > Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1]. "Linux is a free set of buggy device drivers." https://news.ycombinator.com/item?id=8470638 https://news.ycombinator.com/item?id=8470638 .
  - digi_owl 10y ago
    More and more it seems to be the prevailing attitude even within the Linux "community". Just observe how systemd is overruling and countermanding Linux behavior any chance it gets.
babesh 10y ago
A product I worked on was a victim of Microsoft changing preferred APIs. Their competing product which the prior year had less market share somehow sported the new UI instantly when the UI became publicly available. Monopolistic behavior if you ask me.
- regularfry 10y ago
  It's why I got out of the MS ecosystem. I bought quite heavily into WPF for the Vista launch, and it was obvious that was a dead end within a couple of years. Not only that, but I could see exactly the same thing happening to all the other neat stuff I was planning to look into at the same time. That was not the way to encourage my long-term membership of the Visual Studio clan.
  - pjmlp 10y ago
    WPF is alive and doing pretty well. Doing new WPF application development for the last three years for the biotech industry. It is also the official API for classical desktop application and shares a lot with UWP.
  - flukus 10y ago
    > and it was obvious that was a dead end within a couple of years As the other reply probably indicated, it's still not apparent to .net developers. MS really dropped the ball with providing a clear path for desktop development.
    - regularfry 10y ago
      I was specifically doing 3D stuff in WPF. That end of things didn't get much love after the initial release (or if it did, it came too late for me).
      - douche 10y ago
        How were you doing it? It's definitely possible to embed DirectX in a WPF control, and not particularly hard to do, with SlimDX or SharpDX, in my experience.
npsimons 10y ago
> It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads. So much this; Linux Plumbers conference years ago was bitching about how every gorram vendor wanted to be a special snowflake, so even though the architecture was ARM, you basically had to port the kernel all over again to every new phone. I haven't kept up with it, but I can't imagine it's gotten better. The problems they're listing as reasons to move to a new kernel aren't caused by Linux and they won't go away until you slap the vendors and slap them hard for the bullshit they pull, both on developers and users. As for kernel ABI, this has been rehashed to death: just release your fucking driver as open source code, and it will be integrated and updated in mainline forever: http://www.kroah.com/log/linux/free_drivers.html http://www.kroah.com/log/linux/free_drivers.html
- bjackman 10y ago
  Overall I agree with your sentiment but it's not just a case of "releasing your drivers" but also of getting it accepted by maintainers. If you don't have an awareness of this process from the beginning of your development cycle then it can be a massive amount of work.

by vii 10y ago

empath75 10y ago

it doesn't need to be a general purpose OS and is probably going to target mobile devices and laptops. I don't think supporting a wide range of hardware is even on the road map.

deleted 10y ago
[deleted]

xiaoma 10y ago

Given that it's Google, I wonder if it will support the languages favored by bootstrappers and small startups—Obj C, Ruby, JavaScript and more recently Swift and Elixir. I get the distinct impression that they're heavily optimizing large team productivity and aren't a fan of functional or highly expressive languages. It's too bad, given how much nicer their app approval process, etc is than Apple's that the Android dev experience has been so much worse all these years.

RyanZAG 10y ago
Well going off common sense, it seems likely that Obj C and Swift definitely would not be supported on purpose.
- leadingthenet 10y ago
  I wouldn't write Swift off yet.
- xiaoma 10y ago
  How is that common sense? Both are open source and Google is happy to lure iOS devs, presumably.

jpfr 10y ago

Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1]. And on mobile devices, many hardware component vendors provide custom drivers (with binary blobs) anyways. It will not be hard to convince them to support Fuchsia for new hardware releases. If they loose access to Android otherwise... [1] https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Rump_kernel

leoc 10y ago
> Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1]. "Linux is a free set of buggy device drivers." https://news.ycombinator.com/item?id=8470638 https://news.ycombinator.com/item?id=8470638 .
- digi_owl 10y ago
  More and more it seems to be the prevailing attitude even within the Linux "community". Just observe how systemd is overruling and countermanding Linux behavior any chance it gets.

babesh 10y ago

A product I worked on was a victim of Microsoft changing preferred APIs. Their competing product which the prior year had less market share somehow sported the new UI instantly when the UI became publicly available. Monopolistic behavior if you ask me.

regularfry 10y ago
It's why I got out of the MS ecosystem. I bought quite heavily into WPF for the Vista launch, and it was obvious that was a dead end within a couple of years. Not only that, but I could see exactly the same thing happening to all the other neat stuff I was planning to look into at the same time. That was not the way to encourage my long-term membership of the Visual Studio clan.
- pjmlp 10y ago
  WPF is alive and doing pretty well. Doing new WPF application development for the last three years for the biotech industry. It is also the official API for classical desktop application and shares a lot with UWP.
- flukus 10y ago
  > and it was obvious that was a dead end within a couple of years As the other reply probably indicated, it's still not apparent to .net developers. MS really dropped the ball with providing a clear path for desktop development.
  - regularfry 10y ago
    I was specifically doing 3D stuff in WPF. That end of things didn't get much love after the initial release (or if it did, it came too late for me).
    - douche 10y ago
      How were you doing it? It's definitely possible to embed DirectX in a WPF control, and not particularly hard to do, with SlimDX or SharpDX, in my experience.

npsimons 10y ago

> It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads. So much this; Linux Plumbers conference years ago was bitching about how every gorram vendor wanted to be a special snowflake, so even though the architecture was ARM, you basically had to port the kernel all over again to every new phone. I haven't kept up with it, but I can't imagine it's gotten better. The problems they're listing as reasons to move to a new kernel aren't caused by Linux and they won't go away until you slap the vendors and slap them hard for the bullshit they pull, both on developers and users. As for kernel ABI, this has been rehashed to death: just release your fucking driver as open source code, and it will be integrated and updated in mainline forever: http://www.kroah.com/log/linux/free_drivers.html http://www.kroah.com/log/linux/free_drivers.html

bjackman 10y ago
Overall I agree with your sentiment but it's not just a case of "releasing your drivers" but also of getting it accepted by maintainers. If you don't have an awareness of this process from the beginning of your development cycle then it can be a massive amount of work.