Hi,
2009/9/22 Benjamin M. Schwartz bmsch...@fas.harvard.edu:
This is incompatible with our (or at least my) goal of allowing
users to throw packages around as atomic objects, without internet access
and without having to understand anything beyond my friend has Sugar, so
it will work. It is
Hi,
Thank you Daniel for documenting all of that. I agree with your
points. There's a lot of it would be cool if it does this but in
most cases of deployments it just doesn't seem to be an issue.
2009/9/22 Benjamin M. Schwartz bmsch...@fas.harvard.edu:
This is incompatible with our (or at
On Thu, Sep 24, 2009 at 12:15, Peter Robinson pbrobin...@gmail.com wrote:
Hi,
Thank you Daniel for documenting all of that. I agree with your
points. There's a lot of it would be cool if it does this but in
most cases of deployments it just doesn't seem to be an issue.
2009/9/22 Benjamin M.
6. Ease of creation of activity packages
Moving to distro-based packaging will not effect the difficulty of
developing activities, since packaging is something you do after
development, not before.
It will affect packaging and distribution. My suggested model (as
employed all over the open
Hi Daniel,
It sounds like you're advocating major architectural and process shifts to
combat hypothetical problems. (Java? C#? I could see JavaScript perhaps
:))
Most activities do not require custom binaries. Those that do have solved
the problem within the .xo format. If you download
Daniel Drake wrote:
4. Sharing of activities between hugely varying systems: The only real
solution to this that I have seen proposed is for *all* activities to
switch to some kind of cross-platform VM platform (e.g. Java)
...
I feel that the one available solution is not realistic or
Dear Sugar folks,
I have avoided wading into this discussion for some time because I wanted to
see where it went without my interference. Therefore, before I say anything
else, thanks for the entertaining show. :)
Next, here are some thoughts for you, based on my own work, uses of Sugar, and
On Thu, Sep 24, 2009 at 4:14 PM, Michael Stone mich...@laptop.org wrote:
Dear Sugar folks,
I have avoided wading into this discussion for some time because I wanted to
see where it went without my interference. Therefore, before I say anything
else, thanks for the entertaining show. :)
Michael Stone wrote:
Consequently, I want to make using activities more like web pages. That's why
I
work on rainbow and on networking design.
...
In my opinion, ideally, they click a URL and the software they
clicked runs most of the time. They don't care what version is underneath. If
Ben wrote:
Michael Stone wrote:
Consequently, I want to make using activities more like web pages. That's
why I work on rainbow and on networking design.
...
In my opinion, ideally, they click a URL and the software they
clicked runs most of the time. They don't care what version is
Michael Stone wrote:
As for interpreters -- I absolutely agree that they should be chosen
carefully.
I just think that the interpreter that we choose carefully should be the
one
that prepares to run a program (e.g. by fetching and installing it, or by
caching it, etc) rather than the one
Bernie Innocenti wrote:
What could be achieved with the .xo bundles that couldn't be achieved
with an rpm?
Let's not talk about .xo. .xo is just the JAR bundle format.
What can you do with JAR that you can't do with RPM?
1. Produce them easily on any platform.
2. Tell the unpacked manifest
El Mon, 21-09-2009 a las 19:13 -0400, Benjamin M. Schwartz escribió:
1. Produce them easily on any platform.
At OLPC, I head this argument made many times, but it's moot:
(1) one could create a bundle on Windows, but not test it.
Since actual development requires a system capable of running
Bernie Innocenti wrote:
El Mon, 21-09-2009 a las 19:13 -0400, Benjamin M. Schwartz escribió:
1. Produce them easily on any platform.
At OLPC, I head this argument made many times, but it's moot:
(1) one could create a bundle on Windows, but not test it.
I'm not thinking about Windows.
El Mon, 21-09-2009 a las 21:27 -0400, Benjamin M. Schwartz escribió:
(1) one could create a bundle on Windows, but not test it.
I'm not thinking about Windows. I'm thinking about Linux. I don't use an
RPM-based distro, so I don't have the RPM tools lying around. I'm not
especially
On Tue, Sep 22, 2009 at 12:13 AM, Benjamin M. Schwartz
bmsch...@fas.harvard.edu wrote:
Bernie Innocenti wrote:
What could be achieved with the .xo bundles that couldn't be achieved
with an rpm?
Let's not talk about .xo. .xo is just the JAR bundle format.
What can you do with JAR that you
On Tue, Sep 22, 2009 at 2:27 AM, Benjamin M. Schwartz
bmsch...@fas.harvard.edu wrote:
Bernie Innocenti wrote:
El Mon, 21-09-2009 a las 19:13 -0400, Benjamin M. Schwartz escribió:
1. Produce them easily on any platform.
At OLPC, I head this argument made many times, but it's moot:
(1) one
El Tue, 22-09-2009 a las 16:51 +0100, Gary C Martin escribió:
This is not a what if it works right now and since 0.84. Any .xo
bundle in your Journal can be 'sent to' over the either to any friend,
where by Journal will automatically install it for them. I have sent
the Physics.xo bundle
Bernie Innocenti wrote:
The use cases that work now would continue to work with any package
format.
That's definitely not true.
One option (the one I thought you were advocating) is to make Activities
just like any other software installed by the distribution package
manager. That means
El Wed, 23-09-2009 a las 12:25 -0400, Benjamin M. Schwartz escribió:
Bernie Innocenti wrote:
The use cases that work now would continue to work with any package
format.
That's definitely not true.
One option (the one I thought you were advocating) is to make Activities
just like any
On Wed, Sep 23, 2009 at 1:07 PM, Bernie Innocenti ber...@codewiz.org wrote:
...
Right. One way around it is using Alien, which I already proposed.
Another solution is to admit that kids running incompatible distros
will be unable to exchange activities -- period. It would be quite a
rare
Bernie Innocenti wrote:
Either we declare that there exists only One True Sugar Distribution
running on One True Hardware Platform -- which is exactly the opposite
of expanding the base for Sugar -- or we accept the increased complexity
that comes from a real multiplatform scenario.
Or, we
El Wed, 23-09-2009 a las 14:33 -0400, Benjamin M. Schwartz escribió:
Or, we bless a small number of completely self-contained virtual machines
(e.g. etoys squeak, mozilla javascript, Sun Java, perhaps a restricted
python), and then run them on any hardware.
I think that would create a much
Bernie Innocenti wrote:
It's still too restrictive for external developers who would like to do
more ambitious things, like Karma and Physics. Those would have to come
and beg us to approve their dependencies.
Karma is HTML+Javascript, for which we have an approved interpreter on the
list, so
Hi Bernie,
On 23 Sep 2009, at 17:19, Bernie Innocenti wrote:
El Tue, 22-09-2009 a las 16:51 +0100, Gary C Martin escribió:
This is not a what if it works right now and since 0.84. Any .xo
bundle in your Journal can be 'sent to' over the either to any
friend,
where by Journal will
On 23 Sep 2009, at 20:22, Bernie Innocenti wrote:
El Wed, 23-09-2009 a las 14:33 -0400, Benjamin M. Schwartz escribió:
Or, we bless a small number of completely self-contained virtual
machines
(e.g. etoys squeak, mozilla javascript, Sun Java, perhaps a
restricted
python), and then run
El Wed, 23-09-2009 a las 21:11 +0100, Gary C Martin escribió:
Would that not potentially be covered if ActivityTeam agree a set of
supported platforms (and agree a 'fat' bundle)? We can _never_ test
and QA every platform in existence, so we have to at least agree on a
core N amount of
Sugar could report an error message on startup: This Activity contains
executable code which was not compiled for this platform. Please contact
the activity author for support.
This would fall into the general category of displaying better error
messages when activities fail to start.
If ARM
El Wed, 23-09-2009 a las 20:13 -0400, Wade Brainerd escribió:
Sugar could report an error message on startup: This Activity
contains executable code which was not compiled for this platform.
Please contact the activity author for support.
This would fall into the general category of
Yamandu Ploskonka wrote:
I for one had hoped that the utterly painful performance
problems with Sugar were a price we were paying for total cross-platform
compatibility though Python. I'm having my innocence crushed as I
follow this thread...
We would do well to clarify this. For the
El Mon, 21-09-2009 a las 23:50 -0400, Benjamin M. Schwartz escribió:
By having distinct packages built separately for each distribution by
experts. This is incompatible with our (or at least my) goal of allowing
users to throw packages around as atomic objects, without internet access
and
I think the .xo activities must be noarch only. These can be modified by
teachers and kids, shared, you can view-source etc.
The .xo can require the binary dependencies using PackageKit.
Now we have one hundred activities based in GCompris and avery one must add
the binaries and the activities
On Tue, Sep 22, 2009 at 12:09 AM, Benjamin M. Schwartz
bmsch...@fas.harvard.edu wrote:
Bernie Innocenti wrote:
Why would we care to have concurrent versions of the same activity for
different user accounts? Our computing model is inherently single-user.
LTSP. NFS with shared clients. Our
Peter Robinson wrote:
On Tue, Sep 22, 2009 at 12:09 AM, Benjamin M. Schwartz
bmsch...@fas.harvard.edu wrote:
Bernie Innocenti wrote:
Why would we care to have concurrent versions of the same activity for
different user accounts? Our computing model is inherently single-user.
LTSP. NFS with
I'm trying to stay out of this massive time sink hole, but I couldn't
let this one float by.
On 22 Sep 2009, at 07:14, Bernie Innocenti wrote:
Last, but certainly not least,
* Activity sharing is not even implemented, yet! We'll think
about these esoteric scenarios when they come... if
El Mon, 21-09-2009 a las 17:15 -0500, Yamandu Ploskonka escribió:
Very good point you make. It gets complicated as the users - kids -
have not been shown they get it regarding giving their full name, age
and address and some even phone number, so it is unlikely they will deal
safely with
On Mon, Sep 21, 2009 at 05:15:31PM -0500, Yamandu Ploskonka wrote:
Chris Ball wrote:
Hi,
TBH I'm not 100% sure on that as I'm not a PackageKit developer
but I believe that is addressed by ConsoleKit and as its in use
on Fedora and I'm pretty sure Ubuntu and others (and I'm
On Mon, Sep 21, 2009 at 11:54:09PM +0100, Peter Robinson wrote:
On Mon, Sep 21, 2009 at 11:47 PM, Martin Dengler
mar...@martindengler.com wrote:
On Mon, Sep 21, 2009 at 05:15:31PM -0500, Yamandu Ploskonka wrote:
Chris Ball wrote:
Hi,
TBH I'm not 100% sure on that as I'm not a
Bernie Innocenti wrote:
Why would we care to have concurrent versions of the same activity for
different user accounts? Our computing model is inherently single-user.
LTSP. NFS with shared clients. Our computing model is not just OLPC.
signature.asc
Description: OpenPGP digital signature
On Mon, Sep 21, 2009 at 07:01:13PM -0400, Bernie Innocenti wrote:
El Mon, 21-09-2009 a las 23:47 +0100, Martin Dengler escribió:
The whole point of Rainbow is that what I think you're talking about
isn't an issue, and it's encouraged that kids share Activities.
Eliminating this sharing
Bernie Innocenti wrote:
How does, for instance, Gimp manage to work perfectly on *all* Linux
distributions? And how do all the other 19K packages in my distro
manage to find *exactly* all the dynamic libraries they need when they
are installed?
By having distinct packages built separately
41 matches
Mail list logo
