headers
Scott Shawcroft | 1 Aug 01:03
Picon

Journal: Sharing and Creative Commons Licenses

Hi all,
I'm Scott and am a tech intern at Creative Commons this summer.  This
week I'm hoping to integrate licensing into the Journal in time for
LinuxWorld here in SF.  I'd like to collaborate on this with the folks
currently working on the journal.  We currently have some mockups of how
it will be done but it doesn't currently align with the current journal
implementation in build 540.  Before I can begin I need to discuss the
implementation further with the developers.  A few questions I have are:

1) Where is the code stored?  Is it packaged?
2) How should the children select the license?  We currently are using a
dialog box in our mockups but I've heard that dialog boxes are not wanted.
3) Is sharing implemented yet?
4) Is there a license metadata field?

Thanks for the help and keep up the good work.
~Scott Shawcroft
Permalink | Reply | 2 comments |
headers
Ryan Pavlik | 1 Aug 02:35
Gravatar

Re: Docs?

I am certainly not an OLPC rep, but what I have seen suggests that the 
intent is for the machines to be self-instructing and not requiring 
documentation.  In addition to the massive translation demands that 
would require, it also does not coincide with the educational 
theories/practices that the organization is pursuing.

Of course, if you want to make developer documentation, then I think 
anyone's answer would be, dive in! :)  Just ask which regions are stable 
first so your work doesn't get obsoleted quickly.

Ryan

Edward Cherlin wrote:
> Is there any plan for official software documentation? I have been a 
> Senior Tech Writer for the last 10 years and would be delighted to 
> work on it (particularly if someone like Red Hat would support me to 
> do it 60 hours a week *<{%-{]}}} <--Goggle-eyed geek in clown hat, 
> moustache, and full beard). Actually, I have been writing about XO 
> software off and on ever since the Dynabook days, when Xerox licensed 
> Smalltalk to Apple, HP, and others in 1981, during my market research 
> period.
>
> For example, I wrote in a study of so-called educational software back 
> then that the overpriced drill-and-practice programs of the time 
> weren't real educational software, and that what children need is 
> sharp tools to do stuff with. Commercial educational software is still 
> a vast wasteland, with a few honorable exceptions. Then I did a study 
> on Personal Instruments (data acquisition and analysis on PCs), and 
> some other reports that touched on education. Besides starting and 
> managing a software project for math for schools. And a few other things.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 1 Aug 04:42
Picon
Favicon

Re: Initial Security Patches

On Tue, 2007-07-31 at 14:20 +0100, Simon McVittie wrote:
> On Mon, 30 Jul 2007 at 16:21:36 -0400, Michael Stone wrote:
> >      @dbus.service.signal(_DBUS_OWNER_IFACE, signature="s")
> >      def CurrentActivityChanged(self, activity_id):
> > -        pass
> > +        if os.path.exists('/etc/olpc-security'):
> > +            self.rainbow.activity_changed(activity_id)
> 
> Minor: It's conventional for D-Bus methods to be named in CamelCase.
> 
> More major: This looks like an example of the same method/signal
> naming inversion we have in Telepathy's streamed media interfaces (which we
> consider to be a bug). Methods should be verbs, like ChangeActivity;
> signals should be events, like ActivityChanged. Can't Rainbow just
> listen for _DBUS_OWNER_IFACE::CurrentActivityChanged? If you're implementing
> Rainbow in Python, that's spelt:
> 
>     bus = dbus.SessionBus()
>     bus.add_signal_receiver(some_callback, 'CurrentActivityChanged',
>                             _DBUS_OWNER_IFACE)
> 
> If you only want to respond to CurrentActivityChanged from the process
> or object that ought to be emitting it, you can also specify a bus name
> or object path, or you can use connect_to_signal() on a proxy for that
> object.
> 
> If you must use a method call for some technical reason, it'd be less
> astonishing if it was called something like ChangeCurrentActivity.

I think I suggested this particular approach because we don't really
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 1 Aug 04:49
Picon
Favicon

Re: Initial Security Patches

