Re: SuperUser permission for the Driver??
We have an activity that wants superuser privilege in order to poke kernel memory. The real questions we should be attempting to address here include: * Who is granting privilege to this activity? * How are they doing so? * How should we record the decision? - My tentative answer is that we should store activities with different security properties in well-known directory chains with appropriately restricted write access. * What kinds of abuse are these mechanisms vulnerable to? * Whose responsibility is it to handle the error condition that the human operator does not, him-or-herself posess superuser privilege, e.g. for theft-deterrence reasons? Comments? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
I am new to programming on Linux, I just searched for Setuid() and found that it sets the effective userid of my program to the userid I specify. So can I just call setuid() in my program when I need superuser privileges and have those privileges. To what part of my program are those privileges confined to? Thanks Shivaprasad On Wed, Jun 25, 2008 at 11:23 AM, James Cameron [EMAIL PROTECTED] wrote: So it is root UID you need for a user-space program, not a kernel driver, I see. Have you considered setuid? -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
Yoshiki Ohshima wrote:
Again, start up time is not a problem. Etoys start up looks a bit
slow on XO, but that is because the DBus communication that has to be
done.
I frequently hear DBus being accused of latency. As badly
implemented as it might be, I can't believe a daemon relaying
a bunch of bytes over a UNIX domain socket can introduce more
than 1ms of lag per message, even on a very slow processor.
Has anybody ever analyzed the actual DBus traffic? With timings?
How many messages are we talking about?
It seems that you are right! I took profile data in Etoys and the
DBus part accounts for about 60-70ms on start up. Other 3 seconds are
spent on Squeak part and I think I could speed them up a bit.
The following two message tallys are taken from two different part
of code upon start up. They should cover most of it.
Sorry for the false alerm.
-- Yoshiki
--
- 1761 tallies, 2164 msec.
**Tree**
95.3% {2062ms} SystemDictionarysend:toClassesNamedIn:with:
|43.2% {935ms} Delay class(Behavior)startUp:
| |17.0% {368ms} SecurityManager classstartUp
| | |17.0% {368ms} SecurityManagerstartUp
| | | 17.0% {368ms} SecurityManagerloadSecurityKeys
| | |16.8% {364ms} Object classreadFrom:
| | | 10.6% {229ms} Array(Object)isKindOf:
| | | 6.2% {134ms} Compiler classevaluate:
| | |6.2% {134ms} Compiler classevaluate:for:logged:
| | | 6.2% {134ms} Compiler classevaluate:for:notifying:logged:
| | |6.2% {134ms}
Compilerevaluate:in:to:notifying:ifFail:logged:
| | | 6.0% {130ms} Compilertranslate:noPattern:ifFail:
| | |6.0% {130ms}
Parserparse:class:noPattern:context:notifying:ifFail:
| | | 4.7% {102ms} Parserinit:notifying:failBlock:
| | |4.7% {102ms} Parser(Scanner)scan:
| | | 4.7% {102ms} Parser(Scanner)scanToken
| | |4.7% {102ms} Parser(Scanner)xLitQuote
| | | 4.7% {102ms} Parser(Scanner)scanToken
[4.7% {102ms} Parser(Scanner)xLitQuote
[ 2.4% {52ms} Parser(Scanner)scanToken
[|2.4% {52ms} Parser(Scanner)xLitQuote
[ 2.3% {50ms} Parser(Scanner)scanLitVec
[2.3% {50ms} Parser(Scanner)scanToken
[ 2.3% {50ms} Parser(Scanner)xLitQuote
| |14.2% {307ms} FileDirectory classstartUp
| | |9.7% {210ms} FileDirectory classsetDefaultDirectory:
| | | |9.4% {203ms} FilePath classpathName:
| | | | 9.4% {203ms} FilePath classpathName:isEncoded:
| | | |9.4% {203ms} FilePathpathName:isEncoded:
| | | | 9.4% {203ms} LanguageEnvironment
classdefaultFileNameConverter
| | | |9.4% {203ms} SystemDictionaryplatformName
| | | | 9.4% {203ms} SystemDictionarygetSystemAttribute:
| | | |9.4% {203ms} SystemDictionary(Object)deprecated:block:
| | | | 9.4% {203ms} Preferences
classshowDeprecationWarnings
| | | |9.4% {203ms} Preferences
classvalueOfFlag:ifAbsent:
| | |3.1% {67ms} SmalltalkImageopenSourceFiles
| | | 3.0% {65ms} FileDirectory classopenSources:andChanges:forImage:
| | |2.6% {56ms} FileDirectory classopenSources:forImage:
| |7.3% {158ms} ExternalSettings classstartUp
| | |7.3% {158ms} ExternalSettings classpreferenceDirectory
| | | 6.2% {134ms} SmalltalkImagevmPath
| | |6.2% {134ms} FilePath classpathName:isEncoded:
| | | 6.2% {134ms} FilePathpathName:isEncoded:
| | |6.2% {134ms} ByteString(String)convertFromWithConverter:
| |3.8% {82ms} Delay classstartUp
|34.4% {744ms} WeakArray classstartUp:
| |34.4% {744ms} WeakArray classrestartFinalizationProcess
| | 34.2% {740ms} Semaphore classforMutualExclusion
|13.0% {281ms} AutoStart classstartUp:
| |7.4% {160ms} AutoStart classcheckForPluginUpdate
| | |7.4% {160ms} PasteUpMorphinstall
| | | 6.2% {134ms} PasteUpMorphinstallFlaps
| | |4.8% {104ms} ProjectassureFlapIntegrity
| | | 4.8% {104ms} IdentityDictionary(Dictionary)removeKey:ifAbsent:
| |5.6% {121ms} AutoStart classcheckForUpdates
| | 5.6% {121ms} PasteUpMorphinstall
| |3.5% {76ms} PasteUpMorphdisplayWorldSafely
| | |3.5% {76ms} WorldStatedisplayWorldSafely:
| | | 3.5% {76ms} PasteUpMorphdisplayWorld
| | |3.5% {76ms} PasteUpMorphprivateOuterDisplayWorld
| | | 3.5% {76ms} WorldStatedisplayWorld:submorphs:
| | |3.5% {76ms} WorldStatedrawWorld:submorphs:invalidAreasOn:
| | | 3.5% {76ms} FormCanvas(Canvas)fullDrawMorph:
| | |3.5% {76ms} FormCanvas(Canvas)fullDraw:
| | | 3.5% {76ms} SugarNavTab(Morph)fullDrawOn:
| | |3.5% {76ms} SugarNavTab(Morph)drawSubmorphsOn:
| | | 3.5% {76ms} FormCanvas(Canvas)fullDrawMorph:
Want to package PostgreSQL for OLPC
Hi, Per e-mail from Michael Stone: https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01331.html I would like to assist packaging PostgreSQL for OLPC. I'm the upstream packager for PostgreSQL, and I also maintain 30+ packages for Fedora+EPEL. What should I do next? Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates This Week to the Sugar Almanac - Using the Datastore and More
Hi Faisal, some answers below:
2008/6/24 Faisal Anwar [EMAIL PROTECTED]:
?? Is there a specific reason why there isn't a set() method in the
datastore.DSMetadata class? Shouldn't people be given standard accessors and
mutators to work with this code. This is especially confusing because it
seems there is presently a get() method, but the set() method does not
exist (so the abstraction is completely different based on whether you are
getting or setting data). d
That class is to be used in the same way as dictionaries in python, so
the API mimics that. By implementing __getitem__, __setitem__ and
get(), the user can do the following:
obj.metadata['my-property'] = 'blah blah'
print obj.metadata['my-property']
print obj.metadata.get('my-property', 'N/A')
?? Several things that are currently documented at
http://wiki.laptop.org/go/Low-level_Activity_API#Keeping_and_Resuming are
outdated. Specifically, it says datastore.create() returns the object_id.
That's wrong, it returns the actual DSObject. Furthermore, it says there are
methods called datastore.update and datastore.get_properties, but they don't
exists.
That page documents the low level API that can be used by all
activities, no matter in which language are written. sugar.datastore
is a higher level API only available to python activities. See here
for the D-Bus API of the datastore:
http://dev.laptop.org/git?p=projects/datastore;a=blob;f=src/olpc/datastore/datastore.py
?? The deletion/destruction of datastore activities seems to be a little
confusing. In particular, there is a datastore.delete() method and there is
also a DSObject.destroy() method. Why doesn't datastore.delete() simply call
the destroy() method in its code so that any files associated with the
deleted datastore object are also removed. Given that a warning is thrown
telling the developer that an object is deleted without directly calling
DSObject.destroy() (it is called indirectly through the __del__ method, but
why not have things more explicit?), I'm not sure why this isn't just done
programmatically. Is there ever a reason why one woul perform a delete() on
an object without doing the functionality in DSObject.destroy() and are any
of these reasons compelling enough that we should keep the delete() and
destroy() methods as they are now?
Well, datastore.delete() instructs the datastore to delete the object
from its persistent storage. DSObject.destroy() is intended to be
called when the user stops needing the transient instance that
represents the persistent object.
This is similar to DB programming with SQL in procedural languages,
deleting the resultset object is not the same as deleting the rows
that are contained in that resultset.
Other questions may come up as people work more on this documentation. In
the meantime, I'd greatly appreciate any feedback on the existing work and
also any answers to the questions above.
Nice work, more questions welcome.
Regards,
Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
On Wed, Jun 25, 2008 at 4:23 AM, Bernie Innocenti [EMAIL PROTECTED] wrote:
Also, I'd like to check if we could do anything to reduce our
dependence on DBus to provide basic desktop services for which
there are existing Freedesktop standards and long established
X conventions.
If we manage to make DBus entirely optional, the initial effort
of porting a Linux applications to Sugar would be greatly
simplified.
As far as I know this is already the case. The only non standard bit
are a couple of custom X properties.
The activity has a DBus service associated with the following methods:
@dbus.service.method(_ACTIVITY_INTERFACE)
def SetActive(self, active):
logging.debug('ActivityService.set_active: %s.' % active)
self._activity.props.active = active
@dbus.service.method(_ACTIVITY_INTERFACE)
def Invite(self, buddy_key):
self._activity.invite(buddy_key)
@dbus.service.method(_ACTIVITY_INTERFACE)
def TakeScreenshot(self):
self._activity.take_screenshot()
They are all optional. SetActive we might be able to get rid off.
TakeScreenshot is quite an hack, we might be able to use gtk offscreen
rendering or composite to get rid of it in the future. Invite I
personally think it's fine to stay a DBus method.
Obviously you start to need DBus heavily as soon as you want to
interact with the journal and the presence service, though.
Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: etoys implementation
My only experience with Squeak/eToys up til now was trying it on the OLPC as a naive user. Poking at objects on the screen with the handles, since that was the only tutorial offered. The way the darn thing saved its workspace in the friggin Journal whenever you tried to quit it reminded me of ancient APL interpreters that contained a jumble of code and data, and Holger's explanation of why it's non-free reinforced that. Of course I have no idea how it's actually implemented inside. (There's apparently no tarball that I could unpack and examine to find out, either; I'd have to learn how to run their GUI just to look at their implementation.) It took some searching, but I found a paper on the design of the guts of Squeak: ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html I don't know if it is still good documentation for the current implementation, but it gives some idea of how Squeak was originally built. The interpreter was written and maintained in a subset of high-level Squeak (smalltalk) but there's also a translator that translates that interpreter into C, which is then compiled to produce a binary interpreter. Whether it does this dynamically or statically I have no idea. Then there's a separate Compiler that turns Squeak/Smalltalk source code into bytecode objects that the interpreter can run? There's another page that purports to talk about how a Squeak image is built, but after explaining how most people never quite feel at home in a Squeak .changes file, it degenerates into details that make no sense to an outsider. Avoid http://wiki.squeak.org/squeak/1053 until somebody rewrites it in English. The rest of the internals doc is sketchy copies of emails, with newer headings that say things like The last system where this worked is 2.7 (January 2000). I haven't yet found similar documentation for eToys, which is apparently something built on squeak rather than built in? There's also a warning at http://wiki.squeak.org/squeak that if you want to run eToys, you need to run a different version of Squeak than everybody else. Anyway, it looks like there's lots of stuff hiding under the covers in Squeak and eToys, but it's so undocumented that only a zealot would ever figure out where or how to start. Perhaps the team should someday spend a month or two on documentation -- after all, it's an education project, and if nobody can even find your source code, how are they going to read it and educate themselves? Or some zealot could do the supposedly trivial implementation exercise of making source code go into separate files, and being able to actually compile source from files into binaries in files, rather than compiling only from running images to running images. These improvements would make the freedom or lack thereof of Squeak/eToys more visible to ordinary programmers -- like me, or the Debian team. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Rebuilt Rainbow olpc-utils
Dear Dennis devel, I rebuilt rainbow olpc-utils. olpc-utils underwent a relatively exciting merge wherein I combined patches from several contributors. I've diffed the resulting RPM against olpc-utils-0.73.2 and I think it will work, but I haven't tested it yet. Also, I built rainbow in F-9 since it doesn't have an OLPC-3 branch, since the F-9 branch was handy, and since I might get some useful bug reports as a result... :) Feel free to ask me to repair the damage (or to do so yourself) if I should have poked someone to make the OLPC-3 branch instead. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Software Status Meeting Today (Wednesday) @ 1400 EDT, 1800 UTC in #olpc-meeting on freenode
Dear friends, Let's welcome Scott home from his vacation by describing all the easy bugs that we squashed in his absence and all the really nasty bugs that we couldn't solve without him. Michael P.S. - We're going to start regular release status meetings in addition to the Wednesday development status meetings so that we make sure we spend enough time resourcing current needs. I'm thinking that Tuesday, somewhere in 1:00 PM - 3:00 PM EDT might be a good time. Comments? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rebuilt Rainbow olpc-utils
Just fyi here is how you usually request branches: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure (Thanks for the build) Marco On Wed, Jun 25, 2008 at 11:28 AM, Michael Stone [EMAIL PROTECTED] wrote: Dear Dennis devel, I rebuilt rainbow olpc-utils. olpc-utils underwent a relatively exciting merge wherein I combined patches from several contributors. I've diffed the resulting RPM against olpc-utils-0.73.2 and I think it will work, but I haven't tested it yet. Also, I built rainbow in F-9 since it doesn't have an OLPC-3 branch, since the F-9 branch was handy, and since I might get some useful bug reports as a result... :) Feel free to ask me to repair the damage (or to do so yourself) if I should have poked someone to make the OLPC-3 branch instead. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
Am 25.06.2008 um 10:49 schrieb Marco Pesenti Gritti:
On Wed, Jun 25, 2008 at 4:23 AM, Bernie Innocenti
[EMAIL PROTECTED] wrote:
Also, I'd like to check if we could do anything to reduce our
dependence on DBus to provide basic desktop services for which
there are existing Freedesktop standards and long established
X conventions.
If we manage to make DBus entirely optional, the initial effort
of porting a Linux applications to Sugar would be greatly
simplified.
As far as I know this is already the case. The only non standard bit
are a couple of custom X properties.
The activity has a DBus service associated with the following methods:
@dbus.service.method(_ACTIVITY_INTERFACE)
def SetActive(self, active):
logging.debug('ActivityService.set_active: %s.' % active)
self._activity.props.active = active
@dbus.service.method(_ACTIVITY_INTERFACE)
def Invite(self, buddy_key):
self._activity.invite(buddy_key)
@dbus.service.method(_ACTIVITY_INTERFACE)
def TakeScreenshot(self):
self._activity.take_screenshot()
They are all optional. SetActive we might be able to get rid off.
TakeScreenshot is quite an hack, we might be able to use gtk offscreen
rendering or composite to get rid of it in the future. Invite I
personally think it's fine to stay a DBus method.
Obviously you start to need DBus heavily as soon as you want to
interact with the journal and the presence service, though.
Well, since these methods are not mandatory there is no need to get
rid of them. An activity can still choose to implement activation/
deactivation by other means, for example.
- Bert -
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Tue, 2008-06-24 at 18:09 -0400, Polychronis Ypodimatopoulos wrote: Sjoerd Simons wrote: I'm setting the ESSID on the msh0 interface indeed. But i never get an association event on it.. While i even get an association event on eth0 when it's not up (but with msh0 being up obviously) :) Seems i've got some more bugs to file Why would you set an ESSID on the mshX interface in the first place? I understand that, from a solid layering perspective, you should be able to set essids on mshX since it's treated as a wireless interface, but it would logically separate network users. It's hard enough as it is to discover nodes in different channels (although different channels do have a radio scaling advantage). You need a way to tell the firmware that you'd like to apply the configuration. And once you tell the firmware that, the firmware somehow needs to notify you that it's completed the requested operations. There is a small but noticeable amount of time between when you send the request, and when the firmware has completed the channel change and set up the state. If you don't wait for the notification, you'll assume you can send traffic when you actually cannot, and things like mDNS announcements and such will be lost. With WEXT, setting either the SSID or the BSSID are those triggers, and the SIOCGIWAP event is the notification. Unfortunately, because WEXT doesn't have a direct link between requests and replies, we have to enforce stricter semantics on behavior. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Wed, 2008-06-25 at 02:34 +0100, Sjoerd Simons wrote: On Tue, Jun 24, 2008 at 06:09:58PM -0400, Polychronis Ypodimatopoulos wrote: Sjoerd Simons wrote: I'm setting the ESSID on the msh0 interface indeed. But i never get an association event on it.. While i even get an association event on eth0 when it's not up (but with msh0 being up obviously) :) Seems i've got some more bugs to file Why would you set an ESSID on the mshX interface in the first place? I understand that, from a solid layering perspective, you should be able to set essids on mshX since it's treated as a wireless interface, but it would logically separate network users. It's hard enough as it is to discover nodes in different channels (although different channels do have a radio scaling advantage). Because we can? Seriously it's not for NetworkManager to decide this kind of policy, some higher layer needs to tell it what to do. If that's the same essid for all machine that's fine (most likely the update sugar NM bits will just have one essid hardcoded). The current wireless firmware might not even actually bother with checking essid's on traffic all. The firmware's mesh functionality doesn't care what the SSID is. The only thing that distinguishes one mesh from another is the tuple of (channel, encryption). I don't even think BSSID matters (which it does in ad-hoc and infrastructure networks). Thus, the only policy that upper layers can or need to apply is the channel and encryption that the connection might use; hence why we eventually exposed the separate channels in Sugar. Dan The more important part, like Dan explained, is that this is the way to tell wireless drivers in linux to go and configure what's needed and tell us when they're ready for actual traffic (by means of an association event). So we can start doing things like dhcp and/or autoip. Sjoerd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
On 25.06.2008 08:07, Michael Stone wrote: We have an activity that wants superuser privilege in order to poke kernel memory. Hello? Please take the poor activity out back and shoot it. No activity has any business poking kernel memory. The real questions we should be attempting to address here include: * Who is granting privilege to this activity? Everybody who wants to ridicule the security model. * How are they doing so? * How should we record the decision? - My tentative answer is that we should store activities with different security properties in well-known directory chains with appropriately restricted write access. * What kinds of abuse are these mechanisms vulnerable to? * Whose responsibility is it to handle the error condition that the human operator does not, him-or-herself posess superuser privilege, e.g. for theft-deterrence reasons? Just say no. Having an activity poke kernel memory is a really strong sign that the interface is totally broken. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Want to package PostgreSQL for OLPC
2008/6/25 Devrim GÜNDÜZ [EMAIL PROTECTED]: I would like to assist packaging PostgreSQL for OLPC. I'm the upstream packager for PostgreSQL, and I also maintain 30+ packages for Fedora+EPEL. What should I do next? Hi Devrim! Thanks for getting in touch - I am the guy looking after the School Server, and that's where we need Pg. Right now, we are based on F7 and though we plan to move to F9, that will take a little bit of time. I am hoping to have Pg 8.2 or 8.3, and I think F9 already has it. How hard is it to get a backport of Pg8.2/8.3, plus some key dependencies (php-pgsql, python-pgsql, pam-pgsql) recompiled to use the new libpq, all on F7? Also - I see you work at CommandPrompt -- so I'll throw a wishlist item I have on my list in your direction. Perhaps you, or someone at CommandPrompt has something similar. With Pg packaged, what we will need to come up with is ~3 sets of config files tuned for different memory footprints. The same XS image will be used in hosts with various memory configurations - 256MB RAM on XO hardware, 1GB on the recommended config, and high-end hosts may have more RAM. Pg cannot take all of that memory, but perhaps 15%-20% is a reasonable footprint. The workload for Pg is mainly Moodle and MediaWiki. One of the key things for the XS is that we should not OOM, and our working set _must not_ end up in swap. And we have several services we have to run, so it's a bit of a tough diet on RAM usage. We gotta sweat every MB :-) cheers, and thanks, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Want to package PostgreSQL for OLPC
On Wed, 2008-06-25 at 08:48 -0400, Martin Langhoff wrote: How hard is it to get a backport of Pg8.2/8.3, plus some key dependencies (php-pgsql, python-pgsql, pam-pgsql) recompiled to use the new libpq, all on F7? http://yum.pgsqlrpms.org ;) I have already built all PG combinations against Fedora 7-8-9 and RHEL 4,5. We have compat packages, and all pam-pgsql, etc in that repository. So, using those files won't be a problem. Also - I see you work at CommandPrompt -- so I'll throw a wishlist item I have on my list in your direction. Perhaps you, or someone at CommandPrompt has something similar. With Pg packaged, what we will need to come up with is ~3 sets of config files tuned for different memory footprints. The same XS image will be used in hosts with various memory configurations - 256MB RAM on XO hardware, 1GB on the recommended config, and high-end hosts may have more RAM. Sure, it is doable -- I can do it for you. Pg cannot take all of that memory, but perhaps 15%-20% is a reasonable footprint. The workload for Pg is mainly Moodle and MediaWiki. Ok. One of the key things for the XS is that we should not OOM, and our working set _must not_ end up in swap. And we have several services we have to run, so it's a bit of a tough diet on RAM usage. We gotta sweat every MB :-) You are right. So, please let me know when you need the config files, and also how can I submit those packages to OLPC repository. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Want to package PostgreSQL for OLPC
On Wed, 2008-06-25 at 09:44 -0400, Martin Langhoff wrote: We have compat packages, and all pam-pgsql, etc in that repository. So, using those files won't be a problem. Fantastic! So python-pgsql and php-pgsql are there too? python-psycopg2 is there, but not php-pgsql. The question is: Is php-pgsql already in OLPC package set? If yes, we have compat packages to satisfy dependencies. If not, I can give it a shot. ... So, please let me know when you need the config files, and also how can I submit those packages to OLPC repository. When? Yesterday ;-) - but perhaps there is no need for rebuilding the packages. What I am wondering about is what the best solution is to maintain those alternative configurations long-term. Perhaps we could have a postgresql-server-altinit package that provides an alternative init script + config files and disables the init script from postgresql-server. The alternative init check memory size, and starts with the appropriate config files. Maybe we can solve this issue during initdb process, and copy the preconfigured config file based on the memory to data directory after we run initdb. It may be easier to maintain... BTW... I must admit that I did not work for OLPC project before, so I don't know how to do things. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [RFC] Unscheduled Software Release for SD Card Corruption Workaround
On Jun 25 2008, at 00:04, Kim Quirk was caught saying: Thanks Deepak. I'd love to see the SD card corruption fixed, but we are just about finished with testing and are now in the release process for 8.1.1... so i recommend that we schedule this fix for the 8.1.2 release (if we do this release) and make sure it gets into 8.2.0, which might be the next release we get out the door. Ah, I didn't fully grok our release schedule and thought 8.1.1 was already out the door. Other thoughts? Eric and I talked about this a bit yesterday and we thought that doing a full USR is probably not needed. What we're looking at doing to help the G1G1 users who are impacted by this is to spin a kernel RPM and initrd that they can install. ~Deepak -- Deepak Saxena [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2073
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2073 Changes in build 2073 from build: 2072 Size delta: 0.52M -gnash-plugin 0.8.2-2.fc9 +gnash-plugin 0.8.3-1.olpc3 -olpc-utils 0.73-2.olpc3.3 +olpc-utils 0.75-1.olpc3 -gnash 0.8.2-2.fc9 +gnash 0.8.3-1.olpc3 -sugar-presence-service 0.81.2-1.olpc3 +sugar-presence-service 0.81.2-2.olpc3 --- Changes for olpc-utils 0.75-1.olpc3 from 0.73-2.olpc3.3 --- + Add registration utility --- Changes for gnash 0.8.3-1.olpc3 from 0.8.2-2.fc9 --- + update to 0.8.3 and adapt to OLPC + rebuild against new xulrunner + ship libklashpart (#441601) -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
Hi, John, My only experience with Squeak/eToys up til now was trying it on the OLPC as a naive user. Poking at objects on the screen with the handles, since that was the only tutorial offered. The way the darn thing saved its workspace in the friggin Journal whenever you tried to quit it reminded me of ancient APL interpreters that contained a jumble of code and data, and Holger's explanation of why it's non-free reinforced that. Of course I have no idea how it's actually implemented inside. (There's apparently no tarball that I could unpack and examine to find out, either; I'd have to learn how to run their GUI just to look at their implementation.) Is this discussion still on whether Etoys can be in Debian? Whether it can or cannot doesn't depend on whether Journal is friggn, the way it saves the workspace content, or the fact that you have to learn how to run (?) the GUI to look at its implementation. The fact that you better to (strictly speaking, you don't have to) use a particular editor is a requirement? (BTW, http://wiki.laptop.org/go/Smalltalk_Development_on_XO might be helpful. Read SqueakV3.sources as EtoysV3.sources in the page, though. http://static.squeak.org/tutorials/BankAccount.html is obsolete, but a classic tutorial.) Lack of some documentation is a problem, but once you know where to click in the GUI, *all* code are nicely hyperlinked together so that reading code and learning it becomes so easy and encouraging. That is why many developers who used to it lose motivation to write getting started documents^^; It is definitely learnable. There are many new (young and old) poeple get interested in Smalltalk all the time and poking around. Papers are published to prestige and not-so-prestige computer science conferences constantly on making deep changes to Smalltalk or making applications, etc. There are companies that are making products. By its nature, it is true that it is much, much easier to get started when you have somebody who already knows it around but it is sometimes hard to find such a person. But let us not derail the discussion. This discssion is not about making you like Etoys/Squeak. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC config in salut in F9?
On Wed, Jun 25, 2008 at 12:01, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mardi 24 juin 2008 à 17:36 -0700, Brian Pepple a écrit : On Wed, 2008-06-25 at 01:12 +0200, Morgan Collett wrote: Can we enable the OLPC-specific patches and config in telepathy-salut in F-9? We're rebasing OLPC builds on F-9 and it would be good to work in the F-9 branch and not need to fork. Does it make sense to have these patches in F9? I'm on vacation right now, so I don't really have time to look at the patches. If it makes sense to have these in F9 in addition to OLPC, I don't have a problem with you doing enabling it. Not really. These patches are ugly OLPC specific workarounds due to XO security model (Rainbow). Building Salut with --enable-olpc doesn't hurt though (Debian does). OK, then we want to make an OLPC-3 branch and build salut there with the patches. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC config in salut in F9?
On Wed, Jun 25, 2008 at 6:15 PM, Morgan Collett [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 12:01, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mardi 24 juin 2008 à 17:36 -0700, Brian Pepple a écrit : On Wed, 2008-06-25 at 01:12 +0200, Morgan Collett wrote: Can we enable the OLPC-specific patches and config in telepathy-salut in F-9? We're rebasing OLPC builds on F-9 and it would be good to work in the F-9 branch and not need to fork. Does it make sense to have these patches in F9? I'm on vacation right now, so I don't really have time to look at the patches. If it makes sense to have these in F9 in addition to OLPC, I don't have a problem with you doing enabling it. Not really. These patches are ugly OLPC specific workarounds due to XO security model (Rainbow). Building Salut with --enable-olpc doesn't hurt though (Debian does). OK, then we want to make an OLPC-3 branch and build salut there with the patches. It would still be good if we could --enable-olpc on the F9 packages, so that Sugar can work right in Fedora 9. Morgan could you take care of that? I agree that the ugly rainbow workarounds should be kept in OLPC-3. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [RFC] Unscheduled Software Release for SD Card Corruption Workaround
Deepak, I think you should feel free to release information and kernel rpms to the devel list, pretty much whenever you want since you (or others) can answer questions and help people who want to try this out. I would consider this as 'developer testing' -- which is great and shouldn't get bogged down in too much process. The benefit of going through a 'release process', in general, is to get the feature or bug fix out to the general public, documented (and supportable), after a more formal QA process. After you are happy with the developer testing, if there is a big enough demand in the general public we can go through the unscheduled release process to get a formal build, testing, and release (8.1.1). If the demand isn't too large and the timing is such that we are pretty close to 8.2.0 release, then we should target it for that release. Kim On Wed, Jun 25, 2008 at 9:14 AM, Deepak Saxena [EMAIL PROTECTED] wrote: On Jun 25 2008, at 00:04, Kim Quirk was caught saying: Thanks Deepak. I'd love to see the SD card corruption fixed, but we are just about finished with testing and are now in the release process for 8.1.1... so i recommend that we schedule this fix for the 8.1.2 release (if we do this release) and make sure it gets into 8.2.0, which might be the next release we get out the door. Ah, I didn't fully grok our release schedule and thought 8.1.1 was already out the door. Other thoughts? Eric and I talked about this a bit yesterday and we thought that doing a full USR is probably not needed. What we're looking at doing to help the G1G1 users who are impacted by this is to spin a kernel RPM and initrd that they can install. ~Deepak -- Deepak Saxena [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New faster build 2073
http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2073 Changes in build 2073 from build: 2071 Size delta: 0.00M -sugar-presence-service 0.81.2-1.olpc2 +sugar-presence-service 0.81.2-2.olpc2 --- Changes for sugar-presence-service 0.81.2-2.olpc2 from 0.81.2-1.olpc2 --- + Depends on telepathy-salut and telepathy-gabble -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC config in salut in F9?
On Wed, Jun 25, 2008 at 18:27, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 6:15 PM, Morgan Collett [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 12:01, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mardi 24 juin 2008 à 17:36 -0700, Brian Pepple a écrit : On Wed, 2008-06-25 at 01:12 +0200, Morgan Collett wrote: Can we enable the OLPC-specific patches and config in telepathy-salut in F-9? We're rebasing OLPC builds on F-9 and it would be good to work in the F-9 branch and not need to fork. Does it make sense to have these patches in F9? I'm on vacation right now, so I don't really have time to look at the patches. If it makes sense to have these in F9 in addition to OLPC, I don't have a problem with you doing enabling it. Not really. These patches are ugly OLPC specific workarounds due to XO security model (Rainbow). Building Salut with --enable-olpc doesn't hurt though (Debian does). OK, then we want to make an OLPC-3 branch and build salut there with the patches. It would still be good if we could --enable-olpc on the F9 packages, so that Sugar can work right in Fedora 9. Morgan could you take care of that? Yes, I'll do that. I agree that the ugly rainbow workarounds should be kept in OLPC-3. I've done a scratch build of telepathy-salut for dist-f9 with the patches: http://dev.laptop.org/~morgan/telepathy-salut/ I'll request the branch. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
John, I separated the real Etoys implementation part from your email. Hopefully it helps to focus on different aspects of discussion. It took some searching, but I found a paper on the design of the guts of Squeak: ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html I don't know if it is still good documentation for the current implementation, but it gives some idea of how Squeak was originally built. At the basic part on how it works, the paper is still valid and good. The performace increased since then quite a bit, and there are other semi-major improvements, but that is ok. Probably you can find a copy of the proceedings (OOPSLA '97) somewhere if you like the paper version. The interpreter was written and maintained in a subset of high-level Squeak (smalltalk) but there's also a translator that translates that interpreter into C, which is then compiled to produce a binary interpreter. Whether it does this dynamically or statically I have no idea. Because it is into C, it is statically done. In the later versions and platform that support loading shared libraries (called plugins) onto the VM, you could write some code for plugin in Squeak, generate C, compile the C code to make a shared library and load it onto the running Squeak session. But that is besides the point. Then there's a separate Compiler that turns Squeak/Smalltalk source code into bytecode objects that the interpreter can run? Yes. The Compiler is written in Squeak and the compiled result of the Compiler itself is in the image. There's another page that purports to talk about how a Squeak image is built, but after explaining how most people never quite feel at home in a Squeak .changes file, it degenerates into details that make no sense to an outsider. The paper definitely serves its intended audience (programming language designers and implementors.) The paper is cited quite often by papers from other language communities. I haven't yet found similar documentation for eToys, which is apparently something built on squeak rather than built in? Where did you find built on vs. built in discussion? It doesn't sound like an important distinction. The Etoys system is a bunch of additional code written in Squeak. There are some deep changes in the base classes of Squeak to support Etoys so it just happen to be distributed as a separated packaged version called Etoys. There is no good documentation (as far as I know) on how Etoys is implemented other than the source. But again, the code is nicely hyperlinked and the live system is there, learning it is possible if you know Squeak. (Etoys is like an application. How many applications you use have good documentation how they are implemented, though?) There's also a warning at http://wiki.squeak.org/squeak that if you want to run eToys, you need to run a different version of Squeak than everybody else. *That* is Etoys. What is wrong with it? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
There's also a warning at http://wiki.squeak.org/squeak that if you want to run eToys, you need to run a different version of Squeak than everybody else. *That* is Etoys. What is wrong with it? Just out of curiosity: Exactly how is it different from vanilla squeak? (If there is such a thing at all.) Is it a different VM, or just a different distribution since it has a different binary blob? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
There's also a warning at http://wiki.squeak.org/squeak that if you want to run eToys, you need to run a different version of Squeak than everybody else. *That* is Etoys. What is wrong with it? Just out of curiosity: Exactly how is it different from vanilla squeak? (If there is such a thing at all.) Whichever two images you would like to compare (why not write Squeak?), launch two images and evaluate: Smalltalk condenseSources. or equivalent in them. Each of image will make a .sources file so you get two .sources file. Then, use diff (perhaps you might want to convert CR to LF before that) to see the difference. Is it a different VM, or just a different distribution since it has a different binary blob? The VM is well synchronized with the trunk VM. They were identical a few weeks ago. We now have a few more patches in the OLPC VM branch but it is not significant. The VM is a separeted rpm BTW. Why do you refer it to as binary blob? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
NoiseEHC wrote: There's also a warning at http://wiki.squeak.org/squeak that if you want to run eToys, you need to run a different version of Squeak than everybody else. *That* is Etoys. What is wrong with it? Just out of curiosity: Exactly how is it different from vanilla squeak? (If there is such a thing at all.) Is it a different VM, or just a different distribution since it has a different binary blob? The Etoys image is different than the main Squeak image, which is mostly used by researchers and web developers.The main Squeak image is more focused on maintaining the Smalltalk libraries and IDE features while Etoys is more like a application. One drawback of the Smalltalk image is it's monolithic nature and while the separation of the main classes and Etoy classes can be done, it's a big job and can become a hassle when all kinds of different users have their own agenda and objectives. Therefor a plethora of images are available and are specialized for their use, much like different Linux distributions. Karl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Want to package PostgreSQL for OLPC
On Wed, Jun 25, 2008 at 9:52 AM, Devrim GÜNDÜZ [EMAIL PROTECTED] wrote: python-psycopg2 is there, but not php-pgsql. The question is: Is php-pgsql already in OLPC package set? If yes, we have compat packages to satisfy dependencies. If not, I can give it a shot. It's not mentioned in our current metapackage. I would go for a libpq4-based php-pgsql if possible. Maybe we can solve this issue during initdb process, and copy the preconfigured config file based on the memory to data directory after we run initdb. Probably not tied to initdb - service init is the right time to assess physical RAM, copes with HW changes that may happen between boots, and also allows us to deploy new versions of the template files. BTW... I must admit that I did not work for OLPC project before, so I don't know how to do things. Nothing too special here :-) - it's a F7 system that aims to be as appliance-like as possible. thanks! m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
Thanks! Why do you refer it to as binary blob? That was the first word jumped into my mind. All I know is that it is not in CVS or GIT so nothing serious. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC XO Opera browser as Sugar activity
Hi All, I run Opera on the XO, but if started as an activity it doesn't run (it runs fine when started from terminal). There is a note on the Opera install page that there is an incompatibility between Rainbow and Opera: Note: There is at present an incompatibility between the Opera activity and the OLPC Rainbow security system on some builds. If when you launch the Opera activity, the screen goes blank and stays blank, you have likely encountered that incompatibility. http://wiki.laptop.org/go/Opera That is the symptom I encounter. Could one of you tell me what this incompatibility is, and how to remove it? I'm using build 703, the latest stable build. -Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
On Wed, Jun 25, 2008 at 11:00 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: [John Gilmore wrote:] There's also a warning at http://wiki.squeak.org/squeak that if you want to run eToys, you need to run a different version of Squeak than everybody else. *That* is Etoys. What is wrong with it? Yes, Etoys is precisely a version of Squeak with more objects added in. Just out of curiosity: Exactly how is it different from vanilla squeak? (If there is such a thing at all.) More objects written in Squeak. Whichever two images you would like to compare (why not write Squeak?), launch two images and evaluate: Smalltalk condenseSources. or equivalent in them. Explain to John and me how you get a command line in Etoys. No, I see it. It's the text input mode in a Scriptor. http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/englisch/sqk/sqk00046.htm tells you how to operate the controls to get to a scriptor and type in it to create a changes file. doFileout Smalltalk changes fileOut. self beep: 'croak' Actually, John, everything you need is in the Etoys Help tool--Script Tiles, Object Catalog, and Halo Handles (including the Viewer and Debugger)--and the Squeak tutorial http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/index.html Each of image will make a .sources file so you get two .sources file. Then, use diff (perhaps you might want to convert CR to LF before that) to see the difference. Is this .sources output what Debian is asking for? If not, why not, and what would we have to do to complete it from their point of view? http://wiki.squeak.org/squeak/759 Smalltalk condenseSources extracts the currently valid definitions form both the sources file and the changes file and merges these into an new sources file SourcesV3.6 (you are asked to supply the name of the new sources file). All outdated definitions are dropped. We have a 14MBytes sources and 10 MBytes changes file. When these merge we have a 16 MBytes source file and a nearly empty changes file. We therefore conclude, that the 10 MBytes of the changes contained 2 MBytes new code and 8 MBytes development history. Can gst bring in a .sources file and a .changes file and create a working image? Is it a different VM, or just a different distribution since it has a different binary blob? The VM is well synchronized with the trunk VM. They were identical a few weeks ago. We now have a few more patches in the OLPC VM branch but it is not significant. The VM is a separeted rpm BTW. Why do you refer it to as binary blob? Yeah, it's mostly Smalltalk source and objects created in Smalltalk. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
Am 25.06.2008 um 23:25 schrieb Edward Cherlin: On Wed, Jun 25, 2008 at 11:00 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: [John Gilmore wrote:] There's also a warning at http://wiki.squeak.org/squeak that if you want to run eToys, you need to run a different version of Squeak than everybody else. *That* is Etoys. What is wrong with it? Yes, Etoys is precisely a version of Squeak with more objects added in. Just out of curiosity: Exactly how is it different from vanilla squeak? (If there is such a thing at all.) More objects written in Squeak. Whichever two images you would like to compare (why not write Squeak?), launch two images and evaluate: Smalltalk condenseSources. or equivalent in them. Explain to John and me how you get a command line in Etoys. No, I see it. It's the text input mode in a Scriptor. http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/englisch/sqk/sqk00046.htm tells you how to operate the controls to get to a scriptor and type in it to create a changes file. doFileout Smalltalk changes fileOut. self beep: 'croak' Actually, John, everything you need is in the Etoys Help tool--Script Tiles, Object Catalog, and Halo Handles (including the Viewer and Debugger)--and the Squeak tutorial http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/index.html Actually, to get at the Smalltalk tools, use the view-source key. This is also mapped to Alt-, if you happen to not run on the XO, while ALt- Shift-W brings up the regular Squeak main menu. Under help-preferences you can disable the etoyFriendly setting, which then brings up the main menu on a background left-click. Each of image will make a .sources file so you get two .sources file. Then, use diff (perhaps you might want to convert CR to LF before that) to see the difference. Is this .sources output what Debian is asking for? If not, why not, and what would we have to do to complete it from their point of view? Only they can answer that. It is all the sources, yes. http://wiki.squeak.org/squeak/759 Smalltalk condenseSources extracts the currently valid definitions form both the sources file and the changes file and merges these into an new sources file SourcesV3.6 (you are asked to supply the name of the new sources file). All outdated definitions are dropped. We have a 14MBytes sources and 10 MBytes changes file. When these merge we have a 16 MBytes source file and a nearly empty changes file. We therefore conclude, that the 10 MBytes of the changes contained 2 MBytes new code and 8 MBytes development history. We currently ship an 18 MB .sources and 600 K .changes file. So the condenseSources step isn't going to make much of a difference (we did it in April to produce EtoysV3.sources). Can gst bring in a .sources file and a .changes file and create a working image? Not currently. - Bert - Is it a different VM, or just a different distribution since it has a different binary blob? The VM is well synchronized with the trunk VM. They were identical a few weeks ago. We now have a few more patches in the OLPC VM branch but it is not significant. The VM is a separeted rpm BTW. Why do you refer it to as binary blob? Yeah, it's mostly Smalltalk source and objects created in Smalltalk. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC config in salut in F9?
On Wed, Jun 25, 2008 at 18:35, Morgan Collett [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 18:27, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: It would still be good if we could --enable-olpc on the F9 packages, so that Sugar can work right in Fedora 9. Morgan could you take care of that? Yes, I'll do that. Done. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Yummy incron
On Tue, Jun 24, 2008 at 8:54 PM, Martin Langhoff [EMAIL PROTECTED] wrote: Looking for a (memory, cpu, power) efficient way to trigger events/scripts on the XS, I came across incrond. It weights ~600KB according to ps_mem.py, and it looks like the kind of tool we want to be using. There are a few processes I have on the XS that signal completion by touching a file in a tmpdir, so that a different process (with different privileges) can perform other steps. Using incron rather than poll frequently from an in-memory process or crond seems much smarter. rant Yes, this a bit like DBus, but DBus was designed for a desktop with Gobs Of Mighty RAM, and it requires that your process must be running in memory, and that it'd be forking/threaded if you want to process stuff in parallel. This means our (mostly python) processes are sitting idly on memory we don't have the luxury to spare. And that little or nothing happens in parallel. I'm confused. Won't the XS servers always have swap/paging space? Idle processes should take hardly any RAM at all. Not being familar with python's threading model, it may be that idle threads (in a single process) will still take up memory. Even then though, partial process/thread paging should be active. Does DBUS wake up processes it shouldn't? (creating RAM thrashing problems) That seems to me to be more of a problem with DBUS message types not being specific enough. OTOH, If you were talking about the XO platform (paging to flash probably being a bad idea), I would agree with you. Bill Bogstad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
Edward Cherlin [EMAIL PROTECTED] writes: [...] Can gst bring in a .sources file and a .changes file and create a working image? It doesn't have to. It builds gst.im from scratch at every bootstrap. If squeak/etoys did something close to that, many concerns would be pacified. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XO Opera browser as Sugar activity
The activity start script should configure Opera to put its configuration file in $SUGAR_ACTIVITY_ROOT/data instead of $HOME/.opera. Also it should set umask to 0002 so the config file is group-writable (otherwise the next activity instance cannot overwrite). See http://wiki.laptop.org/go/Low-level_Activity_API#File_Access QSettings: error creating /home/olpc/isolation/1/uid_to_home_dir/ 1/.qt opera: Can not use personal directory: /home/olpc/isolation/1/ uid_to_home_dir/1/.opera This looks more like a bug in Rainbow than in Opera. Why would Sugar or Rainbow be setting $HOME to a rainbow-created directory that the activity can't make subdirectories in? (The universe of Unix programs isn't going to rewrite itself because OLPC decided that $SUGAR_ACTIVITY_ROOT is the right place to keep your files on Unix. $HOME has been that place for decades. Rainbow is already setting $HOME. It's just apparently setting it to something that doesn't work.) Also it should set umask to 0002 so the config file is group-writable (otherwise the next activity instance cannot overwrite). If Rainbow runs the same activity as many different UIDs that share a single group ID, then yes, Rainbow should be setting the umask so that files are created group-writeable by default. There should be no need to modify ordinary Unix programs for this. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
At Wed, 25 Jun 2008 19:09:12 -0400, Frank Ch. Eigler wrote: Edward Cherlin [EMAIL PROTECTED] writes: [...] Can gst bring in a .sources file and a .changes file and create a working image? It doesn't have to. It builds gst.im from scratch at every bootstrap. If squeak/etoys did something close to that, many concerns would be pacified. Yes, for GNU Smalltalk, these are not .sources file and .changes file but you can create an image file. BTW, Smalltalk-72 had a text file called ALLDEFS that is the bootstrap file for the entire system. For Smalltalk, bootstraping from a text file is not a new concept. While Dan and others were experimenting different ideas like image, somehow a part of free software community made very rigid by people who only know one way of doing it and now we are having this conversation. For those who are curious, try Smalltalk-72 emulator available here: http://map1.squeakfoundation.org/sm/accountbyid/a6930213-b578-49b1-862e-228cc5ab39e7/package/b98225e0-151d-4508-88fe-483db46f9814/autoversion/1 BTW, As pointed out many times, we are not sticking to Squeak because it is Smalltalk; but because it has Etoys. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
At Tue, 24 Jun 2008 17:12:23 -0400, Frank Ch. Eigler wrote: The gist of the argument is that one can't currently know what's really inside an etoys image, except beyond what it itself tells us, BTW, have you now understood that this was not true? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
Yoshiki Ohshima [EMAIL PROTECTED] writes: The gist of the argument is that one can't currently know what's really inside an etoys image, except beyond what it itself tells us, BTW, do you now agree that this was not true? If you give me an image file and ask me why the word at offset 0x12345 in the file is 0x89ABCDEF?, I can answer that by opening the image file externally with InterpreterSimulator, examine the bits and answer something like this is a second slot of an Array that points to a number object, and the array is pointed to by this, this and ths object., etc. Yes, that sounds much better (from a security/trust point of view) than having to ask the virtual machine itself to introspect. It stills seems somewhat too low level to enable version control. (Back in the early 90's, when I wrote Smalltalk code for a living (sort of), we ended up having to use external system (teamwork/envy IIRC) to get decent version control and reproducible builds.) It may be a useful exercise to run this over the whole etoys image to identify those parts that are recompilable from the .source/.changes files, those that represent plain data that could be serialized, and perchance surprise objects whose existence was only known to Alan Kay or Adele Goldberg back in the 80s. :-) - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
After writing the most of reply here, I found it now largely off-topic (thanks to Frank for understanding!) At Wed, 25 Jun 2008 21:00:24 -0400, Frank Ch. Eigler wrote: Yoshiki Ohshima [EMAIL PROTECTED] writes: The gist of the argument is that one can't currently know what's really inside an etoys image, except beyond what it itself tells us, BTW, do you now agree that this was not true? If you give me an image file and ask me why the word at offset 0x12345 in the file is 0x89ABCDEF?, I can answer that by opening the image file externally with InterpreterSimulator, examine the bits and answer something like this is a second slot of an Array that points to a number object, and the array is pointed to by this, this and ths object., etc. Yes, that sounds much better (from a security/trust point of view) than having to ask the virtual machine itself to introspect. Well, if you understand more about the relationship between InterpreterSimulator and the VM, external or not would not make so much difference. And, the VM is compiled by a foreign system (a C compiler), there cannot be a place to hide something like Tompson's attack. External or not wouldn't be the factor. (And you probably meant that better than asking the image itself.) It stills seems somewhat too low level to enable version control. (Back in the early 90's, when I wrote Smalltalk code for a living (sort of), we ended up having to use external system (teamwork/envy IIRC) to get decent version control and reproducible builds.) Of course, what you would like to version control is the code people write. ENVY and others are designed for that purpose. For doing version control, we could more or less freeze an image to be a base (like our etoys-dev-3.0.image), and make a release image automatically by applying the updates (http://tinlizzie.org/updates/etoys/updates/) and evaluate the do it (ReleaseBuilderSqueakland new prepareReleaseImageForOLPC) from a Makefile (if that makes people happy). The diffs are all in small textual files. As long as you trust the base image, you only have to look at the updates. Now and then, we may want to change the base image. We do something that gave the perception to people that the previous base image is trustable there and that would do. It may be a useful exercise to run this over the whole etoys image to identify those parts that are recompilable from the .source/.changes files, those that represent plain data that could be serialized, and perchance surprise objects whose existence was only known to Alan Kay or Adele Goldberg back in the 80s. :-) I don't know in what sense it is *useful*, but the core image of Spoon (http://netjam.org/projects/spoon/) is 1,337 bytes (and of course every byte is understood). -- Yoshiki (And '80s is wrong time to go back in that sense, and Alan Kay and Adele Goldberg aren't the names to be mentioned in that context.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
Marco Pesenti Gritti wrote: If we manage to make DBus entirely optional, the initial effort of porting a Linux applications to Sugar would be greatly simplified. As far as I know this is already the case. The only non standard bit are a couple of custom X properties. Oh, is there a way around this requirement too? A few days ago someone here at OLE Nepal bundled up Firefox 2 and was disappointed to get the infamous circle icon. For them, changing the code and rebuilding from source would be overkill. (please don't ask me why Firefox 2... it might have been any large Linux application) If nobody has looked at this before, I might give it a shot to see what the Gnome wnck applet does to pair windows with their applications and desktop icons. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
On Wednesday 25 Jun 2008 12:08:44 am Albert Cahalan wrote: *All the source code* for *every* piece of byte code in the image is available, and not only that, we even *ship* it No. This is not true. You ship a binary blob. That doesn't count, even if so-called source code is viewable from within the blob. Albert, You are confusing binary as in secret encoding with binary as in encoding based on freely available specifications. A UTF-8 encoded file containing Mandarin or Hindi text would be unreadable on an ASCII text editor, but that doesn't make it a closed binary blob. A video file encoded using a secret patented codec would constitute a closed binary blob in the first sense since it cannot be decoded with publicly available readers nor can one be written without overriding someone's legal rights. Squeak image is not a blob in the first sense. One can write a program to decode any image file and recover any data stored in it. The problem with the blob is not that it is closed, but it is monolithic and limited in capacity. The limit is not that restrictive for personal computing purposes, but it will hurt when one has to deal with audio/video clips, 3-D simulations or large databases. There is no checksum to verify integrity. Objects are stored higgedly piggedly making even partial recovery difficult. However, these are programming limits, not that of policy. Subbu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
Sorry for being naive before. Now I have got rules file in udev which grants access for my usb driver to detach the usb device from the kernel and my driver works fine without having to be super user. Thank you so much for all your suggestions. But I got one more question for you, now to install the activity and having it running I have to copy the rules file into /etc/udev/rules.d folder. How can I do this while installing the activity itself. ( I need to make sure that when I unzip my activity .xo file the rules file lands in the /etc/udev/rules.d folder) On Wed, Jun 25, 2008 at 5:31 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: On 25.06.2008 08:07, Michael Stone wrote: We have an activity that wants superuser privilege in order to poke kernel memory. Hello? Please take the poor activity out back and shoot it. No activity has any business poking kernel memory. The real questions we should be attempting to address here include: * Who is granting privilege to this activity? Everybody who wants to ridicule the security model. * How are they doing so? * How should we record the decision? - My tentative answer is that we should store activities with different security properties in well-known directory chains with appropriately restricted write access. * What kinds of abuse are these mechanisms vulnerable to? * Whose responsibility is it to handle the error condition that the human operator does not, him-or-herself posess superuser privilege, e.g. for theft-deterrence reasons? Just say no. Having an activity poke kernel memory is a really strong sign that the interface is totally broken. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
