Floppy disks are a thing of the past. Except if you’re in retrocomputing like I am. Recently I had to repair an old, vintage Commodore Floppy Disk drive due to leaking electrolytic capacitors. It was a dual drive and when re-assembling it I found that one of the drives had one head with a high error rate. But when I tried to read up on floppy drive theory and operation, I found it unbelievably hard to find anything useful on the web. So here are my notes of what I found.
In my home I am running a raspberry-pi based digital video recorder. To copy the recorded files to my server, I use a cron-triggered rsync script. While that worked in other situations just fine, here I always get an "error in rsync protocol data stream (code 12) at io.c(226)". Finally looking deeper into it I think I have an explanation and a solution.
When you come from using a classical source code repository like Concurrent Versions System (CVS) or Subversion (SVN), it can be difficult to understand the flexibility and the possibilities of Git. This article tries to explain the workings of Git and how it all fits together, so you don't have to try to remember the commands, but instead just know what to do because you understand it well.
Note: this article has originally been published on IBM's developerWorks website in 27 January 2015, and is here republished within IBM's publishing guidelines. Here is the developerWorks link.
Here is an interesting read about what Xerox PARC was really "worth". I often have the feeling that large corporations don't see the value in real invention anymore, but are only on the lookout for "innovative companies" to buy and squeeze out. Which may work for a short term to raise revenue and profit, and thus the share price - until this company has been assimilated, talent has drained to other companies, and a new one needs to be bought.at
For really a long time I have used a really nice feature of the X11 windowing system - remote login. That was rather easy to do. Just enable XDMCP and connecto to the X server remotely. It was not safe over the networks, but I used it only locally. My main use case was and is using the main PC in my home office from other places.
Now for a few releases the Linux distributions started to disable the protocol, or at least make it more complicated to use, as XDMCP isn't supported in the admin tools anymore.
Almost two years ago I demonstrated a 10MHz accelerator card for the Commodore PET on the Classic Computing exhibition. For this presentation I wrote a small demo program that draws a 3-D cube on the PET's screen - first with 1 MHz, then with 10 MHz. As I was concentrating on the 10MHz speedup, I didn't have enough time to look deeply into the demo program itself. So it was questioned why it was so slow in 1MHz compared to other demos. Finally I found the time to have a look at this, so I'll make this an example of a performance optimization job. Read on to learn about how the proper approach for a performance optimization even helps fixing performance problems in an old Commodore BASIC program.
Recently I have written about refactoring a 20 year old code base, namely of the file system server code for my old Commodore computers (see here: Refactoring-20-year-old-code... ). Here is a description of the internal structure of that code. I do this description in the form of an "architecture overview", a form that I think is missing for many a software project.
When I was working on my selfbuilt 6502 operating system, I had a file system server on the PC, connected to the 6502 via a serial line (RS232). It was using a generic, packet-based protocol on the serial "wire", so I decided to reuse the protocol and the server for an AVR-based implementation of a Commodore disk emulator. The Commodore would talk to the AVR via IEEE488 or the CBM serial IEC protocol, which would behave as a disk drive and use the wire protocol to talk to the PC to server files from there. In the beginning it looked like a good idea. But it took much more time than expected. Read on for the full story.
It is a well known fact that bugs are the harder and the more expensive to fix the later they are discovered in the project lifecycle. The cheapest one is the bug not made of course. The most expensive one is when your business critical application crashes and can not be recovered. And everything in between.
I have often been called into projects to investigate performance problems or to optimize a system for performance. What I find is that performance problems can have a lot of causes. Some are design problems, for example using the wrong algorithm for a problem, or processing items one by one instead of by collection. Others are database problems caused by bad access patterns. Network problems add their share. With the growing complexity of modern distributed systems (think cloud!) the situation is getting even worse. More and more systems and services are being combined to provide the business functionalities. Each one could be the cause of a performance problem.
My name is André Fachat, and like the "extra miles" you go in your job, those "extra pages" are what I try to write in my spare time.
Sometimes it's more documentation, sometimes more call to action, sometimes rant.
Most will be about my ongoing hobbies and passions - 8 bit computing for one, with my main page here: http://www.6502.org/users/andre/index.html , but the other is software engineering quality, and more specifically performance and other non-functional requirements.
I work as an IT Architect @ IBM Germany for a living, however, this is my private blog. The postings here are my own and don't necessarily represent IBM's positions, strategies or opinions.
If you want to contact me, you can reach me via email on firstname.lastname@example.org. It has a strong spam filter and I am pretty busy, so it may take a while for me to answer, though.
I hope you enjoy these pages!