On Tue, 2007-07-31 at 21:45 +0200, Marco Pesenti Gritti wrote:
> Hello,
> 
> thanks for the explanation, it clarifies a lot of things.
> 
> As I just said to Ivan and coderanger on irc we needs to be clear on
> the actual goals for Trial-3. In particular I'd like to know:
> 
> 1 Are we aiming to enable this by default for Trial-3

Yes.  If activities in containers don't go into Trial 3, they will not
get into FRS.  They don't have to be locked down at all, just have
activities launched in containers.  We just have to figure out by
Trial-3 if people can fix the bugs that come up.  If they can't, we rip
containers back out and re-evaluate the security position.

> 2 Are we aiming at pushing one-instance-per-process for Trial-3

We may just end up whitelisting EToys and Browse as
multiple-instance-per-process activities, and just accept that one
Browse instance can interact adversely with all other instances.  I
don't think we've  made that call concretely yet though we did discuss
it on the train today.

Dan
Permalink | Reply | 13 comments |
headers
Noah Kantrowitz | 1 Aug 05:02
Picon
Favicon

Re: Initial Security Patches

Dan Williams wrote:
> On Tue, 2007-07-31 at 21:45 +0200, Marco Pesenti Gritti wrote:
>   
>> Hello,
>>
>> thanks for the explanation, it clarifies a lot of things.
>>
>> As I just said to Ivan and coderanger on irc we needs to be clear on
>> the actual goals for Trial-3. In particular I'd like to know:
>>
>> 1 Are we aiming to enable this by default for Trial-3
>>     
>
> Yes.  If activities in containers don't go into Trial 3, they will not
> get into FRS.  They don't have to be locked down at all, just have
> activities launched in containers.  We just have to figure out by
> Trial-3 if people can fix the bugs that come up.  If they can't, we rip
> containers back out and re-evaluate the security position.
>
>   
>> 2 Are we aiming at pushing one-instance-per-process for Trial-3
>>     
>
> We may just end up whitelisting EToys and Browse as
> multiple-instance-per-process activities, and just accept that one
> Browse instance can interact adversely with all other instances.  I
> don't think we've  made that call concretely yet though we did discuss
> it on the train today.
>   
This has always been the plan for the two of them AFAIK. When we
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Stone | 1 Aug 06:24
Favicon
Gravatar

Re: Initial Security Patches

Simon,

On Tue, 2007-07-31 at 14:20 +0100, Simon McVittie wrote:
> On Mon, 30 Jul 2007 at 16:21:36 -0400, Michael Stone wrote:
> >      @dbus.service.signal(_DBUS_OWNER_IFACE, signature="s")
> >      def CurrentActivityChanged(self, activity_id):
> > -        pass
> > +        if os.path.exists('/etc/olpc-security'):
> > +            self.rainbow.activity_changed(activity_id)
> 
> Minor: It's conventional for D-Bus methods to be named in CamelCase.

I don't care much whether we follow this convention or the PEP-8
convention:

    "Function names should be lowercase, with words separated by
    underscores as necessary to improve readability."

> More major: This looks like an example of the same method/signal
> naming inversion we have in Telepathy's streamed media interfaces (which we
> consider to be a bug). Methods should be verbs, like ChangeActivity;
> signals should be events, like ActivityChanged. Can't Rainbow just
> listen for _DBUS_OWNER_IFACE::CurrentActivityChanged? If you're implementing
> Rainbow in Python, that's spelt:
> 
>     bus = dbus.SessionBus()
>     bus.add_signal_receiver(some_callback, 'CurrentActivityChanged',
>                             _DBUS_OWNER_IFACE)

Rainbow runs as root; hence, it is statically prevented from connecting to the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ryan Pavlik | 1 Aug 06:57
Gravatar

Re: Docs?

By self-documenting I mean that the interface obviates the need for 
documentation, not that it produces written documentation.  You might be 
interested to look at http://wiki.laptop.org - it is as much (more!) an 
education project as a laptop project, and the educational theory behind 
the decision decisions is pretty interesting.

Ryan

