151–160 of 197 posts
I'm disappointed there is no download available. This news seems a little premature.
Earlier quoted context omitted.
> 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…
> However, the voice recognition module wasn't actually used unless you opted into the "Ok Google" hotword feature. 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…
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…
Which package manager are you thinking of? The dpkg ecosystem (i.e. Debian and Ubuntu etc.) definitely uses sonames. It is true that the soname version ends up in the package name, but this happens automatically, at build time, and it's only the binary package name that carries the soname, the source package remains unchanged.
You can install[] packages with libxyz.1.so and libxyz.2.so; you cannot install two -devel packages, because that package contains symlink libxyz.so to specific version.
Often, the system even installs such packages for you (they have compat in package filename, i.e. compat-libstdc++).
[] provided they don't contain additional files with assets, that conflict with each other. But this problem is not solved by gobo either.
I want regular Linux on my phone, not Java Linux on my desktop.
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.
What about apps created with the NDK?
Will it be open source? "Free for licensing" isn't quite clear. Will anyone by able to license access to the source code for free? If yes, what about forking? EDIT: Okay, this isn't what I've hoped for: >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.
yeah this is not great. moving right along...
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 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…
Comparing X11 to Win32 is just laughable. X11 is ANCIENT. It also provides no widgets or anything other than windows and drawing primitives (which are ancient). You can't do anti-aliased fonts for example, you have to render then with freetype2 into a pixmap buffer and put that in your window. Practically every GUI toolkit does it that way - allocate window, do the drawing yourself, present final pixmap. Win32 is mor…
To consider you example with text, in Windows, you also have to use GDI+ or Uniscribe to have at least passable text (without shaping, that is). Or use DirectWrite, which is about as old as Pango.
Even OSX went through changes, AAT/OpenType wasn't available when QuickDraw GX was all the rage.
Where is the downloading link of the OS for PC?
[1] http://www.xda-developers.com/jide-announce-multi-window-and...
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…
> There are just so many, let me say, shady, "apps" out there, so I don't install anything from Google Play Store on my smartphone Lately I've found myself checking if something is available on F-droid before installing from Google Play. Sometimes it is! If something is on F-droid, I'm less worried about it being scammy spyware disguised as useful software.
Earlier quoted context omitted.
> However, the voice recognition module wasn't actually used unless you opted into the "Ok Google" hotword feature. 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…
Oh please. If google wanted to record from Chrome users, they could do it easily. If you actually trust packagers to know what Chrome is doing, you're crazy.
Of course you could say in a large codebase like chromium, bad things can be hidden. But at least there's a better chance such things are found, and it's more risky to put it there in plain sight.
In a perfect world, all software would have reproducible builds and there would be no issue with trusting that binaries contained no hidden functionality not in the source, as there'd be third parties to rebuild and compare the result against the published binaries. We're a ways away from that.
Earlier quoted context omitted.
Your users have a right to get the full corresponding source of GPLed software you distribute to them, though.
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?