User: Password:
|
|
Subscribe / Log in / New account

Distributions for the Nexus 7 (TGDaily and HotHardware)

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 18:21 UTC (Wed) by hummassa (subscriber, #307)
In reply to: Distributions for the Nexus 7 (TGDaily and HotHardware) by ibukanov
Parent article: Distributions for the Nexus 7 (TGDaily and HotHardware)

The "private files" thing can be bypassed (using the "same uid" on the manifest, or setting up doc sharing between the apps).

And it's not really practical in a desktop/laptop (or in a more "complete" tablet): it is common to share files between unexpected sets of applications in more complete workflows.

But, that being said, it's perfectly possible to replicate the "one uid per app/set of apps" thing on desktop linux.


(Log in to post comments)

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 19:52 UTC (Wed) by ibukanov (subscriber, #3942) [Link]

> The "private files" thing can be bypassed (using the "same uid" on the manifest, or setting up doc sharing between the apps).

Yes, there are issues with Android, but at least it is base architecture is sound and does allow to run untrusted or unverified code while common Linux distributions is in worse shape now in that area than Windows 8.

> And it's not really practical in a desktop/laptop (or in a more "complete" tablet):

It is a matter of proper GUI. I am typing this in a VM running on qubes-os.org which allows a secure way to share files between VMs. There are some annoyances, but they comes from the fact that the only IMO reasonable way to isolate the current desktop Linux apps is to put them into separate VMs. That of cause wastes a lot of resources and requires high-end laptop. It would be nice to have the security without the need for VMs, but I just do not see how with the current desktop API this is feasible.

> it's perfectly possible to replicate the "one uid per app/set of apps" thing on desktop linux.

Yet this is not available now while Android is around for over 5 years. So I do not see as useful all those efforts to optimize desktop Linux model for tablets rather than fix Android to allow to run the desktop Linux apps without breaking the sandbox.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 20:08 UTC (Wed) by shmerl (guest, #65921) [Link]

Android is not fixable in many other fundamental ways, so I don't see at as a future for mobile Linux.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 20:55 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

What ways?

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 0:38 UTC (Thu) by shmerl (guest, #65921) [Link]

Like inferior libc (bionic vs glibc).

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 1:27 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

We've argued about it in the past:
1) There are no _fundamental_ deficiencies in bionic. Mostly some not-yet-implemented stuff.
2) You can still use glibc (with some difficulty) and uClibc (without much less problems) on Android.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 4:37 UTC (Thu) by shmerl (guest, #65921) [Link]

And after discussions it came out, that bionic isn't going to improve, because upstream doesn't want to accept those fixes. So why bother. There are normal systems with better libc. And security can be built as needed.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 4:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Wrong. It came out that upstream is not particularly _interested_ in these fixes. That doesn't mean it'll forever stay this way - most fixes are trivial.

>There are normal systems with better libc. And security can be built as needed.
And they are?...

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 6:03 UTC (Thu) by shmerl (guest, #65921) [Link]

Not interested [to improve themselves] and not accepting the fixes - is not the same. Not accepting means preventing the improvement. It's better to work with those who collaborate for improvement, instead of overcoming some resistance for no real reason, and coming up with weird workarounds, when effort can be spent straight on positive things.

Any normal Linux with glibc is already without these problems.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 8:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Wrong. "Not accepting" in Android right now means "we are too busy with really important stuff".

Which is justifiable, because nobody really cares about iconv() or some kind of exotic xsdstradfhdup function in bionic. Instead Google concentrates on really important stuff, the stuff that allows them to achieve 1.5M activations every single day.

If they really need that shit from glibc (which is by far the shittiest library in a standard Linux stack) then it'll be added in a minute.

> Any normal Linux with glibc is already without these problems.
Yeah sure. And that why Android is already about 20x bigger than all Linux desktop systems that ever existed.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 17:08 UTC (Thu) by shmerl (guest, #65921) [Link]

You seem to care about politics and who is bigger. I care about technology and what is technically better. We have different interests.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 28, 2012 23:49 UTC (Fri) by bronson (subscriber, #4806) [Link]

You seem to have ignored "which is by far the shittiest library..." That's a technical argument.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Shmerl is aware of my technical objections.

I think that glibc (and generally all libcs) are designed by a band of idiots that should not be allowed EVER to come close to a computing device.

For example, glibc requires a metric ton of additional stuff like locales and timezones. And all this shit can't even be used! For example:
1) There's no way to get the next time for DST transition. Too complex? I can do this just fine in .NET.
2) There's no way to simply get the time in another timezone without modifying a hidden global variable!
3) Ditto for localization - it only works to make regexes like [A-Z] fail in Estonian locale (because Z is not the last letter in Estonian alphabet). But normalizing a string for a given locale without modifying a global variable? No can do.
4) There's dependency on NSS that makes it impossible to install glibc without raping the whole OS. And what for? Only to make a couple functions like getpwent() work. And of course, this functionality is insufficient for a lot of real-world tasks, like searching a list of by a prefix. Do you see a pattern here?

uclibc and bionic made the right decision - to jettison all that crap and instead build a lean and mean libc.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:49 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>like searching a list of by a prefix
Correction: "like searching a list of users in a huge LDAP directory by a prefix".

glibc

Posted Dec 30, 2012 7:57 UTC (Sun) by jrn (subscriber, #64214) [Link]

I'll bite. What does "normalize a string for a given locale" mean? Are you referring to case folding or something?

I think the band of idiots you are referring to is called the POSIX standards committee. Though I like their work and don't consider them to be a band of idiots.

glibc

Posted Dec 30, 2012 8:33 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> I'll bite. What does "normalize a string for a given locale" mean? Are you referring to case folding or something?
For example, convert string to a title case in en_ZA locale while the system locale is es_ES.

> I think the band of idiots you are referring to is called the POSIX standards committee. Though I like their work and don't consider them to be a band of idiots.
Yup. The sheer amount of idiotic decisions in POSIX made it irrelevant long time ago. Almost all real software has to rely on various kinds of extensions.

Oh, by "irrelevant" I mean that POSIX compliance is not even worth the time spent to read POSIX spec.

glibc

Posted Dec 30, 2012 8:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> For example, convert string to a title case in en_ZA locale while the system locale is es_ES.
Or even a better example, convert the string "is this true" to upper case to uppercase in en_US with tr_TR locale. We got hit with this "bug" _several_ time.

The other way around is also hilarious.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 18:54 UTC (Fri) by nix (subscriber, #2304) [Link]

So... your entire body of complaints regarding glibc being 'by far the shittiest library in a standard Linux stack' relates to localization? And, in particular, relates to glibc not providing various admittedly useful localization functions?

These functions are not provided for a single simple reason -- they are not required to implement the POSIX API: random extensions really shouldn't be thrown into glibc, because they have to be maintained forever (yes, yes, strfry() shouldn't be there, but it dates from a time when glibc was much younger and development was much wilder -- and now it cannot be removed). The localization databases and the like are required to implement that API (including things like the localization support in printf()). This is doubly true for the timezone stuff which is really there only so that conversions to the local timezone for filesystem stuff works.

What mystifies me is that you suggest that this problem is resolved by, uh, using bionic et al, which don't implement *any* of the POSIX-mandated localization stuff *at all* and thus may break real applications that depend on the existence of this support. Surely this leaves you even worse off than glibc does? At least (in the new glibc governance world) these problems are potentially resolvable? You can't add proper localization to bionic at *all* without adding all the features that glibc already has, then adding more on top of that.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 19:53 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>So... your entire body of complaints regarding glibc being 'by far the shittiest library in a standard Linux stack' relates to localization?
Also:
1) Inability to use statically linked glibc or bundled glibc.
2) Inability to use latter versions of glibc to create binaries for earlier versions. So I'm forced to install a parallel chrooted system so that my binaries compiled on a recent Ubuntu can be started on RHEL.
3) Fairly slow malloc implementation.
4) Huge size for embedded systems and inability to create a cutdown version.
5) Dependency on runtime-loadable modules (NSS).
...

