101–110 of 121 posts
Earlier quoted context omitted.
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…
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…
Smartphones are far, far more about communication and collaboration than passive content consumption. 'Functioning' in our digital society isn't about everyone individually watching the same movies on a 5" screen on the bus. Most people use their phones as a glossier smartphone with navigation capability and that's just fine.
Earlier quoted context omitted.
Google has already made Android apps run on Chrome OS, and I think are at least planning to do with Fuchsia. Which is to say, Google could kill the Android OS as long as they preserve the Android app platform. See also: Windows has actually replaced their Win32 app model with UWP which is nearly a whole different app platform, but they still support Win32 apps and have made it increasingly easier to deploy Win32 apps…
> Windows has actually replaced their Win32 app model with UWP This is wishful thinking on Microsoft's part. > they still support Win32 apps Because it is despite their best efforts more popular and more important. So it cannot be said that they "replaced" it.
Earlier quoted context omitted.
A big difference is that development of Android is done behind closed doors, whereas for Linux you can observe what is happening in public (discussions on the mailing lists for example). This means that it's essentially impossible to follow or contribute to Android development in a meaningful way. This is also reflected in the fact that there are open issues in Android with almost no reaction from any developer for y…
"it would be a simple thing to fork the thing and ditch the corporate version" ^ This is what I was speaking to. This holds for Android.
Furthermore, android really wasn't built to be easy for individuals to work on. Compare compiling and modifying Linux to compiling and modifying android. I've done the first but I don't think I've ever even finished downloading the source (tens to hundreds of gigabytes) to even start with the second.
Earlier quoted context omitted.
"it would be a simple thing to fork the thing and ditch the corporate version" ^ This is what I was speaking to. This holds for Android.
A large portion of the components needed to boot (not to mention use) android have always been closed. This is absolutely not the case for Linux. You can boot a totally free kernel on most PCs and don't really even need much userspace (busybox and whatever app you want to run (provided it doesn't need X11) is usually enough) Furthermore, android really wasn't built to be easy for individuals to work on. Compare compi…
Earlier quoted context omitted.
A large portion of the components needed to boot (not to mention use) android have always been closed. This is absolutely not the case for Linux. You can boot a totally free kernel on most PCs and don't really even need much userspace (busybox and whatever app you want to run (provided it doesn't need X11) is usually enough) Furthermore, android really wasn't built to be easy for individuals to work on. Compare compi…
Those components are presumably hardware drivers, right? In which case they're kept closed-source by the OEMs, and in which case you'd face the same problem whether you're putting Android on top of them or not. The solution in either case is to develop open source drivers. This is true regardless of whether you start with Android or go back to the Linux kernel and start over.
Earlier quoted context omitted.
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…
So your complaints are that you couldn't use your preferred commercial services on an open platform. But if you zoom out to Smartphone Global Scale, the vast majority of people don't use those services anyhow. Netflix has 155 million total subscribers globally, which means it doesn't have about 3,745 million other Internet users. Smartphones are far, far more about communication and collaboration than passive content…
You use Netflix as a stand-in for all "commercial services". The majority of smartphone users in the world may not have Netflix on their phones, but the majority of Americans - the largest market by value - do. And more importantly, I guarantee you that the vast majority of smartphone users worldwide regularly use Facebook and/or WhatsApp. Those are commercial services. I personally have trouble staying in the loop at work without Slack on my phone. That's a commercial service. Plenty of mobile, commercial services are truly essential to modern life. Singling out Netflix is a straw-man.
Earlier quoted context omitted.
Those components are presumably hardware drivers, right? In which case they're kept closed-source by the OEMs, and in which case you'd face the same problem whether you're putting Android on top of them or not. The solution in either case is to develop open source drivers. This is true regardless of whether you start with Android or go back to the Linux kernel and start over.
On modern Linux the drivers are part of the kernel which puts them under the GPL, legally obligating the release of their source code. On android the graphics drivers are part of userspace which lets the authors get around this.
As a tech community, we should really rally around a libre/free mobile OS and soon. Being beholden to corporations for our operating systems is antithetical to freedom.
Earlier quoted context omitted.
> Windows has actually replaced their Win32 app model with UWP This is wishful thinking on Microsoft's part. > they still support Win32 apps Because it is despite their best efforts more popular and more important. So it cannot be said that they "replaced" it.
The main hold up to new development being UWP is the lack of compatibility with Windows 7, which is going out of support in January. Enterprises will most all have switched by then, and it will be considered pretty safe to develop ew software with UWP over legacy APIs.
1. The large body of win32 code already written, maybe exceeds the quantity of future UWP apps.
2. The quality gap between what you can write with new and old stuff.
Maybe they have closed 2, I stopped paying attention a few years ago. But last I knew there was a bit of a chicken-egg problem where nothing substantial was being written with the new thing, thus no means for it to be validated and improve.
Also there is the general problem that 21st century Microsoft cannot compete with Windows NT. Can a new UI framework from Microsoft ever outdo the old stuff? Debatable. There have been several attempts.