Category Archives: Development

Development, Electronics, Rockbox, Technology

My phone does not replace my Rockbox

I have one of them mp3 capable mobile phones and I have a 4GB NAND flash inserted in it that is packed with music I like. Yet I never end up using it as a music player.

I see people everywhere use their phones for music and I repeatedly read and hear the soon coming death of the portable music player being predicted not far away by opinion-expressing know-it-allers.

My phone plays mp3 files just fine, but there are several reasons why I don’t use it for that. The primary one being that it gets a lousy battery run-time if I do that, and if I’d run down the battery all the way when listening to music then how would I be able to use the phone for regular voice? With a separate (Rockbox) device I can listen to music until the last drop of power goes out without hampering my communication abilities.

In my particular case, my phone’s lack of a proper standard USB port and it’s lack of anything but “full speed” (and yes full speed is less than high speed and is a lot slower than it sounds) when connecting it using the custom cable to my Linux box are two more reasons. Not to mention that it has this “database-only” approach to the music which I really don’t like – but yeah, I can learn to live with it.

Besides, it’ll be a while longer until I can hack my phone to run Rockbox and thus work the way I want it. Let’s hope Android or OpenMoko or similar efforts actually make it possible one day.

Development

Swedish Top Developers?

I find it hilarious that IDG.se out of all publications put together the “best developers in Sweden” and lists the top-75 ones (article in Swedish). It is funny because IDG is not exactly a place flooding over with technical (or any kind of in-depth) knowledge, so obviously they got this list by getting input from others and how on earth can they then compare person A against person B when they’ve been mentioned by different sources? Also, just lumping every kind of “developer” into the same pile and then trying to order them is also an interesting challenge. Clearly some of these devs are more project managers, theorists and similar, while others are hardcore kernel-hackers, C coders or Java dudes.

I don’t mean to bash the people present on this list, as I’m sure I would also liked being present if I had been that. I just think the list fits so well into IDG’s style of populistic journalism. The audience wants top-lists, let’s give them another one!

Or perhaps I’m just jealous that I’m not included! 😉

Development, Electronics, Rockbox

D2 vs M6 given a few days use

A lot of people have asked me about my opinions on and comparisons between these babies, the Cowon D2 and the Meizu M6, and here’s my take. Of course a lot of this involves the original firmwares’ functionalities as that’s what I’ve been using on them so far. The Rockbox port for the D2 is progressing at great speed but isn’t yet capable of producing sound, and the Meizu port still has a long way to go (since it’s still in its infancy with research and reverse engineering being the primary doings atm).

Cowon D2

Touch screen isn’t really the best idea for a portable media player I’d say, but I must confess that the UI with “pop-up” buttons is rather nifty. See this little video for a grasp on how it works:

I haven’t used it a lot but the UI is working nicely and is fairly easy to use. I haven’t yet got myself an SD card to insert and try out, but I should soon! It does have visible tiny little screws that shows it could be disassembled quite possibly without too much efforts. Some of my other Rockbox friends are interested in the D2 quite a lot because it comes in a DAB model too, but my version is limited to FM radio only and even

Meizu M6

Next to the D2 this baby feels extremely small. It also has no visible screws or anything that reveals how it could be disassembled! The bootup procedure is first a bit silly since you need to hold down the PLAY key for a while but it doesn’t actually start until you release it, and you don’t know exactly how long you need to hold it. But then I think it proceeds nicely with the screen not even showing that it started, apart from a little “Loading…” text.

The M6 doesn’t use a touch screen but instead they have a “weirdo” slider pad with four button areas. Most of everything in the UI that goes up and down, like moving in menus, changing values, changing volume etc is done by letting a finger slide on the pad. This could’ve been a nice way of input if it wasn’t far too sensitive and thus I always seem to miss my goal menu item and have to go up and down several times before I manage to “hit” my target. Quite annoying!

Of course one downside with this player that isn’t a surprise at all but can be stressed, is the lack of any expansion slot so the original 8GB I got is all this unit is ever gonna see.

Conclusion

I think I end up liking the D2 somewhat more, mostly because of the slider on the M6 being annoying and that the D2 is expandable. The D2 also has a nicer OF (original firmware), but that’s not really what I care about since I plan to run Rockbox on both. Unfortunately I’ve not had a lot of spare time for actually getting into the hacking recently so right now I can’t comment on that much. I’ve seen interesting progress done by others in the mean time though!

I cannot say that the D2 is twice as good as the M6 so I’d actually say that M6 is a better value purchase.

Ok, that’s it for now. These are my first impressions, I’ll try to come up with some further ones later on after some more usage and hopefully some real rockboxing on them

Development, Electronics, Rockbox, Windows

How to hack firmwares and get away with it

It is with interest we in the Rockbox camp checked out the recent battle in Creative land where they shot down a firmware (driver really) hack by the hacker Daniel_K as seen in this forum thread.

We’re of course interested since we do a lot of custom firmwares for all sorts of targets by all sorts of companies, and recently there are efforts in progress on the Creative series of players so could this take-down move possibly be a threat to us?

But no.

In the Rockbox community we have already since day one struggled to never ever release anything, not code nor images or anything else, that originates from a company or other property owner. We don’t distribute other’s firmwares, not even parts of them.

For several music players the install process involves patching the original firmware file and flashing that onto the target. But then we made tools that get the file from the source, or let the user himself get the file from the right place, and then our tool does the necessary magic.

I’m not the only one that think Daniel Kawakami should’ve done something similar. If he would just have released tools and documentation written entirely by himself, that would do the necessary patching and poking on the drivers that the users could’ve downloaded from Creative themselves, then big bad Creative wouldn’t have much of legal arguments to throw at Daniel. It would’ve saved Daniel from this attack and it would’ve taken away the ammunition from Creative.Lots of Rockbox Targets

