Re: OLPC XO Opera browser as Sugar activity
Am 26.06.2008 um 00:49 schrieb Stevens:
Hi Bert, all,
I changed the script (OperaActivity.py) posted on the wiki
(http://wiki.laptop.org/go/Opera
).
This is the old script:
import logging
from sugar.activity import activity
import sys, os
import gtk
class OperaActivity(activity.Activity):
def __init__(self,handle):
activity.Activity.__init__(self,handle)
self.set_title('Opera Activity')
os.system('opera -notrayicon ')
The above script resulted in the 'blank screen' activity. I added a
personaldir switch, shown below:
import logging
from sugar.activity import activity
import sys, os
import gtk
class OperaActivity(activity.Activity):
def __init__(self,handle):
activity.Activity.__init__(self,handle)
self.set_title('Opera Activity')
os.system('opera -notrayicon -personaldir $SUGAR_ACTIVITY_ROOT/data
')
(The only change is in the last line: added personaldir command line
switch.)
This resulted in progress. Now, in addition to the blank screen
activity, it starts Opera.
However, this may not have been the right thing to do, or I may need
to make some additional changes as there is still a bug: two glyphs
show up in the activity circle, one the Opera glyph which when
clicked on goes to a blank screen, and the other (a gray circle)
which when clicked on goes to Opera. (Before I made the change to
the script just the blank screen activity started.)
Is the change I made correct for this case? And, is there some other
change I should make to eliminate the 'blank screen' being started?
Sure. Do not use the Python script. You don't want to run a Python
activity but a native one - otherwise you get two windows, the empty
one opened by Python and the real one by Opera. Instead, you only need
a tiny shell script that preloads a little library, which may work
with Opera:
http://lists.laptop.org/pipermail/devel/2008-January/009387.html
And since you're investigating this, what would be great is if you
could re-package Opera as a real activity. That means, just move the
Opera files that are normally installed in the system into the bundle
itself, and setup the environment in the shell script so it works from
that non-standard directory. Then zip up the activity directory,
rename to .xo, and we have a real Opera bundle :) That way it would
also survive a system upgrade which erases all manually installed RPMs.
- Bert -
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
On Wed, Jun 25, 2008 at 11:13 PM, K. K. Subramaniam [EMAIL PROTECTED] wrote: 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. Sure, but I actually can get an independent implementation of an editor for such data -- it doesn't depend on itself. A good situation would be that you can build the image from plain text just like GNU Smalltalk does. That could happen on the laptop when the activity starts, or when the activity is created. The next best thing would be to supply a custom editor which is **external** to the image, along with any other tools needed to edit and create the image. It should be possible to start from some standard build tools, feeding in a mix of source code and standard media files, to end up with a set of tools. Note that you could write such tools in Smalltalk if you used GNU Smalltalk, which is able to be bootstrapped. This solution essentially treats the image like a multimedia file instead of code. (a dump tool is all you have AFAIK; there is no editor that can reliably edit a VM image) Best would be both. Currently, you have neither. 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. It's also a problem for change tracking, shared development, use of one's favorite editor, code sharing with GNU Smalltalk, etc. This idea of applying patch collections is disturbing. It reminds me of the terrible mess that Minix was back in 1991, when the license permitted people to share patches but not code with the patches applied. Here you have a technical limit instead of a legal one, but I expect that the result is not much different. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2076
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2076
Changes in build 2076 from build: 2074
Size delta: -0.26M
-kernel 2.6.25-20080619.1.olpc.279b9db99a30fe6
+kernel 2.6.22-20080523.1.olpc.28f4cb6e780db07
-python-jinja 1.2-2.fc7
+python-jinja 1.2-1.fc9
--- Changes for kernel 2.6.22-20080523.1.olpc.28f4cb6e780db07 from
2.6.25-20080619.1.olpc.279b9db99a30fe6 ---
+ pull from testing
+ Merge branch '2.6.25.y' into testing
+ md: fix use after free when removing rdev via sysfs
+ sparc: Fix mmap VA span checking.
+ sit: Add missing kfree_skb() on pskb_may_pull() failure.
+ POWERPC: mpc5200: Fix unterminated of_device_id table
+ Linux 2.6.25.3
+ CRYPTO: api: Fix scatterwalk_sg_chain
+ CRYPTO: eseqiv: Fix off-by-one encryption
+ reiserfs: Unpack tails on quota files
+ CRYPTO: cryptd: Correct kzalloc error test
+ mm: fix usemap initialization
+ kprobes/arm: fix decoding of arithmetic immediate instructions
+ b43: Fix dual-PHY devices
+ b43: Fix some TX/RX locking issues
+ vfs: fix permission checking in sys_utimensat
+ kprobes/arm: fix cache flush address for instruction stub
+ CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
+ sched: fix hrtick_start_fair and CPU-Hotplug
+ 2.6.25 regression: powertop says 120K wakeups/sec
+ x86 PCI: call dmi_check_pciprobe()
+ Merge branch '2.6.25.y' into testing
+ md: fix use after free when removing rdev via sysfs
+ sparc: Fix mmap VA span checking.
+ sit: Add missing kfree_skb() on pskb_may_pull() failure.
+ POWERPC: mpc5200: Fix unterminated of_device_id table
+ Linux 2.6.25.3
+ CRYPTO: api: Fix scatterwalk_sg_chain
+ CRYPTO: eseqiv: Fix off-by-one encryption
+ reiserfs: Unpack tails on quota files
+ CRYPTO: cryptd: Correct kzalloc error test
+ mm: fix usemap initialization
+ kprobes/arm: fix decoding of arithmetic immediate instructions
+ b43: Fix dual-PHY devices
+ b43: Fix some TX/RX locking issues
+ vfs: fix permission checking in sys_utimensat
+ kprobes/arm: fix cache flush address for instruction stub
+ CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
+ sched: fix hrtick_start_fair and CPU-Hotplug
+ 2.6.25 regression: powertop says 120K wakeups/sec
+ x86 PCI: call dmi_check_pciprobe()
+ Merge branch '2.6.25.y' into testing
+ md: fix use after free when removing rdev via sysfs
+ sparc: Fix mmap VA span checking.
+ sit: Add missing kfree_skb() on pskb_may_pull() failure.
+ POWERPC: mpc5200: Fix unterminated of_device_id table
+ Linux 2.6.25.3
+ CRYPTO: api: Fix scatterwalk_sg_chain
+ CRYPTO: eseqiv: Fix off-by-one encryption
+ reiserfs: Unpack tails on quota files
+ CRYPTO: cryptd: Correct kzalloc error test
+ mm: fix usemap initialization
+ kprobes/arm: fix decoding of arithmetic immediate instructions
+ b43: Fix dual-PHY devices
+ b43: Fix some TX/RX locking issues
+ vfs: fix permission checking in sys_utimensat
+ kprobes/arm: fix cache flush address for instruction stub
+ CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
+ sched: fix hrtick_start_fair and CPU-Hotplug
+ 2.6.25 regression: powertop says 120K wakeups/sec
+ x86 PCI: call dmi_check_pciprobe()
+ OHCI: fix regression upon awakening from hibernation
+ V4L/DVB (7473): PATCH for various Dibcom based devices
+ Merge branch '2.6.25.y' into testing
+ {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets
+ dccp: return -EINVAL on invalid feature length
+ md: fix raid5 'repair' operations
+ sparc: Fix SA_ONSTACK signal handling.
+ sparc: Fix fork/clone/vfork system call restart.
+ sparc64: Stop creating dummy root PCI host controller devices.
+ sparc64: Fix wedged irq regression.
+ SPARC64: Fix args to 64-bit sys_semctl() via sys_ipc().
+ serial: Fix sparc driver name strings.
+ sparc: Fix ptrace() detach.
+ sparc: Fix mremap address range validation.
+ sparc: Fix debugger syscall restart interactions.
+ sparc32: Don't twiddle PT_DTRACE in exec.
+ Linux 2.6.25.4
+ r8169: fix oops in r8169_get_mac_version
+ SCSI: aha152x: Fix oops on module removal
+ SCSI: aha152x: fix init suspiciously returned 1, it should follow 0/-E
convention
+ sch_htb: remove from event queue in htb_parent_to_leaf()
+ i2c-piix4: Blacklist two mainboards
+ SCSI: qla1280: Fix queue depth problem
+ ipvs: fix oops in backup for fwmark conn templates
+ USB: airprime: unlock mutex instead of trying to lock it again
+ rtc: rtc_time_to_tm: use unsigned arithmetic
+ SCSI: libiscsi regression in 2.6.25: fix nop timer handling
+ SCSI: libiscsi regression in 2.6.25: fix setting of recv timer
+ can: Fix can_send() handling on dev_queue_xmit() failures
+ macvlan: Fix memleak on device removal/crash on module removal
+ nf_conntrack: padding breaks conntrack hash on ARM
+ sparc: sunzilog uart order
+ r8169: fix past rtl_chip_info array size for unknown chipsets
+ x86: use defconfigs from
Activity home dirs (was Re: OLPC XO Opera browser as Sugar activity)
Am 26.06.2008 um 01:22 schrieb John Gilmore: 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. Agreed, but Peter's question was about build 708 so it might be fixed in the mean time. Indeed I remember discussion about that, although I can't find the Trac report. I recall that HOME is set to $SUGAR_ACTIVITY_ROOT/instance now, which should work at least, but I think is also wrong as it is not shared between activity instances. The right place would be $SUGAR_ACTIVITY_ROOT/data. And I think umask is set by Sugar nowadays. But that won't help machines in the field now so I gave a recipe that would work around that bug. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
But /etc/udev/rules.d is executed as root, so your activity would still need excessive privilege. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Albert, Before drifting to a new topic, let me make sure one thing; did you get convinced that FSF's definition of software freedom doesn't contradict with a binary image file with right tools to fully explore/understand/modify it? If not, please explain. If so, I understand that you don't like it, and that is ok with me. In the following, you are discussing my preference part but here goes: At Thu, 26 Jun 2008 02:41:00 -0400, Albert Cahalan wrote: Sure, but I actually can get an independent implementation of an editor for such data -- it doesn't depend on itself. You can edit a file out with your favorite text editor and file it in to the image to do any kind of stuff. A good situation would be that you can build the image from plain text just like GNU Smalltalk does. That could happen on the laptop when the activity starts, or when the activity is created. The next best thing would be to supply a custom editor which is **external** to the image, along with any other tools needed to edit and create the image. It should be possible to start from some standard build tools, feeding in a mix of source code and standard media files, to end up with a set of tools. Note that you could write such tools in Smalltalk if you used GNU Smalltalk, which is able to be bootstrapped. You never explained why these things are good. This solution essentially treats the image like a multimedia file instead of code. (a dump tool is all you have AFAIK; there is no editor that can reliably edit a VM image) We don't exactly treat the image file as code. Image is a snapshot of state of objects. It's also a problem for change tracking, shared development, use of one's favorite editor, code sharing with GNU Smalltalk, etc. You can of course file out and file in textual code and if the code is compatible with GNU Smalltalk, you can share the code. This idea of applying patch collections is disturbing. It reminds me of the terrible mess that Minix was back in 1991, when the license permitted people to share patches but not code with the patches applied. Here you have a technical limit instead of a legal one, but I expect that the result is not much different. No, no. You don't get it. Applying patch happens when building a release image and the resulting image gets into a package to be distributed. It is just the same as compiling an executable binary from source code and distribute the binary. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 2074
Am 26.06.2008 um 02:55 schrieb Build Announcer v2: +perl 4:5.10.0-27.fc9 I re-opened #234 to get this fixed. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Running regular X11 apps
Am 26.06.2008 um 05:12 schrieb Bernie Innocenti: 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. The only part-way solution so far is Albert's libsugarize: http://lists.laptop.org/pipermail/devel/2008-January/009387.html - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New faster build 2076
http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2076
Changes in build 2076 from build: 2073
Size delta: -0.39M
-kernel 2.6.25-20080619.1.olpc.279b9db99a30fe6
+kernel 2.6.22-20080523.1.olpc.28f4cb6e780db07
-python-jinja 1.2-2.fc7
+python-jinja 1.2-1.fc7
--- Changes for kernel 2.6.22-20080523.1.olpc.28f4cb6e780db07 from
2.6.25-20080619.1.olpc.279b9db99a30fe6 ---
+ pull from testing
+ Merge branch '2.6.25.y' into testing
+ md: fix use after free when removing rdev via sysfs
+ sparc: Fix mmap VA span checking.
+ sit: Add missing kfree_skb() on pskb_may_pull() failure.
+ POWERPC: mpc5200: Fix unterminated of_device_id table
+ Linux 2.6.25.3
+ CRYPTO: api: Fix scatterwalk_sg_chain
+ CRYPTO: eseqiv: Fix off-by-one encryption
+ reiserfs: Unpack tails on quota files
+ CRYPTO: cryptd: Correct kzalloc error test
+ mm: fix usemap initialization
+ kprobes/arm: fix decoding of arithmetic immediate instructions
+ b43: Fix dual-PHY devices
+ b43: Fix some TX/RX locking issues
+ vfs: fix permission checking in sys_utimensat
+ kprobes/arm: fix cache flush address for instruction stub
+ CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
+ sched: fix hrtick_start_fair and CPU-Hotplug
+ 2.6.25 regression: powertop says 120K wakeups/sec
+ x86 PCI: call dmi_check_pciprobe()
+ Merge branch '2.6.25.y' into testing
+ md: fix use after free when removing rdev via sysfs
+ sparc: Fix mmap VA span checking.
+ sit: Add missing kfree_skb() on pskb_may_pull() failure.
+ POWERPC: mpc5200: Fix unterminated of_device_id table
+ Linux 2.6.25.3
+ CRYPTO: api: Fix scatterwalk_sg_chain
+ CRYPTO: eseqiv: Fix off-by-one encryption
+ reiserfs: Unpack tails on quota files
+ CRYPTO: cryptd: Correct kzalloc error test
+ mm: fix usemap initialization
+ kprobes/arm: fix decoding of arithmetic immediate instructions
+ b43: Fix dual-PHY devices
+ b43: Fix some TX/RX locking issues
+ vfs: fix permission checking in sys_utimensat
+ kprobes/arm: fix cache flush address for instruction stub
+ CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
+ sched: fix hrtick_start_fair and CPU-Hotplug
+ 2.6.25 regression: powertop says 120K wakeups/sec
+ x86 PCI: call dmi_check_pciprobe()
+ Merge branch '2.6.25.y' into testing
+ md: fix use after free when removing rdev via sysfs
+ sparc: Fix mmap VA span checking.
+ sit: Add missing kfree_skb() on pskb_may_pull() failure.
+ POWERPC: mpc5200: Fix unterminated of_device_id table
+ Linux 2.6.25.3
+ CRYPTO: api: Fix scatterwalk_sg_chain
+ CRYPTO: eseqiv: Fix off-by-one encryption
+ reiserfs: Unpack tails on quota files
+ CRYPTO: cryptd: Correct kzalloc error test
+ mm: fix usemap initialization
+ kprobes/arm: fix decoding of arithmetic immediate instructions
+ b43: Fix dual-PHY devices
+ b43: Fix some TX/RX locking issues
+ vfs: fix permission checking in sys_utimensat
+ kprobes/arm: fix cache flush address for instruction stub
+ CRYPTO: authenc: Fix async crypto crash in crypto_authenc_genicv()
+ sched: fix hrtick_start_fair and CPU-Hotplug
+ 2.6.25 regression: powertop says 120K wakeups/sec
+ x86 PCI: call dmi_check_pciprobe()
+ OHCI: fix regression upon awakening from hibernation
+ V4L/DVB (7473): PATCH for various Dibcom based devices
+ Merge branch '2.6.25.y' into testing
+ {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets
+ dccp: return -EINVAL on invalid feature length
+ md: fix raid5 'repair' operations
+ sparc: Fix SA_ONSTACK signal handling.
+ sparc: Fix fork/clone/vfork system call restart.
+ sparc64: Stop creating dummy root PCI host controller devices.
+ sparc64: Fix wedged irq regression.
+ SPARC64: Fix args to 64-bit sys_semctl() via sys_ipc().
+ serial: Fix sparc driver name strings.
+ sparc: Fix ptrace() detach.
+ sparc: Fix mremap address range validation.
+ sparc: Fix debugger syscall restart interactions.
+ sparc32: Don't twiddle PT_DTRACE in exec.
+ Linux 2.6.25.4
+ r8169: fix oops in r8169_get_mac_version
+ SCSI: aha152x: Fix oops on module removal
+ SCSI: aha152x: fix init suspiciously returned 1, it should follow 0/-E
convention
+ sch_htb: remove from event queue in htb_parent_to_leaf()
+ i2c-piix4: Blacklist two mainboards
+ SCSI: qla1280: Fix queue depth problem
+ ipvs: fix oops in backup for fwmark conn templates
+ USB: airprime: unlock mutex instead of trying to lock it again
+ rtc: rtc_time_to_tm: use unsigned arithmetic
+ SCSI: libiscsi regression in 2.6.25: fix nop timer handling
+ SCSI: libiscsi regression in 2.6.25: fix setting of recv timer
+ can: Fix can_send() handling on dev_queue_xmit() failures
+ macvlan: Fix memleak on device removal/crash on module removal
+ nf_conntrack: padding breaks conntrack hash on ARM
+ sparc: sunzilog uart order
+ r8169: fix past rtl_chip_info array size for unknown chipsets
+ x86: use defconfigs from
Re: Running regular X11 apps
On Thu, Jun 26, 2008 at 9:16 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: 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. Other than the circle icon, do you have any major issue? If it's just that, adding _NET_WM_ICON support to the sugar shell should be really easy. I'm planning to work on a proper fix for the whole issue (at the window management level at least) for 0.84. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Running regular X11 apps
On Thu, Jun 26, 2008 at 10:35 AM, Albert Cahalan [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 4:14 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Other than the circle icon, do you have any major issue? If it's just that, adding _NET_WM_ICON support to the sugar shell should be really easy. Great. BTW, the old-style bitmaps could be given the XO colors and then scaled. I'm planning to work on a proper fix for the whole issue (at the window management level at least) for 0.84. How will it work? Consider running one Sugar activity per virtual desktop. This would allow multi-window programs like the infamous gimp to fit in pretty well, except that of course they are not full-screen and thus receive window borders. Nobody ever sees a window border until they run something that isn't full-screen. Not fully defined yet. Sayamindu experimented with it a bit, there are (messy) notes on the wiki: http://wiki.sugarlabs.org/go/WindowManagement Your idea is interesting, I'll try to think it all through. I added it to the wiki btw. Thanks, Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
On Thu, Jun 26, 2008 at 3:02 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: Before drifting to a new topic, let me make sure one thing; did you get convinced that FSF's definition of software freedom doesn't contradict with a binary image file with right tools to fully explore/understand/modify it? I don't subscribe to the notion that the FSF defines open source. Heck, I don't care for them and they don't care for open source. A good situation would be that you can build the image from plain text just like GNU Smalltalk does. That could happen on the laptop when the activity starts, or when the activity is created. The next best thing would be to supply a custom editor which is **external** to the image, along with any other tools needed to edit and create the image. It should be possible to start from some standard build tools, feeding in a mix of source code and standard media files, to end up with a set of tools. Note that you could write such tools in Smalltalk if you used GNU Smalltalk, which is able to be bootstrapped. You never explained why these things are good. Right. I'm also not explaining why software freedom is good, why maintainability is good, why interoperability is good, etc. Values are values. This idea of applying patch collections is disturbing. It reminds me of the terrible mess that Minix was back in 1991, when the license permitted people to share patches but not code with the patches applied. Here you have a technical limit instead of a legal one, but I expect that the result is not much different. No, no. You don't get it. Applying patch happens when building a release image and the resulting image gets into a package to be distributed. It is just the same as compiling an executable binary from source code and distribute the binary. I got that. The fundamental problem is the patch collection. There is a problem even if you can distribute the result. Patches need to be applied. If you do that, and distribute a blob, then we're back to the blob problem. If you don't do that, then we have the Minix problem. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Yummy incron
On Wed, Jun 25, 2008 at 2:50 PM, Martin Langhoff [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 2:36 PM, Bill Bogstad [EMAIL PROTECTED] wrote: I'm confused. Won't the XS servers always have swap/paging space? Paging is tolerable for batch processes, or for interactive stuff that is not subject to timeouts (let the user wait while we bring OpenOffice back from swap). Network services and swapping don't mix well at all - they just timeout, which leads to users perceiving it as crashed, hitting refresh if available, and in our case perhaps volunteering a fix in the form of a hard reboot. Sure but any process that is waiting for a file to appear in the filesystem seem more like a batch process to me. There is no way to know how long it will take (and thus your timeouts). Ouch. If you look at apache and other web-services tuning strategies, the *first* thing they do is ensure that the working set _never_ touches swap. As soon as any network service gets swapped out, it's unavailable for all intents and purposes. Yes, you want your working set to fit in memory. Still not clear to me how a process which is waiting (I'm assuming for a while) for another process to do something can in any sense be considered part of the current working set. In fact the usage model of incrond is that it won't even be a process (so clearly not in the working set). A paged out process is also clearly not in the current working set. Still not seeing the problem. OTOH, I do see the problem of using cron to startup a process just to check for existence of a file. Some other rendezvous is preferable. You don't seem to like DBUS (I'm guessing because of the complexity of retrofitting it into preexisting programs or scripts). Perhaps using a named pipe with a write to it from the source process to wake up the destination process might be preferable. This can easily be done from any language, doesn't require an additional permanent daemon process (incrond), and allows the destination process to have gotten past its startup cost and be ready for immediate action. Paging the destination process back from disk should not be slower then starting a new process (via incrond). The only advantage I see of incrond is the destination process can remain almost oblivious to the signaling mechanism. Named pipe rendezvous would require a small amount of additional code in both the source and destination process. Processes sitting idly in memory are wasteful unless they have a ton of state in them to make them valuable. And even then, in many cases they can just marshall that data, and pick it up later (lots of exceptions for this - connection poolers for example). Processes that are truly 'idle' (waiting for a socket event for example) should be paged out as the system needs their memory. I can see lots of methods to avoid filesystem polling which don't involve adding a new daemon to the set of programs that OLPC is already supporting. Maybe the tradeoff is such that incrond is still the right choice, but I don't see why you seem to be objecting to a paged out process (as opposed to one which hasn't even been started yet). If the memory taken up by the process slot and other kernel bookkeeping is that much of a problem, then things are already so close to desperate that you are probably going to fall over soon anyway. Bill Bogstad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
GSoC Status Report: Vision Processing
As you may know, OLPC got GSoC students again this summer. I am one of them, and my project is Vision Processing. That is, a library to use the webcam for more than capturing images. I am implementing this by adding v4l2 and computer vision functions to pygame. My code is available at http://git.n0r.org/?p=pygame-nrp;a=summary and is currently pygame 1.8.1 with the addition of a camera module that supports v4l2 cameras that use MMAP and have pixelformats of RGB24, RGB444, YUYV, SBGGR8, or YUV420. Basic usage is as follows: import pygame from pygame import camera cam = camera.Camera(/dev/video0, (640, 480), RGB) # the third argument can be YUV or HSV too. cam.start() frame = cam.get_image() # the frame returned is a 24bit pygame Surface You can also do fun stuff like: http://eclecti.cc/bytes/living-pointillism-a-pygame-webcam-script or more practical stuff like having it track the centroid of a specific hue (green in this case): http://eclecti.cc/files/centroid.py My plans are to add functions like finding the largest connected component, optical flow, and other things useful for computer vision. Currently, performace is pretty poor on the XO; a combination of the Geode being slow and having to convert from 24bit to 16bit surfaces to display any captured frames. The XO is fast enough to capture and blit a 320x240 RGB frame at 30fps, but not at 640x480 or a frame being converted to HSV. I'm not sure how or if I'm going to be able to overcome those performance problems. I'd appreciate any comments, suggestions, or reality checks on improving performance or anything else, or any requests for vision functions to add. Also, I only have the camera in the XO, vivi, and a poorly supported USB webcam, so if anyone could test it on other webcams, that would be great. Thanks, Nirav Patel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Running regular X11 apps
Marco Pesenti Gritti wrote: Other than the circle icon, do you have any major issue? If it's just that, adding _NET_WM_ICON support to the sugar shell should be really easy. I'm not sure... Surendra has been working on it. Added him to cc in case he has comments. I'm planning to work on a proper fix for the whole issue (at the window management level at least) for 0.84. Yay, thanks! -- \___/ 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: [Server-devel] Yummy incron
On Thu, Jun 26, 2008 at 12:45 AM, Bill Bogstad [EMAIL PROTECTED] wrote: Sure but any process that is waiting for a file to appear in the filesystem seem more like a batch process to me. There is no way to know how long it will take (and thus your timeouts). Bill, everything you say makes sense, except that perhaps a key concept is missing. Most of our scripts and processes are in Python. If I have 20 such scripts idling in memory, waiting for something to happen (a dbus event?), the footprint is huge - clearly this does not scale. Even if they get paged out. Incron, otoh, is a single process, weighing 600K, and can have a config file listing 20 scripts that might be triggered by a (inotify) event. Make that 200 scripts. The memory footprint doesn't change. You don't seem to like DBUS Why do you repeat that? I have no problem with DBus where it makes sense: processes that are guaranteed to be running in memory all the time. The key problem with paging out is that if you have a dozen idle processes in memory that are network daemons, and a dozen that are batch processes waiting for a dbus signal, the kernel will page them indiscriminately - the batch ones will be able to do their job ok when called, the network ones will timeout on their users. The kernel has no way of knowing. This isn't theoretical stuff -- rather very practical concerns of offering network services in real life. Memory usage matters. OTOH, I'm open to seeing facts that contradict my analysis - if you or anyone has a strategy that is better than incron - say, way to keep 20 to 200 python scripts in memory in 600K of (safely swappable) memory - I'd love to see it. cheers, m -- [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: 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). I asked Dennis about branching salut, and he recommended we try keep everything in F-9 if possible. Is it feasible to put the rainbow specific patches in such that they are enabled with a runtime option, if built with --enable-olpc? Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC config in salut in F9?
On Thu, Jun 26, 2008 at 17:03, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le jeudi 26 juin 2008 à 17:01 +0200, Morgan Collett a écrit : 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). I asked Dennis about branching salut, and he recommended we try keep everything in F-9 if possible. Is it feasible to put the rainbow specific patches in such that they are enabled with a runtime option, if built with --enable-olpc? Then it would be build time option and F9 users will have the patch applied anyway (which is not really a good idea). Can we make it a runtime option? Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC config in salut in F9?
Le jeudi 26 juin 2008 à 17:23 +0200, Morgan Collett a écrit : On Thu, Jun 26, 2008 at 17:03, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le jeudi 26 juin 2008 à 17:01 +0200, Morgan Collett a écrit : 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). I asked Dennis about branching salut, and he recommended we try keep everything in F-9 if possible. Is it feasible to put the rainbow specific patches in such that they are enabled with a runtime option, if built with --enable-olpc? Then it would be build time option and F9 users will have the patch applied anyway (which is not really a good idea). Can we make it a runtime option? We certainly don't want to add a CM parameter for this. We could eventually check an env variable but I'm not convince that's a so good idea as these workarounds are very very hackish. Sjoerd, Daf: Thoughts? G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
shivaprasad wrote: 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) james wrote: But /etc/udev/rules.d is executed as root, so your activity would still need excessive privilege. unless i'm misunderstanding, it seems to me that this is a problem that needs to be solved -- there are lots of little user-oriented USB devices that an activity might like to have access to -- serial, GPS, cameras, etc. just as we make USB storage devices accessible to the user, we need to allow for other types of h/w accessories. (i have an activity that needs this as well, if it's to be useable without unix commandline knowledge.) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Deepak Saxena wrote: | I agree with Paul that we need to have a solution to these | cases iff we want to support running arbitrary software and | hw combinations on the XO. The other option is to limit the | scope of the system to a very specific set of sw and hw, | treating the XO as embedded education appliance instead of | a general-purpose laptop device, which I don't think | we want to do. That is _precisely_ what I want to do. OLPC's goal is to distribute XOs to the poorest children in the world. That means that in the category of electronics, the great majority will have the XO and nothing else. Peripherals are a rarity, an edge case. There is a planned design to allow the user to grant extra privileges to different Activities, but those privileges will probably never extend to loading arbitrary kernel modules. I have no problem declaring that anyone who is modifying the kernel is a developer, and should therefore get a devkey and call modprobe themselves. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjw/AACgkQUJT6e6HFtqQlSgCfbDujhumR3cmtT/MpEH8qQidC cYEAn0atipCHDcuYjAIvS/E6IpxD0Ktb =WJse -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
benjamin m. schwartz wrote: Deepak Saxena wrote: | I agree with Paul that we need to have a solution to these | cases iff we want to support running arbitrary software and | hw combinations on the XO. The other option is to limit the | scope of the system to a very specific set of sw and hw, | treating the XO as embedded education appliance instead of | a general-purpose laptop device, which I don't think | we want to do. That is _precisely_ what I want to do. OLPC's goal is to distribute XOs to the poorest children in the world. That means that in the category of electronics, the great majority will have the XO and nothing else. Peripherals are a rarity, an edge case. perhaps, but i have trouble believing that no school will ever have any loaner, or classroom shared peripherals that the students may not own, but will still need to be able to use. (but perhaps most of these will fall into some well-known categores -- e.g., USB serial adapters. and we could maybe support them with a canned udev entry?) There is a planned design to allow the user to grant extra privileges to different Activities, reference? paul but those privileges will probably never extend to loading arbitrary kernel modules. I have no problem declaring that anyone who is modifying the kernel is a developer, and should therefore get a devkey and call modprobe themselves. =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
... to install the activity and having it running I have to copy the rules file into /etc/udev/rules.d folder. The preferred short answer seems to be NO. But if an Activity (application) *does* need something to be put into the operating system, should the Sugar environment provide a way to add that ? A benefit (to people who manipulate their systems) of putting add-on Activities into /home/olpc was to make them independent of an 'olpc-update' which replaced the operating system. One solution to the problem above would be to create TWO packages, one (.xo) to install the user-permissions material (done once), and the second (.rpm ?) to install the system modifications (done every time the system is replaced). [Etoys already supplies two such packages.] An RPM is static, and platform/version dependent. Ought the Sugar environment provide an intelligent facility which would 'hook/unhook' drivers [and objects on removable devices] into the running system (e.g., to add/remove Sugar Activities) ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Am 26.06.2008 um 10:53 schrieb Albert Cahalan: This idea of applying patch collections is disturbing. It reminds me of the terrible mess that Minix was back in 1991, when the license permitted people to share patches but not code with the patches applied. Here you have a technical limit instead of a legal one, but I expect that the result is not much different. I got that. The fundamental problem is the patch collection. There is a problem even if you can distribute the result. Patches need to be applied. If you do that, and distribute a blob, then we're back to the blob problem. If you don't do that, then we have the Minix problem. I don't actually disagree with that. Smalltalk is an excellent personal computing environment (well, you would expect that from the guys who largely invented personal computing). It does not fare nearly as well for distributed, collaborative development (although the Squeak community has developed work-arounds, like Monticello, a nice distributed SCM). But: Why should these shortcomings in development style be a reason to not include it in a Linux distribution? It's not like if every other app is well-coded or well-maintained. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
Benjamin M. Schwartz writes: There is a planned design to allow the user to grant extra privileges to different Activities, but those privileges will probably never extend to loading arbitrary kernel modules. VMWare-1.xo It's the only way to get usable performance on a system that doesn't have hardware virtualization support. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: touchpad issues on 2072
I'm tracking Fedora 9 issues here: http://wiki.laptop.org/go/OLPC-3 On Thu, 2008-06-26 at 11:50 -0500, Mark Bauer wrote: I upgraded my G1G1 as I have many times to the latest joyride build (2072). The touchpad is almost impossible to use, about 0.5 of movement will send the pointer all the way across the display. http://dev.laptop.org/ticket/7211 Then it locks up the pointer for 20 or 30 seconds. http://dev.laptop.org/ticket/7341 The rest of the machine is still running, and the keyboard is fine. I have attempted to olpc-update -r -f -v joyride-2076, but that seems to have a problem with one of the libraries (libicui18n.so.36). http://dev.laptop.org/ticket/7336 Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: touchpad issues on 2072
On Thu, Jun 26, 2008 at 12:50 PM, Mark Bauer [EMAIL PROTECTED] wrote: I upgraded my G1G1 as I have many times to the latest joyride build (2072). The touchpad is almost impossible to use, about 0.5 of movement will send the pointer all the way across the display. Then it locks up the pointer for 20 or 30 seconds. The rest of the machine is still running, and the keyboard is fine. I have attempted to olpc-update -r -f -v joyride-2076, but that seems to have a problem with one of the libraries (libicui18n.so.36). Anyone else having this problem, or do I need to reflash my machine back to a known good state. as mentioned in the first ticket, xset m 1 0 works well for me in the latest joyride. its not perfect but its usable bobby Mark ___ 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: touchpad issues on 2072
Am 26.06.2008 um 20:32 schrieb Bobby Powers: On Thu, Jun 26, 2008 at 12:50 PM, Mark Bauer [EMAIL PROTECTED] wrote: I upgraded my G1G1 as I have many times to the latest joyride build (2072). The touchpad is almost impossible to use, about 0.5 of movement will send the pointer all the way across the display. Then it locks up the pointer for 20 or 30 seconds. The rest of the machine is still running, and the keyboard is fine. I have attempted to olpc-update -r -f -v joyride-2076, but that seems to have a problem with one of the libraries (libicui18n.so.36). Anyone else having this problem, or do I need to reflash my machine back to a known good state. as mentioned in the first ticket, xset m 1 0 works well for me in the latest joyride. its not perfect but its usable bobby I find it completely unusable unless I apply this workaround: http://dev.laptop.org/ticket/7362 - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2078
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2078 Changes in build 2078 from build: 2076 Size delta: -0.13M -olpccontents 2.2-0 +olpccontents 2.3-1 --- Changes for olpccontents 2.3-1 from 2.2-0 --- + Repackage as proper F9/olpc3 rpm, which should fix the dependency -- 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: touchpad issues on 2072
On Thu, Jun 26, 2008 at 09:20:49PM +0200, Bert Freudenberg wrote: Am 26.06.2008 um 20:32 schrieb Bobby Powers: On Thu, Jun 26, 2008 at 12:50 PM, Mark Bauer [EMAIL PROTECTED] wrote: I upgraded my G1G1 as I have many times to the latest joyride build (2072). The touchpad is almost impossible to use, about 0.5 of movement will send the pointer all the way across the display. Then it locks up the pointer for 20 or 30 seconds. The rest of the machine is still running, and the keyboard is fine. I have attempted to olpc-update -r -f -v joyride-2076, but that seems to have a problem with one of the libraries (libicui18n.so.36). Anyone else having this problem, or do I need to reflash my machine back to a known good state. as mentioned in the first ticket, xset m 1 0 A variety of changes to the build have rendered the once sane default setting for cursor acceleration (xset m 7/4 0) unusable. xset m 7/6 0 ... has been included as a patch to olpc-utils and should appear in a joyride quite soon. You must type this into a terminal running within sugar for it to obtain a connection to the X server and change the settings. I find it completely unusable unless I apply this workaround: http://dev.laptop.org/ticket/7362 This is very interesting. I will investigate. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
On Thu, Jun 26, 2008 at 1:38 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Am 26.06.2008 um 10:53 schrieb Albert Cahalan: This idea of applying patch collections is disturbing. It reminds me of the terrible mess that Minix was back in 1991, when the license permitted people to share patches but not code with the patches applied. Here you have a technical limit instead of a legal one, but I expect that the result is not much different. I got that. The fundamental problem is the patch collection. There is a problem even if you can distribute the result. Patches need to be applied. If you do that, and distribute a blob, then we're back to the blob problem. If you don't do that, then we have the Minix problem. I don't actually disagree with that. Smalltalk is an excellent personal computing environment (well, you would expect that from the guys who largely invented personal computing). It does not fare nearly as well for distributed, collaborative development (although the Squeak community has developed work-arounds, like Monticello, a nice distributed SCM). But: Why should these shortcomings in development style be a reason to not include it in a Linux distribution? It's not like if every other app is well-coded or well-maintained. The very foundation of the Linux development community (which Squeak developers are asking to be accepted by) includes an expectation that software can be handled in certain ways. Any person can browse the source, with the worst case being that one must download an archive file or perform a check-out. (better: web git/cvs/svn access) Any person can use external tools, which themselves are likewise open, to view/edit/save/create/share the source. (better: those tools are standard, like emacs/gimp/audacity) We also expect a certain degree of openness (not a lot of non-public communication) and a certain degree of modularity (parts are interchangable across similar projects and versions, allowing distributions to mix and match). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: custom kernel problem
On Tue, Jun 24, 2008 at 10:23 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi Scott, Unfortunately, after I boot up the custom kernel, the X server fails to start because /home is mounted read-only. It's a bug in the master series kernel RPMs (or rather, in the initrd that accompanies them). It's being worked on. Does this have anything to do with olpcrd? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: custom kernel problem
On Thu, Jun 26, 2008 at 4:33 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:23 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi Scott, Unfortunately, after I boot up the custom kernel, the X server fails to start because /home is mounted read-only. It's a bug in the master series kernel RPMs (or rather, in the initrd that accompanies them). It's being worked on. Does this have anything to do with olpcrd? Fixed in olpcrd 0.44, in the next joyride. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC config in salut in F9?
On Thu, Jun 26, 2008 at 05:01:04PM +0200, Morgan Collett wrote: I asked Dennis about branching salut, and he recommended we try keep everything in F-9 if possible. Is it feasible to put the rainbow specific patches in such that they are enabled with a runtime option, if built with --enable-olpc? Could you put up a link to the OLPC-specific patches? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity home dirs (was Re: OLPC XO Opera browser as Sugar activity)
On Thu, Jun 26, 2008 at 08:53:47AM +0200, Bert Freudenberg wrote: Am 26.06.2008 um 01:22 schrieb John Gilmore: 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. It was considered to be a feature at the time it was introduced. Why would Sugar or Rainbow be setting $HOME to a rainbow-created directory that the activity can't make subdirectories in? Because the spec it was built to said that activities should be permitted to write to precisely three directories named 'tmp', 'data', and 'instance'. Furthermore, it was entirely unclear at the time which one $HOME should point to. (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). rainbow = 0.7.4 (available since Nov. 10, 2007) sets umask(0) before running the activity. However, we found that several important library calls like mkstemp, mkdtemp, and the equivalent file creation code used by xulrunner hardcode the use of modes like 0700 and 0600 for directories and files that they create. It would not surprise me if Opera behaved similarly. 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. Agreed, but Peter's question was about build 708 so it might be fixed in the mean time. rainbow = 0.7.12 causes $HOME to be writable. This change has been available since April 10, 2008 in joyride and is expected to be included in our next major release. $SUGAR_ACTIVITY_ROOT/instance now, which should work at least, but I think is also wrong as it is not shared between activity instances. As a result of the fact that xulrunner hardcodes the use of modes like 0700 and 0600 in its file creation code, I decided that we should set $HOME == $SAR/instance by default so that programs would be less likely to encounter files they couldn't write. Activities which dislike this default are fully capable of changing themselves when they are executed. That being said, I'm open to arguments about what the default should be. Have you got some mechanism for setting $HOME to $SAR/data which would be safe in the face of programs like xulrunner? (For what it's worth, I happen think that the real defect is that uids and instance dirs are deleted on reboot and recreated on activity resume rather than being persistent and reused at activity resume. Unfortunately, though I intend to address this issue as soon as my other responsibilities permit, it will probably be a while before that happens. Interested onlookers should definitely take initiative here and then submit their results for discussion and possible merging.) But that won't help machines in the field now so I gave a recipe that would work around that bug. Thanks! Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2079
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2079 Changes in build 2079 from build: 2078 Size delta: 0.39M -bootanim 0.17-0 +bootanim 1.0-1 -kernel 2.6.22-20080523.1.olpc.28f4cb6e780db07 +kernel 2.6.25-20080625.2.olpc.744e740861edba9 --- Changes for bootanim 1.0-1 from 0.17-0 --- + Add 'N' to font subset, so that mass-production serial numbers display -- 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: [OLPC Security] SuperUser permission for the Driver??
On Thu, 26 Jun 2008, Deepak Saxena wrote: On Jun 25 2008, at 14:01, Carl-Daniel Hailfinger was caught saying: 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. What if I replace Michael's statement with some specific use cases: - An activity requires a specific device driver module to be (un)loaded to properly function and loading this driver requires su privilege. or: - An activity requires a device to switch operation modes and that operation mode is configured via a sysfs file. The file is poked by a library API, but it requires su privilege to do so. I agree with Paul that we need to have a solution to these cases iff we want to support running arbitrary software and hw combinations on the XO. The other option is to limit the scope of the system to a very specific set of sw and hw, treating the XO as embedded education appliance instead of a general-purpose laptop device, which I don't think we want to do. It can be a general purpose laptop. And we need not surrender our common sense: if we want the thing to be better, it will have to be different. In particular, it cannot have kernel modules promiscuously loaded and unloaded. Thus not all software will run on the laptop. But that is already the case for the most widely distributed home systems: a Microsoft program will not run on GNU/Linux, an Apple program will not run on a Microsoft OS, etc.. I don't have any immediate answers to any of Michael's questions but I think looking at how the standard ditros deal with this would be a starting point. ~Deepak The usual free Unices' security apparatus is ludicrously inadequate. The XO system should be much better. oo--JS. -- Deepak Saxena [EMAIL PROTECTED] ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] SuperUser permission for the Driver??
On Thu, 26 Jun 2008, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Deepak Saxena wrote: | I agree with Paul that we need to have a solution to these | cases iff we want to support running arbitrary software and | hw combinations on the XO. The other option is to limit the | scope of the system to a very specific set of sw and hw, | treating the XO as embedded education appliance instead of | a general-purpose laptop device, which I don't think | we want to do. That is _precisely_ what I want to do. OLPC's goal is to distribute XOs to the poorest children in the world. That means that in the category of electronics, the great majority will have the XO and nothing else. Peripherals are a rarity, an edge case. There is a planned design to allow the user to grant extra privileges to different Activities, but those privileges will probably never extend to loading arbitrary kernel modules. I have no problem declaring that anyone who is modifying the kernel is a developer, and should therefore get a devkey and call modprobe themselves. - --Ben Yes. oo--JS. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjw/AACgkQUJT6e6HFtqQlSgCfbDujhumR3cmtT/MpEH8qQidC cYEAn0atipCHDcuYjAIvS/E6IpxD0Ktb =WJse -END PGP SIGNATURE- ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: FW: Fundacion Marina Orth - Upgrade to image 703
Edgar, According to the release notes: http://wiki.laptop.org/go/OLPC_8.1.0_Software_Release_Notes official-703 is a reference OS release which contains no activities. Luis needs to follow the instructions in that page to install activities or he needs to install a derivative build such as http://download.laptop.org/xo-1/custom/peru/peru-703-6/ which contains activities (in this instance, customized for Peru). Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Am 26.06.2008 um 22:13 schrieb Albert Cahalan: On Thu, Jun 26, 2008 at 1:38 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Am 26.06.2008 um 10:53 schrieb Albert Cahalan: This idea of applying patch collections is disturbing. It reminds me of the terrible mess that Minix was back in 1991, when the license permitted people to share patches but not code with the patches applied. Here you have a technical limit instead of a legal one, but I expect that the result is not much different. I got that. The fundamental problem is the patch collection. There is a problem even if you can distribute the result. Patches need to be applied. If you do that, and distribute a blob, then we're back to the blob problem. If you don't do that, then we have the Minix problem. I don't actually disagree with that. Smalltalk is an excellent personal computing environment (well, you would expect that from the guys who largely invented personal computing). It does not fare nearly as well for distributed, collaborative development (although the Squeak community has developed work-arounds, like Monticello, a nice distributed SCM). But: Why should these shortcomings in development style be a reason to not include it in a Linux distribution? It's not like if every other app is well-coded or well-maintained. The very foundation of the Linux development community (which Squeak developers are asking to be accepted by) includes an expectation that software can be handled in certain ways. Any person can browse the source, with the worst case being that one must download an archive file or perform a check-out. check (better: web git/cvs/svn access) Any person can use external tools, which themselves are likewise open, to view/edit/save/create/share the source. check (better: those tools are standard, like emacs/gimp/audacity) We also expect a certain degree of openness (not a lot of non-public communication) check and a certain degree of modularity (parts are interchangable across similar projects and versions, allowing distributions to mix and match). check No problems, great. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Trac Usage Conventions
Dear world, In yesterday's software status meeting, we formulated some conventions for using Trac for the next few months. They are: 1. The release team - presently including me, Greg Smith, and Kim Quirk will occasionally tag a ticket as 'blocks:8.2.0' to indicate that it blocks the 8.2.0 release. Such tickets will be understood to be part of our release criteria. If you think that a ticket should be so marked, please poke us until we deal with it. 2. Greg will record customer preference data according to whatever means he sees fit and will inform us of these data in regular meetings. 3. Kim wants a way to keep track of 'critical' bugs. Michael defined 'critical bugs' as those bugs which receive the most careful oversight by the release team. Shortly, the release team will invent a convention for identifying such bugs which permits their inclusion in reports. These reports will be listed on the frontpage of Trac. 4. People should indicate the release they _wish_ that changes would land in via the Milestone field. 5. People should indicate their confidence that the changes _will_ land by tagging tickets with strings like: 8.2.0:+ -- means that the change is within reach or, preferably, has been included in a dist-olpc3-updates series build. 8.2.0:? -- the change is in danger of missing the boat. 8.2.0:- -- the change is unlikely to be ready for release (NB: Please be conservative in tagging things rel:+.) 6. When it's unambiguous, people should attach test results to tickets with tags like: joyride-2027:- -- the issue persists in joyride-2027 joyride-2029:+ -- the issue was not reproducible in joyride-2027 If appropriate, please also describe the test procedure that was executed to generate the result. 7. We have added a 'Needs Action' field to Trac with several states for common actions (and various kinds of ignorance of what action is needed.) Please use it. Let us know if we need to change the set of actions. 8. The 'priority' field is a place for component maintainers to say what they think is important; however, we expect that our regular IRC meetings and emails will be the primary vehicle for communicating day-to-day priority information. (NB: We may revisit the priority information decisions.) Please comment freely. Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Trac Usage Conventions
On Fri, Jun 27, 2008 at 1:24 AM, Michael Stone [EMAIL PROTECTED] wrote: 4. People should indicate the release they _wish_ that changes would land in via the Milestone field. I tend to think the Milestone should be set by the bug owner (or by other developers in its team) and not by the bug reporter. I'm not sure if that's what you mean with people or not. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Albert, The very foundation of the Linux development community (which Squeak developers are asking to be accepted by) includes an expectation that software can be handled in certain ways. I don't know if it is *very* foundation, yeah there is an expectation. I know it because I was one of them. But the questions are that what would be the greater benefit for everybody, and whether the exepectation justifies to limit other people's freedom. The technical stuff you wrote below (ah, Bert replied, too) *can* be done (though not common practices) with Etoys/Squeak. How many times you try to spread the same false information, the fact doesn't change. Anyway, you now seem to agree that Etoys qualifies as open source. That is good. and a certain degree of modularity (parts are interchangable across similar projects and versions, allowing distributions to mix and match). Again and again and again, you can just write a method or two internally or externally and send it to your friend or post it to trac, etc. And a person who are using similar versions of Squeak, he can just load it. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Running regular X11 apps
On Thu, Jun 26, 2008 at 2:19 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 10:35 AM, Albert Cahalan [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 4:14 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Other than the circle icon, do you have any major issue? If it's just that, adding _NET_WM_ICON support to the sugar shell should be really easy. Great. BTW, the old-style bitmaps could be given the XO colors and then scaled. I'm planning to work on a proper fix for the whole issue (at the window management level at least) for 0.84. How will it work? Consider running one Sugar activity per virtual desktop. This would allow multi-window programs like the infamous gimp to fit in pretty well, except that of course they are not full-screen and thus receive window borders. Nobody ever sees a window border until they run something that isn't full-screen. Not fully defined yet. Sayamindu experimented with it a bit, there are (messy) notes on the wiki: http://wiki.sugarlabs.org/go/WindowManagement Your idea is interesting, I'll try to think it all through. I added it to the wiki btw. From what I gathered from my experiments, I think it makes sense for us to go with Metacity + maximus. That would require no code changes in metacity and minor changes in sugar. If we want to support activity icons though, we would probably require some more code changes in sugar. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: FW: Fundacion Marina Orth - Upgrade to image 703
Thank you Michael, We will give it a try tomorrow. Regards, Edgar - Original Message - From: Michael Stone [EMAIL PROTECTED] To: Edgar Ceballos Cc: Michail Bletsas [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; Luis Fernando Sanchez Hurtado [EMAIL PROTECTED]; Luis Fernando Sánchez [EMAIL PROTECTED] Sent: Thu Jun 26 18:47:52 2008 Subject: Re: FW: Fundacion Marina Orth - Upgrade to image 703 Edgar, According to the release notes: http://wiki.laptop.org/go/OLPC_8.1.0_Software_Release_Notes official-703 is a reference OS release which contains no activities. Luis needs to follow the instructions in that page to install activities or he needs to install a derivative build such as http://download.laptop.org/xo-1/custom/peru/peru-703-6/ which contains activities (in this instance, customized for Peru). Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Trac Usage Conventions
On Fri, Jun 27, 2008 at 01:31:24AM +0200, Marco Pesenti Gritti wrote: On Fri, Jun 27, 2008 at 1:24 AM, Michael Stone [EMAIL PROTECTED] wrote: 4. People should indicate the release they _wish_ that changes would land in via the Milestone field. I tend to think the Milestone should be set by the bug owner (or by other developers in its team) and not by the bug reporter. I'm not sure if that's what you mean with people or not. Your suggestion seems good; also, I was intentionally vague. What do others think? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Parallel desktops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There have been periodic suggestions, including some by potential OLPC buyers, that they would be more interested if the project offered a GUI that more closely resembled the environments to which they are accustomed. ~ I strongly disagree with these people, feeling instead that Glucose is already a highly effective environment with a very bright future. However, it seems that some deployments, seeing Glucose as unfamiliar, might instead choose Windows, which I hate to death [1]. To demonstrate that we too can play the same old desktop game, I would like to construct a disk image for the XO that provides, on each login, a choice between Sugar and a standard desktop environment. Indeed, we may even choose to ape Windows to the edge of nausea, like LXDE [2], or Windows-ish XFCE themes [3], just to prove that we can. I would like to collect all information necessary to execute this task, which we have been talking about for months if not years. I am told that precisely this sort of desktop switching is already working on Ubuntu, using gdm. What is its status under Fedora 9 and the new joyride? What needs to be done? - --Ben P.S. I'm talking to you, dgilmore. [1] http://www.penny-arcade.com/comic/2007/04/09/ [2] http://www.lxde.org/screenshots.html [3] http://www.23hq.com/Vincentt/photo/2871684 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhkOtkACgkQUJT6e6HFtqQ4XQCfcWnQ8VOMpGqfGMnuaSuTybXq /LkAnjjHEEbmxwEBDRh/AJcKvr7w5VfX =uHaL -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2080
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2080 Changes in build 2080 from build: 2079 Size delta: 0.00M -olpcrd 0.43-0 +olpcrd 0.44-0 +olpcsudo 1.3-0 -olpcupdate 2.8-0 +olpcupdate 2.9-1 -telepathy-salut 0.2.3-1.fc9 +telepathy-salut 0.2.3-2.fc9 --- Included olpcsudo version 1.3-0 --- --- Changes for olpcupdate 2.9-1 from 2.8-0 --- + Repackage as RPM using mock. --- Changes for telepathy-salut 0.2.3-2.fc9 from 0.2.3-1.fc9 --- + dev.laptop.org #6782: Improve debug info when joining a muc -- 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 now available in Debian's non-free repository
On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED] wrote: I'm glad that Debian didn't break the rules for etoys. You're claiming to be open source, yet you've LOST the source code decades ago. This turns out not to be the case. All of the source code for the parts of Etoys written in Squeak/Smalltalk is in the image. The .sources file and .changes file contain all of this code nicely formatted. The core of Smalltalk, the part not written in Smalltalk, is also available in both source and in binary parts of the usual image. The usual tools for handling all of this are in Smalltalk/Squeak. Nothing prevents you from rewriting them in C, Python, or what you like. The Smalltalk community is puzzled that anybody would prefer to work on Smalltalk in something other than Smalltalk. Hacking up binary images is shockingly horrible software non-engineering. It isn't hacking up, and it isn't a binary image. They mostly leave .sources alone, and write code in Smalltalk, which normally goes into the .changes file as structured text within a structured and documented programming object until a new release. The .changes file is recompiled whenever needed, such as when refactoring previously defined objects. GNU Smalltalk is built in a relatively normal way. s/normal/conventional/ OLPC could ship that instead, assuming that Smalltalk is desirable. No point. Anybody who wants to can extract the source code from an Etoys image and create the objects you desire. That is the point. You, and apparently some of the Debian people, are complaining about two things, as far as I can tell. One is that the Etoys people haven't given you a directory tree of text files including appropriate makefiles that would recreate the entire Etoys image, bit-identical to what they ship. I'm happy to discuss that, since creating those files would apparently let Etoys go into the Free repository. The other complaint is that all of the tools for working on Smalltalk source are written in Smalltalk, except for the bits to be compiled in C. I don't get it. All of your C tools are in C. A .tgz of a directory tree of files is a binary object just as much as an Etoys image is, neither more nor less. If your tree includes the sources for some app, plus emacs and gcc and the necessary libraries (source or binary), the .tgz is still a binary object with all of your tools in it. In the extreme case we have a complete Gentoo distribution, and we compile _everything_ from source, including another instance of gcc. I can examine the sources elsewhere, but I have to trust the compiler to some extent, and a lot of other code that I haven't examined. Most of it has been examined by somebody, but there are arcane parts of X, for example, where I don't know that you or even Jim Gettys could give me the name of anybody who still understands it. In any case, this has no practical significance. If _you_ want to write tools external to Etoys and Smalltalk that replicate functions in Smalltalk, knock yourself out. But does Debian want them? I don't see any reason to. But it doesn't matter what I think. What does Debian think? Now, for the rest of you, let's see what we can produce, to make Albert happy, but more importantly Debian. We have .sources and .changes. Albert and Debian would like to see source for the VM, in the manner of gst, and the binary core of Smalltalk that goes with it. What can we show them, and what would it take to show them the rest? The Squeak system includes code for generating a new version of the virtual machine (VM) on which it runs. It also includes a VM simulator written in itself (Squeak). For this reason, it is easily ported. What's missing? Is there anything in bytecode without Smalltalk source? It doesn't seem so. The primitives like memory management and BitBlockTransfer get translated to C and compiled along with the VM. Is that right? Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs using the full range of Smalltalk semantics, including blocks. http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html, Related Work. So apparently we can translate all of the Smalltalk tools for creating code files and rebuilding an image to C source, and we can presumably preserve the original comments from the Smalltalk. Would that make Albert happy? What about Debian? Albert, would you take a look at http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html? It explains the bootstrapping process from Apple Smalltalk to Squeak, including writing tools in Smalltalk to generate compilable C code from a Smalltalk interpreter written in Smalltalk, and writing a small C program to interface to the OS. Since the result was a complete Squeak image with all Smalltalk source code, and C source where needed, is anything else missing? The interpreter is structured as a single class that gets translated to C along with the ObjectMemory and BitBlt classes. Is that it? What is the source management system for
Re: Parallel desktops
Hi, There have been periodic suggestions, including some by potential OLPC buyers, that they would be more interested if the project offered a GUI that more closely resembled the environments to which they are accustomed. There's another use case, unmentioned, which is the G1G1 community. Some of these donors expect a laptop that follows their expectations about computers: robust support for wireless access points, printing, office automation programs, and loading files from a filesystem without finding a clever way to inject them into our journal first. Instead of (or as well as) preparing a separate disk image, we could prepare a Desktop activity which launches an Xfce session and includes some office tools, the standard NetworkManager applet, a configurable CUPS installation, and so on. This could reduce our support load, allowing us to proceed on with our regularly-scheduled world-saving. Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XO Opera browser as Sugar activity
Hi Bert, all -- On Jun 25, 2008, at 11:37 PM, Bert Freudenberg wrote: Sure. Do not use the Python script. You don't want to run a Python activity but a native one - otherwise you get two windows, the empty one opened by Python and the real one by Opera. Instead, you only need a tiny shell script that preloads a little library, which may work with Opera: http://lists.laptop.org/pipermail/devel/2008-January/009387.html I tried a shell script and it works: #!/bin/sh while [ -n $2 ] ; do case $1 in -b | --bundle-id) export SUGAR_BUNDLE_ID=$2 ;; -a | --activity-id) export SUGAR_ACTIVITY_ID=$2 ;; -o | --object-id) export SUGAR_OBJECT_ID=$2 ;; -u | --uri) export SUGAR_URI=$2 ;; *) echo unknown argument $1 $2 ;; esac shift;shift done export LD_PRELOAD=$SUGAR_BUNDLE_PATH/lib/libsugarize.so export NET_WM_NAME=OperaBrowse exec opera -notrayicon -personaldir $SUGAR_ACTIVITY_ROOT/data This starts Opera from Sugar and it runs correctly. Thanks for the direction. -Peter And since you're investigating this, what would be great is if you could re-package Opera as a real activity. That means, just move the Opera files that are normally installed in the system into the bundle itself, and setup the environment in the shell script so it works from that non-standard directory. Then zip up the activity directory, rename to .xo, and we have a real Opera bundle :) That way it would also survive a system upgrade which erases all manually installed RPMs. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Parallel desktops
On Friday 27 June 2008 1:59:16 pm Chris Ball wrote: Instead of (or as well as) preparing a separate disk image, we could prepare a Desktop activity which launches an Xfce session and includes some office tools, the standard NetworkManager applet, a configurable CUPS installation, and so on. This could reduce our support load, allowing us to proceed on with our regularly-scheduled world-saving. In another thread there is talk of using virtual desktops per Activity, which is an idea that I had been wondering why it hadn't been that way from the beginning. I think the best outcome would be to find a way to do these two complimentary. I don't like the Idea that a desktop and and sugar are mutually exclusive. Simply clicking on an activity in sugar and getting a traditional desktop would work for those that want it. A Windowsy theme and Wine may even satisfy those with urges leaning in that direction. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Parallel desktops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Ball wrote: | Instead of (or as well as) preparing a separate disk image, we could | prepare a Desktop activity which launches an Xfce session and includes | some office tools, the standard NetworkManager applet, a configurable | CUPS installation, and so on. This could reduce our support load, | allowing us to proceed on with our regularly-scheduled world-saving. I agree that this is a very interesting idea, but at present it's also a pretty serious research project. It potentially involves Xephyr and some crazy Sugar window management hackery. Meanwhile, the dual-desktop approach is /already working/. I'm just trying to get someone to tell me /how/ it's working, so that I can smush it into a build. Also, on a memory-constrained system, running only one desktop environment at a time may prove to be an important design choice. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhkVwgACgkQUJT6e6HFtqR5sgCfb+sUCTUH9Xu15nZUrjWHh4ZE 2VwAniT359xkEEPnx1LDSdU760LO70jU =pr+7 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
A greater cause (Re: etoys now available in Debian's non-free repository)
Hello, Sorry for causing some email traffic last a few days. We, everybody who are participating the project, including Albert, John, Bert and myself, are working for a greater cause; that is to empower children all over the world via computer technology and education. There are some difference of opinions, but let us not lose the sight of the bigger goal. Etoys is already installed millions of computers, and children all over the world have been using it several years. If we get Etoys to the hands of more children, more children can exchange projects, share ideas, work together, and unite. It doesn't matter whether the computer they use is XO or not because Etoys happens to run everywhere. And, on XO, I heard from people at deployments/pilots often that Etoys is one of the most important activity. So, I think that trying to get Etoys into major Linux distributions serves for the greater cause. Of course, even if Etoys gets in a Linux distribution, not every user/developer has to work on Etoys nor everybody has to understand how it is implemented. For those, it is just several unfamiliar files on their disk and there is absolutely no harm. On the other hand, we would like to get more people to help Etoys development And I can assure you that you can go deeper than any other systems once you dive in. Please join us! Even if your only computer is XO, you can participate as good as the core developers. (If you are good, you can join/take over the core team, in fact.) Also, please think about making a similar/better system in any other languages. Alan Kay gave a keynote speach at Euro Python a few years ago and urged the community to think about it. It seems that a few project got started but it takes years to be somewhat usable. Finally, thank you for everybody who have been involved in the actual process of getting Etoys accepted to these distributions! -- Yoshiki In a sense, Albert, John, Frank and others are kindly playing the devil's adovocate role so that we can write stuff that we usually don't. Thank you guys, too^^; ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Running regular X11 apps
On Thu, Jun 26, 2008 at 8:28 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: From what I gathered from my experiments, I think it makes sense for us to go with Metacity + maximus. That would require no code changes in metacity and minor changes in sugar. If we want to support activity icons though, we would probably require some more code changes in sugar. Maximus won't handle the gimp AFAIK. Can't regular activities just ask to be maximized and/or ask to be the same size as the screen? The common Python libraries could do this. The critical thing here is switching between multi-window programs that have stuff like floating toolbars. I suspect that a one-desktop-per-activity policy will get you that. If metacity needs to change, then it changes. Changing it might involve a new freedesktop.org specification, so that the changes don't become some sugar-specific hack. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] [PATCH] postprocess.py gets fleshed out, and incrontab tweaks
From: Martin Langhoff [EMAIL PROTECTED] postprocess.py now provides hardlinked timestamped directories, and maintains a symlink pointing to the latest transferred directory. The timestamped directories are maintained with a resolution of the nearest minute - we don't expect to have more than one per hour. The incrond crontab gets updated to deal well with rsync clients too. To work well with rsync, the rsync client must use the -T option to avoid creating tempfiles in the monitored directory. Strangely, incrond cannot handle comments on its tab files, so we workaround that for the moment. This is known as bug 173 in the incrond bugtracker (bts.aiken.cz). --- server/incron-ds-backup.comments | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 server/incron-ds-backup.comments diff --git a/server/incron-ds-backup.comments b/server/incron-ds-backup.comments new file mode 100644 index 000..6edb8d8 --- /dev/null +++ b/server/incron-ds-backup.comments @@ -0,0 +1,11 @@ +## NOTE: incrond v0.5.5 cannot cope with +## comments in its tab files. So we +## put them here, until incrontab gets +## better at this :-) + +# We monitor create and move to, because +# while touch/echo will trigger IN_CREATE, +# rsync transfers (use the -T flag!) will +# create the file in a tempdir and then mv +# it into place. Again: use rsync -T /tmp +# : [EMAIL PROTECTED] -- 1.5.6.dirty ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] [PATCH] ds-backup client - fix rsync paths to the XS.
From: Martin Langhoff [EMAIL PROTECTED]
---
client/ds_backup.py |8 +---
client/ds_backup.sh |2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/client/ds_backup.py b/client/ds_backup.py
index 60d0be2..089a2e9 100755
--- a/client/ds_backup.py
+++ b/client/ds_backup.py
@@ -83,9 +83,11 @@ def rsync_to_xs(from_path, to_path, keyfile, user):
# Transfer an empty file marking completion
# so the XS can see we are done.
+# Note: the dest dir on the XS is watched via
+# inotify - so we avoid creating tempfiles there.
tmpfile = tempfile.mkstemp()
-rsync = (/usr/bin/rsync --timeout 10 -e '%s' '%s' '%s'
- % (ssh, tmpfile[1], to_path+'/.transfer_complete'))
+rsync = (/usr/bin/rsync --timeout 10 -T /tmp -e '%s' '%s' '%s'
+ % (ssh, tmpfile[1],
'schoolserver:/var/lib/ds-backup/completion/'+user))
rsync_p = popen2.Popen3(rsync, True)
rsync_exit = os.WEXITSTATUS(rsync_p.wait())
if rsync_exit != 0:
@@ -130,7 +132,7 @@ if __name__ == __main__:
sstatus = check_server_available(backup_url, sn)
if (sstatus == 200):
# cleared to run
-rsync_to_xs(ds_path, 'schoolserver:datastore', pk_path, sn)
+rsync_to_xs(ds_path, 'schoolserver:datastore-current', pk_path, sn)
# this marks success to the controlling script...
os.system('touch ~/.sugar/default/ds_backup-done')
exit(0)
diff --git a/client/ds_backup.sh b/client/ds_backup.sh
index 9916334..334e4eb 100755
--- a/client/ds_backup.sh
+++ b/client/ds_backup.sh
@@ -121,7 +121,7 @@ fi
# We use this to stagger client machines in the 30 minute
# slots between cron invocations...
# (yes we need all the parenthesys)
-(sleep $(($RANDOM % 1200)));
+#(sleep $(($RANDOM % 1200)));
# After the sleep, check again. Perhaps something triggered
# another invokation that got the job done while we slept
--
1.5.6.dirty
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
