[ale] difference between android and linux ?

[David Tomaschik]

(Responses inline)

On 08/13/2011 05:49 PM, Ron Frazier wrote:
> I want to say thanks to Pat R, Tavarvess W, James S, Jim K, Michael T,
> and others who have responded to this inquiry to try to clarify
> things.  It IS a bit confusing.  I want to review each of your replies
> in more detail, but for now, I have a few more questions.  What I'm
> getting from the discussion is that you first have "the core" or the
> Linux kernel on GNU Linux and on Android Linux.  Serving comparable
> duty would be the NT Kernel in Windows and the Mac OSX Kernel on Mac. 
> Then, wrapped around or sitting on top of the Kernel are various
> libraries and functions which make up the API of the OS which
> applications can call on.  Then, you have the applications themselves
> which call on the API to get things done.
>
Correct.  Just FYI, the OS X Kernel is named "Darwin."
> At a binary level, applications for Windows, Mac, GNU Linux, and
> Android Linux are not compatible with each other.  Even on machines
> with comparable and adequate resources, the API's, functions, and
> libraries are too different among the various systems, in general. 
> So, Firefox for Ubuntu is fundamentally different, even though
> functionally the same, than for Windows or Mac (if available), for
> example.
There are definitely big differences in the APIs.  There are also
differences in the actual format the programs are presented within the
file.  (Linux normally uses a format called 'ELF', Windows uses
'PE'--portable executable.)
>
> Even various binary executables for different GNU Linux systems may be
> fundamentally different.
>
Generally, they're not too different.  Different systems may have
slightly different versions of the same library, but for the most part,
they're pretty similar.  For example, you could build a binary on a
current Fedora Core and I would be surprised if it didn't run on a
current Ubuntu (provided that you had the dependent libraries installed).
> Full desktop OS's like Ubuntu generally will not run on something like
> an Android tablet due to resource constraints.  A more stripped down
> version of GNU Linux may be able to run on a tablet with decent hardware.
Sure.  This is mostly due to the desktop environment in use.  KDE
4/Gnome 3/Unity all expect a (relatively) modern desktop.  I currently
run XFCE, and though I'm on a Core i5, it would run quite nicely on even
a Pentium III.  Fluxbox and other WMs/DEs can probably run on even less.
>
> I'd like to propose a hypothetical development scenario and gather
> opinions on what factors will affect the developer.
>
> I'm making up this scenario, so it may or may not ever happen.  Let's
> say that I want to create a great application for stellar
> cartography.  Let's say the user should be able to use a menu and form
> query system to select star charts and view them in windows or print
> them.  Let's say that there are various calculation functions
> included, so you can find out how far it is from various points in the
> galaxy in three dimensions.  Let's say you can also do things like
> calculate the cumulative mass of stars in various nebulae and generate
> reports and graphs on this data.  As I said, I'm just making this up,
> and I'm not an astronomer.  The point is, that this application, like
> many, will have (at least) a GUI UI component, a logic and calculation
> component, a database component, and perhaps an output component
> (printing) other than the GUI.  Let's say I want this application to
> work on Windows, Mac, Android Linux, and the top 5 flavors of GNU
> Linux.  A quick check of distrowatch.com says those are Ubuntu, Mint,
> Fedora, Debian, and SUSE.  Nothing against the others, but developing
> for 8 OS's is probably enough of a challenge for now.  The application
> has to be functionally identical on each system.  We could make
> allowances for UI design guides and traditions on each, but might
> choose to make them all exactly the same as well.  The executables may
> be different, but the data files the app creates, loads, and saves
> must be compatible across all systems.  A user must be able to use the
> app on any of the mentioned systems and do exactly the same things, or
> transport data from any system to any system.  Code reuse must be
> maximized among different versions, since I don't want to spend 8X the
> time it would take to make one version.
>
Seems like reasonable specifications.
> Putting aside what it actually takes to design a stellar cartography
> application, I want to address what it takes to set up the development
> environment.  I had read somewhere that you can maximize portability
> among apps by breaking them into the UI, logic, and database sections,
> which is why I structured this the way I did.  I added an output
> section because it seemed logical and appears that that would
> encompass a major subsystem.  The stuff I read said that if each
> subsection is built as a black box, so to speak, with a clearly
> defined IO interface at its boundary, then you could share some black
> boxes among multiple systems and customize others for each system.
>
Absolutely.  This "black box" concept is exactly what makes up an API
(application programming interface).  For example, libc provides a
malloc() function.  The implementation of this function probably varies
quite a bit by which libc you're using and on what hardware.  But no
matter what, you can call malloc() and get some memory allocated.
> Now, as far as I know, C++ standards based compilers are available for
> each platform, although I'm not totally sure about Android.  Assuming
> that's true, then I should be able to make the logic and calculations
> "box" identical for each system, with exactly the same code.
The only exposed API on Android is through the Dalvik Virtual Machine,
which is based on the Java programming language.  No C++ for Android. 
(It might be available on some rooted systems, I'm not sure.)
>
> It appears to me that the other "boxes", UI, database, and output;
> would have to be customized to each system, based on the API that each
> is presenting.  So that makes it sound like my code reuse factor is
> taking a beating, with somewhere in the range 25% of code that is
> common and 75% of code that is unique for each system.  However, it
> also seems that I may be able to get some help from libraries, such as
> FLTK or QT, which are available on different systems.  If such things
> are available on all these systems, then I can write my app to call
> the API of the add on libraries only, and avoid native OS calls.  That
> way, I would think that I could get my code reuse up to the range of
> 75% of code that is common and 25% of code that is unique to each
> system.  More common and less unique is obviously better.
UI and output seem to be the same to me.  Use TK, QT, or GTK and your UI
will be easily portable with almost no trouble.  For databases, use
MySQL, PostgreSQL, or sqlite.  sqlite, unlike the others, is implemented
entirely in the library, so no DB server needed -- great for single-user
applications.  (sqlite is used within Firefox and Thunderbird, for example.)
> I'm trying to set up a development system which will let me do exactly
> the type of thing I've described, when I'm ready for it.  What I don't
> want is a system that forever prevents me from porting my apps to
> other OS's.  Thus far, I'm thinking GNU tool chain (G++, GCC, GDB,
> MAKE, etc.).  I know this is available on GNU Linux systems and on
> Windows, although I don't know how to install it on Windows at this
> point.  I don't know for sure if it's available on Mac or Android.  I
> don't own a Mac or an Android device at this moment, so I cannot test
> that.  I'll probably use VIM for editing.  It would be nice if I can
> do equivalent development on any platform, but, if I'm stuck to
> developing on a specific system, that's OK.  I just have to be able to
> compile applications that will run on each system.  I'm thinking FLTK
> to start as a GUI library.  It's available on Windows and GNU Linux. 
> Again, not sure about Mac and Android.  Maybe later, I'd advance to
> something more comprehensive.  I don't know about database libraries
> and printing libraries.  Maybe MySQL, etc.
See above for databases.  Even on Windows, you can build against a GNU
toolchain with Cygwin.
> So, I'd like any advice I can get as to how to build a TRULY cross
> platform development environment, which can service all the OS's I
> mentioned.  Not that I'm ready to publish such an app, nor will I be
> in the near future, but I want to be eventually capable of it.
>
> I just had another idea, which may be great or crazy.  Let's say I
> encapsulate my app within a VM, even if it is not visible to the
> user.  Let's take for example, the VM that VirtualBox (or VMWare)
> presents.  These systems emulate a specific set of hardware every
> time.  So, assuming I could get the VM "player" modules on each target
> platform as part of my app installation, I could just target whatever
> "machine" API is being presented to my program by the VM player.  I
> write code solely to the virtual machine, and ignore whatever is going
> on in the real machine.  Any resources available on the real machine
> should be presented to my app through the VM player's API.  Great...
> or crazy?
That was the idea behind Java.  JVM = Java Virtual Machine.  It's not a
fully-emulated VM, but it abstracts the user's machine to create a
"virtual machine."
>
> Sometime later, we can talk about version control, IDE's, and
> packaging and publishing for the various OS's.  As usual, any advice
> is greatly appreciated.
>
> Sincerely,
>
> Ron

Developing for (non-rooted) Android devices is a completely different
ballgame from developing for the rest.  You'd need to use the toolkits,
libraries, etc. available on the Android platform.  If I were you, I
would focus on non-Android development first (unless mobile is your goal.)

In my opinion, the most portable language available these days is
python.  There are plenty of functions to abstract things from the
underlying system, it's easy to get started with (shallow learning
curve) and there is plenty of good documentation and tutorials out there.

Hope this helps!

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110813/071d0982/attachment-0001.html