10 ms·

As a hardcore Linux user, I'm really torn about Android. On the one hand, it has created a nice software ecosystem by pushing a consistent set of APIs. Linux d

by nextos 11y ago

As a hardcore Linux user, I'm really torn about Android. On the one hand, it has created a nice software ecosystem by pushing a consistent set of APIs. Linux desktop applications were never remarkable except for a few ones. I think fragmentation into a myriad of frameworks led to this. The only 2 X11 applications I use are firefox and zathura. On the other hand, too much stuff has been redone in Android. It's too foreign. I would prefer less app-ification, less stores, more package management. And no mothership, no Google.

Someone1234 11y ago
I cannot help but wonder if "apps" aren't going to eventually replace package managers. That's certainly what Docker-like containers try to do. It might sound crazy when you consider some of the services typically installed with a package manager but ultimately there's no reason why an "app" cannot run in root, many root packages aren't actually installing drivers, they're only root for historical reasons (e.g. being able to read/write to /etc). Why, for example, couldn't a web server be an app? Or a DNS client? Or a DNS server? Sure, there are certain system services which cannot (anything installing drivers/filter drivers/core UI/sound subsystem/graphics subsystem) but MOST things can.
- nextos 11y ago
  I'm certain containers will end up replacing package managers. This idea is being pushed by the systemd guys. I think its a step backwards, as you loose tight control over dependencies. E.g., in case of a security issue, one cannot easily patch all containers if they are blackboxes. IMHO, the right tool for this is an improved package manager such as Nix or Guix (which incidentally also support containers in their own way). Perhaps the future should be a Nix-like package manager for dependency management, and container-ization for security and resource limits.
  - amazari 11y ago
    Well, at least xdg-app has the concept of "runtimes" shared among applications. If a lib/bin in a runtime has a security issued, the whole runtime might be updated. Transparently for the apps running over it. A runtime might be FreeDesktop-1, Gnome-3.14 for example. Lets say a 0day is discovered and patched in gtk 3.14, a new version of the Gnome-3.14 is issued and dl by the clients. Magically (with the help of overlayfs and co) all the apps depending on this specific runtime have a secure gtk.
  - digi_owl 11y ago
    That seems like yet another case of freedesktop/gnome/fedora finding another hammer and applying it to all the "nails". Containers fix a problem that unix has solved for decades. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname The problem is the package managers used by most distros getting hung up on there only being a single version number of each package name installed at any one time. Sort that out, like say how Gobolinux does it, and you do not need containers. But containers is all the rage on the web these days, so ipso facto is also must be all the rage for desktop Linux. Back before Gnome and Freedesktop, desktop Linux was a kernel up project. But more and more these days however it is a web down. Meaning that web people get interested in using the L in LAMP on their desktops, start looking into Gnome/KDE, then get involved in Freedesktop plumbing, and all the while bring their web-isms ("move fast and break stuff" being the most annoying) with them further down the stack.
    - oblio 11y ago
      Unix has solved for decades? Not really, if we look at the state of adoption of this solution. We supposedly discovered concrete 2 millennia ago but only adopted it widely 150 years ago. I wouldn't diss people who actually have a shot at fixing the problem, even though you might not like their solution.
      - digi_owl 11y ago
        Those that do not learn from history is destined to repeat it...
      - throwaway7767 11y ago
        Is there a problem with adoption of SONAMEs? I use debian all the time, and the major libraries are versioned, and some have more than one version available. Debian is a very common linux distro, and through it, a lot of child distros get it too. AFAIK, RedHat and Fedora do this too. So, do you mean that the state of adoption is bad for niche linux distros?
    - netheril96 11y ago
      How does `soname` solve the problems of privilege separation? Like letting the user forbids certain apps from making network connections?
  - jayd16 11y ago
    If we're in the app world with dependencies running as background services packaged in apps, you still keep all the control.
- icebraining 11y ago
  I'd say that's what Bitnami already is: an app store for servers. https://bitnami.com/ https://bitnami.com/ I've never actually used it, though, since Debian packages work fine for me.
