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 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.
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.
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".
Lately I've found myself checking if something is available on F-droid before installing from Google Play. Sometimes it is!
If something is on F-droid, I'm less worried about it being scammy spyware disguised as useful software.
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+).
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.
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 basic problem with most package managers is that they ignore the soname mechanism.
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.
* QubesOS, SubgraphOS, NixOS(?), etc.
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.)
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.
I love F-Droid, but they plan to drop Firefox, and Chromium will never make it on there.
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.
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 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.
Containers fix a problem that unix has solved for decades.
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.
I've never actually used it, though, since Debian packages work fine for me.
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.
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)?
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.
They should have worked out a viable business model with an open Sailfish.
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.
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.
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.
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.
And what do you mean by "Linux"? Would GNU coreutils and a terminal be sufficient, or is there something else you need?
These links might be useful:
https://sturmflut.github.io/ubuntu/bq/2015/07/02/hacking-the...
https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5-ubuntu-...
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.
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.
"Right click" is a feature. That makes sense but I still find it funny.
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.
> "With that in mind, Remix OS for PC is free to download, free to install, and free to use."
No idea about open source, though.
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?
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).
This sort of thing is what makes me hopeful for a Linux desktop one day-- that I actually enjoy using. I'm really excited to give this a try.
Does anyone know where to download or when it'll be available? Doesn't seem to be available yet?
[0]: http://www.jide.com/en/remixos-for-pc
Edit: apparently this will include windows and mac, so assuming it's going to be like a normal distro.
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.
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 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.
[1] http://arstechnica.com/gadgets/2015/12/android-on-the-deskto...
This might be good for intermediate/casual/netbook users though or those who do computing on some remote machine.
One reason being they could go back and look at previous actions.
Another being how you could only do one thing at a time, and put other stuff on hold (and was reminded if you wanted to shut down).
The author likened the latter to putting a bill somewhere visible as a reminder to pay it.
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.
[1]: http://magazine.odroid.com/wp-content/uploads/ODROID-Magazin...
We'll need a proper ARM desktop... How about one based on AMD's A1100? :)
"The Android Open Source Project uses a few open source initiative approved open source licenses for our software"
Android is based on a fork of the Linux kernel which is GNU GPL v2. RemixOS should release their code, it contains several GNU GPL parts.
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.
The UI looks like a uglier clone of ChromeOS.
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.
This is the first I'm hearing of this. Do you happen to know what the project was called or anything more specific that I might be able to look up?
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.
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.
[1] http://www.xda-developers.com/jide-announce-multi-window-and...
> Today’s public release of Remix OS, based on Android x86, is something that we’ve been working towards since we founded Jide Technology in 2014
So it's a commercial fork of the Android x86 project, basically.