dthornburg <at> aol.com wrote:
> If the OLPC is self-documenting, who is handling this, how much memory 
> does it take, and what does the interface look like?  It seems that 
> this would have come up in conversations by now.
>
> Just asking.
>
> David Thornburg
>
>
> -----Original Message-----
> From: Ryan Pavlik <abiryan <at> ryand.net>
> To: Edward Cherlin <echerlin <at> gmail.com>
> Cc: sugar <at> lists.laptop.org
> Sent: Tue, 31 Jul 2007 7:35 pm
> Subject: Re: [sugar] Docs?
>
> I am certainly not an OLPC rep, but what I have seen suggests that the 
>
> intent is for the machines to be self-instructing and not requiring 
>
> documentation.  In addition to the massive translation demands that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Noah Kantrowitz | 1 Aug 07:25
Picon
Favicon

Re: Initial Security Patches

Michael Stone wrote:
> Simon,
>
> On Tue, 2007-07-31 at 14:20 +0100, Simon McVittie wrote:
>   
>> On Mon, 30 Jul 2007 at 16:21:36 -0400, Michael Stone wrote:
>>     
>>>      @dbus.service.signal(_DBUS_OWNER_IFACE, signature="s")
>>>      def CurrentActivityChanged(self, activity_id):
>>> -        pass
>>> +        if os.path.exists('/etc/olpc-security'):
>>> +            self.rainbow.activity_changed(activity_id)
>>>       
>> Minor: It's conventional for D-Bus methods to be named in CamelCase.
>>     
>
> I don't care much whether we follow this convention or the PEP-8
> convention:
>
>     "Function names should be lowercase, with words separated by
>     underscores as necessary to improve readability."
>   
I changed the two new methods in rainbow, but left "create_activity" to
avoid breaking sugar.
>   
>> More major: This looks like an example of the same method/signal
>> naming inversion we have in Telepathy's streamed media interfaces (which we
>> consider to be a bug). Methods should be verbs, like ChangeActivity;
>> signals should be events, like ActivityChanged. Can't Rainbow just
>> listen for _DBUS_OWNER_IFACE::CurrentActivityChanged? If you're implementing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tomeu Vizoso | 1 Aug 09:41

Re: Journal: Sharing and Creative Commons Licenses

Hi,

On Tue, 2007-07-31 at 16:03 -0700, Scott Shawcroft wrote:
> Hi all,
> I'm Scott and am a tech intern at Creative Commons this summer.  This
> week I'm hoping to integrate licensing into the Journal in time for
> LinuxWorld here in SF.  I'd like to collaborate on this with the folks
> currently working on the journal.  We currently have some mockups of how
> it will be done but it doesn't currently align with the current journal
> implementation in build 540.  Before I can begin I need to discuss the
> implementation further with the developers.  A few questions I have are:
> 
> 1) Where is the code stored?  Is it packaged?

Repository: http://dev.laptop.org/git.do?p=journal-activity;a=summary

You can install it along with the rest of sugar in your regular computer
using sugar-jhbuild: http://wiki.laptop.org/go/Sugar_with_sugar-jhbuild

> 2) How should the children select the license?  We currently are using a
> dialog box in our mockups but I've heard that dialog boxes are not wanted.

Eben Eliason (cc'ed) can help you here.

> 3) Is sharing implemented yet?

Not yet, we're still figuring out the user experience. Eben, any new
thoughts on it?

> 4) Is there a license metadata field?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marco Pesenti Gritti | 1 Aug 13:48
Picon

Re: Initial Security Patches

On 8/1/07, Michael Stone <michael <at> laptop.org> wrote:
> Simon,
>
> On Tue, 2007-07-31 at 14:20 +0100, Simon McVittie wrote:
> > On Mon, 30 Jul 2007 at 16:21:36 -0400, Michael Stone wrote:
> > >      @dbus.service.signal(_DBUS_OWNER_IFACE, signature="s")
> > >      def CurrentActivityChanged(self, activity_id):
> > > -        pass
> > > +        if os.path.exists('/etc/olpc-security'):
> > > +            self.rainbow.activity_changed(activity_id)
> >
> > Minor: It's conventional for D-Bus methods to be named in CamelCase.
>
> I don't care much whether we follow this convention or the PEP-8
> convention:
>
>     "Function names should be lowercase, with words separated by
>     underscores as necessary to improve readability."

I think we should follow the D-Bus convention here. All the new code
in Sugar follows it (and we should probably fix the cases which
doesn't).

Marco
Permalink | Reply | 2 comments |

Gmane