- krakensden 11y ago
  I mean, I guess, but they tend to all be built out of packages assembled by a traditional package manager. Corralling and testing a bunch of things from a bunch of different sources and making sure they work together is hard. Plus, C library wrangling is becoming a bit of a lost art.
api 11y ago
Most Linux distros have a mothership in the form of the package repositories and the signing keys thereof. Doing without would require a more decentralized system that would be harder to engineer, unless you want to go back to the days when all software updates were piecemeal and manual. I would actually say that Linux distributions pioneered the app store concept via "yum install" and "apt-get" and such. Linux is certainly the first OS where I can remember seeing a centralized app repository you could pull from with a single command.
- nextos 11y ago
  Oh, I meant no deep embedding of Google services, like in Cyanogenmod.
- mkesper 11y ago
  But no information is sent out to Debian without my opt-in consent, in sharp contrast to Google, Microsoft, Apple and Ubuntu.
legulere 11y ago
> I would prefer less app-ification, more package management. I would argue for the opposite: One problem with linux is that you can't run untrusted software without it getting the same access as the user. That's exactly what the appification is. I see package managers as a source of some problems of linux: Package maintainers are a unneeded middleman between the writers of the software and you, package managers interact with the whole system, scattering files around the whole filesystem and running scripts as root when installing/uninstalling packages. Applications being files/folders that can be installed/uninstalled with cp/rm seems way more unixy to me.
- marssaxman 11y ago
  I've never liked the traditional unix way of managing a filesystem either; GoboLinux had the right idea.
  - digi_owl 11y ago
    Well for the most part because it uses what unix offers rather than ignoring it. The basic problem with most package managers is that they ignore the soname mechanism. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname This allows multiple versions of a lib to live side by side, while giving the binaries the version(s) they want. package managers ignore this, and instead is hung up on getting that one "true" version everywhere. This because their basic design only allow one version pr package name. Thus you can't have ABC 1.0 and 1.1 installed at the same time. Instead you have to mangle ABC into something like ABC1 to allow 1.1 to install without removing 1.0 in the process.
    - thwarted 11y ago
      I wouldn't strictly blame the package managers. Last I checked, it's not straight-forward to link against any library version other than what the versionless .so symlink points to (-llibname will always use liblibname.so). The lame workaround is to move a portion of the version into the basename, and that's where you get libname2.so, so you can explicitly ask for it with -llibname2). You can specify the path of the library file to link against, but this doesn't get you the same dynamic linking semantics (and you really want to let the linker search the cache for the exact file rather than having to specify the path yourself). It's actually pretty straight forward to build multiple packages with the same name and different versions that can be installed side-by-side: it's like a single line in an RPM spec file, as long as the files list doesn't conflict. A lot of the required effort is in building the software that uses the library. The library's header files are not often in versioned paths, so the -devel package for multiple versions has conflicts. It's easier to specify the option to configure that installs all the files with a version suffix and just be done with it. It is, unfortunately, not in the interest of the person doing the packaging to significantly diverge from how upstream suggests it be installed in their docs. That is, what should happen is entirely doable but, as part of the larger ecosystem of software and packaging and distributions, it's complicated and has little payoff.
dharma1 11y ago
Would be nice to be able to run Android apps in normal Linux distros
- recrof 11y ago
  you kinda can, via chrome android runtime.
  - dharma1 11y ago
    emphasis on the word "kinda"
