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.
> 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.
> 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.
High-standards imposed by distros (see for example: https://www.debian.org/doc/debian-policy/) and tedious work of packagers has been a very important part of the free software ecosystem, and kept GNU/Linux snoopware-, malware- and virus-free and trustable [1]. They are far from "unneeded middleman".
Here's a very recent example of this system at work: Chromium sneaks a binary blob which secretly listens to your microphone and sends data to Google: https://lwn.net/Articles/648392/
This is just one instance, there has been many many examples of this.
There are just so many, let me say, shady, "apps" out there, so I don't install anything from Google Play Store on my smartphone. On my desktop/laptop however, I feel safe installing whatever I need from the official repositories.
I personally don't want to use a distro to which "app" developers from Android ecosystem can freely push their programs (and updates to them).
> Applications being files/folders that can be installed/uninstalled with cp/rm seems way more unixy to me.
But that's essentially what a package manager does for you, although it takes away your freedom to screw up in the process. In GNU/Linux, it essentially 1) protects you from screwing up your system accidentally 2) allows you trust system-wide binaries (assuming that your distro is trustable).
App Stores are also package managers, so I'm not sure what you're trying to point out here.
====
[1] I'm excluding Ubuntu here. Ubuntu comes with spyware, spies on you by default and monetizes the privacy and trust of its users [2]. I don't trust it, I don't use it, and I recommend against it.
Downside is that you are limited to what software your distro has vetted and provides. With a strong and trusted app sandbox, I can more easily trust less-vetted software, because I can see what it can do before running it.
E.g. if it can only do file accesses outside of it's own settings folder after prompting me, I know that it has way less abilities to screw up my system.
I don't think that can replace a package manager for "complex" or "infrastructure" software, but for other things it could open the selection up. Many people already run sandboxed applications, in sandboxes called "Firefox" or "Chrome".
In some cases the version on F-Droid has been modified to remove the questionable functionality (tracking, ads, etc). So it's possible the google play version has that stuff even though the app is also available on F-Droid.
> Here's a very recent example of this system at work: Chromium sneaks a binary blob which secretly listens to your microphone and sends data to Google: https://lwn.net/Articles/648392/
Downloading a binary blob in the first place was the real issue. However, the voice recognition module wasn't actually used unless you opted into the "Ok Google" hotword feature.
Getting back on topic, Android handles similar problems in a different way, via the permission system (esp. the improvements in Android 6.0+).
> However, the voice recognition module wasn't actually used unless you opted into the "Ok Google" hotword feature.
So says someone, but you don't know what else the binary blob (which can be "updated" at the will of Google, without asking anything to the user) does for sure, do you? If you're content with that explanation, you're essentially taking their word for it with blind trust. For example, will it push a new binary and/or suddenly start listening to you or send certain files from your computer if someone three-letter government agency tells Google to do so? Would you bet your life on it?
Trust in software may not be that serious for you, but there are people out there whose lives depend on it.
The issue here is twofold, and in terms of security, it being a binary blob is the lesser one: 1) this is a binary blob which hasn't been vetted by the eyeballs of FOSS world 2) Google circumvents the package manager (along with package reviewers and FOSS community) and secretly and freely installs (and updates) a binary blob on your system, which is essentially a closed-source backdoor singularly controlled by a US company.
A program that silently pushes programs on users' systems (and silently executes them!) at the pleasure of a company never had any place in Debian or any distro with similar principles. It wouldn't matter if they pushed the source code and compiled it on your system (in fact, some rootkits work just like that).
> Getting back on topic, Android handles similar problems in a different way, via the permission system (esp. the improvements in Android 6.0+).
You're talking about a totally different problem/class of permissions here though (accessing network/video/audio/filesystem etc vs ability to install packages as a non-root user).
Oh please. If google wanted to record from Chrome users, they could do it easily. If you actually trust packagers to know what Chrome is doing, you're crazy.
I trust the package managers to build software in a way that I can be sure matches with the published source package. That's the important difference. Projects bundle blobs into their binaries that aren't in the source code all the time (cf. chromium as discussed, but firefox did (does?) this too).
Of course you could say in a large codebase like chromium, bad things can be hidden. But at least there's a better chance such things are found, and it's more risky to put it there in plain sight.
In a perfect world, all software would have reproducible builds and there would be no issue with trusting that binaries contained no hidden functionality not in the source, as there'd be third parties to rebuild and compare the result against the published binaries. We're a ways away from that.
You can't use it to deny specific permissions, only groups of them. If an all wants to write something your contacts, you also have to allow it to read them. This even though the core permissions system allows that level of granularity.
also, network access is deemed safe (by Google) and is thus in a group of permissions the user has no control over.
> 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...
It sounds like you'd enjoy Slackware's approach to package management. Zero dependency resolution, packages are built from the source tarball with little or no patching (unless you patch it yourself), and the files are installed where the author intended them to be (though that can be good or bad depending on your perspective). If the application has dependencies, you're left to install them yourself, ensuring that only the absolutely necessary dependencies are installed, and not, for example, all of Gnome when you just want a simple text editor.
> ...and running scripts as root when installing/uninstalling packages.
Given that this happens even when you build from source and install yourself (./config, make, sudo make install), I'm not sure what you're asking for. Perhaps the Mac OS X method of "the app is a folder with pre-built binaries and all necessary libraries"? And even some OS X apps require elevation to install, especially those distributed as .pkg files.
The parent is advocating for the Slackware approach—just take whatever's in the upstreams and slam it together—but installed into a container (so all that slamming doesn't conflict with anything), and distributed as a container image. This is effectively the 'modern Linux app philosophy', as supported by systemd et al. It's similar in concept to app bundles, but it also assumes automatic sandboxing.
It's great for games in particular, given that you'll be able to boot up a 10-year-old game container-image as if it were new. (In that way, it's like game emulation, but without the performance drawbacks.) Most other "app" software gets lesser-but-still-significant benefits, in much the same way you see on e.g. the Mac App Store with their self-sandboxing apps.
There's little advantage in distributing system software this way, given that system software is usually full of low-level extension-points that other system software plugs into to achieve the purpose. And this is what can make a platform abstraction layer like Android make sense. With a platform, the system software is all composed together by the platform maker into an underlayer, and a single, clean API is specified atop it. Above the platform abstraction, there doesn't need to be any exposed runtime model for system software—since it's all been encapsulated into the black box of the underlayer. The platform only needs to specify a model for developing+running+distributing app software.
Sometimes things straddle the boundary, though. There are numerous cases of software that has "failed out" of the Mac App Store after a while, because the software is fundamentally a system-software/app-software hybrid, and sandboxing the system-software aspects just didn't work.
> The parent is advocating for the Slackware approach—just take whatever's in the upstreams and slam it together—but installed into a container (so all that slamming doesn't conflict with anything), and distributed as a container image.
Have you heard of Nix and NixOS? It doesn't use containers for this, but each package's tree is kept isolated from the others'.
Nix is probably the optimal package manager, but it still is a package manager, and so still encodes particular ontological choices that get made differently by different distros at different times.
In other words: I don't just want my game from ten years ago to run; I want my game from ten years ago that was built for a RHEL-alike to run on the Debian-alike I've got today (or maybe even using FreeBSD's Linux-binary support.) Nix can't give me that, except by just being the particular tool that ends up putting together the packages that go into a container-image.
Nix can be used to exactly re-instantiate the same set of files ten years later, presuming the original Nix repo you found the software on was still alive ten years later. In that way, it is similar to creating a container-image. But for this use-case, it doesn't give you anything that the container-image doesn't, while the container-image does give you an assurance that a stable (sandbox-based) interaction model was defined at the time of the image's creation, which can still be used today.
Something that intersected the Nix package-management model with the Mac App Store "only self-sandboxed apps will be accepted" model would be strictly equivalent to containers, though.
GNU Stow gives shell users a great way to build contained applications that can be patched into the traditional filesystem through symlinks, avoiding the uncontrollable spew of files everywhere.
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.
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.
I'm not sure exactly what you're referring to; the -soname ld option is used to set the value internally to a library that that library is known as when building a library, and is used as part of ld.so at runtime to find the appropriate .so file to run-time dynamically link against.
The issue I described is during build time of a program that uses a shared library. Given this list of available libraries:
lrwxrwxrwx 21 Apr 20 2011 libevent.so.2 -> libevent.so.2.1.3
-rwxr-xr-x 106656 Aug 20 2010 libevent.so.2.1.3
lrwxrwxrwx 21 Jun 3 2012 libevent.so.5 -> libevent.so.5.1.3
-rwxr-xr-x 277760 Jun 3 2012 libevent.so.5.1.3
lrwxrwxrwx 21 Jun 3 2012 libevent.so -> libevent.so.5.1.3
there is no way to use the -levent option to gcc or ld to specify you want to link against libevent.so.2. If you just give it -levent, it will always link against libevent.so, which as these symlinks show, is pointing to libevent.so.5.1.3 (which is actually libevent-2.0) — this is documented in the ld man page under the -l option as for how "namespec" is resolved. Unfortunately, the APIs are different between 1.4 and 2.0, which is why this is necessary: not everyone who uses libevent has updated their code to use the new libevent API, yet we still want to use that software.
The "fix" is to move some kind of "logical" version number into the filename (although, which is "logical" and which is "physical" becomes ambiguous), like so:
$ ll libevent[-.]*
lrwxrwxrwx 21 Apr 20 2011 libevent-1.4.so.2 -> libevent-1.4.so.2.1.3
-rwxr-xr-x 106656 Aug 20 2010 libevent-1.4.so.2.1.3
lrwxrwxrwx 21 Jun 3 2012 libevent-2.0.so.5 -> libevent-2.0.so.5.1.3
-rwxr-xr-x 277760 Jun 3 2012 libevent-2.0.so.5.1.3
lrwxrwxrwx 21 Jun 3 2012 libevent.so -> libevent-2.0.so.5.1.3
so you can obtain a linkage against 2.1.3 by specifying -levent-1.4. This "encourages" one to use the 2.0 API by using libevent-2.0 if you specify a bare -levent. The -devel package with the header files will usually be for the latest version anyway, complicating the build process on a single machine with both libraries available (you'd have to build against a local/non-system-include-tree copy of 1.4's headers). I know some redhat/centos packages do do this (which is why I have both libevent-1.4 and libevent-2.0 on my system, but I don't know how those packages' specifically do this.
The other way around this is to explicitly link against the full path /usr/lib64/libevent.so.2.1.3 and not use the -l option at all for this library. This works in part because of the -soname option you pointed out. While this works, and produces the same output if one could use -l to select the correct library file, most of the build tools we have at our disposal prefer to use -l to select libraries at build time rather than full paths (because if you use -l to select a system installed library, ld does the work of searching its cache and standard paths for you; however, you can get around this with the :filename version of namespec to the -l option). This means that some programs' build processes would be different on systems that have only the old, only the new, or both libraries on the system, and a bunch of programs build processes might need to change once the new version comes out.
The problem here is that -l only lets you specify the name, not the version to link against, under the (arguably well-founded) assumption that old versions should not be used for new builds but you need to keep them around for already-built programs to link against (dynamically, at run time).
> The basic problem with most package managers is that they ignore the soname mechanism. ... This allows multiple versions of a lib to live side by side, while giving the binaries the version(s) they want.
I see you've qualified your statement with "most", so you're not in the wrong, but unless I'm mistaken both Nix[1] (and NixOS) and Guix[2] handle this problem well and do it in a way which scales infinitely.
> The basic problem with most package managers is that they ignore the soname mechanism.
Well, there's a million hobby project package managers, so I'm sure many of them fall in to that category. But the big ones, the ones used by the vast majority of linux users, don't have a problem with this (deb and rpm-based distros commonly version their libraries and install multiple versions side-by-side). This is a pain in the ass for the package maintainers as a lot of software developers don't think about versioning their API, but it's great for users.
Which package manager are you thinking of?
The dpkg ecosystem (i.e. Debian and Ubuntu etc.) definitely uses sonames. It is true that the soname version ends up in the package name, but this happens automatically, at build time, and it's only the binary package name that carries the soname, the source package remains unchanged.
You can install[] packages with libxyz.1.so and libxyz.2.so; you cannot install two -devel packages, because that package contains symlink libxyz.so to specific version.
Often, the system even installs such packages for you (they have compat in package filename, i.e. compat-libstdc++).
[] provided they don't contain additional files with assets, that conflict with each other. But this problem is not solved by gobo either.
I would sorely like both. The system level stuff should be package managed to create a coherent base system. For individual apps I would really like to use the latest version of e.g. Libreoffice without having to leave the comparative stability of a LTS distribution or adding a ppa. I would also like to run something like Skype or Dropbox in a sandbox.
I think many distribution* are evolving toward an even better compartmentalization with containers / VM, I just wish we'd work more toward than and indeed stop having to package apps for every distributions...
A large value of app sandboxes are easy but controlled ways to allow exceptions. E.g.: an app can ask the sandbox for file access, the sandbox then prompts the user to select a file and only that file is then exposed to the app.
Or even giving global access to functionality from a manifest file, without having to set up a restricted user/environment manually. (I wouldn't know without looking it up how to set up a linux user account that can't talk to the network. Or even better, only can talk to some part of the network.)
Reminds me of a friend of mine that when provided with a manual for how to do something "that's too complicated, please do it for me".
Meaning that "containers" just becomes a wrapper for things that can already be done, if one just learn to do it rather than pointing and drooling (as someone once referred to the GUI as).
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.
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?
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.
Gotcha, so very roughly speaking the same reason that people sometimes leave Debian for Ubuntu, because they hit the balance between ideological purity and convenience a bit better.
And even if after much begging you get a .apk from them, it often still won't work on a Google-free Android because it uses the damn Google API that requires the Google binaries that you don't want to soil your system with.
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.
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.
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.
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.
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?
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.
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.
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.
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)?
"DLL hell" doesn't have anything to do with the built-in GUI API calls. The part of the API that pertains to the GUI is built-in, standard, and has been since the 90's. I can take an application written today and run it on Windows XP-10 and it will work as long as I take care to not use any API calls that are specific to later versions of Windows (very few for most apps).
If you want to criticize the GUI aspect of Windows, you should target the lack of any standard modern GUI API calls that don't involve using Direct2D or GDI+ (by modern, I mean full support for transparency and anti-aliasing, among other things). The old API, plain GDI, was standard and well-understood, whereas the newer improvements are completely different types of layers built on top of GDI. That's the real mess.
Comparing X11 to Win32 is just laughable. X11 is ANCIENT. It also provides no widgets or anything other than windows and drawing primitives (which are ancient). You can't do anti-aliased fonts for example, you have to render then with freetype2 into a pixmap buffer and put that in your window. Practically every GUI toolkit does it that way - allocate window, do the drawing yourself, present final pixmap.
Win32 is more like Qt and if we could just fucking standardise Qt as THE API to target, everyone would be much happier. But of course then the Gnome devs won't be happy. The Linux desktop would be in a much better place if Gnome was dead.
Win32 is also ancient. It is the model of programming with handles and window message loops, that was inspired by MacOS (Classic) and that the OSX abandoned 15 years ago.
To consider you example with text, in Windows, you also have to use GDI+ or Uniscribe to have at least passable text (without shaping, that is). Or use DirectWrite, which is about as old as Pango.
Even OSX went through changes, AAT/OpenType wasn't available when QuickDraw GX was all the rage.
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.
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...
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.
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.
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.
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.
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.
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.
Will it be open source? "Free for licensing" isn't quite clear. Will anyone by able to license access to the source code for free? If yes, what about forking?
EDIT:
Okay, this isn't what I've hoped for:
>Disclaimer: Remix OS is only licensed to authorized business partners and pre-loaded on specific product models of those partners;it's not intended for personal use.
An .iso you can download gets you those without the 'corporate communications' problems you get when you have to fill out a form, use language like 'licencing' and then get the official IT department to install stuff.
> free to download, free to install, and free to use
Remix OS is based on Android and Android includes, among other things, the Linux Kernel, which is GPL, which is Copyleft, which would mean that the Remix OS creators would need to provide the source code to users, wouldn't it?
You can build closed and proprietary software on top of GPL software (for certain definitions of "on top of"), as long as any changes to the GPLed software are released as source, and LGPLed software is only linked to dynamically.
Example: If I wrote an alternative GUI system to replace X and the open window managers, I wouldn't necessarily be forced to open-source that system.
Real-world example: My employer uses Linux in some of its products, integrated with our proprietary software in license-compliant ways (and we've got a legal office that verifies that we're following the licenses for all the software that we use, to avoid legal trouble).
They do have that right. Sometimes the legal office gets requests designed to check our GPL compliance. Every release, we file information on the distributions we use, their versions, which libraries we link to, which compiler versions we use, build instructions for any components that we did a custom compilation of, etc. The CYA paperwork is pretty extensive.
Only if you've modified it. If not, then it's upstream's responsibility to distribute source. And even if you've modified it, I think distributing patchsets is enough, no?
If you distributed binaries made from GPL code to me, you're obliged to provide the source code if I ask you. You can do that by pointing me to an upstream url fine, but you need to be sure that that url will be valid when I ask you.
Even beyond that, we need to be able to prove that the binaries we're distributing were made from the source that we claim they are, and be able to provide exact instructions for a customer to independently re-create the binaries. That usually means that we stick to versions of libraries and compilers that are on the GA installation disks for a system, with exceptions made for a few security-critical libraries like OpenSSL.
I think the potential for the Android desktop is huge, and can threaten Intel in a serious way. Look at the Amazon Fire TV equipped with a Mediatek 64 bit quad core A72 + A53 SoC. The same SoC is scheduled to be in Chromebooks shortly.
This tiny 4 inch by 1 inch box can play 4k at 30fps, provide super fast internet browsing, Facebook, Youtube, Office apps, video conferencing and play Android 3D titles well. And it costs 64 Pounds or 90 USD! It geekbenches 1600/3500 which is pretty respectable compared to an Intel i3 which retails for around $150 just for the CPU. Why spend anything more for grandma's, mum's or a just a general PC. It also has good support for Kodi so no need for expensive HTPCs.
So here is a 60 GBP device doing a of lot of thing a traditional basic PC or laptop does at a fraction of the price, power, noise and size! This is disruptive.
The only thing holding it back is the absence of proper desktop support in Android and the relatively closed nature especially GPU of the Arm ecosystem. Also the PC ecosystem is accustomed to a much more open hardware and software playing field, and the driver scenario for ARM and Google's control of Android itself can be problematic.
Android is currently completely touch oriented and even though you can attach a keyboard and mouse, as the recent Ars review highlights [1] there are quite a few rough edges.
Remix OS is a step in that direction but it appears some of the issues are serious enough that only Google can address. A better situation is ARM being more open, Linux is already well supported on ARM so if it opens up the drivers in good faith without the back and forth of licensor and licensee that open source developers deal with, desktop need not depend just on Android.
How on earth does this threaten Intel compared to running a normal Linux distro on any other arm machine?
I already have a raspberry pi2 B set up identically to my laptop and synced with syncthing and everything just works.
If I wanted to leave Intel today I could and nothing would change at all (no thanks to android)
I'd prefer Android on my Chromebook Pixel (assuming for a second that I didn't just install Arch Linux on it) instead of having Chrome OS. I'd take a working Skype + Browser over just a Browser. There aren't any webapps that I really use that don't have a comparable in quality or better app. Assuming multi-window works, this would actually just be ChromeOS++ for me.
They also get lost in the GUI in my experience. Too many things that are clickable or possibly clickable, too much information on the page and they get overwhelmed.
With CLI, you do have to remember commands and compose things, but somehow it is easier for them. I am actually always surprised by this. More people should try to teach their older relatives some CLI magic.
Ironically, if this was available on the Google Pixel C it'd be a compelling option. (The Pixel C runs Android 6 with no multi-window/multi-app on-screen capability, which somewhat defeats the object of having such a device -- one that with a more comprehensive OS would be a potential Surface competitor. And indeed the Pixel C looks like it was originally designed for ChromeOS.)
Well I'm sceptical you can make a good desktop OS by modifying Android. Major desktop OSs (including their ecosystems!) have been developed for decades, there's a lot of depth in their functionality, flexibility, different use cases. Two of the main issues are that apps designed for Android touch devices suck on desktop and that the Android SDK is very limited compared to what deskop OSs offer. Don't get me wrong, I also think that current desktop OSs suck - it's just that Android-as-a-desktop is not the solution.
About the sdk point I completely agree. Unless you want somewhat shallow os
There is no way for Android sdk to compete with real world desktop os.
By shallow I mean something which don't have much functionality. This is not absolutely bad thing.yes most of powey users will not use that ,but for people who want to chat, browse, and use Skype this is not a bad this.but the point is these kind of users already leaving desktop after tablets/phone revolution.
It's exactly for those users. Android is easy to maintain and hard to fuck up for the regular user, which is what everyone does with any and all Windows PCs. And you can't just get a grandma to use Linux.
I'd rather see the web evolve even further and make "apps" irrelevant and have a desktop OS on my phone, that respect my privacy, rather than the other way around... And FOSS!
Yes something like termux might be a sufficient addition to "android". Note a standard GNU coreutils build is about 15M, though one can configure to use a multi-call binary like busybox, reducing the install size to about 1M. See the coreutils-single subpackage in Fedora rawhide for example: http://pkgs.fedoraproject.org/cgit/rpms/coreutils.git/commit...
When you 'apt install coreutils' in Termux you get coreutils installed as a multi-call binary to save space. 1556 kB for the package in total (including man pages).
The battery lasted about three hours with heavy use. Standby life was about one week as well. (I still use a perma-docked n800 with 64GB storage Canola to listen to rsync'ed audiobooks.)
I would seriously avoid using the browser, especially with Flash on that device at this point. Also I believe there's only a DoS CVE for SSH.
With the OTG USB, they're still a cheaper alternative to lots of Raspberry Pi projects.
Android used to use it own process-based virtual machine; Dalvik. This is not the case anymore. Now Android Runtime (ART) is used. Applications are compiled to native machine code upon installation. There is no virtual machine.
Yeah, that's what you need on a desktop. A OS designed for "touch" with "innovative features" (which features were standard on a desktop 25 years ago).
Years ago I installed a mouse driver for iOS on a jailbroken iPad 2 on iOS 6, it more or less worked for most applications that didn't require two finger gestures. I was able to paint with Brushes and such.
It wasn't a pleasant experience but I was just tinkering to see what it'd be like. If you like big huge icons, zooming when highlighting, and having to occasionally touch your screen, I suppose it was good.
I can't imagine its about being a viable desktop OS more than push the envelope of Android.
Why isn't anyone talking about how the hardware for their ultra tablet is literally the Surface 2? Did they get a bunch of unsold inventory or did they just have manufacturing rights to the design?
Yeah and sadly ms totally screwed up with rt when they had no available porting strategy for real applications to arm. And now rt is basically on life support and the rt devices have locked down bootloaders as far as I've heard which makes them kind of an even worse investment as far as buying a device goes.
Google could - and certainly has (even with the latest Pixel C) - do much worse than RemixOS for the desktop. If they can't come up with any other way to make Android look good on the desktop, it should at least acquire RemixOS and go from there.
I'm not a fan of the whole "Android apps inside Chrome OS" idea - it seems like a very roundabout and complex way to achieve what Android already can by itself - run over a million Android apps. However, if it does make an Android Wear-like Android for PCs, I do think Google should retain all control, so it can update Android for PCs just as easily as it can do with ChromeOS (or as Microsoft can do with Windows). Google should in no way repeat the update failure of Android on smartphones.
I would rather slowly move everything to ChromeOS and abandon android. I find it ridiculous that I am running an OS from Google with a broken mobile browser. I also find it more likely that the ChromeOS model could remain secure despite the contents of the play store than the Android "we aren't quite sure what we meant to do here" model.
I feel like this is what Android would be today if not for Sundar Pichai killing off Android's laptop project in order to protect Chrome OS. The janky methodology of having Chrome OS run some Android apps is silly, when this could've been Google's path.
Not any sort of name, but an article on Sundar specifically cited that it was one of his early moves after taking over Android. I can dig up the source if you want it, but there's not a lot of additional info there, unfortunately.
"And Pichai killed a project to develop a version of Android for touchscreen laptops—it overlapped with Chromebooks—shifting attention toward tablets and new categories such as smart TVs and wearable computers."
Thanks. The reasoning wasn't terribly sound. (Android and Chrome OS overlap regardless of the target hardware).
But from a branding perspective it makes sense to distance a immature product from a widely popular product. (Obviously that wasn't the idea though since Android Auto, Android TV, Android Wear)
I can also see why they wouldn't want to kill off Chrome OS since it allows them to experiment with a diverging set of strengths and features that Android might not be conducive toward. Those strengths could be leveraged in their other products especially Android.
The biggest problem, IMHO, is that Windows is now leading the charge for a converged OS. Ubuntu is talking it too. OS X and iOS are getting better interconnected in recent versions. Chrome OS's Android app port thing kinda indicates Google knows it's the future.
Soon it's going to be an expectation that your apps are available on someone's desktop and their phone. Google shot themselves in the foot here.
It seems like a good idea, but of course its not running the latest version of Android. Most of the problems with Android stem from security updates not reaching devices in a timely manner, and RemixOS is just another example of a skin that is behind. Most devices are only on RemixOS 1.5, which is Android 5.0.2.
It's basically a Raspberry Pi sized PC (in a case) that runs Remix OS.
Honestly, I rather like it though I have not used it a ton. I got the most use out of it when I was traveling for work a few months back, I took it with me to the hotel and hooked it to the TV and got my first real use out of it.
As for why I have not used it a ton, the HDMI out on it doesn't support my "Dumb cable" HDMI to DVI cable. So I have to hook it to a TV to use it, HDMI to HDMI, which is annoying at best. If I could hook it to a regular PC monitor on my desk I'd probably use it pretty regularly as a secondary machine.
Most of the apps I tried on it worked fine, Netflix, TuneIn Radio, Amazon Music, Hearthstone, Fallout Shelter. It hooks to your Google Play account so you get all the apps you already have purchased there.
Quite a large number of "regular PC monitors" these days ship with HDMI ports, as many desktop PCs have HDMI as well. You can usually find a decent monitor for about $99 with an HDMI port.
It looks like it's available to flash on some Nexus devices, and their own tablet is shipping within the next month or so: http://www.jide.com/en/remixos/devices
I have no idea how open it is to modification in practice, though. I might consider trying it if I can get a proper shell on it (similar to the Android shell you get in an emulator when using 'adb shell'), even if I cannot fork their DE code itself.
Looks like it's available on their custom hardware, but not as software only.
From the bottom of the page:
Disclaimer: Remix OS is only licensed to authorized business partners and pre-loaded on specific product models of those partners;it's not intended for personal use.
This is really cool. What is the target audience? I have been thinking of making a custom in car computer and this seems better than a linux distro for that purpose.
>Disclaimer: Remix OS is only licensed to authorized business partners and pre-loaded on specific product models of those partners;it's not intended for personal use.
If you want Android, one option you can look at is using an SBC like the Odroid C1+ or XU4 which can run Android and connect to an external screen. See [1] page 6.
The problem with Canonical is that it looks like they started working from the wrong end of the stick. So long as you make it to your pre-defined convergence point, what does it matter if you start with Ubuntu and try to evolve it towards mobile, or start with Android and work the other way? The difference is that if they'd taken the latter approach, they could've probably already reached it by now. Instead, they set themselves up to fight an uphill battle, alone, and get bogged down with a bunch of diversions wrt to Unity and Mir and systemd, which, in the grand scheme of things, should have only appeared as pit stops along the way. It's silly.
I'm surprised they didn't have a download reminder option - they must have noticed a traffic spike. There's not even a part that says "download is not yet available" which is annoying; perhaps they want people to search the site for the download though, maybe that's good for them somehow.
That's not how that GPL works. To be precise, although there might be a (very small) chance that a court has found or will find that software running in user space is a derived work of the kernel, that finding would not apply to Linux's user space because Linus declared (in the 1990s) that the conditions of Linux's license do not apply to user space.
Tivo was one of the first owners of proprietary software to test this area of the law: their devices ran Linux, but they never had to publish the source code for the software on their devices that ran in user space.
The distributors of RemixOS would have to publish the source code to any changes they make to the kernel itself, but someone else in the comments says they have made none.
I also enjoy the openness of Android and the fact that it works on a large variety of hardware.
In all seriousness though, if this works as well as their little launch video show it working, 2016 could REALLY be the year of desktop linux. 'This year / next year is the year of desktop linux!' is a long running joke, but this could really be it.
It will run on hardware other than Apple, for those who do not own an Apple computer. It will be "always on", similar to iOS. If you use Android on your phone, you will feel right at home.
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.