81–90 of 197 posts
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. Source: http://www.jide.com/en/partnerships
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…
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.
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…
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+).
Android barely works on smartphones.
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…
> 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…
Earlier quoted context omitted.
> 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…
> 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…
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).
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 co…
This might be good for intermediate/casual/netbook users though or those who do computing on some remote machine.
Earlier quoted context omitted.
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…
There's always fdroid! https://f-droid.org/
I love F-Droid, but they plan to drop Firefox, and Chromium will never make it on there.
Earlier quoted context omitted.
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 ga…
> 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'. https://nixos.org/nixos/about.html
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.
Earlier quoted context omitted.
It seems that "Remix OS for PC" will be at least "free to use": > "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.
> 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?