Meeks: Linux on the (consumer) Desktop

Posted Sep 12, 2012 18:25 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

Posted Sep 12, 2012 20:31 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Posted Sep 12, 2012 5:02 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Posted Sep 12, 2012 5:39 UTC (Wed) by khim (subscriber, #9252) [Link]

Efficiency of attacker on systematic hunt for bugs does *not* diminish, though.

It goes down, too. If library just sits out there and nobody uses it then it's useless for attacker anyway. If library is actually needed by some software then user will find and install it (unless s/he'll abandon Linux, that is) and thus it'll be available for the attacker anyway. And if library is not present in the latest version of the distribution but is transplanted from older version then it'll be more buggy, not less.

It's just that your "solution" really isn't.

It's the only alternative which works. We may lament that it's bad for one reason or another (and it is!) but as long as it's the only game in town…

Neither is bundling libraries with ISV code using those, for the same reasons.

Again: if you don't provide stable ABI in your system then ISVs will bundle libraries with their offers. Acrobat brings openssl and libcurl, Firefox brings SQLite and NSS. And games bring practically everything including bundled version of SDL and libvorbis, sometimes even libjpeg and libpng.

If you think that this approach magically makes your system more secure than the one which supplies obsolete libraries in it's core then you are sorely mistaken.

As I've said: few percents of users may be satisfied with selection of goods offered in their repo. Fine, but maybe it's time to create something for the rest of us?

Posted Sep 15, 2012 17:31 UTC (Sat) by khim (subscriber, #9252) [Link]

I think you have missed one small yet vital letter. I'll highlight: totally incompatible between versions at the C A⇒B⇐I level. ABI, not API. Here we go:
$ objdump -T /usr/lib/libtcl8.[45].so.0 | grep 'g DF' | cut -b 62- | sort | uniq -d | head _fini
_init
Tcl_Access
Tcl_AddErrorInfo
Tcl_AddInterpResolvers
TclAddLiteralObj
Tcl_AddObjErrorInfo
Tcl_AlertNotifier
Tcl_Alloc
TclAllocateFreeObjects
$ objdump -T /usr/lib/libtcl8.[45].so.0 | grep 'g DF' | cut -b 62- | sort | uniq -d | wc -l 639

You can not easily use TCL in any library or plugin because of that. If one plugin will use TCL 8.4 and another plugin will use TCL 8.5 you'll have Russian Roulette: it may work for sime time, but nobody can predict when (and if!) it'll kill you.

Note that even Microsoft is guilty: .NET framework 1.x is totally incompatible with .NET framework 2.x. Thankfully they quickly dropped this insane idea and .NET frameworks 3.x were built on top of the CLR 2. .NET frameworks 4.x use different (and incompatible!) runtimes, but you can use in-process side-by-side hosting to run multiple versions of the CLR in a single process.

Sure, you can do with TCL using some tricks with dlopen and some recompileable shims (nVidia does this even with Linux kernel ABI which is infamous for it's instability!), but… this is not something TCL authors propose and support. They push for the same tried and found wanting "recompile the world" approach.

Posted Sep 13, 2012 2:28 UTC (Thu) by bojan (subscriber, #14302) [Link]

Posted Sep 13, 2012 21:27 UTC (Thu) by khim (subscriber, #9252) [Link]

You know, people cannot complain that Fedora is the perpetual alpha/beta of RHEL and that RHEL is not developed in the open at the same time.

Yes, they can. Because both facts are true. Fedora is perpetual alpha/beta of RHEL and RHEL is not developed in the open.

High risk/high disruption things are done in the open. But then “enterprise features” are added behind the closed doors. So Fedora users are used as free alpha/beta testers but never receive the end result which is developed in secrecy. It's not too bad: if you really want the finished product without the support service then CentOS closes the loop. But to claim that Fedora users are not treated as alpha/beta testers for RHEL or that RHEL is developed in the open is to lie about the state of affairs.

And this is RedHat! One of the most FOSS-friendly companies around!

These things are mutually exclusive.

Absolutely not. Google does the same with ChromeOS BTW: 99% if code is developed in the open, but 1% which makes it possible to, you know, watch the videos on Netflix or talk with your peer in Google Talk... these pieces are developed privately.

But, my point was and still is something else. It is the commitment and expertise that counts. The engineering resources, the contract with OEMs and ISVs, the financial capacity and most importantly a stable strategic direction.

Right. And this is where all the secrecy comes from. You need to herd the cats: ASUS, Acer, HTC, Motorola, and Samsung may want to jointly develop OS—but they don't want to ever show the unique differentiators before release! And of course if they need changes in the system core they don't want to show them to the cheap chinese competitors, too. That's how all the complexity Android's VCS is born.

Posted Sep 13, 2012 2:16 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]