Live data from Hacker News

RemixOS – Android for the desktop

jide.com

101–110 of 197 posts

Re: RemixOS – Android for the desktop

#101
post #47

The licensing seems to make this a non-starter. But let's suppose they must fix that. (This is pretty clearly a derived product...?) We'll need a proper ARM desktop... How about one based on AMD's A1100? :)

By "derived product" do you mean an obligation to open-source? If yes, there isn't any: Android is licensed Apache 2.0. https://source.android.com/source/licenses.html

Read the first sentence:

"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.

Re: RemixOS – Android for the desktop

#102
post #92
post #87

Earlier quoted context omitted.

Why would grandma want a desktop instead of a chromebook? And why would a poweruser or a gamer want an underpowered PC? This might be good for intermediate/casual/netbook users though or those who do computing on some remote machine.

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.

Got me thinking about an article that claimed that perhaps the command line was the better one for older people.

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.

Re: RemixOS – Android for the desktop

#104

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.

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.

[1]: http://magazine.odroid.com/wp-content/uploads/ODROID-Magazin...

Re: RemixOS – Android for the desktop

#105
post #79

Earlier quoted context omitted.

> 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 inte…

> 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 wh…

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".

Re: RemixOS – Android for the desktop

#106
post #100

Earlier quoted context omitted.

su "limited account" -c "questionable binary"?

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 lin…

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).

Re: RemixOS – Android for the desktop

#107
post #82
post #15

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 for…

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 binar…

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.

Re: RemixOS – Android for the desktop

#108
post #15

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 for…

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.

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.

Re: RemixOS – Android for the desktop

#109
post #101
post #47

Earlier quoted context omitted.

By "derived product" do you mean an obligation to open-source? If yes, there isn't any: Android is licensed Apache 2.0. https://source.android.com/source/licenses.html

Read the first sentence: "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.

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.

Re: RemixOS – Android for the desktop

#110
post #107
post #82

Earlier quoted context omitted.

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 binar…

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…

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)?

Post reply on HN