[Sugar-devel] The ARM is near

[Jonas Smedegaard]

On Fri, Aug 28, 2009 at 07:02:30PM +0200, Tomeu Vizoso wrote:
>On Fri, Aug 28, 2009 at 18:55, Jonas Smedegaard<dr at jones.dk> wrote:
>> On Fri, Aug 28, 2009 at 12:02:44PM +0200, Tomeu Vizoso wrote:
>>>
>>> On Fri, Aug 28, 2009 at 11:37, Jonas Smedegaard<dr at jones.dk> wrote:
>>>>
>>>> On Fri, Aug 28, 2009 at 10:13:24AM +0200, Tomeu Vizoso wrote:
>>>>>
>>>>> If fat binaries are not desired, which alternatives do we have?
>>>>
>>>>  1) Include more aggressively/liberally arch-dependent stuff in Sucrose,
>>>>    and include/write wrappers for popular arch-independent languages
>>>>    (e.g. Python)
>>>>  2) Promote as "first class Activities" those written in arch-
>>>>    independent languages and depending only on stuff included in
>>>>    Sucrose.
>>>
>>> Both sound like good ideas to me,
>>
>> It was meant as a single alternative containing 2 steps.
>>
>>
>>> though 1) concerns more to deployers: do they want to have to 
>>> install hundreds of megs of software that might or might not be used 
>>> by any Sugar activities they get to use?
>>
>> Sucrose does not grow automatically.  Sugarlabs maintains Sucrose, so 
>> gets to decide if it should bloat or if the author of an activity 
>> written in YACNL (Yet Another Cool New Language) is told to either 
>> rewrite in one of the existing supported languages or accept that the 
>> Activity will be a 2nd class activity due to the weird choice of 
>> language.
>>
>>
>>> I think that deployers should be the ones to say what can go in the
>>> platform and what not. But the more we have there, the easier it is
>>> for us developers.
>>
>> Could you give a concrete example of this dilemma (preferrably 
>> non-theoretical - i.e. tied to actual activities and languages 
>> currently used for them)?
>
>Let's say that a country wants to develop activities in java and have
>it as part of the platform. Maybe some other deployer with restricted
>disk space would be opposed to have to ship Java? Same with the cups
>filters, Mono, etc

Not a problem if the deplyer wants to extend locally with Java or some 
other bloat.  Sugarlabs need not change the Fructose specs for that.  
The rest of the world need not suffer from such local oddities.

If, on the other hand, Sugarlabs choose to adopt all those cool 
activities created in Java, then Sugarlabs would bloat Fructose 
globally, and we would all suffer from the bloat.  True.

But really such problem of Sugarlabs shooting itself in the foot like 
that is IMHO independent from the challenge of arch-dependent code in 
activity packages: If Sugarlabs wants the ability to make 
small-diskspace deployments then Sugarlabs must set the bar high for 1st 
class activities.


Oh, and in case we might be talking past each other due to terminology: 
I use the term "Fructose" as "the very minimal core set of stuff that 
must always be available for a system to sanely claim to run "Sugar".

I apologize for any confusion if I misunderstood the term.


Kind regards,

  - Jonas

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

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090828/5d6483fb/attachment-0001.pgp