Re: Using python + pygtk in Desktop modules



 --- Sean Middleditch <elanthis awesomeplay com> wrote: 
> On Tue, 2004-09-28 at 18:13 +0200, Danilo Å egan wrote:
> > Hi Sean,
> > 
> > Today at 16:50, Sean Middleditch wrote:
> > 
> > > And it's not just packages, it's any app.  GNOME is great for third-
> > > party developers because they can just push out their app in a (mostly)
> > > LSB RPM or a tarball or automatic installer or Autopackage or whatever,
> > > and have it Just Work(tm), because the GNOME ABI is stable and you know
> > > for sure that any distro with the version you targeted or higher can run
> > > the app.  This makes third-party packages for GNOME apps actually
> > > feasible without needing a massive compile farm or expecting users to
> > > compile from source.
> > 
> > The current practice is *still* to have suitable packages for each
> > architecture, distribution, and distribution release.  So, you're
> > basically talking about a pipe-dream, and trying to convince us that
> > it's not possible with Python (while in practice, it's not being done
> > even with stable GNOME C libraries).
> 
> Yes, actually, it *is* being done.  Look at the Autopackage project, at
> the distro-independent Mozilla or OOo packages/installers, at various
> commercial apps that install with loki_setup or some other installer,
> and so on.
> 

And getting there is actually really simple - you just fix the build 
machine at a pre-agreed library levels and you "suddenly" get binaries 
that "just work" for everybody. Sure, this can't be the same box you 
experiment with your pet latest unstable glibc and X.org / Xfree86 on, 
but its not a large problem. 

There are people out there making glibc 2.0.x compiled versions of OOo.

> The stable C ABI *is* used, and works great.  And it works because of a
> "pipe dream" that people actually worked on, instead of taking your
> approach and going, "oh, things aren't perfect right now, so forget
> trying to make it better." (yes, that was over-dramatized - no offense
> meant, Murray.)
> 
> > 
> > I have always had more problems running applications distributed via
> > binary packages for [not-my-system] unless they were, of course,
> > statically compiled (but ABI is not too important then), than running
> > Python code written for certain version of Python.  So basically,
> > Python programs tend to be more cross-architecture (note this one,
> > which you silently ignore ;-), cross-distribution and cross-release
> > than binary packages of C libraries/programs.  I'm talking about
> > completely *real* and *practical* issues now, and I'm not making
> > things up.  If I don't have suitable GCC 3.x libraries, none of the
> > GCC3 compiled programs will work for me (I remember something like
> > this happening to me, but I'm not sure about technical details).  If
> 
> GCC3 did indeed break a lot of things.  It's not an excuse to keep
> breaking things left and right.  It's an example of how making decisions
> purely for technical reasons with no thought to how much you screw over
> users can make the system a nightmare to use.  GNU/Linux systems aren't
> marketed to anyone but geeks and niche corporate markets, so it is still
> OK to pull crap like that.  If the systems were on even 10% of the
> desktop market, you'd destroy the system's credibility by breaking most
> of the applications in existence.  There are still tons and tons of
> companies and individuals that won't touch GNU/Linux specifically
> because of all the turmoil, and the fact that their proprietary or in-
> house apps can't live in an environment like that without massive
> support costs.
> 
> It's a reason I'd argue against using C++ for any Developer Platform
> modules, too, at least until a stable C++ ABI is out and around for a
> few years.  (LSB 2.0 seems like it might take care of that, finally, in
> a couple years when it's widely available.  The GCC developers are also
> claiming, again, that the new v6 C++ ABI is final...)  
> 

The gcc c++ abi instablity is a *MAJOR* PITA. It would be very nice to have 
c++ bindings in the platform, but as things stand it just doesn't make sense. 
Having a platform component that regularily breaks on all supported platforms
except Solaris would be ... quite bizzare, honestly. 

> -- 
> Sean Middleditch <elanthis awesomeplay com>
> AwesomePlay Productions, Inc.


=====
Open Source - the religion of doing it right


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]