But yeah, the design of localization and time handling is just an iconic example.

>These functions are not provided for a single simple reason -- they are not required to implement the POSIX API.
And so freaking what? Create a separate 'lib-shitfulled-POSIX-compatible abomination-c' and be done with that. Then continue developing a sane successor.

Most developers don't care about POSIX at all (which is good).

> What mystifies me is that you suggest that this problem is resolved by, uh, using bionic et al, which don't implement *any* of the POSIX-mandated localization stuff *at all* and thus may break real applications that depend on the existence of this support.
Good. Any application that depends on glibc for localization is broken.

>Surely this leaves you even worse off than glibc does?
No, it's actually much better solution. I can bundle bionic (or uClibc) and my favorite localization library along with my application.

> You can't add proper localization to bionic at *all* without adding all the features that glibc already has, then adding more on top of that.
Yes, I realize that glibc can't be modularized at this point. But it can at least be made _useful_ by including obvious extension functions. They even (gasp!) can later be standardized.

But noooo, POSIX is a sacred cow and everybody should bow down before it.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:25 UTC (Sat) by khim (subscriber, #9252) [Link]

I care about technology and what is technically better.

Do you care about ability to use it for anything practical or not? That's critical question.

There are people who are doing things like Haiku: things which are technically interesting and challenging but which are not used by Joe Average and will never be used by Joe Average. Eventually they end up in some kinda VM and show “the possible alternate world” for the future generations.

And then there are practically useful things: for these you need popularity. Because technical problems can be fixed (Windows is prime example: Windows 3.0 was popular but highly unstable while Windows 7 is extremely stable and relatively secureз… more secure then Linux in some circumstances), but they can only be fixed when you have enough developers and you only have enough developers when your system is popular.

Systems which ignore “cheap popularity” and concentrate on “technical soundness” usually migrate from the second camp to the first one. Some developers accept and embrace such transitions (witness HURD), but some suddenly start caring about popularity at some point… but usually it's way too late then. *BSD are prime example: long time ago they stopped trying to win popularity contests and concentrated on “doing things right” (there are many ways to define what the “right” thing is—that's why we have many different versions of BSD). And they had huge headstart (when FreeBSD and NetBSD were already quite complete and useful systems Linux was a joke). Today they all are struggling to survive.