voltagex_ 11y ago
Every year I go look where Maemo/Meego/Mer/Tizen (whatever it's been rebranded as) got up to. The N900 remains the greatest phone I ever owned. I had high hopes for Jolla but I doubt they're really out of their financial troubles - they owe me a very expensive tablet, currently. By the time it's delivered it will be obsolete.
- nextos 11y ago
  It's a shame they didn't opensource, IMHO failing to attract a share of Linux enthusiasts. They should have worked out a viable business model with an open Sailfish.
- stasm 11y ago
  I'd love to revive my N900. Do you have any recommendations about which OS to install on it these days?
- chc4 11y ago
  It certainly didn't help that their phones aren't authorized to be sold for the US. That's probably a very big segment of the pro-Linux poweruser demographic...
- pekk 11y ago
  Swordfish is great on a phone. The picture for Jolla looks different if you are not in the US speaking from an Android/iPhone centric point of view. There is really nobody else taking Linux on mobile this seriously.
  - h4waii 11y ago
    ... It's Sailfish.
BHSPitMonkey 11y ago
Android has been friendly toward removing the mothership since day one. Anyone can deliver APKs using either a homegrown app store (see Amazon's App Store app) or by just letting the user download APKs from the browser. The problem is that most app developers currently -only- distribute their app via Google Play, as it's the primary distribution channel that devices tend to come with. This isn't a complete lock-in, since you can still get those installed APKs from a device where they've been installed and archive them or reinstall them on other devices. (Refer to ApkMirror as an ethically dubious prime example of this) Still, this is nothing to hold against Android itself.
- _lce0 11y ago
  There's always fdroid! https://f-droid.org/ https://f-droid.org/
  - yohui 11y ago
    Are there any other good sources for open source Android apps? I love F-Droid, but they plan to drop Firefox, and Chromium will never make it on there.
    - wutbrodo 11y ago
      Do you know why they're planning to drop Firefox? And why would Chromium never make it on there? I don't know much about F-Droid and its limitations. EDIT: Okay I did the Google search that I should've just done in the first place. Apparently they're not dropping Firefox fully, but rather forking it to "remove the proprietary binaries out of the official builds" (Google Play API, etc). I suppose APIs like that are important enough to your use-case that you need an alternative source for Firefox?
      - yohui 11y ago
        F-Droid wants to drop Firefox because Google Play is now required to build it (though not to run it). Same reason why Chromium isn't being considered: https://f-droid.org/forums/topic/chromium/page/2/#post-16388 https://f-droid.org/forums/topic/chromium/page/2/#post-16388 F-Droid has (temporarily?) taken down their Fennec fork, seemingly due to difficulties with development: https://f-droid.org/forums/topic/please-do-not-drop-firefox-support/page/2/#post-18072 https://f-droid.org/forums/topic/please-do-not-drop-firefox-... This is presumably why Firefox's removal has been continuously postponed. Reliability is one of the reasons why I would prefer first-party Firefox over a third-party fork. Though there are good reasons why F-Droid doesn't include Chromium and seeks to remove Firefox, the absence of many open source Android apps from F-Droid's catalog has a direct impact on utility. It's also not uncommon for apps on F-Droid to lag behind the version on Google Play or the latest release direct from the developer. (Again, there are good reasons why they screen apps, but it does impose a delay.) I appreciate F-Droid's screening process, and I wouldn't want it to go away, but it'd be nice to have an alternative open source Android app catalog that's a little more liberal.
tagrun 11y ago
Why do you think having different APIs (qt, gtk mainly) had much to with the fact that a lot of people don't use Linux for desktop? If you're talking about binary compatibility, that's an issue for closed-source shops. With static linking, that isn't an issue that you can't workaround either actually (there are many closed-source programs for Linux such as thousands of Steam games). Distros will never put their binary blobs in the repositories, but companies still can (and do) publish .deb/.rpms (and third-party repos in some cases) for their programs. Binary compatibility is an issue nevertheless, of course. But it is an issue that FOSS distros consciously don't care about, mostly because binary blobs taint a FOSS environment and stand against the underlying philosophy of FOSS. It's not because Win32 is a superior API that games and big software titles are Windows only. For decades, people were force-fed Windows when they bought a computer, and they became a monopoly, much of it thanks to the deal they cut with IBM. It wasn't like people chose Windows. And Windows kept many big companies from making Mac/Linux ports with behind-the-door deals. And Android didn't end up dominating the desktop either. Smartphone-land is a totally different and distinct user base. And the fact that it dominated over iPhone doesn't have anything to do with the API either.
- pjmlp 11y ago
  Yes it does. For application developers there is a consistent set of APIs that are expected to exist in each version of Windows, Mac OS X, Android, iOS, Windows Phone... On GNU/Linux one needs to bundle the libraries with the application, preferably static linked. But no one is going to do with with GNOME or KDE applications, for example. Then there are the deviations each GNU/Linux distribution does from UNIX daemon management and paths. So application developers are forced to choose a set of gold distributions and let everyone else to figure out how the application might, compile and run on their own system.
  - tagrun 11y ago
    I thought we're talking about users here, not developers. Steam, Mathematica, Mendeley Desktop etc. have long proven that stable API for GUI toolkit doesn't have to be an issue for users. > For application developers there is a consistent set of APIs that are expected to exist in each version of Windows, Mac OS X, Android, iOS, Windows Phone... This problem you're referring to isn't something inherent in or specific to Linux. On Windows, the very same problem exists and is known as DLL hell. Android is another Linux distribution, and you're talking about Java programs running on top of a VM on top of it. Java programs work just fine on Linux too. I belive you're talking about Cocoa and Win32 API. On Unix, there is POSIX and X11 which go way back. And there are many GUI toolkits (including but not limited to Qt and wxWindows) that allow you to statically ship your program, with the added bonus of being cross-platform. API isn't an issue that can't be solved for developers either. > On GNU/Linux one needs to bundle the libraries with the application, preferably static linked. But no one is going to do with with GNOME or KDE applications, for example. Yes, they can and they do ship statically linked binaries. While they don't generally use Qt or GTK, both promise binary compatibility with a major version. They don't need to make it a GNOME or KDE apps to run it under X11. > Then there are the deviations each GNU/Linux distribution does from UNIX daemon management and paths. Can you be more specific about the problem you're referring to? Are you talking about a particular closed-source daemon program that uses something other than /etc/init.d or systemd (which has sysv init compatibility layer)?
threatofrain 11y ago
I did a quick Google but Zathura is a popular name. Do you mean Zathura the document viewer? Just asking because I've been looking for one.
- nextos 11y ago
  Yes, zathura the document viewer. It's a very minimal GUI with vim-like keybindings and it supports several PDF, DJVU, PS... backends
frik 11y ago
Isn't RemixOS required to release their source code? It's based on open source Android (incl GNU GPL parts) and yet doesn't publish the code. They shrug off such questions in their official forum.
- thecupisblue 11y ago
  A huge amount of OEMs in Android does this as well or release late. Let's not jump the gun on a company doing amazing things and give them some time to do it.
  - ris 11y ago
    I think it's unlikely that they intend to release the source as they talk about "Partnering for free!" for "licensing", so clearly want to retain some pretty tight rains on the code. "Profit sharing" is a term they throw around a bit too. Count me out.
- thecupisblue 11y ago
  A huge amount of OEMs in Android does this as well or release late. Let's not jump the gun on a company doing amazing things and give them some time to do it.
- masmullin 11y ago
  Android is mostly Apache licensed. Meaning OEMs don't have to publish their changes. http://source.android.com/source/licenses.html http://source.android.com/source/licenses.html
oneJob 11y ago
It has created a nice software ecosystem by being a good target for developers because of its (massive) user base. It has a massive user base because Google works hard to make it a good, user-friendly consumer product and they work hard to get manufacturers to get (many models of) handsets to market. It helps that the average person needs and can afford a phone, most of which are now smartphones. Linux never made the effort required to be a serious consumer grade product (well, Ubuntu gave it a good go). This is not so much a technical issue. Sure, the technicals need to be there, but when the average consumer goes looking for a computer, they don't start with the question, "How stable are the apis for this OS?" They do not know what an api is. And developers will not develop just because of stable apis. The Windows phone has not been a resounding success, but if ever there were a product that I, as a developer, would target due to expectations of stable apis, that would be it. Appification is why my dad uses the iPhone. He can do cool things by hitting squares with his finger, and then get on with the rest of his day which will likely include a lot of mentally draining tasks. It's the same thing that gravitated folks to Apple's first graphical operating system. The user friendliness. The approachability. Not the cutting edge object oriented software behind it. But the mouse and a picture of a garbage can. In that context, it's not foreign at all. I'm mean, the first time I saw the command line, that was foreign. But now it's not. But hitting a picture of an envelope to send mail, not so foreign.
smrtinsert 11y ago
Please kill package management. Android brilliantly bundled reusability within the app concept itself via Intents. It's safer, centrally managed, and way easier for the user. A new Android OS and your favorite software is installed in minutes compared to traditional desktop oses and their awful combination of command line and gui crap.
teekert 11y ago
Like Ubuntu Snappy Core?

by nextos 11y ago

Someone1234 11y ago

I cannot help but wonder if "apps" aren't going to eventually replace package managers. That's certainly what Docker-like containers try to do. It might sound crazy when you consider some of the services typically installed with a package manager but ultimately there's no reason why an "app" cannot run in root, many root packages aren't actually installing drivers, they're only root for historical reasons (e.g. being able to read/write to /etc). Why, for example, couldn't a web server be an app? Or a DNS client? Or a DNS server? Sure, there are certain system services which cannot (anything installing drivers/filter drivers/core UI/sound subsystem/graphics subsystem) but MOST things can.

nextos 11y ago
I'm certain containers will end up replacing package managers. This idea is being pushed by the systemd guys. I think its a step backwards, as you loose tight control over dependencies. E.g., in case of a security issue, one cannot easily patch all containers if they are blackboxes. IMHO, the right tool for this is an improved package manager such as Nix or Guix (which incidentally also support containers in their own way). Perhaps the future should be a Nix-like package manager for dependency management, and container-ization for security and resource limits.
- amazari 11y ago
  Well, at least xdg-app has the concept of "runtimes" shared among applications. If a lib/bin in a runtime has a security issued, the whole runtime might be updated. Transparently for the apps running over it. A runtime might be FreeDesktop-1, Gnome-3.14 for example. Lets say a 0day is discovered and patched in gtk 3.14, a new version of the Gnome-3.14 is issued and dl by the clients. Magically (with the help of overlayfs and co) all the apps depending on this specific runtime have a secure gtk.
- digi_owl 11y ago
  That seems like yet another case of freedesktop/gnome/fedora finding another hammer and applying it to all the "nails". Containers fix a problem that unix has solved for decades. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname The problem is the package managers used by most distros getting hung up on there only being a single version number of each package name installed at any one time. Sort that out, like say how Gobolinux does it, and you do not need containers. But containers is all the rage on the web these days, so ipso facto is also must be all the rage for desktop Linux. Back before Gnome and Freedesktop, desktop Linux was a kernel up project. But more and more these days however it is a web down. Meaning that web people get interested in using the L in LAMP on their desktops, start looking into Gnome/KDE, then get involved in Freedesktop plumbing, and all the while bring their web-isms ("move fast and break stuff" being the most annoying) with them further down the stack.
  - oblio 11y ago
    Unix has solved for decades? Not really, if we look at the state of adoption of this solution. We supposedly discovered concrete 2 millennia ago but only adopted it widely 150 years ago. I wouldn't diss people who actually have a shot at fixing the problem, even though you might not like their solution.
    - digi_owl 11y ago
      Those that do not learn from history is destined to repeat it...
    - throwaway7767 11y ago
      Is there a problem with adoption of SONAMEs? I use debian all the time, and the major libraries are versioned, and some have more than one version available. Debian is a very common linux distro, and through it, a lot of child distros get it too. AFAIK, RedHat and Fedora do this too. So, do you mean that the state of adoption is bad for niche linux distros?
  - netheril96 11y ago
    How does `soname` solve the problems of privilege separation? Like letting the user forbids certain apps from making network connections?
- jayd16 11y ago
  If we're in the app world with dependencies running as background services packaged in apps, you still keep all the control.
icebraining 11y ago
I'd say that's what Bitnami already is: an app store for servers. https://bitnami.com/ https://bitnami.com/ I've never actually used it, though, since Debian packages work fine for me.
krakensden 11y ago
I mean, I guess, but they tend to all be built out of packages assembled by a traditional package manager. Corralling and testing a bunch of things from a bunch of different sources and making sure they work together is hard. Plus, C library wrangling is becoming a bit of a lost art.

api 11y ago

Most Linux distros have a mothership in the form of the package repositories and the signing keys thereof. Doing without would require a more decentralized system that would be harder to engineer, unless you want to go back to the days when all software updates were piecemeal and manual. I would actually say that Linux distributions pioneered the app store concept via "yum install" and "apt-get" and such. Linux is certainly the first OS where I can remember seeing a centralized app repository you could pull from with a single command.

nextos 11y ago
Oh, I meant no deep embedding of Google services, like in Cyanogenmod.
mkesper 11y ago
But no information is sent out to Debian without my opt-in consent, in sharp contrast to Google, Microsoft, Apple and Ubuntu.

legulere 11y ago

> I would prefer less app-ification, more package management. I would argue for the opposite: One problem with linux is that you can't run untrusted software without it getting the same access as the user. That's exactly what the appification is. I see package managers as a source of some problems of linux: Package maintainers are a unneeded middleman between the writers of the software and you, package managers interact with the whole system, scattering files around the whole filesystem and running scripts as root when installing/uninstalling packages. Applications being files/folders that can be installed/uninstalled with cp/rm seems way more unixy to me.

marssaxman 11y ago
I've never liked the traditional unix way of managing a filesystem either; GoboLinux had the right idea.
- digi_owl 11y ago
  Well for the most part because it uses what unix offers rather than ignoring it. The basic problem with most package managers is that they ignore the soname mechanism. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname This allows multiple versions of a lib to live side by side, while giving the binaries the version(s) they want. package managers ignore this, and instead is hung up on getting that one "true" version everywhere. This because their basic design only allow one version pr package name. Thus you can't have ABC 1.0 and 1.1 installed at the same time. Instead you have to mangle ABC into something like ABC1 to allow 1.1 to install without removing 1.0 in the process.
  - thwarted 11y ago
    I wouldn't strictly blame the package managers. Last I checked, it's not straight-forward to link against any library version other than what the versionless .so symlink points to (-llibname will always use liblibname.so). The lame workaround is to move a portion of the version into the basename, and that's where you get libname2.so, so you can explicitly ask for it with -llibname2). You can specify the path of the library file to link against, but this doesn't get you the same dynamic linking semantics (and you really want to let the linker search the cache for the exact file rather than having to specify the path yourself). It's actually pretty straight forward to build multiple packages with the same name and different versions that can be installed side-by-side: it's like a single line in an RPM spec file, as long as the files list doesn't conflict. A lot of the required effort is in building the software that uses the library. The library's header files are not often in versioned paths, so the -devel package for multiple versions has conflicts. It's easier to specify the option to configure that installs all the files with a version suffix and just be done with it. It is, unfortunately, not in the interest of the person doing the packaging to significantly diverge from how upstream suggests it be installed in their docs. That is, what should happen is entirely doable but, as part of the larger ecosystem of software and packaging and distributions, it's complicated and has little payoff.

dharma1 11y ago

Would be nice to be able to run Android apps in normal Linux distros

recrof 11y ago
you kinda can, via chrome android runtime.
- dharma1 11y ago
  emphasis on the word "kinda"

voltagex_ 11y ago

Every year I go look where Maemo/Meego/Mer/Tizen (whatever it's been rebranded as) got up to. The N900 remains the greatest phone I ever owned. I had high hopes for Jolla but I doubt they're really out of their financial troubles - they owe me a very expensive tablet, currently. By the time it's delivered it will be obsolete.

nextos 11y ago
It's a shame they didn't opensource, IMHO failing to attract a share of Linux enthusiasts. They should have worked out a viable business model with an open Sailfish.
stasm 11y ago
I'd love to revive my N900. Do you have any recommendations about which OS to install on it these days?
chc4 11y ago
It certainly didn't help that their phones aren't authorized to be sold for the US. That's probably a very big segment of the pro-Linux poweruser demographic...
pekk 11y ago
Swordfish is great on a phone. The picture for Jolla looks different if you are not in the US speaking from an Android/iPhone centric point of view. There is really nobody else taking Linux on mobile this seriously.
- h4waii 11y ago
  ... It's Sailfish.

BHSPitMonkey 11y ago

Android has been friendly toward removing the mothership since day one. Anyone can deliver APKs using either a homegrown app store (see Amazon's App Store app) or by just letting the user download APKs from the browser. The problem is that most app developers currently -only- distribute their app via Google Play, as it's the primary distribution channel that devices tend to come with. This isn't a complete lock-in, since you can still get those installed APKs from a device where they've been installed and archive them or reinstall them on other devices. (Refer to ApkMirror as an ethically dubious prime example of this) Still, this is nothing to hold against Android itself.

_lce0 11y ago
There's always fdroid! https://f-droid.org/ https://f-droid.org/
- yohui 11y ago
  Are there any other good sources for open source Android apps? I love F-Droid, but they plan to drop Firefox, and Chromium will never make it on there.
  - wutbrodo 11y ago
    Do you know why they're planning to drop Firefox? And why would Chromium never make it on there? I don't know much about F-Droid and its limitations. EDIT: Okay I did the Google search that I should've just done in the first place. Apparently they're not dropping Firefox fully, but rather forking it to "remove the proprietary binaries out of the official builds" (Google Play API, etc). I suppose APIs like that are important enough to your use-case that you need an alternative source for Firefox?
    - yohui 11y ago
      F-Droid wants to drop Firefox because Google Play is now required to build it (though not to run it). Same reason why Chromium isn't being considered: https://f-droid.org/forums/topic/chromium/page/2/#post-16388 https://f-droid.org/forums/topic/chromium/page/2/#post-16388 F-Droid has (temporarily?) taken down their Fennec fork, seemingly due to difficulties with development: https://f-droid.org/forums/topic/please-do-not-drop-firefox-support/page/2/#post-18072 https://f-droid.org/forums/topic/please-do-not-drop-firefox-... This is presumably why Firefox's removal has been continuously postponed. Reliability is one of the reasons why I would prefer first-party Firefox over a third-party fork. Though there are good reasons why F-Droid doesn't include Chromium and seeks to remove Firefox, the absence of many open source Android apps from F-Droid's catalog has a direct impact on utility. It's also not uncommon for apps on F-Droid to lag behind the version on Google Play or the latest release direct from the developer. (Again, there are good reasons why they screen apps, but it does impose a delay.) I appreciate F-Droid's screening process, and I wouldn't want it to go away, but it'd be nice to have an alternative open source Android app catalog that's a little more liberal.

tagrun 11y ago

Why do you think having different APIs (qt, gtk mainly) had much to with the fact that a lot of people don't use Linux for desktop? If you're talking about binary compatibility, that's an issue for closed-source shops. With static linking, that isn't an issue that you can't workaround either actually (there are many closed-source programs for Linux such as thousands of Steam games). Distros will never put their binary blobs in the repositories, but companies still can (and do) publish .deb/.rpms (and third-party repos in some cases) for their programs. Binary compatibility is an issue nevertheless, of course. But it is an issue that FOSS distros consciously don't care about, mostly because binary blobs taint a FOSS environment and stand against the underlying philosophy of FOSS. It's not because Win32 is a superior API that games and big software titles are Windows only. For decades, people were force-fed Windows when they bought a computer, and they became a monopoly, much of it thanks to the deal they cut with IBM. It wasn't like people chose Windows. And Windows kept many big companies from making Mac/Linux ports with behind-the-door deals. And Android didn't end up dominating the desktop either. Smartphone-land is a totally different and distinct user base. And the fact that it dominated over iPhone doesn't have anything to do with the API either.

pjmlp 11y ago
Yes it does. For application developers there is a consistent set of APIs that are expected to exist in each version of Windows, Mac OS X, Android, iOS, Windows Phone... On GNU/Linux one needs to bundle the libraries with the application, preferably static linked. But no one is going to do with with GNOME or KDE applications, for example. Then there are the deviations each GNU/Linux distribution does from UNIX daemon management and paths. So application developers are forced to choose a set of gold distributions and let everyone else to figure out how the application might, compile and run on their own system.
- tagrun 11y ago
  I thought we're talking about users here, not developers. Steam, Mathematica, Mendeley Desktop etc. have long proven that stable API for GUI toolkit doesn't have to be an issue for users. > For application developers there is a consistent set of APIs that are expected to exist in each version of Windows, Mac OS X, Android, iOS, Windows Phone... This problem you're referring to isn't something inherent in or specific to Linux. On Windows, the very same problem exists and is known as DLL hell. Android is another Linux distribution, and you're talking about Java programs running on top of a VM on top of it. Java programs work just fine on Linux too. I belive you're talking about Cocoa and Win32 API. On Unix, there is POSIX and X11 which go way back. And there are many GUI toolkits (including but not limited to Qt and wxWindows) that allow you to statically ship your program, with the added bonus of being cross-platform. API isn't an issue that can't be solved for developers either. > On GNU/Linux one needs to bundle the libraries with the application, preferably static linked. But no one is going to do with with GNOME or KDE applications, for example. Yes, they can and they do ship statically linked binaries. While they don't generally use Qt or GTK, both promise binary compatibility with a major version. They don't need to make it a GNOME or KDE apps to run it under X11. > Then there are the deviations each GNU/Linux distribution does from UNIX daemon management and paths. Can you be more specific about the problem you're referring to? Are you talking about a particular closed-source daemon program that uses something other than /etc/init.d or systemd (which has sysv init compatibility layer)?

threatofrain 11y ago

I did a quick Google but Zathura is a popular name. Do you mean Zathura the document viewer? Just asking because I've been looking for one.

nextos 11y ago
Yes, zathura the document viewer. It's a very minimal GUI with vim-like keybindings and it supports several PDF, DJVU, PS... backends

frik 11y ago

Isn't RemixOS required to release their source code? It's based on open source Android (incl GNU GPL parts) and yet doesn't publish the code. They shrug off such questions in their official forum.

thecupisblue 11y ago
A huge amount of OEMs in Android does this as well or release late. Let's not jump the gun on a company doing amazing things and give them some time to do it.
- ris 11y ago
  I think it's unlikely that they intend to release the source as they talk about "Partnering for free!" for "licensing", so clearly want to retain some pretty tight rains on the code. "Profit sharing" is a term they throw around a bit too. Count me out.
thecupisblue 11y ago
A huge amount of OEMs in Android does this as well or release late. Let's not jump the gun on a company doing amazing things and give them some time to do it.
masmullin 11y ago
Android is mostly Apache licensed. Meaning OEMs don't have to publish their changes. http://source.android.com/source/licenses.html http://source.android.com/source/licenses.html

oneJob 11y ago

It has created a nice software ecosystem by being a good target for developers because of its (massive) user base. It has a massive user base because Google works hard to make it a good, user-friendly consumer product and they work hard to get manufacturers to get (many models of) handsets to market. It helps that the average person needs and can afford a phone, most of which are now smartphones. Linux never made the effort required to be a serious consumer grade product (well, Ubuntu gave it a good go). This is not so much a technical issue. Sure, the technicals need to be there, but when the average consumer goes looking for a computer, they don't start with the question, "How stable are the apis for this OS?" They do not know what an api is. And developers will not develop just because of stable apis. The Windows phone has not been a resounding success, but if ever there were a product that I, as a developer, would target due to expectations of stable apis, that would be it. Appification is why my dad uses the iPhone. He can do cool things by hitting squares with his finger, and then get on with the rest of his day which will likely include a lot of mentally draining tasks. It's the same thing that gravitated folks to Apple's first graphical operating system. The user friendliness. The approachability. Not the cutting edge object oriented software behind it. But the mouse and a picture of a garbage can. In that context, it's not foreign at all. I'm mean, the first time I saw the command line, that was foreign. But now it's not. But hitting a picture of an envelope to send mail, not so foreign.

smrtinsert 11y ago

Please kill package management. Android brilliantly bundled reusability within the app concept itself via Intents. It's safer, centrally managed, and way easier for the user. A new Android OS and your favorite software is installed in minutes compared to traditional desktop oses and their awful combination of command line and gui crap.

teekert 11y ago

Like Ubuntu Snappy Core?