[Wylug-discuss] Themes for future introductory talks

[Roger Leigh]

Damian Allinson <d.allinson at virgin.net> writes:

Hi Damian,

[This is quite a long post.  It's mainly a mishmash of my ideas about
my own future embedded development work.  Any comments are welcome!]

> I am involved in embedded systems design and would be interested in
> hearing about real world experiences of embedding Linux in a commercial
> or industrial product (technical and political aspects).

I'm currently starting to get involved in this sort of work.  I've
recently started a job working as a coder/tech support for a company
producing EPOS (electronic point-of-sale) machines for retailers.

The software, while very good at what it does, is DOS-based and the
nature of the language it is written in (a 4GL), makes it difficult to
add new features and maintenance takes much longer than a more modern
language would require.

The company want to move to a more modern platform in the future,
going to an embedded board and a touch-screen display.


Technical aspects:

The main issue is re-rewriting the application from scratch.  One
possibility was going to Windows (CE), and upgrading to the latest
version of the 4GL (now re-written in Delphi), which would mean
porting the existing codebase to the new version of the language, so
re-writing would not be necessary.  However, this is not a
possibility, since WinCE for ARM would require a full rewrite anyway
(the 4GL is ix86-only).  This moved Linux/ARM to the top place--since
rewriting from scratch is unavoidable.

Given that a rewrite is necessary, this allows us to choose the most
appropriate hardware platform and OS.  We would like to have the
ability to run the program on a standard i386 Windows9x OS as well as
Linux and the embedded hardware.  The candidates we have looked at
are:

Databases:
* PostgreSQL running natively on whatever platform we need (the
  forthcoming 7.4 stable release will run natively on Windows).
* MySQL (this has the disadvantage of being pants for "serious" usage,
  due to its nonexistent/immature support of many of the features we
  would require such as transactions, views, cursors, stored
  procedures and strict referential integrity, amongst others).
Asyncronous replication would also be very nice to have, which one of
the PG replication projects supports.

Languages and libraries:
* Java, using the native Java graphics toolkit, using JDBC to talk to
  Postgres.
  Advantages: The binaries will run anywhere.
  Disadvantages: I haven't used Java before; JVM quality; API
  stability; ?lack of libraries?; performance issues.
* C, using GTK+/libglade and libpq to talk to Postgres.
  Advantages: Simple interface; small and fast executables (my test
  program was just 8 KiB!); Glade can greatly simplify interface
  construction and can autoconnect signals, reducing code size.
  Disadvantages: GObject is complex and callbacks are not type-safe;
  difficult to derive new objects; callbacks are not class methods
  (i.e. state-containing).
* C++, using Gtkmm/libglademm and libpqxx to talk to Postgres.
  Advantages: Signal handlers are type-safe, but need to be connected
  manually (Glade signal autoconnection isn't implemented);  Gtkmm
  allows easy derivation of widgets which is very difficult in GTK+;
  Derived widgets can hold state information and signal handlers can
  be class methods.
  Disadvantages: Initially more complex than GTK+; Signals must be
  manually connected.  C++ is a much more complex language than C.
* Both the C and C++ applications and the respective libraries can be
  built on Windows using Cygwin/MinGW, at least in theory (untested).

Whether or not it is actually chosen, I have been learning GTK+ and
Gtkmm, and have knocked up some simple programs in each.  I'll be
putting together a demo prototype of the new system using
C++/Gtkmm/Postgres (my preferred combination).  If anyone is
interested in getting into GTK+ using the C or C++ bindings, I'll
probably be competent enough to give a talk on this sometime later
in the year.


Semi-political aspects:
* Choice of language!  I tend to favour C or C++, having used C
  extensively, and I have been learning C++ over the last year.  I've
  only ever coded for POSIX/SUS systems.  My boss has a background
  using MS technologies like VB, as well as JavaScript and DOS 4GL
  languages, and favours Java.  I'm not sure how over-hyped Java
  is--it's not something you come across much doing free software
  development, so I'm not sure of its capabilities.  As we will both
  be co-developing the new system, we need a language we can both work
  with.  He is a bit apprehensive about learning C++, while I tend to
  feel learning Java would be a waste of my hard-earned C and C++
  skills.  I'm also leary of using a completely new language on a
  large project, without understanding all of the nuances of the
  language--after more than a year of C++, I've still only scratched
  the surface of the STL, having not yet needed much of its
  functionality.  How much of a learning curve would Java be?
* Advocacy of free software.  I've not had much to do, since my boss
  is not a MS fan, and would like to create cross-platform software to
  avoid being tied to a particular vendor.  It's important to be aware
  of licensing issues and ensure that your co-workers and management
  understand the GPL/LGPL/BSD licenses etc., so you can comply with
  them.  When writing software using free libraries, you need to be
  aware of the implications.
* The software I write is going to be proprietary, unfortunately, but
  the skills I learn will surely be useful for future free software
  development.  If you can persuade your company to freely license the
  software, you may reap long-term benefits from doing so, such as
  shared development efforts and a long-term future for the software.


> Also from the real time point of view, has anybody switched to Linux
> from the proprietary RTOSes and experiences in doing so.

Sorry, this is well out of my experience.


Regards,
Roger

--
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers