181–190 of 197 posts
Earlier quoted context omitted.
http://www.ubuntu.com/phone
Isn't Ubuntu Phone using an Android kernel though ?
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 have the Remix PC from the Kickstarter. 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 "D…
Earlier quoted context omitted.
Why? Serious question. And what do you mean by "Linux"? Would GNU coreutils and a terminal be sufficient, or is there something else you need?
Yes something like termux might be a sufficient addition to "android". Note a standard GNU coreutils build is about 15M, though one can configure to use a multi-call binary like busybox, reducing the install size to about 1M. See the coreutils-single subpackage in Fedora rawhide for example: http://pkgs.fedoraproject.org/cgit/rpms/coreutils.git/commit...
Earlier quoted context omitted.
yeah this is not great. moving right along...
Early adopters in organisations are important. 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.
Earlier quoted context omitted.
I cannot help but wonder if "apps" aren't going to eventually replace package managers. That's certainly what Docker-like containers try to do. 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…
I'm certain containers will end up replacing package managers. This idea is being pushed by the systemd guys. 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 ow…
Earlier quoted context omitted.
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.
http://www.bloomberg.com/bw/articles/2014-06-24/googles-sund... "And Pichai killed a project to develop a version of Android for touchscreen laptops—it overlapped with Chromebooks—shifting attention toward tablets and new categories such as smart TVs and wearable computers."
But from a branding perspective it makes sense to distance a immature product from a widely popular product. (Obviously that wasn't the idea though since Android Auto, Android TV, Android Wear)
I can also see why they wouldn't want to kill off Chrome OS since it allows them to experiment with a diverging set of strengths and features that Android might not be conducive toward. Those strengths could be leveraged in their other products especially Android.
Earlier quoted context omitted.
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. ... This allows multiple versions of a lib to live side by side, while giving the binaries the version(s) they want. I see you've qualified your statement with "most", so you're not in the wrong, but unless I'm mistaken both Nix[1] (and NixOS) and Guix[2] handle this problem well and do it in a way which scales infinitely. [1] ht…
Earlier quoted context omitted.
Only if you've modified it. If not, then it's upstream's responsibility to distribute source. And even if you've modified it, I think distributing patchsets is enough, no?
If you distributed binaries made from GPL code to me, you're obliged to provide the source code if I ask you. You can do that by pointing me to an upstream url fine, but you need to be sure that that url will be valid when I ask you.
Earlier quoted context omitted.
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.