Live data from Hacker News

RemixOS – Android for the desktop

jide.com

161–170 of 197 posts

Re: RemixOS – Android for the desktop

#161

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…

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

Re: RemixOS – Android for the desktop

#163
post #122

Earlier quoted context omitted.

That seems like yet another case of freedesktop/gnome/fedora finding another hammer and applying it to all the "nails". Containers fix a problem that unix has solved for decades. https://en.wikipedia.org/wiki/Soname 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 d…

Unix has solved for decades? Not really, if we look at the state of adoption of this solution. We supposedly discovered concrete 2 millennia ago but only adopted it widely 150 years ago. I wouldn't diss people who actually have a shot at fixing the problem, even though you might not like their solution.

Is there a problem with adoption of SONAMEs?

I use debian all the time, and the major libraries are versioned, and some have more than one version available. Debian is a very common linux distro, and through it, a lot of child distros get it too. AFAIK, RedHat and Fedora do this too.

So, do you mean that the state of adoption is bad for niche linux distros?

Re: RemixOS – Android for the desktop

#164

Why would I want this when I can just use OSX on the desktop ?

One big reason, at least for me: Because OS X is the least secure desktop OS - http://venturebeat.com/2015/12/31/software-with-the-most-vul...

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.

Re: RemixOS – Android for the desktop

#165

Earlier quoted context omitted.

Java? What are you talking about? 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.

> Applications are compiled to native machine code upon installation What about apps created with the NDK?

Basically the same result. NDK uses a customized cross-compiler built on the arm-eabi-gcc compiler.

Re: RemixOS – Android for the desktop

#166
post #110
post #107

Earlier quoted context omitted.

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…

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

Re: RemixOS – Android for the desktop

#168
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…

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.

Re: RemixOS – Android for the desktop

#170
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…

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, s…

> -only- distribute their app via Google Play

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.

Post reply on HN