Slashdot Mirror

Linux has this same bug. It's in "ohci1394.c". I reported this to the Linux kernel mailing list years ago, and the reaction of the kernel developers was to make it a "feature" for "remote debugging" that's enabled by default.

Technically, here's how it works. First, see the OHCI specification, section 5.15, "Physical Upper Bound register". This determines the highest memory address into which an external device can store directly by sending a packet. If set to zero, this feature is disabled. That feature is intended for slave devices, like peripherals. On computers with an operating system, it should be zero. It's not.

In the Linux kernel, that security hole was installed in "ohci1394.c" with the comment:
/* Turn on phys dma reception.
*
* TODO: Enable some sort of filtering management.
*/

In early kernels, it was unconditionally enabled. In 2.6, it's enabled by default, but can be turned off.

Also, This patch indicates that this security hole may have been designed into some FireWire controllers, so that the "upper bound register" didn't really do anything, but read back zero.

The latest hardware is the slot-1 type, which is a DS-sized card and requires no additional hardware or modifications to the DS. These are much simpler to use than slot-2 devices, but as the majority of homebrew was designed for the slot-2 hardware and it's ability to boot GBA software, there are some compatibility issues. They are thankfully being ironed out, and as slot-1 devices become the standard we fully expect that all new homebrew will be designed with them in mind.'

