Re: Article criticizing Linux in the Economist - large need of software support time

[Sebastian Reitenbach]

On Wednesday, April 4, 2012 18:42 CEST, Ivan Vučica <ivucica@gmail.com> wrote:

> 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.

In my opinion, its best to have packages in the main packages repository of each
OS/Linux distribution. That's the most easiest thing for $average user. They 
would
just upgrade, like they do with any other installed software. No need to tinker 
around
with self compiling, or extra repositories in extra locations, or whatnot. They 
just
use their default tools to manage packages on their favourite OS, and they are 
done.


>
> 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.

This is only easy, if the API doesn't change. With the latest stable releases,
I have headaches, making sure, all applications in the OpenBSD ports tree
still compile/work. This is mostly fine on i386 right now, but on amd64, some
things compile, but break horribly. One of the reasons, I did not yet upgraded
the main gnustep libraries there, first have to prepare/fix the apps depending
on it, then upgrading.

A thing that would really help, is when with each release, there would be a
page in the wiki, detailing the API changes of that version. Listing new classes
and methods, and especially things that were changed, which can potentially
break existing apps. Whenever someone commits to svn which changes the API,
the relevant page for the lib/version should be updated.

Sebastian



>
>
> >
> > 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.
>
> --
> Ivan Vučica - ivan@vucica.net