I’ve been getting a little frustrated of late with this. Mainly because of turnaround times in rebuilding the kernel etc. I was looking at the kernel sources and sticking in printks here and there to try and make things clearer for me. But the time it took to rebuild the kernel, reinstall it, reboot it and grep for my lines was/is killing me. Plus, if I break the kernel I gotta go back to my working one and do it right this time. It was really difficult to make any progress so I started looking for other ways.
KDE 4.4 was released on the 2nd of March 2010:
I am currently running Kubuntu 9.10 which by defualt has KDE 4.3.2 but the KDE 4.4 packages are available for the adventurous. So, why would you want to upgrade? Well, 4.4 is a bigger number than 4.3 right so it is therefore better 🙂 KDE 4.4 is based on QT 4.6 versus KDE 4.3 QT 4.5 so that comes with its own benefits. Also, if you do any KDE development you will need to have the latest and greatest KDE to develop off the trunk.
So if you can’t wait for the packages to reach the main repositories, here is how to do it, it is quite simple:
sudo add-apt-repository ppa:kubuntu-ppa/beta
sudo apt-get update
sudo apt-get dist-upgrade
Remember though, it’s beta, so if anything goes wrong you could be stuck. Roll back is not something that aptitude does very well at all.
I have recently left the tools team of quite a large firm, who shall remain nameless. There are things I shall miss, of course, but I could never quite buy into the tools delivery strategy. Someone,somewhere, has made the decision that a developer needs to come into work, switch on their PC, open their IDE and never leave it. Their IDE is an editor, a debugger, a compiler, a defect tracking system, a project management tool, a version control system (or at least an interface to one) and in the case of embedded development a bunch ofother remote target stuff. And the list goes on. Now I agree in some respects that this is a nice ideal target to have and there are certain use cases where it really does work (eg. using the Eclipse debug framework to display core files. The work is already done.)
Here I am going to go through bootstrapping a PC. I will walk through this using QEMU. Basically I just want to build and link a bootable disk image and get this up and running in QEMU.
When I am on a Windows machine, my tool of choice is normally cygwin. Mainly because it feels more unixy. It’s got that self contained feel, and the package management is pretty slick. So I try to avoid Mingw. But I couldn’t get gdb to build under cygwin. A quick google told me it was something in some script that was incompatible with windows. I don’t know anything about it so I didn’t try to fix it. So I turned to Mingw. And it just worked. To be honest I didn’t think it would work, but, it just did. Pretty simple:
Download the mingw gdb src and execute the following from the msys shell:
./configure –prefix=/mingw –disable-nls
I have arrived, here we go