Monday, December 01, 2003

So you would like to make a Linux PDA/Phone?

Here is a list of things to do to make a truly sucessful Linux PDA. This is a list that I have been putting together in my free time the last few years as I have been interacting with this growing field. Some ideas you may like, some you may disagree with. A few ideas you might not have known about, and many that you probably could list yourself. Without further delay here it is:

    System Overview

  1. To provide a stable and user friendly commercial open source Linux based PDA that can be used by a teenager, but scale for the enterprise. - If a teenager can't use it then the Enterprise wont want to put it in the hands of the fourteen year old in the stock room.

  2. Have the ability to fit in only 8MB Flash and run in 16MB RAM. - It is easy to expand something, but hard to shrink.

  3. The primary goal of the project is to be fast, small/stable, and bugfree. (Rather then to be built cheaply/fast) The reason for this is that the applications will run on devices that should not need to be updated.

  4. Applications should either be a single file/module or file/directory based (palm and OSX respectively), any other choice will cause you pain and dollars in tech support. This allows for easy moving to memory cards, transfer to friends, transfer to another device (irda), transfer to desktop all without installing or having the application have to know about the file system. Also they can be removed without worring about left over files.

  5. Enterprise Services
  6. Custom ROMS - With maybe nothing more then a different "Walmart" logo, but there is money to be made here.

  7. Building Custom Applications - With custom roms come custom applications.

  8. VPN Intigrated/module - Security always wins points.

  9. Java Solution - Must be buzzword compliant and let manager take advantage of those cheap undergrads and proclaim JAVA is the one true...oh never mind.

  10. Jabber - Instant communication using an open protocol that can be secured and wont change or go away three months into your product lunch.

  11. Developer Services
  12. Application Certification Program - Not meant to be a money maker, but just help recover some of the cost and at the same time improving the quality of the applications running on your device/platform. Some ideas include:

    1. Check over an applications install/uninstall

    2. Check name description, for inconsistencies etc and possible better

    3. Run Valengrind for memory leaks

    4. If source if provided check over for possible improvements.

  13. Unique device ID or some other common method for commercial applications to prevent piracy as much as possible. - Shows that you are there to help the developer.

  14. Host commercial applications. - Provide the hosting for their application so every developer doesn't have to re-invent the wheels while providing a common portale for your users.

  15. Developers can buy views for their certified application as the homepage's "Featured application".

  16. User Services
  17. Buy/Download applications online and automaticly sync. The package manager can and must be able to buy apps online. The ability for users to just click, ten seconds later the application is installed and their credit card is billed $5 with no hassle. This is a marketing wet dream that is not difficult to impliment.

  18. Web based agenda sync (for example:

  19. Backup PIM data and or all data remotely via Jabber.

  20. Provide a pda web portal like:

  21. Provide service similar to ziproxy. ziproxy is a forwarding (non-caching) proxy that gzips text and HTML files, and reduces the size of images by converting them to low quality JPEGs.

  22. PDA applications could be nativly compiled for the desktop side so users could try them for free and then buy them for their pda.

  23. Sync
  24. Open API. There is no reason for the sync software to be proprietary. You sell hardware and services on that hardware NOT sync software! An open api will allow for plugins to sync to palm/outlook/kmail/etc.

  25. Outlook of course

  26. Copy the data via any means (ftp, scp, Samba, nfs, jabber etc )

  27. Kernel
  28. 2.4.2X And 2.6.X

  29. On boot using lpp (or similar) to have a "pretty" active user experience that doesn't seem to hang

  30. Well written GPL'd drivers in the official kernel (Audio, usb, IR, touch screen etc)

  31. Ability to scale the CPU speed as needed

  32. USBIO, USBNET, WIFI, IRDA, and serial for connectivity.

  33. Driver for a VGA CF out is one of those nice things that no one uses, but everyone shows off.

  34. System
  35. Ability to boot VERY quickly so it can be shutdown to save power when not used for X amount of time. (Possible even suspend/resume to disk if fast enough)

  36. Easy to install a new ROM by the user. (One and only one click!)

  37. With so many very small fast webservers out there there are too many uses begging to be be taken advantage of. Perhaps Displaying the users vCard and any public Docs, allow login to see addressbook/calendar for printing from the desktop webbrowser. Spending ten minutes a hundred ideas could easily be created.

  38. Finger server - Present what is on the/a specific todo list.

  39. VNC

  40. Multi user - Applications should never crash the system.

  41. Some sort of factory reset available to users (Union FS with cram fs and jff)

  42. Windowing system: X11/kfb (both?) I can't decide because I have never seen hard numbers on this. How much memory they use and how long it takes to start are two principle numbers that need to be discovered before a decision can be made. Unless you have real comprehensive numbers on this any e-mails concerning this will be promptly deleted.

  43. If X11 is used then fun things like:

    1. Easy Remote Login & Audio

    2. Easy Remote Application Launch/Running

    3. Easy way to show applications on desktop side.

  44. Clean good small fonts are a must.

  45. GCC 3.X with prelink to help reduce those startup times. Maybe even use uclibc.

  46. Uses Debian for easy portability and reuse of precompiled and packaged applications along with large number of applications that work together and will have future updates - Customers care where you will be in five years, but Debian will never go away.

  47. Application launcher should be modular to allow for other designs from the community.

  48. Launcher has a built in Today screen that is updated (from the db? xml files? other?).

  49. If using Qt or QtE a mini-kde library should be created allowing for much quicker KDE cross porting. They have plenty of really good classes and there is no reason to not take advantage of them. Along the same lines an open communication should be forged with KDE (or whomever) to help share ideas.

  50. A clean simple widget theme similar to PocketPC which uses the screen space very well.

  51. Palm got it right, the "Hardware Pulldown" button that slides menu up/down from off screen should be present. It saves screen space and is just all around good.

  52. PIM
  53. They should talk to each other via a database. For such things as a recuring todo list item that is spawned from the calander saying it is someone's birthday and to buy a present.

  54. An OPEN API - Is your business only about selling some pim software? If not then open the api and reap the rewards.

  55. The source for these applications should be open so that other can help improve them. (Note I didn't say GPL)

  56. Application must be able to link to each other.

  57. Floating appointments.

  58. This pim list could go on forever. Just copy DateBK4, they got it right.


In the event that you aren't sure what applications you need for your device here is a small list:


  • Today type application - Integrated into the launcher for zero second load time.

  • Notes

  • Todo

  • Address Book

  • Calender

  • e-mail

  • Jabber client (Sms, PGP Encrypted IM's, sync, whiteboard, backup)

  • Calculator

  • Phone (VOIP)

  • PIM Extras
  • Advanced Calc with graphing features

  • Data tracker and grapher (mini excel)

  • Expense tracker

  • Car tracker

  • Shopping list

  • Applications
  • Blood alcohale calculator

  • Tip calculator

  • Currency converter

  • Scale converter (C->F degrees, Feet->meters etc)

  • Word Reader

  • Excel Reader

  • Audio Recorder

  • Remote controller (ir)

  • Movie times

  • Recipe manager

  • Diet manager

  • Bible (and Virtual Girl)

  • Area code lookup

  • Zip code lookup

  • Stop Watch/Big Clock/Alarm Clock

  • Language dictionary

  • Stock manager

  • String search (Grep frontend).

  • P2P

  • Password saver/manager.

  • Web browser

  • ebook reader with voice integration

  • Video/Audio Media Player

  • Image viewer

  • Image editor

  • Text editor

  • Test application

  • Developer Applications
  • Console both serial and local

  • File manager

  • Wireless sniffer

  • Wireless scanner

  • Process manager

  • VNC

  • Network monitor tool

  • Network utility (ping, whois etc)

  • Games
  • Chess

  • Puzz-le

  • Tetris

  • Checkers

  • Scrabble

  • Multiplayer doom with screen touches for movement.

  • Buzzword Bingo

  • Simple line based game

  • BlackJack

  • System
  • Media Manager (Disk Formater)

  • Clock & timezone with Internet time getter

  • Security/username (Security application wouldn't be number based, but image based.)

  • Screen Calibration

  • Light & Power

  • IR control

  • System Info

  • Package Manager

  • Network (lan, wifi, ppp, bluetooth, vpn)

  • Appearance

  • Audio (or would this be an applet?)

  • Applet manager?

  • Backup & Restore. (Maybe be part of Jabber)

  • Internationalization - Planning from the start it easier then converting later on.

  • Accessability

  • Reboot Utility (Restart the launcher, reboot)

  • Applets
  • Audio (or would this go in system?)

  • Battery

  • Turn off screen, but leave system on.

  • Keyboard/input (graffiti, keyboard, pickboard, etc)

  • Clock

  • Quick application menu (Similar to Pocket PC. NOT a start menu listing all applications)

  • Screenshot
  • Wednesday, October 29, 2003

    Communal Source

    Everyone knows how currently (2003) Microsoft has billions in the bank. The question most often following that statement is: "If they have all that money why does their software still crash?"

    In the corporate world a developer is assigned to create a specific portion of a project. It might be a whole application or just a small module. That portion of code is in owned by one person and rarely modified by anyone else. The original developer may even discourage others from just looking at the code. This attitude is the exact opposite of one of the best feature of pair programming. In pair programming two developers own a piece of code. Code written using pair programming is much more likely to be reviewed and improved by developers other then the original authors. Pair programming creates an enviorment similar to a small scale version of what happens in the open source world. Many eyes look at and improve one piece of code. In the end the code is better, more bug free, and easier to maintain.

    Pair programming has been highlighted as a way to produce superior code in numerous studies. In pair programming, two programmers sit side by side on one computer and work on a design and or programming task. While one person is typing the other person can catch mistakes and offer suggestions on how to improve the code. Many times it is as simple as choosing better variable names or adding higher quality comments, but other times it is larger, such as suggesting a design that is twice a fast and half the size. Pair programming is a social activity and also instills the idea that more then one person can improve the code. Having already worked on the code with someone else they are more likely to allow new developers to look at their code and improve it and are less likely to be hostile to those who want to improve it.

    At a typical corporation every bit of code is owned by an assigned developer. They wrote it, they release it and they maintain it. A lot of pride goes into their code. They have put in their own standards and might not appriciate others who want to work on their code. Some even take the request to look at the code as an insult. Others don't comment their code as a way of job safety thinking that they will be the only ones that can maintain the code in years to come. Because they don't have or expect anyone else to be looking at their code, commiting code into a revision control system might only occur when their code reaches 1.0 rather then iteratively, which is the purpose of a revision control system. Closed source is rarely viewed by more then one person, missing out on all of the benifits of peer review.

    In the open source world it is a common occurance to recieve code fixes and improvments. In turn one doesn't think twice about fixing or improving someone else's code. I have several piece of code that I am responsible for in KDE. The code is kept in KDE's CVS repository and when changes are made to that code I am notified so I can review the changes.

    On average the changes to my code are little more then small improvments such as making the code conform to KDE's standards. Other time the changes to the code are new features or bug fixes. More often the changes are in areas where I do not specialize.

    No matter what the change is, having your code looked at and worked on by other people is part of what KDE is all about. Browsing through KDE's CVS you wont find a single application that has had only one person touch the code.

    The idea that your code might best be served if you don't own it is an idea that pair programing formalized. In the open source world developers had discovered it over time out of necessity. If you want help on your part time project, other developers are bound to touch the code that you are working on, they might even take ownership of it when you get bored. In this philosophy one begins to think of all code as both yours and not yours. You feel an obligation to improve both code that you are working on and improve code that you don't work on. Knowing that others will look at the code you write a higher pride comes into play and the code becomes elegant rather then cryptic.

    The reason why Microsoft's applications can still crash no matter how much money they toss at it is because at Microsoft everyone owns their code. A developer only touches the code they maintain. The only person I known to have been fired from Microsoft was a programmer who wasn't willing to fix bugs against his code until "later". The idea that other developers might fix the code would be like telling a stock trader in the 1920's to diversify. Whenever only one developer owns a piece of code it can never be as sound as code owned by many. The collective work will always be superior to the individual.

    Tuesday, September 02, 2003

    New Job

    I've taken a new job with Symbol Technologies and moved out to Long Island New York. On top of the move Jen and I have purchased a new car. Check out a photo of our new 2004 Infiniti G35.

    Wednesday, June 11, 2003

    Old Pascal Games

    While spring cleaning I found the floppy disks containing the source code for two Pascal games I wrote in high school. The source code with some Dos binaries have been put up on GitHub here.

    Monday, April 07, 2003

    Bad Apples

    and how commercial companies should utilize Open Source with in-house development.

    Open Source software is for most a new and unknown idea whose time has finally come. Many managers who have never even heard of Linux are finding themselves attempting to integrate it into their in-house development. They hear all of the wonderful benefits of utilizing Open Source software and want to be part of that. Unfortunately too often the projects fail for what seems unknown reasons. The majority of the time the problem stems from the false idea that Free Software means no cost across the board. Projects are done on a shoestring budget and the idea of interacting with the community is forgotten. The community is a large asset at the companies disposal that should not be ignored. A successful Open Source project within a company must incorporate developers within the community into the project.

    John Macintosh owned an apple tree farm. The vast majority of his apples were shipped out by the ton to a company that made apple cider. After seeing a local farm open its fields to those who wanted to hand pick their own apples with fantastic success he decided to do it also. The margin for selling hand picked apples is much better then selling apples by the ton so why not give it a shot he thought. Come the next spring he put out a sign by the road stating that anyone could hand pick apples. As the summer wore on he found a few customers stopping by, but due to the infrequency he mostly found them to be an annoyance and considered stopping the program all together. Near the end of the August he had a friend over whom also ran an apple farm. The topic turned to John's field and the his lack of customers. His friend quickly pointed out a number of problems that John had overlooked:

    • Customers were given little help when picking the apples. Basics such as ladders, apple grabbers, and bags or crates were not provided.
    • There was no one officially hired at the farm to deal with customers. John who was often busy with other things made the customers feel as though they were not his top priority (it doesn't matter if they really were or not).
    • Getting customers to know about his farm was nothing more then a sign down near his driveway. Because of the success of other farms he incorrectly assumed that this is all he would have to do.

    Each one of these were a problem that in the end hurt John's apple farm.

    Of course John Macintosh and his farm doesn't exist, but if you replace him with a manager and apples with Open Source you suddenly have an interesting situation. Most all business managers when presented with the apple story know the list of problems even before it was listed, but when talking about Open Source they go tripping all over themselves asking why didn't it work? The problem is mostly a lack of knowledge about how Open Source works. They hear about Open Source and Free Software and think that is exactly what it is, something that they can take for free and with very minimal effort get Open Source developers to help. Half of the reason for using Open Source software is to utilize the community, letting them help in improving and developing the software. Managers hear about the army of programmer just working away on code in their free time. They then incorrectly assume that this army of free programmers are just waiting for them to start their project. Managers often times think that very little to no effort will be needed to utilize the community.

    Customers were given little help when picking the apples. Basics such as ladders, apple grabbers, and bags or crates were not provided.

    Developers want to work on Open Source software, your Open Source software! There is no excuse for not giving them every opportunity to do that. Providing timely updates, nightly build, access to the bug tracking system, and mailinglists are all very easy things that can be provided in most cases. There are of course many more things, but those four are a very good start. If a project doesn't even have those internally then there are problems that this article can't cover. Other gestures can be Open Sourcing tools that provide little to no value to the company, but are valuable to developers. Helping developers work on your code is always a good thing.

    There was no one officially hired at the farm to deal with customers. John who was often busy with other things made the customers feel as though they were not his top priority (it doesn't matter if they really were or not).

    Someone needs to be assigned to work with the community on the Open Source project. Often times those who are trying to use Open Source / Free Software get in the mentality that there should be no costs at all associated with it. They think that a project can be successful without any technical help. That somehow the internal and external developers will get together and things will magicly work. A designated developer must be assigned to span the two groups. If the community feels like they are being ignored they will leave (or worse start there own competing project) and then you will have no community. The person who was assigned to work with the community must have full access to both groups to be successful.

    Getting customers to know about his farm was nothing more then a sign down near his driveway. Because of the success of other farms he incorrectly assumed that this is all he would have to do.

    A developer should get a little extra help then extra users. Remember that they are working on code for free. Putting up the source code on the website when intern John gets around to it, although legally correct will win no points with the community. Having a set internal policy how developers can purchase/barrow hardware or other tools is an excellent start. If developers are only thought of as just a way to push a few more units out the door they too will quickly realize this. A successful Open Source project will attract new developers while one that is being neglected will cause the opposite.

    There is no reason for an Open Source project to fail in this day and age. A few simple steps can be followed to make it a success. Developers desire to code and like any relationship they don't want to feel ignored. When they take their free time to report problems they shouldn't feel as though their problems are on the bottom just because they are working in their free time and not being paid $100 an hour. Remember a bug in code is still a bug to be fixed no matter who reports it. Working with the Open Source community does not mean ignoring targets and milestones. It means taking advantage of a extraordinary resource available.

    Last day with Sharp

    Last Monday was my last day at Sharp electronics as my contract with them is now over. After all of the stress from Sharp and the Zaurus project I will be spending some time relaxing and hacking on KDE.

    Saturday, January 11, 2003

    Optimizing KDE Applications

    There are two sides to optimizing KDE. On the user side there are many advanced tweaks that can be made to the system to make it run faster. These tips range from making sure you are running the final release binaries that don't contain debug symbols, to turning off unneeded graphics. If you are looking for those types of hints go here. The other side of enhancing KDE applications is up to developers. This encompasses speeding up an overall application feel, reducing its binary size, and speeding up the application start. Optimization doesn't always mean tuning a function to run faster, but also encompasses the "feel" of the application. Making the entire application runs as smooth as possible. This article won't give you specific tips or examples, but it should point you in the right direction on where to find the information that will.

    Application Design

    An application that is poorly designed will gain more out of re-design than performing small tweaks and improvements. Optimization should not be the last step, but should be built into the design when choices such as the algorithms and data structures are decided. Note that actually optimizing chunks of code *should* be last and done by profiling. An excellent book that covers this topic in depth is Code Complete: A Practical Handbook of Software Construction by Steve C McConnell.

    Utilizing Existing Classes

    Often times developers will write their own classes when in fact, one already existed that they simply did not know about. You should be familiar with the toolkits and the classes in them. Take some time exploring the toolkits documentation to fully find out what it has. You don't need to know all of the details of every class. Simply know what exists so when you need something you wont re-implement it yourself by accident. Classes that are included in the toolkits are generally optimized and bug free because many developers have looked at them.

    KDE Documentation:

    QT Documentation:

    Optimizing C++ Code

    Just like software design, C++ optimization is far beyond the scope of this article. Here are a few books that have been specificlly written about how to optimize C++ code.

    C++ Footprint and Performance Optimization by Rene Alexander and Graham Bensley

    Efficient C++: Performance Programming Techniques by Dov Bulka and David Mayhew

    More Effective C++: 35 New Ways to Improve Your Programs and Designs by Scott Meyers

    The Association of C & C++ users has a comprehensive listing of computer science books along with reviews.

    Doing a search on Google will also bring up some sites that have been created about optimizing C++. Here are a few of them: 1, 2, 3, 4, 7, 8. Although some good information can be attained from these sites, getting a comprehensive book is still recommended, as it will cover a magnitude more. If you have a book or site that you would like to recommend, drop me a line and I will add it. Last but not least check out KCachegrind, which can be used to profile an application and find problem areas that should be improved.


    Remember that in almost all cases where GUI applications are involved, you shouldn't go overboard in trying to improve functions. Doing so can complicate the functions to the point where they become difficult to maintain. Application designs should be clean rather than fast.

    Popular Posts