3 ms·

It's so much harder to do on mobile, for multiple reasons: - Hardware is not very modular (mainly because of size constraints), meaning you have to purpose-bui

by _bxg1 8y ago

It's so much harder to do on mobile, for multiple reasons: - Hardware is not very modular (mainly because of size constraints), meaning you have to purpose-build libre hardware if you can't/don't want to run on tech-giant devices (you can right now if you're forking Android; you probably won't be able to once it's replaced with Fuschia). - Developers' needs have always been a bastion for keeping desktop OSes flexible and open. No matter how closed-down software gets, someone somewhere has to be able to muck with it so as to build and improve it in the first place. This doesn't apply to mobile OSes; people don't use them for development. Not that it's impossible for these things to be overcome, but it's a much steeper uphill battle.

_bxg1 8y ago
Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem, which is even more important today (and especially on mobile) than it used to be in the PC era. You could get some mileage out of the web- but first you'd have to build or port a browser. Chromium certainly won't target your open OS, and with its 75% market share, it now strongarms the direction that web standards take. And many app makers don't even have mobile web apps these days (or their web apps are crippled versions of their "real apps"). Good luck getting Slack and Favor, or your bank, to build apps for your new OS. Or even Dropbox and Evernote. Forget about Netflix and YouTube. Maybe you're okay with going back to the iPhone 1.0 days where a smartphone was just for phone calls, texting, email, a calendar, listening to music, looking up directions, and searching the web. But while you might get an mp3 player app, many people no longer own copies of their music and you won't get Pandora or Spotify. You certainly won't have a decent maps app - maps are one of the most heavily monopolized core features of today's phones, mainly because of the sheer size of the task of mapping the world. OpenStreetMap exists, but it's honestly not very good. You start to see the problem. I used an Android fork for about a year without any Google services before I gave up. I was able to grab a few crucial apps from APKMirror, but not many. I tried using OsmAnd for maps; it was awful. I once bought a pair of headphones I literally couldn't use without the app - available only on the App Store and Play Store. I used web apps to fill in some of the gaps; they were spotty and many were ugly and/or slow and/or didn't hook into APIs like push notifications. At least I had a fully up-to-date Chrome fork to use as my browser. Maybe after the death of Android there would be greater momentum behind building and sustaining this kind of ecosystem. That would help bolster not only app development, but possibly even the value of the open web, and maybe even the contributions to (and therefore quality of) things like OpenStreetMap. It's hard to say.
- _bxg1 8y ago
  For those curious, what I ended up doing was switching to an iPhone. I decided that my boycott of Google was mainly about privacy, not openness, and I resigned to the fact that I'd rather be able to fully function within our digital society than have openness in my phone (I still use Linux on my desktop). I've been happy with my decision; but for what it's worth I'd still try out a mature, truly open mobile OS if one ever surfaced.
- 0815test 8y ago
  > Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem The "app ecosystem" on a free mobile OS would be shared with the "ecosystem" of free PC apps. Chromium does target, e.g. Debian GNU/Linux, as do quite a few proprietary apps relying on Flatpack. There's no reason why we shouldn't be able to piggiback on this work for the mobile platform. Yes, UI is different, but not that different. Modern Linux apps already come with a touch-friendly UI, for example.
  - _bxg1 8y ago
    Assuming the free mobile OS was Linux-based. And if it's going to be, I don't see why one wouldn't just start with an Android OSP fork. Even if Google stopped maintaining the latter, it's a huge head start compared to the alternative. That said, because of the way Google APIs have extended their tentacles into non-Google Android apps, many of them cease to function without Google Services installed. So you'd still have most of the app ecosystem problem.
    - 0815test 8y ago
      AOSP is way too fragmented. An "app" dating back to, e.g. Android 2.3 (not that long ago), or even as late as Android 4.0 will not even build in a form suitable for a present-day version of AOSP - you have to go and rewrite the code yourself, there is no backward compatibility that reaches that far. Linux platforms are truly mature and can easily run code dating back to the 1980s. Add to that the pointless overhead caused by Dalvik/ART (especially wrt. RAM use - quite critical on a system with no swap space whatsoever!), and the gratuitous differences with widespread Linux kernel and userspace standards. Starting from scratch on a better base is short-term pain for long-term gain.
