4 ms·

How is it unusable for research purposes, it seems it can be compiled and run by anyone?

by mda 8y ago

bayindirh 8y ago
For how long? Fuchsia is in its infancy now. A little prototype. with its stable API and other features, it smells like a "hardware-vendor friendly" (or vendor-first or oriented) platform. It may replace Android, maybe Linux in Google's own data centers. Then, we'll have another platform like OpenSolaris. Open, but not. The primary reason I like Linux is its transparency, openness, freedoms it provides and the resulting flexibility, and I'd hate to see these freedoms are eradicated with a so-called Open platform controlled by another mega-corporation called Google.
- gtirloni 8y ago
  The biggest problem with OpenSolaris was proprietary blobs required to build it. Do you know if Fuchsia has any of those? If it doesn't, then just fork it.
  - bayindirh 8y ago
    What I'm trying to say it, it'll probably end like AOSP. Downloadable, buildable, but useless without vendor or closed source add-ons/drivers. Forking is always easy, maintaining is hard. Also, we're not sure whether things will be made harder by Google when things get mature.
    - gwilkes 8y ago
      I think useless is going a bit far, isn't Fire OS a fully maintained fork? I believe there are some maintained forks in China as well but I know less about those
      - bayindirh 8y ago
        Yeah, useless a bit too far to generalize, you're right. But, in the end, it will won't be usable by general public or software hackers (in its original definition). I don't have any Android devices, and I don't follow its forks, derivatives or general state too closely. If you have the money and the means, you can always make a fork of an open source software and make it work for you. To be more accurate, maybe I can say it won't be very useful for the general public, but big companies can do whatever they want since they have the money and the man-hours.
      - juliangoldsmith 8y ago
        Fire OS is a fully maintained fork, but it still requires proprietary blobs to be functional. As far as I know, there are no commercially-supported Android forks that have open-source drivers outside of the kernel.
    - usrusr 8y ago
      A clean cut between a free core and the adtech layer should be a welcome property. Think Chrome/Chromium, not Android/AOSP. For AOSP, our perception is dominated by all the trouble that derives from hardware vendors forcing binaries into a kernel that actively rejects them.