I’m not really defending Creative’s actions, although I must admit it wasn’t really a surprising action seeing that Daniel did ask for money (donations) for patching and distributing derivates of Creative’s software.

So far in our 6+ years of history, the Rockbox project has been target of legal C&D letter threats multiple times, but never from one of the companies for which targets we develop firmwares for. It has been other software vendors: two game companies (Tetris Company and PopCap games) fighting to prevent us from using their trademarked names (and we could even possibly agree that our name selections were a bit too similar to the original ones) and AT&T banning us from distributing sound files generated with their speech engine software. Both PopCap and Tetris of course also waved with laywers saying that we infringed on their copyrights on “game play” and “look” and what not, but they really have nothing on us there so we just blanked-faced them on those silly demands.

The AT&T case is more of a proof of greedy software companies having very strict user licenses and we really thought we had a legitimate license that we could use to produce output and distribute for users – sound files that are to a large extent used by blind or visually impaired users to get the UI spelled out. We pleaded that we’re an open source, no-profit, no-money really organization and asked for permission, but were given offers to get good deals on “proper” licenses for multiple thousands of dollars per year.

Ok, so the originating people of the Rockbox project is based in Sweden which may also be a factor as we’re not as vulnerable to scary US company tactics where it seems they can sue companies/people who then will have to spend a fortune of their own money just to defend themselves and then you have to counter-sue to get any money back even if you were found not guilty in the first case. Neither is Rockbox an attempt to circumvent any copy protections, as if it were it would have violated laws in multiple countries and regions. Also, reverse engineering is perfectly legal in many regions of the world contrary to what many people seem to believe.

If this isn’t sticking your chin out, then what is? 😉

Update 4-apr-2008: Creative backpedals when their flame thrower backfired.

Development

Conference in my living room

a kids drawing easel thing by IKEAToday (uh make that yesterday since we’re now past midnight here…) around lunch I drove my two kids over to my parents in law and got back to my house to host four friends (associated with a company that shall remain nameless in this blog – at least for now) coming over to discuss some work stuff.

It was great fun sitting in my living room chatting for a few hours, having a cup of coffee and instead of using a fancy company white board I brought my kids’ drawing easel (oh we love IKEA). The picture is the actual model we used, called “MÃ…LA”.

And we did indeed manage to get some good decisions done and some proper architectural stuff set. Admittedly, my kids’ drawing pens were a bit thin and not as thick and “powerful” as the ordinary office white board pends tend to be.

Development, Open Source

I don’t like Java

8 Comments

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.No java thanks

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.

Books, Development

The Mythical Man-Month

The Mythical Man-MonthFrederick Brooks wrote this classical book already back in 1975 and added a few extra chapters for the twenty years anniversary 1995…

Large portions of it feels of the age and there’s a lot of talk about Fortran, System/360 and PL-1 as if we should know about them (which made me fast forward over some chapters). But there are gems as well, and the most significant things people seem to remember Brooks’ book for are still pretty valid and fine.

Adding more people to a project leads to the need for more communication and thus it may slow down development rather than speed it up. Also known as Brooks’s law.

Given the complexity of software and software development, there’s no single method or concept that will lead to an improvement by an order of magnitude – within a decade. There’s No Silver Bullet. (This section was not in the original edition of the book.)

The risks involved when rewriting something and wants to fix everything that was wrong in the previous version so you over-work and over-design the successor. The so called Second system effect.

A lot of the book is spent on thoughts and theories around how to manage really really large software projects, like when you involve thousands of persons. Is it even possible to make such huge projects successful and if so, what does it take? The extra chapters do indeed add value since they offered Brooks a chance to re-evaluate his earlier claims and ideas and to check what seemed to be truths and what mistakes he did in the original edition.

A very interesting read that I’m glad I finally got time to get through!

Development

Food Calendar

2 Comments

MatkalendernFacing the every day problem with what to eat, planning and shopping food for the family I took the familiar route: I wrote a web site (the site is in Swedish!) and service for it to ease this boring work!

Using this site, you enter the recipes of the dishes you tend to eat, you assign meals to days and then you can get the site to produce a nice and handy shopping list of all the ingredients that the planned meals require.

With multiple users, you can bookmark other users’ recipes to avoid having to enter them yourself. With top-lists and statistics you can see what meals you plan to eat the most and the least and so on. It actually works pretty neat. We have a set of user logins handed out as well, but I don’t think very many people other than me and my wife actually use it…

It still has lots of room for improvements to make it even easier to plan and to make the grocery store shopping list easier and quicker to deal with, but it scratches my itch already and I’m improving it slowly over time. I started the development of this in early 2006 and we’ve been using it in my family for well over a year now.

cURL and libcurl, Development, Open Source

ABI Breakage

1 Comment

Domenico Andreoli, the Debian curl and libcurl maintainer posted to the curl-library list about the recent libcurl soname bump and the related issue of ABI breakage.

I responded, explaining my view on why the soname bump from 3 to 4 was valid, but I’ve also gone back in my mail archives and checked out a private discussion I had with Bjorn Reese over this subject a long time ago and I feel it is about time it hits the air.

An ABI breakage occurs when one or more of the following changes are made

Functions:

  • Change function names
  • Remove existing functions
  • Change parameters
  • Change behavior
  • Change undefined behavior
  • Add dependence on other functions (e.g. A() must be called before B())

Data structures:

  • Change the order of elements
  • Add elements
  • Remove elements
  • Change the data type or size
  • Change alignment
  • Change element values (e.g. change bits in flag variables)

Global variables:

  • Change variable names or types
  • Remove variables

Update: Dan Fandrich posted on the curl-library list and mentioned Mike Hearn’s great related page: Writing shared libraries.