torpor
hack hack hack, the little machines fight back
Is it just apathy? Is it just poor organization? Is it disinterest, or is there something else going on that makes it practically impossible to coordinate ones efforts? With USB-Host now well and truly fixed, I really want to get some work done on folding in new features to the GP2X sysimage .. such as MIDI(MidiShare), such as Powermate, such as adding USB-Keyboard/USB-Mouse/Powermate support to the SDL, etc.
But lately I'm beginning to think that all the hype about the Open2X project is really just a straw man to make people think there is something going on, when really .. there isn't anything.
To me, and I could be wrong, the purpose of the OPEN2X project is to get all the pieces together required to assemble an open, community-supported, hackable firmware consisting of:
-a factory-compatible Linux kernel
-factory-compatible libs
-the basic system tool image rootfs, containing: /bin /usr/bin /etc.
However, as I see it, the OPEN2X project is an abysmal failure so far, for the following reasons:
1. For weeks now I have tried to:
With nothing but this result:
No matter who I talk to, or send email to, or try to catch up with in #gp2xdev, this problem doesn't get fixed. It seems it is impossible to use SourceForge as a centrally organized, easily-used, means of coordinating development among interested parties .. effectively, this is not just a total failure of the OPEN2X 'project' to support the efforts of those wanting to actually get something real done for the Open2X community ideal, but its also a major hindrance to any attempt to coordinate things with fellow hackers.
Plus, notice that this isn't in the list of 'doable' OPEN2X svn commands:
Why is that? Both of these pieces of the puzzle should be 'doable' right now .. certainly there exist kernel hackers able to get their custom kernels on the GP2X for interesting purposes: how come this work isn't available to all to build on? Why are people coveting the 'obvious' work they're doing on GPL code instead of sharing it in a community development environment?
2. Very little active progress reports are made to the community-at-large to keep hackers up to date on whats going on. It seems that there are at least 4 different individuals with their own kernel tree's and set of patches for hacking on the GP2X, and either none of these hackers really want to share their work in a community spirit, or just aren't interested in making sure others can use what they've done to build on top of it and get things rolling all the way end to 'final, compatible, community-based firmware image'. Have you OPEN2X guys just gotten interested in other platforms, or what? The WIKI doesn't work: it either gets ignored, or not updated, or people just don't know about it .. and besides, its very difficult to ascertain what is the 'latest' detail about the OPEN2X world .. also, the OPEN2X mailing lists seem to not be working, or not be usable, or ..
3. GPH seem to be actively sabotaging any attempts by the community to organize itself. As soon as some hacker pitches their tarball into the mix for others to use, either the GPH firmware changes, or there are bits missing from their source release, or there is some korean/anti-korean confusion going on that wreaks havoc on anyone trying to get a clear picture of, exactly, what *does* work and what *doesn't*. Countless times I have heard "oh, after I released my kernel tree, I was contacted by GPH, who don't want people to be doing this sort of thing, so I'm holding it back until there is an 'official' release" ..
Can I please get some sort of response from folks who are interesed in the OPEN2X project, who may have some insight into how to resolve this situation? For me, it seems that by now we for sure should have:
1. a public tree for the kernel, which can be used to reliably reproduce a config similar (if not equal, nay superlative) to the factory-released kernel.
2. a public tree for the basic /bin /sbin /etc toolset that is compatible with the factory firmware release.
3. a way of folding in new libs into a working OPEN2X bootable system image with little fuss.
4. a Compatible OPEN2X sysimage in active use by hackers/testers/users to make their GP2X's really rock.
If the OPEN2X project were producing working bootable alternative firmware images, which are factory (GPH)-compatible, and if there were a fair and open mechanism for contributing to such things, I could put a fair bit of interesting work into the mix to make the GP2X more and more interesting to a wide audience.
Is it time for an OPEN2X shakeup? I think so ..
But lately I'm beginning to think that all the hype about the Open2X project is really just a straw man to make people think there is something going on, when really .. there isn't anything.
To me, and I could be wrong, the purpose of the OPEN2X project is to get all the pieces together required to assemble an open, community-supported, hackable firmware consisting of:
-a factory-compatible Linux kernel
-factory-compatible libs
-the basic system tool image rootfs, containing: /bin /usr/bin /etc.
However, as I see it, the OPEN2X project is an abysmal failure so far, for the following reasons:
1. For weeks now I have tried to:
Code:
svn checkout https://svn.sourceforge.net/svnroot/open2x/trunk/toolchain
svn checkout https://svn.sourceforge.net/svnroot/open2x/trunk/libs
With nothing but this result:
Code:
A toolchain/binutils-2.16.1/gas/testsuite/gas/d10v/warning-007.s
A toolchain/binutils-2.16.1/gas/testsuite/gas/d10v/instruction_packing-001.s
A toolchain/binutils-2.16.1/gas/testsuite/gas/d10v/address-010.l
svn: REPORT request failed on '/svnroot/open2x/!svn/vcc/default'
svn: REPORT of '/svnroot/open2x/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
No matter who I talk to, or send email to, or try to catch up with in #gp2xdev, this problem doesn't get fixed. It seems it is impossible to use SourceForge as a centrally organized, easily-used, means of coordinating development among interested parties .. effectively, this is not just a total failure of the OPEN2X 'project' to support the efforts of those wanting to actually get something real done for the Open2X community ideal, but its also a major hindrance to any attempt to coordinate things with fellow hackers.
Plus, notice that this isn't in the list of 'doable' OPEN2X svn commands:
Code:
svn checkout https://svn.sourceforge.net/svnroot/open2x/trunk/kernel
svn checkout https://svn.sourceforge.net/svnroot/open2x/trunk/sysimage
Why is that? Both of these pieces of the puzzle should be 'doable' right now .. certainly there exist kernel hackers able to get their custom kernels on the GP2X for interesting purposes: how come this work isn't available to all to build on? Why are people coveting the 'obvious' work they're doing on GPL code instead of sharing it in a community development environment?
2. Very little active progress reports are made to the community-at-large to keep hackers up to date on whats going on. It seems that there are at least 4 different individuals with their own kernel tree's and set of patches for hacking on the GP2X, and either none of these hackers really want to share their work in a community spirit, or just aren't interested in making sure others can use what they've done to build on top of it and get things rolling all the way end to 'final, compatible, community-based firmware image'. Have you OPEN2X guys just gotten interested in other platforms, or what? The WIKI doesn't work: it either gets ignored, or not updated, or people just don't know about it .. and besides, its very difficult to ascertain what is the 'latest' detail about the OPEN2X world .. also, the OPEN2X mailing lists seem to not be working, or not be usable, or ..
3. GPH seem to be actively sabotaging any attempts by the community to organize itself. As soon as some hacker pitches their tarball into the mix for others to use, either the GPH firmware changes, or there are bits missing from their source release, or there is some korean/anti-korean confusion going on that wreaks havoc on anyone trying to get a clear picture of, exactly, what *does* work and what *doesn't*. Countless times I have heard "oh, after I released my kernel tree, I was contacted by GPH, who don't want people to be doing this sort of thing, so I'm holding it back until there is an 'official' release" ..
Can I please get some sort of response from folks who are interesed in the OPEN2X project, who may have some insight into how to resolve this situation? For me, it seems that by now we for sure should have:
1. a public tree for the kernel, which can be used to reliably reproduce a config similar (if not equal, nay superlative) to the factory-released kernel.
2. a public tree for the basic /bin /sbin /etc toolset that is compatible with the factory firmware release.
3. a way of folding in new libs into a working OPEN2X bootable system image with little fuss.
4. a Compatible OPEN2X sysimage in active use by hackers/testers/users to make their GP2X's really rock.
If the OPEN2X project were producing working bootable alternative firmware images, which are factory (GPH)-compatible, and if there were a fair and open mechanism for contributing to such things, I could put a fair bit of interesting work into the mix to make the GP2X more and more interesting to a wide audience.
Is it time for an OPEN2X shakeup? I think so ..