- mda 8y ago
  I don't understand. Having a stable api is also good for researchers / amateurs as well?
  - bayindirh 8y ago
    API and ABI stability look nice on paper, and really useful in some circumstances, however, it creates two problems, so Linus opposes it (and I take Linus' side). First of all, it allows hardware vendors to be lazy. If a driver compiles, unless there's a grave bug in the driver, the vendor won't do anything. Because it doesn't hurt their bottom line much (nVidia has some serious bugs with their closed source driver, and they play the deaf, but that's another issue). When the API is not stable, something will change/improve inevitably, and the driver will break. A non-compiling driver is guaranteed to wake the vendor up, and maybe they'll fix some of the smaller bugs while they are at it. Second, it hampers kernel development. You have a killer feature you want to implement, and it needs new API calls to be a first-class implementation? No, you can't do that because the API is stable, you can't change it. You need to work around it, tuck it behind more generic calls, add overheads, etc. Fuchsia's API stability mean that a vendor can write the driver once, and send it to integrators once. Unless someone complaints enough, they won't need to touch the code. When the ABI is stable, you can just distribute the .o files, and forget all about it. The driver is working somehow, the integrator is happy, the vendor is making money. This is the dream of commercial software. They can implement once, and deprecate once and for all. Hooray!
    - ebg13 8y ago
      > First of all, it allows hardware vendors to be lazy. This completely ignores the fact that most hardware vendors have no financial incentive to make driver updates for hardware that you have no choice to replace because it's a chip embedded in your phone and they get to choose between forcing you to pay them more money for a new one _or_ spending money for no reason to update the drivers for old hardware. Breaking compatibility very demonstrably does not get mobile device vendors to ship updates, but it _does_ fuck the device owners. Let the driver that works just fine keep working just fine! Don't make a billion people suffer on old kernels because you think that a hardware vendor should do extra work to support a chip that they already made their money from just because you decided to break something that was working just fine before you made your change.

How is it unusable for research purposes, it seems it can be compiled and run by anyone?

by mda 8y ago

How is it unusable for research purposes, it seems it can be compiled and run by anyone?

For how long? Fuchsia is in its infancy now. A little prototype. with its stable API and other features, it smells like a "hardware-vendor friendly" (or vendor-first or oriented) platform. It may replace Android, maybe Linux in Google's own data centers. Then, we'll have another platform like OpenSolaris. Open, but not. The primary reason I like Linux is its transparency, openness, freedoms it provides and the resulting flexibility, and I'd hate to see these freedoms are eradicated with a so-called Open platform controlled by another mega-corporation called Google.

gtirloni 8y ago
The biggest problem with OpenSolaris was proprietary blobs required to build it. Do you know if Fuchsia has any of those? If it doesn't, then just fork it.
- bayindirh 8y ago
  What I'm trying to say it, it'll probably end like AOSP. Downloadable, buildable, but useless without vendor or closed source add-ons/drivers. Forking is always easy, maintaining is hard. Also, we're not sure whether things will be made harder by Google when things get mature.
  - gwilkes 8y ago
    I think useless is going a bit far, isn't Fire OS a fully maintained fork? I believe there are some maintained forks in China as well but I know less about those
    - bayindirh 8y ago
      Yeah, useless a bit too far to generalize, you're right. But, in the end, it will won't be usable by general public or software hackers (in its original definition). I don't have any Android devices, and I don't follow its forks, derivatives or general state too closely. If you have the money and the means, you can always make a fork of an open source software and make it work for you. To be more accurate, maybe I can say it won't be very useful for the general public, but big companies can do whatever they want since they have the money and the man-hours.
    - juliangoldsmith 8y ago
      Fire OS is a fully maintained fork, but it still requires proprietary blobs to be functional. As far as I know, there are no commercially-supported Android forks that have open-source drivers outside of the kernel.
  - usrusr 8y ago
    A clean cut between a free core and the adtech layer should be a welcome property. Think Chrome/Chromium, not Android/AOSP. For AOSP, our perception is dominated by all the trouble that derives from hardware vendors forcing binaries into a kernel that actively rejects them.
mda 8y ago
I don't understand. Having a stable api is also good for researchers / amateurs as well?
- bayindirh 8y ago
  API and ABI stability look nice on paper, and really useful in some circumstances, however, it creates two problems, so Linus opposes it (and I take Linus' side). First of all, it allows hardware vendors to be lazy. If a driver compiles, unless there's a grave bug in the driver, the vendor won't do anything. Because it doesn't hurt their bottom line much (nVidia has some serious bugs with their closed source driver, and they play the deaf, but that's another issue). When the API is not stable, something will change/improve inevitably, and the driver will break. A non-compiling driver is guaranteed to wake the vendor up, and maybe they'll fix some of the smaller bugs while they are at it. Second, it hampers kernel development. You have a killer feature you want to implement, and it needs new API calls to be a first-class implementation? No, you can't do that because the API is stable, you can't change it. You need to work around it, tuck it behind more generic calls, add overheads, etc. Fuchsia's API stability mean that a vendor can write the driver once, and send it to integrators once. Unless someone complaints enough, they won't need to touch the code. When the ABI is stable, you can just distribute the .o files, and forget all about it. The driver is working somehow, the integrator is happy, the vendor is making money. This is the dream of commercial software. They can implement once, and deprecate once and for all. Hooray!
  - ebg13 8y ago
    > First of all, it allows hardware vendors to be lazy. This completely ignores the fact that most hardware vendors have no financial incentive to make driver updates for hardware that you have no choice to replace because it's a chip embedded in your phone and they get to choose between forcing you to pay them more money for a new one _or_ spending money for no reason to update the drivers for old hardware. Breaking compatibility very demonstrably does not get mobile device vendors to ship updates, but it _does_ fuck the device owners. Let the driver that works just fine keep working just fine! Don't make a billion people suffer on old kernels because you think that a hardware vendor should do extra work to support a chip that they already made their money from just because you decided to break something that was working just fine before you made your change.