For DSLinux, the issues cannot be ironed out! So this new trend gives us headaches :(

The DS has only 4MB of RAM. DSLinux has been using extra RAM present in add-on devices for some time now (usually an extra 32MB). But because only slot-2 is mapped into RAM, only slot-2 devices can provide additional RAM. Slot-1 devices can only be accessed via serial.

So if you want to run DSLinux, don't get a slot-1 device, get a slot-2 device that provides additional RAM.

See also:
http://mailman.dslinux.in-berlin.de/pipermail/dsli nux-devel/2006-December/000379.html
http://www.dslinux.org/wiki/Running_Homebrew#Recom mended_storage_devices

We are developing the port of Linux to the Nintendo DS. The project is based on uClinux. We have inherited uClinux' build system and CVS organisation.

Just like in uClinux, our CVS repository contains everything (Linux kernel, uClibc C library, uClinux userland). It is very, very large (almost 1GB). It has multiple branches to keep imports of third party sources organised. I've written a page on our wiki that explains how we set things up in the repository.

Not everyone is really happy with this. While I am comfortable using CVS (since by now I know how not to shoot myself in the foot), there are a couple of things that CVS cannot do for us. When it comes to moving things around on a great scale CVS is just a pain in the ass.

Regarding the build system: Our current setup makes package management quite impractical, but people keep requesting this feature It is very hard to incorporate, because of our strong ties to the way things are done in uClinux (zero package management).

Also, there is currently only one anonymous CVS mirror. At peak times the load is very high, and people keep complaining about poor performance of the server. Making CVS use a ram disk for temporary files helped a little, but the bottleneck is really CVS's poor ability to scale to large trees.

So we are considering moving to git. I am currently investigating it and I must say that I like it much more than CVS and subversion. The way we handle branching should feel much more natural with git. Conversion from CVS seems to be very smooth, at least according to the git documentation.

Conclusion:
Changing the version control system is not a huge problem really. You can always do that. What is very hard is changing the build system. You should really consider and evaluate all alternatives you've got before going productive. The question is of course what you really want to do, and what you are starting out with.

In your case, you should probably take a look at various other Debian-based projects. You may find a suitable solution, already tried and tested.

In our case, uClinux was an obvious choice, since it included an (incomplete) port of Linux to the Gameboy Advance, which DSLinux is based on. Alas, it looks like we now have to live with the deficiencies of the build system.

We are developing the port of Linux to the Nintendo DS. The project is based on uClinux. We have inherited uClinux' build system and CVS organisation.

Just like in uClinux, our CVS repository contains everything (Linux kernel, uClibc C library, uClinux userland). It is very, very large (almost 1GB). It has multiple branches to keep imports of third party sources organised. I've written a page on our wiki that explains how we set things up in the repository.

Not everyone is really happy with this. While I am comfortable using CVS (since by now I know how not to shoot myself in the foot), there are a couple of things that CVS cannot do for us. When it comes to moving things around on a great scale CVS is just a pain in the ass.

Regarding the build system: Our current setup makes package management quite impractical, but people keep requesting this feature It is very hard to incorporate, because of our strong ties to the way things are done in uClinux (zero package management).

Also, there is currently only one anonymous CVS mirror. At peak times the load is very high, and people keep complaining about poor performance of the server. Making CVS use a ram disk for temporary files helped a little, but the bottleneck is really CVS's poor ability to scale to large trees.

So we are considering moving to git. I am currently investigating it and I must say that I like it much more than CVS and subversion. The way we handle branching should feel much more natural with git. Conversion from CVS seems to be very smooth, at least according to the git documentation.

Conclusion:
Changing the version control system is not a huge problem really. You can always do that. What is very hard is changing the build system. You should really consider and evaluate all alternatives you've got before going productive. The question is of course what you really want to do, and what you are starting out with.

In your case, you should probably take a look at various other Debian-based projects. You may find a suitable solution, already tried and tested.

In our case, uClinux was an obvious choice, since it included an (incomplete) port of Linux to the Gameboy Advance, which DSLinux is based on. Alas, it looks like we now have to live with the deficiencies of the build system.

Communication Personelle/Professionelle Ouverts et Digital (Communication Personelle/Professionelle Open and Digital)

Wrong about MySql failing to gracefully scale to RAM storage, btw:

MySql polymorphically implements several different types of table, all conforming to the same interface. One of those implementations (HEAP tables) is designed to store data entirely in memory:

(You need the new I2C stack from the lm_sensors package for this, though)
----

No. Qt can (and will) however now be included in Debian proper ("main"), rather than being available in "non-free".

Or are the licensing concerns still as valid as they ever were?

The licensing concerns are that Qt's license is incompatible with KDE's (GPL). This has regrettably not changed with the QPL. Knghtbrd, one of Debian's developers, provided a lot of input to Troll Tech regarding the QPL, but they couldn't be convinced to make the QPL GPL-compatible.

If the licensing issue had been about Qt1's non-freeness by itself, KDE could simply be in the "contrib" section. But the licensing issue is an interaction between licenses that prevents us from redistributing KDE binaries.

Luckily, there are strong indications that the KDE developers will be changing KDE's license to one that does not interact badly with the QPL (e.g. an Artistic-like license); once that happens, KDE can go in Debian proper.

What Qt 2 being free means to Debian is that Qt itself will now become a part of Debian proper, and that Qt-using software that doesn't suffer from the licensing issue (e.g. like pi-address, which is GPL + exception clause) can go in Debian.

Qt 2.0 will be released under the QPL 1.0 which is a DFSG-free / Open Source license. ( development snapshots are already available licensed under the QPL)

The QPL 1.0 is however incompatible with the GPL (Debian's analysis still holds for QPL 1.0). Thus, to redistribute binaries, an exception clause is needed like pi-address has:

Additionally, you are granted permission to assume, for the purposes of distributing this program in object code or executable form under Section 3 of the GNU Public License, that the QT library is normally distributed with the major components of the operating system on which the executable or object code runs.

The KDE developers are reportedly preparing a different license change that will resolve this conflict.

I have a card with the bt848 chip on it and it does good for grabbing a frame or video up to 30fps. The bttv video4linux driver that are included with the kernels worked great when compiled and loaded as modules.

The three applications that I use most often that came with xawtv and work great. I run streamer from a cron job to capture an image every minute for the webcam on my homepage. xawtv runs under X, fbtv runs under SVGA through the kernel frame buffer, and both can run overlay, grab while displaying, or snapping images while you watch. The documentation with the source tarball is excellent.

Full motion high quality video at 30fps for 14 seconds yeilded me a whopping 46MB avi! streamer will also let you grab at a framerate of your choice if you wish to make interesting time elapsed movies, such as watching grass grow...

I did have some strange problems with my bt848 card at first, but they were traced to the card not being seated in the socket correctly. I would soon find out my bt848 works like a champ. :)

If anyone needs help I would be glad to help as I greatly enjoy this card. I got mine as a refurbished Panasonic color egg cam package for $75 (US). It has the usual video-in RCA type connector. For good reading about video in Linux, there is the video4linux mailing list.