I have been following prior discussions about codecs in general (it is
not about Gnash) and there is one thing I cannot understand.
As I see for example a H.264 AVC codec license is 0 or 10 or 20
cents/device. If I am mistaken somebody please correct me. See:
Ivan,
I wasn't referring just to the packages, but also to the ChangeLog entries.
Cheers,
Reinier
Ivan Krstić wrote:
On Jan 8, 2008, at 5:54 PM, Reinier Heeres wrote:
As an added bonus, it should be possible to create a diff between *any*
two versions.
See also
On Tue, 2008-01-08 at 19:34 -0700, Rob Savoye wrote:
Sigh, I am getting so tired of this issue with codecs... Gnash for
the XO is built without support for any proprietary audio or video
codecs. Because of the patent laws, the OLPC project (which is based in
the US) cannot
On Tue, 2008-01-08 at 20:06 -0700, Rob Savoye wrote:
To go along with this, I've been working on a clone of the Adobe
Media Server, so we can steam free codecs. Right now you can only do
this with icecast, but it doesn't speak the flash protocols, which
Gnash now supports.
Oooh. Gnash
On Jan 8, 2008, at 23:54 , Reinier Heeres wrote:
Hi all,
I recently started working on a new build announcer script in python.
It's available at dev.laptop.org/~rwh/announcer.
Looks good :)
I'd like to compare the output of my script and the present announcer
for a couple of days to make
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build676/
-matchbox-window-manager.i386 0:1.2-1
+matchbox-window-manager.i386 0:1.2-3.20070628svn
--
This email was automatically generated
Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html
[EMAIL PROTECTED] wrote:
The other option is to write implementations of the codecs that avoid
the patents. Whether that is possible depends on the exact wording of
the patent, and sometimes it takes a few weeks working with a good
patent attorney to work out exactly what the patent really
All three bars along the top row of the keyboard act as analog sliders
when the FN key is held down. They have four distinct key assignments under
normal operation.
-walter
On Jan 9, 2008 2:51 AM, Zarro Boogs per Child [EMAIL PROTECTED] wrote:
#5859: Need a way to tactily distinguish keys on
On 08/01/08 17:09 -0800, William Fisher wrote:
Jordan Crouse wrote:
On 08/01/08 12:06 -0500, Bernardo Innocenti wrote:
(cc CP, aleph)
David Woodhouse wrote:
1. Did anybody profile the kernel while reading files? Last thing I red
on this list is that the profiler does not work on the XO in
Right now we have a problem with mesh portal discovery.
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST). Furthermore,
as the address previously assigned indicates which mesh portal
Have 674. Don't quite know if this is equivalent or not, but
instead of doing 'olpc-update' for 675 and 676, I've just been using
'yum update'. Seems to upgrade the same modules as the new builds.
mikus
___
Devel mailing list
Devel@lists.laptop.org
On Wednesday 09 January 2008, Mikus Grinbergs wrote:
Have 674. Don't quite know if this is equivalent or not, but
instead of doing 'olpc-update' for 675 and 676, I've just been using
'yum update'. Seems to upgrade the same modules as the new builds.
that will work for everything except
John Watlington [EMAIL PROTECTED] wrote on 01/09/2008 11:34:29 AM:
Right now we have a problem with mesh portal discovery.
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST).
On Jan 9, 2008 10:51 AM, Jordan Crouse [EMAIL PROTECTED] wrote:
We can't use NMI, because we have no mechanism for causing the NMIs.
Modern processors such as the k8 use registers called event counters
to count a number of events between sample periods (events being some
processor quality like
On Jan 9, 2008 11:21 AM, Michail Bletsas [EMAIL PROTECTED] wrote:
...
The largest issue is how wrong, ugly and painful is to use DHCP on a mesh
network.
Because of RADV, IPv6 doesn't have that issue. The original mesh portal
discovery method was
proprietory but also extremely lightweight
Walter Bender wrote:
All three bars along the top row of the keyboard act as analog
sliders when the FN key is held down. They have four distinct key
assignments under normal operation.
Yes. And each one of the analog sliders is actually *8*
keys rather than just 4.
We currently have no
On Wed, 2008-01-09 at 12:18 -0600, Charles Durrett wrote:
On Jan 9, 2008 11:21 AM, Michail Bletsas [EMAIL PROTECTED] wrote:
...
The largest issue is how wrong, ugly and painful is to use
DHCP on a mesh
network.
Because of RADV, IPv6 doesn't have
My XO is on order and I don't know when it will arrive.
I have filled my main system up with crap trying to get an XO emulator to
work.
I now have a system just for XO emulation.
So which OS/QEMU/VM works best.
I am really tired of working on this problem. I want to get on with XO
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1524/
-NetworkManager.i386 1:0.6.5-0.8.svn2925.olpc2
+NetworkManager.i386 1:0.6.5-0.8.svn3218.olpc2
-coreutils.i386 0:6.9-5.fc7
+coreutils.i386 0:6.9-6.fc7
-glibc-common.i386 0:2.6.90-19
+glibc-common.i386 0:2.7-2
-glibc.i686 0:2.6.90-19
I have had great success using vmware.
Download an image file from here: http://dev.laptop.org/pub/virtualbox/
(I have been using build 653)
and then open it with vmware.
I also tried qemu and virtualbox, but vmware was by far the easiest
to get going.
-josh
On Jan 9, 2008, at 10:31 AM, Kent
On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote:
Right now we have a problem with mesh portal discovery.
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST). Furthermore,
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build677/
+cairo.i386 0:1.4.10-1.fc7
-cairo.i386 0:1.4.12-1.fc7
-olpc-utils.i386 0:0.59-1.olpc2
+olpc-utils.i386 0:0.63-1.olpc2
-sugar-datastore.noarch 0:0.7.2-1
+sugar-datastore.noarch 0:0.7.3-1.olpc2
+totem.i386 0:2.18.2-11
-totem.i386
On Jan 9, 2008, at 2:08 PM, David Woodhouse wrote:
On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote:
Right now we have a problem with mesh portal discovery.
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not
On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote:
Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this
problem. It's easy to discover the shortest way out of the mesh
(nearest mesh portal), but setting up the larger mesh networkl
infrastucture means you also need to
What do you propose to do about it? Throw away pointless engineering
into cobbling together some way of making Legacy IP work a bit better? I
seriously hope not. Just switch off the Legacy IP, as we should have
done months ago, and get on with making things work properly. Anything
else is a
On Jan 9, 2008, at 2:40 PM, David Woodhouse wrote:
On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote:
Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this
problem. It's easy to discover the shortest way out of the mesh
(nearest mesh portal), but setting up the larger
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:40:46 PM:
We can also
check the mesh path length to the origin of each RA we see, and choose
the best one.
The way this was originally implemented in a way that can be used for any
well defined service (not just network gateways),
On Jan 9, 2008, at 2:55 PM, Michail Bletsas wrote:
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:40:46 PM:
We can also
check the mesh path length to the origin of each RA we see, and
choose
the best one.
The way this was originally implemented in a way that can be used
On Wed, 2008-01-09 at 14:43 -0500, Michail Bletsas wrote:
What do you propose to do about it? Throw away pointless engineering
into cobbling together some way of making Legacy IP work a bit better? I
seriously hope not. Just switch off the Legacy IP, as we should have
done months ago, and
The DHCP server was needed anyway. And to implement shortest path
routing both for sent and received packets, we needed a mechanism for
receiving an IP address that reflected the nearest MPP anyway (or use
NAT, something we would like to avoid inside the school)
I completely fail
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:57:50 PM:
NAT-PT and proxying should solve that problem relatively simply. I
should investigate the implementation at http://tomicki.net/naptd.php
Running application proxies on every XO that wants to act as a mesh
portal?
M.
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 03:17:30 PM:
On Wed, 2008-01-09 at 15:15 -0500, Michail Bletsas wrote:
Running application proxies on every XO that wants to act as a mesh
portal?
Running NAT-PT. Since they're required to run NAT as it is anyway, that
shouldn't be
On Wed, 9 Jan 2008, John Watlington wrote:
In the case of the mesh portal (A NAT Internet Gateway in our case) we
need to get back the IP address of the gateway as well as DNS info.
A simple python server listening at a predefined port was providing
that.
That simple server has been replaced
I completely fail to see why we need the DHCP server to get the IP
address
of the nearest MPP or get the optimal path to and from it.
The MPP discovery mechanism originally proposed worked great for getting
packets out of the mesh through the shortest path. The problem was
that
outside
The MPP discovery mechanism originally proposed worked great for getting
packets out of the mesh through the shortest path. The problem was
that
outside of running NAT on each MPP, there wasn't a good way to ensure
that packets sent to that laptop entered the mesh through the same MPP.
On Wed, 9 Jan 2008, John Watlington wrote:
I completely fail to see why we need the DHCP server to get the IP
address
of the nearest MPP or get the optimal path to and from it.
The MPP discovery mechanism originally proposed worked great for getting
packets out of the mesh through the
Hi all,
Thanks a lot for your help and comments.
However it seems quite difficult for us to encode our videos in
Theora+Vorbis right now. I'm gonna talk to different people in the
company to get their opinion and see what we can do.
In the meantime, I've heard of the Helix Media Player
Is it 8 or 7? I thought it was the four + 3 intermediaries.
-walter
On Jan 9, 2008 1:26 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote:
Walter Bender wrote:
All three bars along the top row of the keyboard act as analog
sliders when the FN key is held down. They have four distinct key
Will it be auto-installed when I olpc-update to latest joyride, or will it
have to be manualy installed?
-ffm
On Jan 9, 2008 4:33 PM, Mitch Bradley [EMAIL PROTECTED] wrote:
http://wiki.laptop.org/go/OLPC_Firmware_q2d08
This firmware has a large number of mostly-minor improvements. It is a
On Wed, 2008-01-09 at 15:59 -0500, John Watlington wrote:
On Jan 9, 2008, at 3:47 PM, Michail Bletsas wrote:
The MPP discovery mechanism originally proposed worked great for
getting
packets out of the mesh through the shortest path. The problem was
that outside of running NAT on
ffm wrote:
Will it be auto-installed when I olpc-update to latest joyride, or
will it have to be manualy installed?
Manual.
-ffm
On Jan 9, 2008 4:33 PM, Mitch Bradley [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
http://wiki.laptop.org/go/OLPC_Firmware_q2d08
This
currently (recent joyride versions) if you try to play a mp3 it fires up
etoys, which then takes you through some very un-suger-like options before
playing the mp3, but the player it's using doesn't seem to respond to any
keys (for pause/play/FF/rev/etc) and the progress bar does not appear to
John,
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST). Furthermore,
as the address previously assigned indicates which mesh portal
was selected, it seems like we should always be
At today's bug status meeting, I was asked to investigate SD card resume
timing from OFW.
The range was 24 mS to 187 mS , depending on which SD card is plugged in.
The fixed component of that time is about 5 mS, including re-initing the
host controller and issuing a sequence of card commands
Thanks for offering help. However, I was thinking more about
ressources (time, people, storage, encoding, priorities, etc.).
Anyway, I'm going to report what everybody wrote and see if we can
make it soon ... or later.
Thanks
Sebastien
On Jan 9, 2008 10:32 PM, Benjamin M. Schwartz [EMAIL
I've just been using 'yum update'.
Seems to upgrade the same modules as the new builds.
that will work for everything except activities which are not shipped as rpms
Would 'sugar-install-bundle' work for activities shipped as .xo ?
mikus
___
I've updated to the Q2D08 firmware now.
Whereas the '07 firmware seemed to run the test /wlan ok, but the wlan
card wasn't visible to the regular OS, now when I run the same command
on the '08 firmware I get
ok test /wlan
Device /wlan not found.
ok
So what's the verdict. Do folks think I
Hello Florian,
the attached patches add an option to pause login until the user hits
a key.
We need something like it on OLPC because:
- we don't want to set an empty password for either user root or olpc
- at the same time, we want to allow users to login as root at the
console
-
On Wed, 9 Jan 2008, Javier Cardona wrote:
The DHCP procedure currently being used only discovers
the nearest mesh portal when it is first run (DHCP_DISCOVER),
not when it tries to renew (DHCP_REQUEST). Furthermore,
as the address previously assigned indicates which mesh portal
was
Just switch off the Legacy IP, as we should have
done months ago, and get on with making things work properly.
Anything else is a distraction.
I sympathize with how overworked OLPC developers are. But a number
of G1G1 systems are getting into the hands of articulate net-aware
people. If
Well, darnit. Looks like things are flaky. Here is the procedure and
the results I just got.
- Flash q2d07.rom
test /wlan worked fine
- Flash q2d08.rom (to verify that 08 is causing problems)
test /wlan fails - device not found
- Flash q2d08.rom (because I wanted 07 and mistyped the
On Jan 9, 2008, at 6:32 PM, [EMAIL PROTECTED] wrote:
On Wed, 9 Jan 2008, John Watlington wrote:
Sounds like you are volunteering to write that code.
We need it by early next week.
Yes, mobile IPv6 is one of our long-term solution possibilities.
two things.
1. I didn't realize that
On Jan 9, 2008, at 6:50 PM, Mikus Grinbergs wrote:
Just switch off the Legacy IP, as we should have
done months ago, and get on with making things work properly.
Anything else is a distraction.
I sympathize with how overworked OLPC developers are. But a number
of G1G1 systems are getting
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1525/
-sugar.i386 0:0.75.6-1
+sugar.i386 0:0.75.7-1
--
This email was automatically generated
Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html
___
Devel mailing list
Tom,
I would RMA the unit, going through Adam Holt instead of the
normal process. We want to see this unit ourselves before sending
it back to the manufacturer, as we haven't seen this problem in the
past.
The WLAN is a separate module, surface mounted to the motherboard.
There have been
On Wed, 2008-01-09 at 22:50 -0500, John Watlington wrote:
Given the lead-free soldering process we are
using, solder cracks are also a possibility.
Or tin whiskers?
___
Devel mailing list
Devel@lists.laptop.org
Jake Beard wrote:
Hopefully, later this year we'll see a completely open Java, and then see
Java on the XO.
Flash is terrible. If it were possible, I'd prefer to see an all-Java
solution.
Sorry, but java sucks rocks, and although I dislike flash, I think
it's a better solution for just
[EMAIL PROTECTED] wrote:
We really need a open project to do patent analysis of this kind and
determine which of these key patents (not just codecs, but also other
important blocking patents) can be avoided, and which ones are too
tied to the format to avoid. Perhaps the OLPC project would
Sebastien Adgnot wrote:
However it seems quite difficult for us to encode our videos in
Theora+Vorbis right now. I'm gonna talk to different people in the
company to get their opinion and see what we can do.
Ffm peg does a fair job at codec conversion. We use our friends at
Lulu.tv to
On Jan 10, 2008, at 12:02 AM, Dan Krejsa wrote:
On Wed, 2008-01-09 at 22:50 -0500, John Watlington wrote:
Given the lead-free soldering process we are
using, solder cracks are also a possibility.
Or tin whiskers?
How'd you know what my nightmares look like ?
Yes, but I don't expect tin
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build679/
+iputils.i386 0:20070202-3.fc7
+libsysfs.i386 0:2.1.0-1.fc7
--
This email was automatically generated
Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html
___
Devel
Hi,
I just tried olpc update from joyride-1500 to
joyride-1525, on a G1G1 XO. I ran
sudo olpc-update joyride-1500
from the terminal activity, and sometime during (or after) the
irsync-dirty part of the update, X restarted. I thought the laptop
was rebooting, but examining /var/log/messages
On Wed, 9 Jan 2008, John Watlington wrote:
On Jan 9, 2008, at 6:50 PM, Mikus Grinbergs wrote:
Just switch off the Legacy IP, as we should have
done months ago, and get on with making things work properly.
Anything else is a distraction.
I sympathize with how overworked OLPC developers are.
63 matches
Mail list logo
