Ubuntu at work

After my many, not so positive, reviews you might be surprised to learn that I’m actually using it at work now. Last week, a recent Mac convert dumped his ‘old’ laptop on my desk which happened to be a Lenovo T60 with a nice core duo processor, ATI graphics and 2 GB of memory. One of the reasons for the mac was that the thing kept crashing. This can either be a hardware or a software problem. I suspect the latter but I’ll have to see.

It so happens that my own windows desktop is increasingly less compatible with the linux based python development going on in the team I’m in. So even before taking the laptop, I was playing around with a vmware image to run some server stuff. My idea was to do the development on my desktop (using eclipse + pydev) and deploy on a vmware server with ubuntu and the right dependencies. Slow, but it should work, mostly.

So instead, last friday I installed Ubuntu 7.10 (only CD lying around) on the T60 and then upgraded it to 8.04 over the network. The scanning the mirror error I discribed earlier struck again. This time because of a corporate http proxy (gee only the entire fortune 500 list probably uses one: either add proxy settings to the installer or don’t attempt to use the network during installation). Solution: unplug network cable and let it time out.

Display detection actually worked this time. Anyway, I was only installing 7.10 to upgrade it to 8.10. Due to the scanning the mirror error, the installer had conveniently commented out all apt repositories. Of course there’s no GUI to fix that (except gedit). After fixing that and configuring the proxy in various places, I installed some 150MB worth of upgrades and then tried to convince the update manager to show me the upgrade to 8.04 dialog that various websites assure users should show up. It refused to in my case. So back to the commandline. Having had nasty experiences upgrading debian from the commandline inside X, I opted to do this in a terminal (alt+f2). Not sure if this is still needed but it can’t hurt. Anyway, this took more than an hour. In retrospect, downloading and burning a 8.04 image would have been faster.

So far so good. The thing booted and everything seemed to work. Except the wireless lan was nowhere to be seen (known issue with the driver apparently, haven’t managed to fix this yet). Compiz actually works and looks pretty cool. I have sound. I have network (wired).

Almost works as advertised one might say.

Until I plugged the laptop in its docking station and connected that with a dvi cable to the 1600×1200 external screen. Basically, I’m still struggling with this one. Out of the box, it seems impossible to scale beyond the native laptop screensize. What should happen is that either the dockingstation acts as a second screen or that it replaces the laptop screen with a much better resolution. Neither of this happens.

I finally edited xorg.conf to partially fix the resolution issue by adding 1600×1200 as an option. Only problem: compiz (the 3d accelerated GUI layer) doesn’t like this. I can only use this resolution with compiz disabled. If I enable it, basically it adds a black bar to the right and below. I wasted quite a bit of time trying to find a solution, so far without luck although I did manage to dig up a few links to compiz/ubuntu bugs (e.g. here) and forum posts suggesting I’m not alone. This seems to be mostly a combination of compiz immaturity and x.org autodetection having some cases where it just doesn’t work. With my home setup it didn’t get this far.

My final gripe concerns the amount of pixels Ubuntu/Gnome wastes. I ran into this running eclipse and noticing that compared to windows it includes a lot of white space, ugly fonts that seem to use a lot of space. Screen real estate really matters with eclipse due to the enormous amount of information the GUI is trying to present. Check here for some tips on how to fix eclipse. This issue was emphasized even more when I tried to access my 1400×1050 windows laptop using Ubuntu’s remote desktop vnc client and the realvnc server running on windows. The retard that designed the UI for that decided in all his wisdom to show the vnc session in a vnc application window with a huge & useless toolbar with a tab bar below that (!) with in that a single tab for my windows session. Add the Ubuntu menubar + task bar and there is no way that it can show a 1400×1050 desktop in a 1600×1200 screen without scrollbars (i.e. altogether I lose around 250-300 pixels of screen real estate). Pretty damn sad piece of UI design if you ask me. Luckily it has a full screen mode.

In case you are wondering why I bother to document this, the links are a great time saver next time I need to do this. Overall, despite all the hardware issues, I think I can agree with Mark Shuttleworth now that under controlled hardware circumstances this is a pretty good OS. Window 95 wasn’t ideal either and I managed to live with that for several years.

Netbeans 5.0 first impressions

With much fanfare (at least on the various Java news sites), Sun has launched its latest edition of netbeans. Netbeans 5.0 is a significant improvement over 4.x. 4.x basically improved the UI to the point where it was reasonably fast and usable. 5.x consolidates the improvements by adding (a lot of) depth to the featurework in 4.x. A new component that is mentioned in every review is Mattisse, the GUI builder. I had a brief session with this thing with one of the betas a few weeks ago. It’s definately a very nice tool. Unlike most GUI builders (including most previous generations of netbeans and the eclipse GUI builder) this one doesn’t suck, most of the time. I’ve had too much exposure to Swing over the past decade to not code my GUIs manually but for someone not so familiar with Swing this is actually quite usable.
Last week I downloaded and installed the release at work. Since I now work for Nokia I, decided to give the mobility pack a spin. The rest of this review is about my impressions using this part of netbeans. The mobility pack basically includes sun’s toolkit (libraries, emulator) and integrates this into netbeans. Overall it is a pretty impressive thing. I have had exactly 0 experience with building J2ME stuff. Just to see where I would end up I started a hello world mobile project.

I was positively surprised at the level of usability the mobile pack offers. The project setup generates a build file for you that basically does all the difficult stuff (like creating a deployable jar that you can install on midp phone). Buildfiles in general are well integrated into netbeans (unlike eclipse). Basically building your project means calling the appropriate ant target. You can do this by selecting the option from the menu, right clicking on your project, etc.

