It is located in the city of Siena, Tuscany.
Tuesday, July 15, 2008
One of The Oldest Banking Institution in The World
The photo below is taken in front of a Bank that started as early as 1492. Yes, exactly the same year as Christopher Columbus landed in America, what a coincidence!
It is located in the city of Siena, Tuscany.
It is located in the city of Siena, Tuscany.
Saturday, July 12, 2008
The Forward+Reverse Engineering Approach
In some certain cases it's not possible to finish an engineering task just by doing a forward engineering approach (doing a design, prototyping and so on until you get the product to market) or vice versa, i.e. the task cannot be finished just by doing a reverse engineering approach (a.k.a tear-down and document everything). In these very peculiar case a combined approach of forward and reverse engineering is required.
I've never been into such a complicated problems like this before but in these last few weeks, the combined approach is clearly the only way to solve the problem. I noticed from books that I read a few years ago that usually a reverse-engineering task involved a legacy software where you couldn't find the documentation anywhere anymore. I can say that this is the "hell's pit" for a software developer, but I finally got into the same case.
The story starts with an Software Development Kit (SDK) that suppose to work on our target hardware in the office. Nonetheless, after 2 months tinkering with it I finally figure out that none of the documentation is exactly inline with the code in the SDK. Therefore, I have to create patches and patches and patches every day to make everything works as intended. OK, I thought everything was finished by then, but reality hits me. The previous version of the SDK produced an almost entirely different format for the output binary and moreover the tools to create this binary is also coming only in executable form in the SDK. I'll say this is take one of the "hell's pit" for me. Because I have to reverse engineer the file format from an SDK that supposed to be backward compatible with the previous version. You might ask why don't I request the previous version of the SDK? Well, it's impossible because apparently it's not there in the hardware vendor's FTP server. I try to ask them politely but they don't know either. I suppose, the development of the SDK is outsourced to some third party guys somewhere in Taiwan and this guy cannot be contacted anymore a.k.a disappear after he shows a working demo of the SDK and he didn't even take into account backward compatibility into account. Yeah, this is still take one boys and girls.
Now, take two. So, we have this driver for the hardware coming only in binary form, yeah binary form! We bought 1K units and we still got the binary form of the driver? This is insane! But taking into account the population of China, 1K units is nothing for them. Lets say, this Taiwanese hardware vendor sold most of their units in China then they won't provide support or a complete source code for those who buys only 1K units. I heard form the one who purchase our units in the office that unless you're buying 10K units you won't even be in their radar, sic.
Now, take three. Finally I decided that these things must be regarded as legacy software and a forward+reverse engineering approach would be very important to finish my task as I described above. Welcome to the "hell's pit" ladies and gentlemen.
Overall, this is an entirely new ground for me. But, I'm quite happy and challenged to see how far I can get with it. I'll give them a lesson. A very hard lesson. But, I hope and I think this won't shake up the industry ;-).
I've never been into such a complicated problems like this before but in these last few weeks, the combined approach is clearly the only way to solve the problem. I noticed from books that I read a few years ago that usually a reverse-engineering task involved a legacy software where you couldn't find the documentation anywhere anymore. I can say that this is the "hell's pit" for a software developer, but I finally got into the same case.
The story starts with an Software Development Kit (SDK) that suppose to work on our target hardware in the office. Nonetheless, after 2 months tinkering with it I finally figure out that none of the documentation is exactly inline with the code in the SDK. Therefore, I have to create patches and patches and patches every day to make everything works as intended. OK, I thought everything was finished by then, but reality hits me. The previous version of the SDK produced an almost entirely different format for the output binary and moreover the tools to create this binary is also coming only in executable form in the SDK. I'll say this is take one of the "hell's pit" for me. Because I have to reverse engineer the file format from an SDK that supposed to be backward compatible with the previous version. You might ask why don't I request the previous version of the SDK? Well, it's impossible because apparently it's not there in the hardware vendor's FTP server. I try to ask them politely but they don't know either. I suppose, the development of the SDK is outsourced to some third party guys somewhere in Taiwan and this guy cannot be contacted anymore a.k.a disappear after he shows a working demo of the SDK and he didn't even take into account backward compatibility into account. Yeah, this is still take one boys and girls.
Now, take two. So, we have this driver for the hardware coming only in binary form, yeah binary form! We bought 1K units and we still got the binary form of the driver? This is insane! But taking into account the population of China, 1K units is nothing for them. Lets say, this Taiwanese hardware vendor sold most of their units in China then they won't provide support or a complete source code for those who buys only 1K units. I heard form the one who purchase our units in the office that unless you're buying 10K units you won't even be in their radar, sic.
Now, take three. Finally I decided that these things must be regarded as legacy software and a forward+reverse engineering approach would be very important to finish my task as I described above. Welcome to the "hell's pit" ladies and gentlemen.
Overall, this is an entirely new ground for me. But, I'm quite happy and challenged to see how far I can get with it. I'll give them a lesson. A very hard lesson. But, I hope and I think this won't shake up the industry ;-).
Wednesday, July 9, 2008
CD/DVD Burning and Gnome's Nautilus
It's been ages since the last time I burn a CD in Linux. Back then I would use X-CD-Roast. Today, I found that it's much easier to do that with the built in CD/DVD writer front-end in Nautilus. The only drawback is I have to log in as root when invoking the CD/DVD writer front-end. In order not to run at full root privilege, I spawn a new shell and invoke the Nautilus CD/DVD writer front-end with:
This way, I was greeted with the following window (or widget if you prefer the *NIX nomenclature)
The rest is just a drag and drop operation.
Anyway, if I've given the permission for reading and writing to the associated CD/DVD device to normal user previously, I shouldn't be bothered to log in as root in the first place.
nautilus --no-desktop --browser burn:///
This way, I was greeted with the following window (or widget if you prefer the *NIX nomenclature)
The rest is just a drag and drop operation.
Anyway, if I've given the permission for reading and writing to the associated CD/DVD device to normal user previously, I shouldn't be bothered to log in as root in the first place.
Tuesday, July 1, 2008
The Fifo and WLAN Ndiswrapper driver bug in kernel 2.6.24.3
Yesterday, I have to adapt my kernel module because of a new device that I have to connect to my linux laptop. This device is actually a serial-to-usb device. It is based on Future Technologies FTDI fifo chip. Because my optimized 2.6.24.3 kernel didn't include the support for this chip, I have to compile the module and create a new kernel image with proper linkage with the new driver. The kernel compilation went OK.
Unfortunately, problems begin to show up with my WLAN ndiswrapper-based driver. The WLAN driver which is somehow linked to the ssb kernel module cannot work when the FTDI serial-to-USB FIFO driver is also loaded. The Ndiswrapper that I'm using is Ndiswrapper version 1.52. After trying to add list of suspected drivers into the blacklist driver list (/etc/modprobe.d/blacklist) in order to prevent the offending driver from loading, I found out that ssb module would always be loaded because it's linked very closely with the FTDI fifo driver. Finally, I decided to try to upgrade my kernel in the hope that the new native linux driver for Broadcom BCM4318 will work, to overcome my inability to use my WLAN in Linux. Upgrading to the latest kernel, i.e. version 2.6.25.9 proves to be a well-working solution. So, now I have all my hardware working as expected. The only draw back with the current driver is I have to disable my Ethernet network adapter prior to activating the WLAN interface. Otherwise, the WLAN interface cannot be activated.
Moreover, when I decided to upgrade my ATI video card Linux driver to it's latest version, I found out that this kernel version (2.6.25.9) plays well with the new ATI driver (Catalyst v8.50.3, i.e. filename: ati-driver-installer-8-6-x86.x86_64.run). I finally able to set the video resolution in Linux into the LCD's wide screen maximum resolution, i.e. 1280x768, which previously would always stuck at 1024x768, even if I set the ModeLine parameter to 1280x768 in /etc/X11/xorg.conf.
Unfortunately, problems begin to show up with my WLAN ndiswrapper-based driver. The WLAN driver which is somehow linked to the ssb kernel module cannot work when the FTDI serial-to-USB FIFO driver is also loaded. The Ndiswrapper that I'm using is Ndiswrapper version 1.52. After trying to add list of suspected drivers into the blacklist driver list (/etc/modprobe.d/blacklist) in order to prevent the offending driver from loading, I found out that ssb module would always be loaded because it's linked very closely with the FTDI fifo driver. Finally, I decided to try to upgrade my kernel in the hope that the new native linux driver for Broadcom BCM4318 will work, to overcome my inability to use my WLAN in Linux. Upgrading to the latest kernel, i.e. version 2.6.25.9 proves to be a well-working solution. So, now I have all my hardware working as expected. The only draw back with the current driver is I have to disable my Ethernet network adapter prior to activating the WLAN interface. Otherwise, the WLAN interface cannot be activated.
Moreover, when I decided to upgrade my ATI video card Linux driver to it's latest version, I found out that this kernel version (2.6.25.9) plays well with the new ATI driver (Catalyst v8.50.3, i.e. filename: ati-driver-installer-8-6-x86.x86_64.run). I finally able to set the video resolution in Linux into the LCD's wide screen maximum resolution, i.e. 1280x768, which previously would always stuck at 1024x768, even if I set the ModeLine parameter to 1280x768 in /etc/X11/xorg.conf.
Subscribe to:
Posts (Atom)