morpheuskafka 8y ago
Almost all hardware is NDA. Even the Raspberry Pi has a lot of it's mobile-oriented chips like the VC GPU under a lot of NDA restrictions and binary blobs. There's basically Qualcomm, Samsung, and Huawei as the only companies making cellular modems and basebands, nearly all of which is closed source.

by _bxg1 8y ago

_bxg1 8y ago

Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem, which is even more important today (and especially on mobile) than it used to be in the PC era. You could get some mileage out of the web- but first you'd have to build or port a browser. Chromium certainly won't target your open OS, and with its 75% market share, it now strongarms the direction that web standards take. And many app makers don't even have mobile web apps these days (or their web apps are crippled versions of their "real apps"). Good luck getting Slack and Favor, or your bank, to build apps for your new OS. Or even Dropbox and Evernote. Forget about Netflix and YouTube. Maybe you're okay with going back to the iPhone 1.0 days where a smartphone was just for phone calls, texting, email, a calendar, listening to music, looking up directions, and searching the web. But while you might get an mp3 player app, many people no longer own copies of their music and you won't get Pandora or Spotify. You certainly won't have a decent maps app - maps are one of the most heavily monopolized core features of today's phones, mainly because of the sheer size of the task of mapping the world. OpenStreetMap exists, but it's honestly not very good. You start to see the problem. I used an Android fork for about a year without any Google services before I gave up. I was able to grab a few crucial apps from APKMirror, but not many. I tried using OsmAnd for maps; it was awful. I once bought a pair of headphones I literally couldn't use without the app - available only on the App Store and Play Store. I used web apps to fill in some of the gaps; they were spotty and many were ugly and/or slow and/or didn't hook into APIs like push notifications. At least I had a fully up-to-date Chrome fork to use as my browser. Maybe after the death of Android there would be greater momentum behind building and sustaining this kind of ecosystem. That would help bolster not only app development, but possibly even the value of the open web, and maybe even the contributions to (and therefore quality of) things like OpenStreetMap. It's hard to say.

_bxg1 8y ago
For those curious, what I ended up doing was switching to an iPhone. I decided that my boycott of Google was mainly about privacy, not openness, and I resigned to the fact that I'd rather be able to fully function within our digital society than have openness in my phone (I still use Linux on my desktop). I've been happy with my decision; but for what it's worth I'd still try out a mature, truly open mobile OS if one ever surfaced.
0815test 8y ago
> Also, perhaps even more importantly, you'd be starting from scratch in terms of app ecosystem The "app ecosystem" on a free mobile OS would be shared with the "ecosystem" of free PC apps. Chromium does target, e.g. Debian GNU/Linux, as do quite a few proprietary apps relying on Flatpack. There's no reason why we shouldn't be able to piggiback on this work for the mobile platform. Yes, UI is different, but not that different. Modern Linux apps already come with a touch-friendly UI, for example.
- _bxg1 8y ago
  Assuming the free mobile OS was Linux-based. And if it's going to be, I don't see why one wouldn't just start with an Android OSP fork. Even if Google stopped maintaining the latter, it's a huge head start compared to the alternative. That said, because of the way Google APIs have extended their tentacles into non-Google Android apps, many of them cease to function without Google Services installed. So you'd still have most of the app ecosystem problem.
  - 0815test 8y ago
    AOSP is way too fragmented. An "app" dating back to, e.g. Android 2.3 (not that long ago), or even as late as Android 4.0 will not even build in a form suitable for a present-day version of AOSP - you have to go and rewrite the code yourself, there is no backward compatibility that reaches that far. Linux platforms are truly mature and can easily run code dating back to the 1980s. Add to that the pointless overhead caused by Dalvik/ART (especially wrt. RAM use - quite critical on a system with no swap space whatsoever!), and the gratuitous differences with widespread Linux kernel and userspace standards. Starting from scratch on a better base is short-term pain for long-term gain.

morpheuskafka 8y ago

Almost all hardware is NDA. Even the Raspberry Pi has a lot of it's mobile-oriented chips like the VC GPU under a lot of NDA restrictions and binary blobs. There's basically Qualcomm, Samsung, and Huawei as the only companies making cellular modems and basebands, nearly all of which is closed source.