After completing the new project wizard, netbeans had generated a nice Visual Midp class for me. The word visual means that you can edit the midp client in a visual environment. This environment is pretty powerful and will probably suit most basic needs. Essentially you drag and drop a various types of screens in a flow. Then you add actions to each of the screens and finally draw some arrows between the screens. At this point you can actually run the application in the emulator (or a real phone) and you will be able to navigate through the screens that were just defined. For the record, you don’t need to write any code to get to this point.

The flow view has a nice other use: it is a perfect companion to a functional specification. Just add a little information on the semantics of all the actions and you’re basically done (with the functional spec). It’s also great for prototyping. You can just click a bunch of screens together and have a live demo on a mobile phone in no time.

Then  we come to library dependencies. Basically any java project will end up using several external libraries. In eclipse they have to be in your project and then you can add them to the classpatth, alternatively you can define external libraries. In Netbeans there’s the library manager where you define libraries. A library may be a project (in which case netbeans automatically figures out that it should use the jar in the dist dir) or a jar file you downloaded. You can also associate source folders and javadoc with the library. Once you have libraries defined, you can edit the project properties and add library dependencies. That’s it. If you do a build of your (mobile) project, netbeans will automagically pull together all libraries and generate one big jar file with everything in it. It will even build projects if the source code is newer than the library. Nice. Eclipse sort of has the same functionality but the netbeans UI for this is simply much better and usable.
So far, I really like Netbeans 5.0. Now we come to the parts that are not so fun. Coding. The code editor in netbeans still sucks. Sure, it has been improved over netbeans 4.x. It is noticably faster with things like autocompletion. The problem is that it is pretty stupid compared to what I am used to: eclipse. Eclipse has whole bunch of editor features that are simply missing from netbeans. You can’t do the “extract local expression” refactoring (alt+shift+l) which means that you have to do that manually (which I never ever do in eclipse). This probably my number 1 missing feature. Several other refactorings are missing. Then there are no quick fixes. So if you write some code that throws an exception you cannot add a catchblock to the try catch you already have. Neither can you add a throws clause. These are just two of the many quickfixes that eclipse has. Templates are implemented but much less functional. I just love typing for and then ctrl + space to generate a foreach for some collection (or select alternative means to iterate over whatever is iteratable in your code). It’s just not there. It will generate a for loop but you still have to fill everything in yourself. There are lots of other features that anyone familiar with eclipse will miss.
In short if your primary task is writing code, stick to eclipse. If you need wizards (mobile and supposedly the J2EE stuff is excellent as well), netbeans may be a better option. You’ll be spending much more time on your code but may still be more productive due to all the convenient stuff that netbeans does for you.

Personally, I’m still in the eclipse camp. It’s just that I am working on this toy midp client at work so I prefer netbeans for this project. For netbeans to win me over permanently they will basically have to add tons of features to the code editor. This being said, the improvements in netbeans are worth some attention from any java developer. It’s nice to see some stuff working that is basically broken (or unsuable, which is the same thing practically) in eclipse. Both projects still have a lot to learn from each other.

Java theory and practice: Urban performance legends, revisited

I don’t comment very often on java performance myth busting articles anymore (I used to do this a lot at slashdot and the javalobby). However, this: Java theory and practice: Urban performance legends, revisited is an exceptionally good and informative article that focuses on memory management. The article explains how both memoray allocation and deallocation and stack usage vs heap usage are smarter in Java then with the default C/C++ mechanisms for memory allocation.

Of course the issue is that whereas there are a lot of performance myths, it is also undeniably true that many Java desktop applications are perceived as slow. On the server the debate is pretty much over. Not in the least because C/C++ is not very suitable for building secure network applications for reasons which have a lot to do with how memory is managed (or rather not managed) in C/C++. All the competing server languages are either interpreted or dynamically compiled.

There are a lot of myths about dynamic compilation too. A lot of people state that “because java is interpreted it will always be slower than a compiled language”. Such statements are usually based on a poor understanding of compiler technology.

In short, a compiler is a program that translates a program to running code. A dynamic compiler does this at the latest possible/convenient time (after starting the program, before executing the code). A static compiler on the other hand does this before the program is started.

So why is the above statement wrong: a dynamic compiler has the same bag of tricks to make code run fast that a static compiler has. Wait that’s not true either: it has a larger bag of tricks because it can observe the code while it is running and optimize for the runtime conditions. All this requires some overhead of course: a minor static effort to do simple compilation + whatever optimizations are worthwhile to do (this to can be determined dynamically).

On modern computer systems, there is plenty of time for this. Proportional to the total cpu time used, the overhead for compilation and optimization is neglegible. Only in constrained environments such as low end mobile phones this is not (yet) true. High end phones on the other hand are already much faster than the PCs I used to do swing development on in 1998!

So memory management and dynamic compilations are the source of many performance myths and yet are also arguably making Java a faster environment than plain old C/C++. So where does the slowness come from. It has a lot to do with program design and library design.

Java makes it easy to do things that used to be really difficult (IO, threading, databases). But you need to know what you are doing to make it perform well.

Especially when trying to make a GUI application, a lot of these things tend to come together. If the application freezes a lot (a common complaint), that is not because java is garbage collecting but because the developer did not understand threading. If the application uses a lot of memory, the reason is probably that it is allocating a lot of it (duh). If that’s a problem, good developers have a large bag of tricks at their disposal to detect and fix memory issues.