Hi all,

Feel free to ignore my comments here - after all I am not doing any of the heavy lifting in this field, I "just" continue to package for Debian from source, independent on what you come up with here...


On Fri, Aug 28, 2009 at 04:47:53AM +0100, Gary C Martin wrote:
As a long time Mac user (and developer) I was/am all for "fat packages" (universal binaries), and we certainly don't have the ability to compile binaries on demand for the significant portion of target sugar HW. Activity bundles are a major plus, from where I'm standing, vs. the traditional ./configure, make install, and dependancy requirements.

Macintosh "universal binaries" was binaries that contained both "the new stuff" and "the old stuff". Pretty easy for users to grasp.

(Back in the day it meant "m68k + powerpc" and later, when m68k was officially dead for some years, it meant "powerpc + i386" (and possibly amd64 too, but I suspect that to be optional for some years)


What would "universal" be in the Sugar context?

i386 + amd64?
i686 + amd64?
i386 + i686 + amd64?
powerpc + i386 + amd64?
armel + i386 + amd64?
powerpc + armel + i386 + amd64?


It is plain ugly IMHO!



With my activity author hat on, I've gone out of my way to avoid the hell of binary blobs, it breaks the whole idea of providing code in Python source for others to easily edit, modify, learn from. But I understand (having adopted maintenance of some old projects) that this has not always been possible for authors (though it woul would always be my goal when writing code).

So you find it acceptable for old code to contain binary blobs.

I am with you on that.

I worry about new Activities using binary blobs too, if not explicitly and loudly discouraged by the Sugar project.



Kind regards,

- Jonas

--
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to