Live data from Hacker News

RemixOS – Android for the desktop

jide.com

111–120 of 197 posts

Re: RemixOS – Android for the desktop

#113
post #100

Earlier quoted context omitted.

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

Who needs restricted user permissions, you can just review the machine code of all your executables before running them ;)

Re: RemixOS – Android for the desktop

#114

Earlier quoted context omitted.

I've never liked the traditional unix way of managing a filesystem either; GoboLinux had the right idea.

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 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. Th…

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.

Re: RemixOS – Android for the desktop

#115
post #92

Earlier quoted context omitted.

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.

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.

Re: RemixOS – Android for the desktop

#116

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.

"if not for Sundar Pichai killing off Android's laptop project" 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?

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.

Re: RemixOS – Android for the desktop

#118
post #21
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…

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

But no information is sent out to Debian without my opt-in consent, in sharp contrast to Google, Microsoft, Apple and Ubuntu.

Re: RemixOS – Android for the desktop

#119

Earlier quoted context omitted.

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

Your users have a right to get the full corresponding source of GPLed software you distribute to them, though.

Re: RemixOS – Android for the desktop

#120
post #88
post #77

Earlier quoted context omitted.

There's always fdroid! https://f-droid.org/

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.

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?

Post reply on HN