2010/1/17 Stephen Pelc <stephen@???>:
> This is an aggregated response. If the lack of attribution
> upsets you, I apologise.
>
>> A majority of the software for the Linux platform is distributed in
>> source code form.
>
> That's the open source business model. It's a service model. You
> pay for service, not for acquisition. That's fine for high-
> volume markets, but it doesn't work for everyone. We've chosen a
> mixed model.
>
> We're not alone. Look also at products such as UltraEdit and
> BeyondCompare, both of which are now available for Linux. And we
> have paid for them.
>
>> When dealing with free, open source software coded
>> largely by volunteers you can take it a stage further -
>> you can get involved and fix it.
>
> We are involved in open source projects, probably just not ones
> that float your particular boat.
>
>> Finally, I don't disagree with the idea that a package
>> management system that simplifies installation across
>> all distributions is a good one, but I do take issue
>> with someone complaining about the state of things when
>> they could be doing something positive about it, one way
>> or another.
>
> I would have said that I don't have the skill set for this - I'm
> not, and don't want to be, a Linux kernel guru. However, I have
> talked to a number of people who produce proprietary Linux apps
> in niche markeys, and they all agree that packaging is a real
> PITA. We may even consider writing a Linux install system for
> human beings. Interested people are welcome to contact me, but
> please don't send me philosophical rants about the evils of
> proprietary software. My flame-proof suit is good - I've been on
> standards committees for many years.
>
>> There is absolutely zero incentive for the Linux distros
>> to make life easier for binary only distributors as it
>> stifles innovation.
>
> That's just "proof by repeated assertion".
>
> There is a significant proportion of the compiler-writing
> community who believe that gcc has stifled compiler innovation.
> In the opinion of many it's an "adequate" compiler. The x86-32
> and x86-64 compilers are have huge commercial input, but are far
> from best-in-class. For other targets, e.g. ARM and Cortex,
> despite the funding of Codesourcery by ARM, the gcc compiler
> just isn't very good.
>
> The downside of gcc is that it has become dominant in certain
> sectors because it is free (beer). Dominance doesn't mean good.
> Open source doesn't necessarily mean good (quality).
>
> Regards, Stephen
> P.S. If you are sending a response to the list, I really don't
> need separate email copies.
> P.P.S. Thank you to those who have sent direct emails with
> offers of support. I'll get back to you in the coming week.
I am happy to give advice, even some reviews of existing packaging for .debs
Have you looked at OpenSuse's OSB (OpenSuse Build System). It is
supposed to allow for easier building of rpms and debs from a single
source system (though you still have to write the rpm specs and debian
specific files/code). I have not had the time to try it so don't know
how good it really is.
You are absolutely correct that an easier way of packaging apps would
help linux in general, but short of "forcing" everyone to use the same
format, this is rather difficult (in truth there is a universal format
- source code... Then each distro will package it to fit them).
The answer is complex - different packages have different names and
versions depending on the distro (so a .deb isn't good enough, you
really need a .deb for each distribution, often one for each release
of each distribution)). As things like library names vary between
debian and ubuntu, you can't easily even have a single package that
works on both unless it is completely statically compiled (and then
you still need one for each architecture)
I have thought about this a lot given I build 14 versions of packages
in a build system at my work (all .debs!), but I cannot see how else
it can work unless you can get everyone to agree... Getting them to
all use .debs (for example) will be comparatively easy compared to
getting them to synchronise library names and versions
Anton
--
Anton Piatek
email: anton@???
blog/photos: http://www.strangeparty.com
pgp: [74B1FA37] (http://www.strangeparty.com/anton.asc)
fingerprint: 7401 96D3 E037 2F8F 5965 A358 4046 71FD 74B1 FA37
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