Note that this process is so acute today exactly because all these supposedly snobby Linux-only projects are struggling to survive, too: they are in similar race—but with Android instead. History repeats itself: Android started as something toy-like (from POV of “traditional” GNU/Linux), but it improves extremely fast (although not always in the direction people from traditional GNU/Linux background like) and it's easy to imagine world where in 5-10 years “traditional” GNU/Linux based desktop will be where *BSDs are today.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 18:43 UTC (Fri) by nix (subscriber, #2304) [Link]

glibc (which is by far the shittiest library in a standard Linux stack)
Evidence? Oh, that's right, you don't have any, because this assertion is ludicrous. Yes, glibc is baroque and somewhat overcomplicated and is notably bad at a few use cases (such as those requiring static linking), but it is robust, reliable, flexible, remarkably complete, has an exceedingly stable API and ABI, and just works under an enormous variety of pressures and loads on a larger number of machines than anything else in the desktop Linux stack bar the kernel itself.

It is not by any measure 'by far the shittiest library in a standard Linux stack'. That goes far past hyperbole into outright untruth. You should apologise to the glibc developers.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 9:58 UTC (Sat) by foka (guest, #6707) [Link]

On the contrary, I see that the Bionic maintainers are indeed improving Bionic, in their own ways. For example, I find their effort in getting Android's bionic C library back in sync with upstream both encouraging and commendable.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds