On Wed, Apr 4, 2012 at 16:06, Gerold Rupprecht
<geroldr@bluewin.ch> wrote:
Hi,
I found the following analysis most interesting:
http://www.economist.com/blogs/babbage/2012/03/desktop-linux
Then I got to reading about your involvement with the automated testing
software called Eggplant.
The key to success is to reduce the support time needed to work with any
piece of software. Would the testplant people be willing to make their
software available on an open-source basis, or better yet the GPL ?
Looking at their web site, it seems to be their primary product, so I suspect the answer would be "no".
How else can we reduce the support costs for GNUstep and its
applications?
Aside from common knowledge (keeping backward compatibility, having good tests), I'll try to come up with something.
By sticking to Cocoa, thus enabling easy portability of existing OS X software and ensuring continuing compatibility.
By getting more users, as a consequence of more app availability.
By eventually coming up with a full desktop environment, perhaps based and integrated into Ubuntu -- in the sense of easily available packages which get GNUstep (or a GS-based environment) to appear in list of sessions in GDM and its session-managing buddies. Installing packages as if built with "prefix=/ layout=GNUstep" would make sense.
All this is aimed at increasing the userbase and making stable snapshot releases, which is the right time to start worrying about compatibility and enterprise maintenance, as well as keeping snapshot builds upgradable and spaced at regular intervals (six months? a year?).
Can some projects be merged to widen the appeal of GNUstep?
I am thinking of the fork that Niklaus Shaller has been working with all
these years. His major need was to support floating point operations on
machines that did not have a FPU.
I suspect that if you want to reduce maintenance issues you don't need to think about additional build options, but about focusing on one build that Just Works(tm).
Developers of GNUstep love to tinker, and GNUstep supports a wide variety of options, configurations, et cetera -- just as it should. But if you are focused on reducing maintenance and upgrade trouble, this one build needs to be extraordinarily supported and verified. And I do mean one build - be it a Linux Sparc build produced with gcc 4.7 and installable from .rpm packages, or a FreeBSD x86-64 build, produced with clang and installable by simply unpacking .tgz into /, it needs to work extraordinarily well and be extraordinarily simple to upgrade.
I suspect one would target any kernel under i386, and that one would need to write a GUI upgrade (if not outright install) system in order to provide a complete, consistent experience. And if one really wants to target enterprise environment and do so better than currently popular Linux distributions, one would also need to provide extraordinarily fine-tuneable forcing of user defaults, configurable via GUI and distributable over network, along with a Windows Domain login support working out of the box along with a single-sign-on solution that interacts with this domain.
All of this in a build that would Just Install(tm) and Just Work(tm), without a lot of magic tinkering with the system.
But this is so far in the future that we should just focus on having the best development libraries for GUI applications under free operating systems. If someone requires stability, the easy solution is simply not to upgrade.
When the upgrade comes, I suspect upgrading a GNUstep system (probably recompiling the apps) is really one of the simpler things done during the upgrade.
The other thing that we talked about at FOSDEM was better cross-compiler
support. Niklaus has been supporting an older tool chain (gcc 2.95 if I
remember correctly) when David Chisnell suggested Clang might be a good
replacement candidate for mult-platform compiler support. Does Clang
support the ARM chip yet?
clang definitely supports ARM, considering iOS is running on ARM and the compiler being used is -- you guessed it -- clang.
How well it works with Linux-based systems on ARM, that's something one of our resident clang contributors will have a better idea about.