Show Must Go On - SoaS for the XO-1
by Sebastian Dziallas
Hi everybody,
I'm very pleased to announce the first early preview of a new generation
of SoaS XO-1 images. Those consist not only of the latest and greatest
Sugar bits, but also a F11 base system and a special OLPC kernel based
on 2.6.30.
This means now that even power management actually works out of the box.
There are some other points, for example the mostly working keyboard
keys. But this is really just a preview!
You'll notice only very few activities in your home view, which is due
to a mistake in our config files. You'd be able to symlink the folders
from /usr/share/sugar/honey to ~/Activities, though. This is a known
issue, but if you come across others, please let us know!
Finally, I'd like to take the chance to thank all the people for their
tremendous work, especially Martin Dengler and all the folks at OLPC!
Now how can you get that? Just download the following two files:
http://download.sugarlabs.org/soas/xoimages/devxo-1.crc
http://download.sugarlabs.org/soas/xoimages/devxo-1.img
Put them on a USB key or a SD card, plug them into your XO and execute:
copy-nand u:\devxo-1.img or copy-nand sd:\devxo-1.img
Note that you'll need to have an unlocked XO and the latest firmware!
So. Happy hacking and let us know what you think! :)
--Sebastian
14 years, 9 months
olpc-switch-desktop issues
by Alexander Boström
Hello,
I'm working on submitting olpc-switch-desktop for inclusion in Fedora. I
(or rather rpmlint) found these issues:
The .spec from the repo, the GNOME .desktop and the Sugar control panel
references a couple of SVG files, but those aren't in the repo. Are
there any suitable icons to use or do someone need to create them?
The .spec creates /etc/skel/Desktop (for the GNOME .desktop file). I
think that breaks the feature that a name from the user's locale is used
when creating the desktop directory (xdg-user-dirs), so that needs to be
done some other way.
Is there a way to place an icon on every user's desktop without poking
around in their ~/Desktop? If not, perhaps the Sugar part can install
the GNOME .desktop file for the user when the user first switches from
Sugar to GNOME? Then it is only done for GNOME users who actually ran
Sugar in the first place (call that a feature or a bug) and by then the
locale is hopefully set correctly so that the desktop directory can be
created the proper way.
Also, the GNOME app should probably have a license declaration at the
top of the source file, or the license should be stated explicitly in
the README.
/abo
14 years, 9 months
Tkinter support in sugar builds
by Shawn Willden
Is there any plan for it? A friend of mine is interested in porting some math
ed apps to the OLPC, but they're written with pytkinter. He's trying to
decide if he needs to port to pygtk.
Assuming it's reasonable to install tkinter on the XO in order to support his
apps, any idea how difficult it would be to "sugarize" a tkinter app, so that
it can run as an activity? I have basically zero knowledge of what's
involved in sugarization, so please excuse me if this is a dumb question.
All comments/suggestions/flames appreciated,
Shawn.
14 years, 10 months
Broken browse activity for strawberry.
by Luya Tshimbalanga
Hello,
With a lot of help of OLPC team, my XO-1 got repaired and I am able to
test strawberry from Sugarlabs. While the power management is not quite
optimized, the wireless connection has definitively improved.
I have a problem running browse active in XO-1 because it traceback
somewhat? Has any with XO-1 got the same issue?
Luya
14 years, 10 months
Re: Broken browse activity for strawberry
by Mikus Grinbergs
> I have a problem running browse active in XO-1 because it traceback
> somewhat? Has any with XO-1 got the same issue?
I'm booting strawberry on my XO-1 from an USB stick. I'm not really
an user of Browse (I prefer Firefox or Opera, both of which launch
ok on strawberry on my XO-1), but *all* the instances in which I've
used Browse (108) on strawberry on XO-1 have worked ok for me.
[Yes, there are some tracebacks in Browse's output log (e.g., for
xpcom using xulrunner), but those did not appear to affect Browse
showing/downloading the things I told it to do.]
I would not say "broken" for Browse Activity on strawberry.
mikus
14 years, 10 months
Fedora packages for XO-1.5 distro
by Daniel Drake
Hi,
Just wanted to point out the slowly-growing list of custom packages that
we're including in the XO-1.5 F11 build:
http://wiki.laptop.org/go/F11_for_1.5#Modifications_to_Fedora
I'm hoping to spearhead some efforts to get these included in the Fedora
package tree (specifically dracut, dracut-modules-olpc, olpc-bootanim,
olpc-library, olpc-switch-desktop and olpc-utils) but I have not found
the time yet. If anyone wants to contribute and has some time on their
hands, getting a head start on a couple of these would be a huge help.
cheers
Daniel
14 years, 10 months
strawberry on XO-1
by Mikus Grinbergs
[ FYI. I am _not_ asking for help; I'm sharing my experiences. ]
Booted my XO-1 from an USB stick with build soas strawberry on it.
[Because I do not have any system on which mounting of a squashfs
filesystem works, I have to use the rawhide version of the
livecd-iso-to-disk script; neither does livecd-iso-to-xo work, so I
am unable to install builds distributed as .iso onto my XO's nand.]
Strawberry (F11-based) works; but it is reproducibly stalling when
doing a huge 'rsync'. [Since the system then is unresponsive, I
can't examine it. My suspicion is that the system ran out of
memory, despite having a swap partition active.] The interesting
thing is that on my XO-1, Soas2-20090622 (on which strawberry is
supposedly based) runs the same 'rsync' without trouble.
mikus
14 years, 10 months
rpm vs xo & activity updates
by Daniel Drake
Just a quick summary of a discussion and a decision that we reached on
IRC, which will hold at least for now with our XO-1.5 software builds.
Further input is welcome, although this is at risk of starting another
huge discussion...
Question: In the early XO-1.5 OS builds right now, we have a mix of
RPM-based sugar activity packages, and .xo files unzipped
in /home/olpc/Activities. Do we want to change?
- It would be a little unfortunate to ignore the hard work of those who
have been actively packaging the activities within Fedora.
- rpm-based packages cannot be updated with Sugar's updater utility,
which is the primary way for updating activities right now. There is no
upgrade path for activities installed by rpms (without updating the
whole OS, which is another open question)
- We could somehow hack the updater to work with rpms, i.e. if it found
a newer .xo bundle it could unzip it over the top of the rpm-installed
files in /usr/share/sugar/activities, but this is nasty and would raise
many issues
- One flaw in the existing OLPC OS releases for XO-1 is that there's no
way for deployments to push automatic activity updates, because
olpc-update doesn't touch /home and the activity updater always has to
be invoked by the user.
- This flaw would go away with rpm-based updates, because whatever
"global" OS updater we choose would include these updates.
- Which leads onto the possibility that *all* activities could be
shipped as RPMs, the sugar control panel activity updater could be
deleted, and then this problem is solved -- but that's quite a change
- The easy option is to do what we've done before: ship activities
entirely as .xo bundles in /home/olpc/Activities
- We're going to go with this option for now, because it's quick and
easy and it's what we're already doing.
- There is certainly room for improvement in future, but finding
development time in the short term may be a bit tricky... or perhaps we
will be able to raise community interest in making or implementing a
plan for improvement... :)
Daniel
14 years, 10 months
update mechanism for new releases
by Daniel Drake
Hi,
We have a bug open here which is a difficult question, in my opinion:
http://dev.laptop.org/ticket/9349
For the upcoming XO-1.5 software build (which will hopefully make it
onto XO-1 in the near future), do we want to ship olpc-update or use
standard Fedora technologies?
My unconclusive thoughts and questions:
olpc-update has some features which aren't available elsewhere, such as
the ability to switch between 2 OS builds installed on the same disk.
However, I've never seen or heard of this being used in the field.
olpc-update is a "deployment quality" system in that it has covered
everything - not only from being an updater, it has olpc-update-query
which implements logic to figure out when to ask for updates and where
to ask for them. It's accompanied by the theft deterrence protocol and 3
different server-side implementations of that. It's been implemented in
OLPC deployments.
olpc-update creates a huge mass of hardlinks on disk, one for every file
on the main OS. It then rsyncs in the updated files on a copy-on-write
basis. Therefore you end up with a hell of a lot of hardlinks, and 2
complete copies of every file that has changed. (this means it is not
great for situations when a lot of files have changed, e.g. changing
between major Fedora releases)
olpc-update presents challenges for deployments that customise their
images. Namely, to produce a build that it is possible to olpc-update to
involves quite a bit of hassle (inserting security keys into the
firmware of each XO, setting up an OATS server, etc). We did manage to
figure this out in Paraguay (thanks to the internet connection, since it
wouldn't be safe to put the OATS server in the schools) and I improved
some tools accordingly.
We've switched to dracut for our initramfs, meaning that the
initramfs-level stuff for the olpc-update system needs to be
reimplemented. Basically we have to wrangle with the strange /versions
filesystem layout and "frob" the /versions/current symlink if the user
is switching between versions. I have reimplemented this logic in a
dracut module but it is completely untested.
The option for using "Standard Fedora technologies" as far as I am aware
is to basically use "yum update" in a fashion somehow suited for
deployments.
Before F11, this would have meant a lot of downloading as each RPM
update was downloaded in full even if only a little bit changed. As of
F11, Fedora is now joining the "only download the bits that change"
movement with yum-presto and deltarpms: http://lwn.net/Articles/329484/
The deltarpm description on that lwn article leaves a little to be
desired -- it wouldn't work with big packages (is the quoted 200mb the
compressed or uncompressed size?), the reconstruction from deltas is a
CPU intensive task and we have a slow CPU, and it's all done in memory
and we don't have a huge amount of memory especially on XO-1.
olpc-update has an overhead of about 5 minutes of checksumming files.
Even though olpc-update isn't great for doing big distro updates
(because of storing 2 copies of changed files, in this case almost all
of them), it worked in those situations. I've never attempted an
RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that
work out for regular Fedora users?
"yum update" always seems to use a surprising amount of bandwidth,
redownloading entire package databases just to see if anything new is
available. olpc-update was much more efficient in this respect, sending
only a 128-byte hash of the filesystem contents file to the OATS server.
For rpms, is there a more efficient alternative for updates-checking in
situations where there is only going to be e.g. 1 update per month?
"yum update" has historically not worked very well on the XO. It hits
OOM, it fills up yum's cache and then aborts, it gets confused between
i586 and i686, etc.
We would have to tweak yum's behaviour quite heavily.. I don't think we
want an rpm cache, or for it to keep the .rpm files at all.
It introduces new questions of security, signing, etc. Deployments will
want to sign their rpm updates that they push out, so we now need a
mechanism for getting that specific RPM signing public key onto all the
laptops in a deployment so that they can trust the updates server.
We had this nailed down for olpc-update: deployments can insert "local"
public keys into the manufacturing through keyjector firmwares for
existing laptops, and Quanta can now manufacture laptops with these keys
already in place for future orders. olpc-update and the bitfrost code
used these keys to verify updates.
For the XO-1 possibility it raises the question of how existing laptops
could be migrated to this new system, without losing their user data.
Using "yum update" would be a large benefit of sharing technologies with
other communities and not having to maintain our own systems and tools.
However olpc-update would be easier in the short term because all the
components have been implemented and deployed, and there aren't really
any open questions.
Any other thoughts/opinions one way or the other?
Daniel
14 years, 10 months
