Hi :)  
I thought that was one of the myths about Gnu&Linux.  

Several times i have seen people saying that packages in Gnu&Linux need a 
separate new compile for each individual distro.  However all the links i gave 
to other projects show only 2-3 downloads and that seems to be enough to cover 
almost all versions of almost all distros.  

I hadn't realised that Evo is slightly different and more tightly integrated 
with just 1 version of just 1 DE.  So although it's not quite possible with Evo 
it does seem to be fine with the others.  

Anyway, to mitigate against that the DE is an excellent one and pretty much my 
fav.  Almost any distro can choose to have that DE even if users are actually 
using a different one that is kinda in parallel.  Users could be seeing and 
using KDE, or LXDE or anything else but just have Gnome 3 as one of the options 
that they barely notice as they are logging in.  So, that is not quite perfect 
imo but is plenty close enough.  It works.  

So for a Gnu&Linux app to hit the vast majority of users it just needs to be 
compiled about 3 times.  Also it doesn't need any faffing around rewriting code 
before doing each of them.  


From what i have heard ... 
For Windows it's a separate one for Xp, then for Win7, Win8 needs another (skip 
Vista right?).  So that's about 3-4 too except that rewrites will probably be 
crucial.  

For Mac it's at least 2 if you want it on their desktops as well as hand-helds. 
 

Except that apparently if you have already done a Gnu&Linux version that might 
just need a rewrite to make it work on Bsd and Mac.  Also i've heard it's a lot 
easier to port from Gnu&Linux (or Bsd) to Windows than it is to port from 
Windows to anything else.  

So starting with Gnu&Linux (or Bsd) makes a LOT of sense because it 
can then be ported to a wide range of platforms for about the same 
amount of hassle as doing different versions of Windows.  
Regards from 
Tom :)  





________________________________
 From: Adam Tauno Williams <[email protected]>
To: [email protected] 
Sent: Tuesday, 27 August 2013, 16:07
Subject: Re: [Evolution] downloads page
 

On Tue, 2013-08-27 at 15:10 +0200, Alberto Ruiz wrote:
> Is less than ideal, it means a lot of trouble for application
> developers:
> a) If you write an app, you have to either learn how to package your app
> for every distro or convince them to package and maintain the package
> for you. In practice it means months before your app can hit the users.
> Compare that to Mac, Windows, Android or iOS, where application
> developers can go live and distribute their apps in day 1.

This is a downside.  But the same *does* apply to other platforms.  You
just learn Android packaging as part of Android development; it is no
less or more documented and opaque.

And depending on you app you may skip in entirely.  I distribute Python
applications as EGGS.  They install as "pip install {appname}", bam,
done.  Other categories of apps provide a similar 'round about'.

> b) You can't install parallel versions of your app, for example, if I
> want a newer version of firefox I have to uninstall the older version.
> This means that power users have no access to beta versions and
> therefore _everybody_ hits more bugs on release time.

Most packages are relocatable.  That works pretty well.  But now we've
jumped from "user" to "power user", which is a bit of a context change.

> c) You need to upgrade your whole system to update a single app, to
> access newer versions of your apps, you need a newer version of your
> OS... which is a ridiculous requirement if all that you want is to get
> rid of a bug or access to a new feature in a single app like LibreOffice
> or evolution.

I upgrade Evolution & LibreOffice all the time - without an OS upgrade.
This claim is wildly exaggerated.  I am running a very-near-current
LibreOffice 4.1 ... on openSUSE 12.1.   Installation was as painless as
a couple clicks.

> d) A package is by definition a part of your system, how on earth is
> making end user apps a part of your operating system an ideal situation?

THEY ARE NOT PART OF THE OPERATING SYSTEM.  That statement is FALSE.
They are packaged by the distribution, that is all.  DISTRIBUTION != OS.

> RPMs have pre/post remove hooks with root privileges, a broken package
> can mess up your whole system.

And this differs from installing on other Operating Systems how?  You
need Administrative access to install all but the most trivial
applications.  The exception is mobile devices which are a different can
of worms entirely, and inherit some limitations from that can [speaking
of having to upgrade the entire OS to access new features...., there is
no packaging nirvana there.]

>  This means that every application
> developer/packager needs to suddenly become a system integrator with all
> the responsibilities and knowledge that comes with it.

Packagers are indeed System Integrators.

> e) This situation actively prevents any closed source app from being a
> well integrated app in the Linux ecosystem, which is bad for everyone
> that cares about free software/open source as it restrains the size of
> our potential user base.

I use several closed source applications.  They provided either packages
are installers.

> In any case, if you think that the current situation is ideal for you,
> then I am happy for you, you're just not the kind of person that suffers
> from all the issues stated above; but the fact that it does work for you
> doesn't mean that it is ideal for everybody.

It may not be ideal for all situations, which is not to say that it is
'broken'.

-- 
Adam Tauno Williams <mailto:[email protected]> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA

_______________________________________________
evolution-list mailing list
[email protected]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
_______________________________________________
evolution-list mailing list
[email protected]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

Reply via email to