For those who like me enjoyed Dreaming In Code, it’s noteworthy to see that Mitch Kapor now ends his involvement in OSAF and the Chandler project. Here’s Mitchell Baker’s view on his helping the Mozilla project (she is or used to be a Mozilla hotshot), and perhaps also interesting the official post about this all in the Chandler camp.
Monthly Archives: January 2008
What Can I do for Rockbox when not Programming?
As in every open source project, people who don’t program but who use and like Rockbox a lot tend to think and sometimes utter the words “I can’t code so I can’t help” when talking about what they can do for the project. But there are of course still endless amount of things we need help with. For example
File good bug reports for bugs. Make an effort to really double-check the details, write up repeat recipes, try to repeat others’ reported bugs, fill in more details on the sparsely reported ones. Tell us when you can’t repeat already reported ones. We have so many bug reports and new ones come at a very high pace, that we need all the help we can get with sorting them out. Killing the bad ones as early as possible and getting the rest as detailed and accurate as possible.
Help out with the manual. The manual covers a lot of functionality for a wide range of targets, and we constantly find bugs and missing stuff in the manual that you can help us out to both find and correct. The manual is what we constantly point newbies to and it needs to remain accurate and well phrased.
Help out with the “support”. People pop in on the IRC channel all the time, we have >14,000 registered users in the forums, we have almost 1,000 subscribers on the mailing lists. You can help out by responding to questions, offer advice etc.
Donate money. As blunt as it sounds, we need money at times. The money we receive by donations are primarily used for buying new and more hardware to developers, but we’ve also used it for developer-related activities such as pizza at devcon!
Donate server resources and bandwidth. Our sophisticated build-on-commit system requires a fair amount of speedy and available (Linux) servers that can rebuild Rockbox on demand from the build master server. We can always use a few more of these, and we only need 2GHz+ machines with a few gigabyte of storage to spare and a reasonable bandwidth.
Help test patches. We get a lot of patches, and learning how to build your own build and apply your own set of patches is quite easily done and really takes just a little effort. In fact, very often people also post binaries and make pre-built patched Rockbox packages available so many patches can even be tested without having to build anything on your own!
So as you see there’s no reason to be shy any more. Step forward and help us improve!
Axis2/C going libcurl?
Apache’s Axis2/C project, said to be “the only complete SOAP engine” is considering to move over to use libcurl for HTTP transport by default. At least Axis2/C developer Dinesh Premalal thinks they should, and he lists multiple reasons in his blog and I can of course do nothing but agree.
One reason he failed to mention is that we all (Axis2/C users and libcurl users) benefit from them switching to libcurl since then we’ll have a larger combined potential developer base and we’ll get more eyes on the code, more testing done and thus in the end we will get a better transport library all over.
I’m slightly puzzled by Dinesh’s blog entry since this bug tracker entry submitted to Axis2/C mentions their failure to include curl’s copyright/license text in the distribution, which seems to imply that they already use (parts of) curl. Or?
curl 7.18.0 feature freeze
I just mailed the curl-library list about us entering feature freeze for the upcoming 7.18.0 release. The plan is to have two weeks of bug fixing and time to allow people to find bugs, before we release it to the public. Please get a daily snapshot and give it a spin!
Here’s the changes that’ll be coming:
- –data-urlencode
- CURLOPT_PROXY_TRANSFER_MODE
- –no-keepalive – now curl does connections with keep-alive enabled by default
- –socks4a added (proxy type CURLPROXY_SOCKS4A for libcurl)
- –socks5-hostname added (CURLPROXY_SOCKS5_HOSTNAME for libcurl)
- curl_easy_pause()
- CURLOPT_SEEKFUNCTION and CURLOPT_SEEKDATA
- –keepalive-time
- curl –help output was re-ordered
… and there are 26 bug fixes mentioned in the RELEASE-NOTES in progress so far!
I don’t like Java
I don’t like Java. I have a hard time to explain exactly why I feel this way, but when facing a Java program or just thinking about doing something in Java I feel nothing but panic and dislike. Why is this? I have to admit that due to my general dislike I’ve never done any major Java developments so my feelings are based on occasional hacks and works and not years of punishment.
Java in itself isn’t terrible as a language I think. It is basically C++ with some of the worst parts removed. It is in fact made so simple that nowadays when all people learn Java at school and not much else, we see people getting out lacking clues about much in how computers and low-level stuff actually works.
What I find annoying is that there’s hardly ever any Java-related problem or program that isn’t on top of 22 layers of existing packages – giving me the feeling I’m building a house of cards.
Running a program with the help of a humongous run-time environment isn’t exactly what I like either. It makes the startup-time terrible and it makes the system/memory requirements far bigger than I like. Also, whatever Java-people try to throw at us, everyone that runs Java-based apps on their PCs or in their phones or wherever knows that Java is slow when used in real-life. Period. (Cute quote from Steve Jobs: “Nobody uses Java anymore. It’s this big heavyweight ball and chain.” – not that I believe he’s right in the first part.)
I dislike how everything in Java seems to always be depending on this and that version and this and that doesn’t work in this and that version etc and it’ll all be fixed in the next release. I don’t like how Java programs can’t be built normally with make, I hate the XML-mess called ant, I’m not friends with using GC-only for memory handling and I don’t like how Java is the run-time, the class-library and the language itself all together.
The fact that Java wasn’t at all possible to do completely open source until very recently of course has always kept me reluctant as well, and even if this situation now has changed the marks still live in me.
Of course, I’m never really much of a friend of OO in general as it is commonly used either, as some of the primary premises of OO is quite the opposite of my own beliefs: I don’t believe in hiding what’s is actually done, and most of the OO works, interfaces and inheritance etc are designed and implemented exactly to hide what is actually being done underneath from the users. I want interfaces and APIs that are clear and that makes the user of them understand what the functions do, and I want the actual source code for the functions and libraries to be easy to read and the flow of the code to be easy to follow. OO actually makes following code flow harder.
This of course shows my “on the metal” state of mind and the fact that I never do very high level application development or similar, but the few times I’ve for example looked around in and worked with the Qt source code (C++) it has made me go completely bonkers. I’ll remain working near the hardware and the OS and mostly on resource-restrained systems. I remain with and I really prefer plain C. For scripting situations, I like perl. This way I won’t have to do any Java.
curl on scan.coverity.com
On scan.coverity.com, the nice guys at Coverity run scans on open source projects to check for flaws in their source code. Their list currently includes 265 projects, and curl is one of them. I have only good words to say about their scanning, as they found no less than 27 flaws in curl 7.16.1 and only one of them was a false positive. All the others were valid and true flaws that we could fix. I don’t think anyone was any serious security risk, but still. 26 bugs detected in one go.
On January 8th 2008, Coverity announced their “rung 2” for eleven projects that had zero flaws left in rung 1 and the rung 2 projects get an upgraded analysis. curl was also at zero flaws left, but it isn’t clear to me what else we could to do to reach rung 2 or even how we can get them to do a follow-up scan on a newer release since 7.16.1 is quite old by now and with all the changes in the code over time there’s always the risk new nasty bugs have crept in… So we’re at rung 1 still with no recent release scanned.
The Agony of Release
In the Rockbox project we haven’t had an official release in several years. We have >400K lines of code, some 60 committers. Some 300 patch contributors. At least 10,000 users, but probably up to 10-20 times that number.
We produce binary downloads after every single commit. We provide daily builds with a 30 day backlog. We provide a UI-based installer that can install the latest package for you.
So, we have a fair setup that provides releases in a fine way to everone interested. What we don’t have is a stable offer. Nobody can get a recent “stable” release (with a set of known bugs) or similar. We only have this endless series of “beta”-releases. We don’t have any particular push for doing a “real” release and among the developers there aren’t that many who think making releases is any fun, so we’re not really striving towards that.
The last time we tried to put together a release (to be called “3.0”) we decided to have a feature freeze period in which we’d only commit bug fixes and not do any new features. This lead to that most people simply stopped committing and developed their new stuff on the side, waiting for the freeze to go over. Only a few people did any actual bugfixing while we had some pretty serious flaws still in the code, so even with extended freezes we just couldn’t get the bug count down to a satisfiable level… we ended up just dumping the idea of a release 3.0 at that time, and it left some scars in the community that has so far prevented us from returning to this topic.
This said, today we’re more than 18 months further down the road, Rockbox runs on many more platforms, lots of code has changed and been improved since the previous 3.0 effort. Maybe it is time to once again make a release-attempt?
I think there are a few preconditions we need for this to succeed, including:
- We need a single release manager person who single-handedly can decide when the release is finished. This person would also have the final say on the outstanding-issues list etc. We can’t manage to get consensus among this large amount of people for this black-and-white style of questions.
- We need to accept that fact that some bugs just have to be in the release and we can live with them – after all most of these sorts of bugs have been with us for a very long time already and all of us have managed to live and use Rockbox fine for years in spite of their presence.
- We need to accept and realize that most of “us” – the devs, the closest team of followers, will not use the release anyway as the day after the release we will provide a new set of spanking fresh binaries to download and use… We don’t do the release for us. We do the release to the huge audience out there who look for “stable” and “known to work” stuff.
- Less people need to worry and have strong opinions about exactly what goes into the release or not. If we just get one release out, there will follow more further on that will get the stuff that is left out in this!
I am officially not volunteering to be a release manager! 😉
Sansa View Info
So we know a bit more about the Sansa View’s internals now!
It is based on a PP-derivate, possibly called PP61x0 something.
It has a “disk” (NAND flash) layout quite similar to the Sansa E200 in that it has a “hidden” second partition in which the bootloader, firmware image and more are stored – in just about the same format as the Sansa E200 has its images. See my separate Sansa View page for more details.
And announced on CES going on right now, and also now mentioned on their official site, it is also available in a 32GB version.
libcurl and libwww today
There’s talk in the Debian camp about dropping libwww as it is over 5 years since its last release and over a year since the last CVS commit in that project. It is also abandoned by the W3C these days. It seems there are just about two remaining packages depending on it, Amaya and wmweather+.
Amaya seems to at least discuss moving over to libcurl. I don’t know about wmweather+, but looking at their code, I actually think switching to libcurl will improve their code… not really related, but still about curl, one post on the Amaya list mentioned this weird list of user-agents you should block from your site, as it claims they are “spam bots” and it explicitly mentions curl in there…
Darcs is however currently adding support for libwww since it apparently does pipelining better, where as libcurl still has some flaws in its support for that.
curl site fixed
As I mentioned before, the curl site was a bit unstable for a while recently but now the hardware’s been replaced, the software updated and everything should now be back up and running fine.
If you see anything that still isn’t fine on the site, please let me know and I’ll make sure it gets fixed!
Now, I’ll really make an effort to get the TODO-RELEASE items done soon and get working on a new release!