The future of Linux - architecture and package inter-dependencies

[Kaimano]

Hi All,

Just joined this list, I started a topic on fedoraforum.org and I was
suggested to refer my thoughts on this list as well. Sorry, is LONG.

Here is a compendium of the messages I posted:

ONE

Linux represents a greatly stable platform and the FC team is doing a
great work in improving the operating system, however I think that we
should all take a step back and look at what the market and ourselves
really need.

What I am looking for, like, I believe 99% of the user base not involved
with developing the OS, is:

1) to install an OS and forget about re-installs for at least two years 2)
to be able to upgrade the applications I most use without having to
re-install the operating system
3) to include among the applications I most use the following:
* openoffice
* evolution
* http server
* kde
* gnome
* firefox and mozilla
* mysql and postgresql
* eclipse
* java

to name a few.

I am unsure about the real value of building java within the OS, so
tightly that most packages builds depend on them.

If I seriously need eclipse, I will go an get the latest JDK from Sun and
the latest eclipse from eclipse.org and run them as such, they install in
minutes and I can update them whenever available. FC5 has created a
massive and unnecessary overhead of work essential to keep up with the
latest releases.

firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk
about evolution 2.4 openoffice and KDE just to name some. The dependencies
on a miriad of packages make the effort ridicolously hard.

The risk is to alienate potential users by forcing them to re-install
their operating system whenever they/we want to use the latest release of
an application that we really care about.

My proposition is to start thinking of a Linux architecture that allows
the re-build/re-placement of essential packages without having to rebuild
most of the operating system, thus increasing the life-span and viability
of a platform installation that need not to be replaced every year.

TWO

The problem is not updating from one version to the next, the problem is
actually to keep up with updating the most important, though not system
vital applications, without updating the core operating system. One guy
using its own computer can do that accepting some difficulties and risk.

Assume an hipotetical scenario of an organization that rolled out Linux
desktop to 35000 workstations. The roadmap includes a desktop refresh in
no less than five years due to costs implications.

The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4. But ... evolution 2.4 requires
python 2.4, our installed base is on a distribution based on python 2.3
(like FC2) which is deeply rooted in several applications. In addition,
upgrading to python 2.4 involves upgrading also to a later version of db4,
on which several other applications depend. Here we go, the chain is so
long and tight that just a simple upgrade of evolution involves
re-building most of the operating system, or ... rolling out a newer
version. That puts me off recommending Linux Fedora or Red Hat for any
business desktop platform.

Are any of the core Fedora / Red Hat architects watching this forum?

I would like to hear from them on this.

THREE

The good of this distro is right that there are discussions and
participation from the community that can have its input, beside the fact
that I am uncomfortable in participating, because I would be working for
free for Red Hat that holds its fingers deep in the pie. As a matter of
fact I am not particularly content with Fedora's license terms (the
packages are open source, but we hold the rights on the OS structure, not
just the logos, that belongs to us), an american lawyer must be behind
those. To this end I believe that either we all work for free or we all
get a share of the benefits.

Having clarified this, I would like to make my little free contribution by
drawing your attention to the fact that "having the latest version of a
package at all costs" does not bring all the advantages that it could. On
the contrary, I think that this tendency has brought Linux to being worse
than Windows that we all criticized when got IE embedded.

I would rather ensure that more attention is given to the system's
architectural solution that should be based on modular components that,
although interacting with each other, allow for the isolation of the
applications into services that are as much as possible independent from
each other, thus allowing for greater flexibility (in replacing them with
newer or different versions), which in the end would bring to the system
greater stability, lower cost of ownership (maintenance effort), and
eventually deeper market penetration.

If Fedora is what Red Hat will pick from, for their future releases, maybe
Red Hat are missing the point, because their are getting spaghetti code.

FOUR

Originally Posted by greenlead
Libraries and apps need to be written for backwards compatibility. An

older app should still function if an updated library is installed.

Precisely, this is at the foundation of any healthy information system,
but it is not happeining with Linux right now, because of the lack of
planning hidden behind the excuse that software solutions evolve rapidly.

[Arjan van de Ven]

Post by Kaimano
Hi All,
Just joined this list, I started a topic on fedoraforum.org and I was
suggested to refer my thoughts on this list as well. Sorry, is LONG.
ONE
Linux represents a greatly stable platform and the FC team is doing a
great work in improving the operating system, however I think that we
should all take a step back and look at what the market and ourselves
really need.
What I am looking for, like, I believe 99% of the user base not involved
1) to install an OS and forget about re-installs for at least two years

this FC already gives you ;)

Post by Kaimano
2)
to be able to upgrade the applications I most use without having to
re-install the operating system

that's a hard one, see below
\

Post by Kaimano
firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk
about evolution 2.4 openoffice and KDE just to name some. The dependencies
on a miriad of packages make the effort ridicolously hard.
The risk is to alienate potential users by forcing them to re-install
their operating system whenever they/we want to use the latest release of
an application that we really care about.
My proposition is to start thinking of a Linux architecture that allows
the re-build/re-placement of essential packages without having to rebuild
most of the operating system, thus increasing the life-span and viability
of a platform installation that need not to be replaced every year.

I think you are missing something here: these "essential packages" *ARE*
most of the operating system. (If you divide FC into "OS" and
"Applications", the essential packages you speak about fall under "OS",
and are the DNA and fabric of what makes it an operating system).

Post by Kaimano
TWO
The problem is not updating from one version to the next, the problem is
actually to keep up with updating the most important, though not system
vital applications, without updating the core operating system. One guy
using its own computer can do that accepting some difficulties and risk.

again.. it's the same thing!
"I want changes. But I also don't want changes"

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

A bug should never ever be a reason to do an upgrade to half the OS.
Missing features, sure, but bugs... no.

[Erwin Rol]

Post by Arjan van de Ven

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

but, but, than you have pay money, and we just switched to Linux because
everything is gratis ;-)

- Erwin

[Rahul Sundaram]

Post by Erwin Rol

Post by Arjan van de Ven

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

but, but, than you have pay money, and we just switched to Linux because
everything is gratis ;-)

Could be gratis if the source is available under a appropriate license
and you have the resources and time to do it yourself. On many occasions
your expertise is not operating system development or more specifically
not backporting Evolution bug fixes and it works out cheaper to pay a
vendor.

[Kaimano]

Post by Erwin Rol

Post by Kaimano

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on

evolution

Post by Kaimano
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

but, but, than you have pay money, and we just switched to Linux because
everything is gratis ;-)

I hope not. The point of Linux is freedom and independence, not being just
"free". On the contrary, personally I spent more with Linux (if I value my
time) than with any other OS I used.

Anyway, I would like to focus more on the way we can improve it, starting
from taking a step back and looking at the core architecture.

The package inter-dependency at "RELEASE" level is killing it.

Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.
Too much is now changed from release to release only because of the lack
of proper planning and design of the interfaces.

--
Mauro M.

[Patrice Dumas]

Post by Kaimano
The package inter-dependency at "RELEASE" level is killing it.
Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.
Too much is now changed from release to release only because of the lack
of proper planning and design of the interfaces.

I think that this issue is not specific of fedora. The issue comes from
upstream where incompatible api or abi are used. And it widely depends on
which package you're looking at. For example glibc is very stable (thanks
to proper use of library versionning), while recently (if I'm not wrong)
gcc has been breaking binary compatibility quite a lot in g++. Other
libraries may benefit from using library versionning (motif comes to my
mind), but it isn't a fedora issue.

Breaking api/abi isn't necessarily bad, as it allows to move on. Fedora
doesn't avoid those changes as the aim of fedora is to use the newest
technologies.

If you want to use stable platforms, there are RHEL and its clones, or
the debian stable, but then you won't be able to upgrade to newest
application versions if the upstream doesn't allow it.

To state it otherwise, if you want improvements in the stability of free
software, then you'll have to help each of the project libraries that don't
have a stable api/abi, but fedora uses what exists and is the most recent.

--
Pat

[Mauro Mozzarelli]

Post by Patrice Dumas
I think that this issue is not specific of fedora. The issue comes from
upstream where incompatible api or abi are used. And it widely depends on
which package you're looking at. For example glibc is very stable (thanks

No it is not, but this does not mean that Fedora could not or should not
address it. Since this distribution is touching the cutting-edge Linux
solutions, it could steer the community to focus more on architectural
design which could bring more benefits than binning backwards
compatibility to support the latest driver hack (just an example).

[Rahul Sundaram]

Post by Mauro Mozzarelli

Post by Patrice Dumas
I think that this issue is not specific of fedora. The issue comes from
upstream where incompatible api or abi are used. And it widely depends on
which package you're looking at. For example glibc is very stable (thanks

No it is not, but this does not mean that Fedora could not or should not
address it.

Trying to shoehorn a ABI or API policy within Fedora would take a large
amount of work without upstream involved in the decisions.

Post by Mauro Mozzarelli
Since this distribution is touching the cutting-edge Linux
solutions, it could steer the community to focus more on architectural
design which could bring more benefits than binning backwards
compatibility to support the latest driver hack (just an example).

Concentrate and help fix problems on the individual projects instead of
drawing out grandiose plans.

[Rahul Sundaram]

Post by Mauro Mozzarelli

Post by Patrice Dumas
I think that this issue is not specific of fedora. The issue comes from
upstream where incompatible api or abi are used. And it widely depends on
which package you're looking at. For example glibc is very stable (thanks

No it is not, but this does not mean that Fedora could not or should not
address it.

Trying to shoehorn a ABI or API policy within Fedora would take a large
amount of work without upstream involved in the decisions.

Post by Mauro Mozzarelli
Since this distribution is touching the cutting-edge Linux
solutions, it could steer the community to focus more on architectural
design which could bring more benefits than binning backwards
compatibility to support the latest driver hack (just an example).

Concentrate and help fix problems on the individual projects instead of
drawing out grandiose plans.

[Mauro Mozzarelli]

Post by Patrice Dumas
I think that this issue is not specific of fedora. The issue comes from
upstream where incompatible api or abi are used. And it widely depends on
which package you're looking at. For example glibc is very stable (thanks

No it is not, but this does not mean that Fedora could not or should not
address it. Since this distribution is touching the cutting-edge Linux
solutions, it could steer the community to focus more on architectural
design which could bring more benefits than binning backwards
compatibility to support the latest driver hack (just an example).

[Arjan van de Ven]

Post by Kaimano
Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.

but now you're contradicting yourself a bit: First you want to use the
most bleeding edge stuff, and now it's about running old stuff.

You can argue perhaps "but if compat is 100% then I can always just drop
in latest", but that's not realistic in the light of the "different
bugs" argument.

[Mike A. Harris]

Post by Kaimano
I hope not. The point of Linux is freedom and independence, not being just
"free". On the contrary, personally I spent more with Linux (if I value my
time) than with any other OS I used.
Anyway, I would like to focus more on the way we can improve it, starting
from taking a step back and looking at the core architecture.
The package inter-dependency at "RELEASE" level is killing it.

That's kindof funny. ;o) If this is something "killing it" as you
say, then why are the number of people using Linux greater right now
than at any previous time? Why are more and more people/companies
utilizing Linux for more and more jobs/tasks every day? Why are many
people/companies completely migrating away from other operating systems
such as proprietary UNICES, Windows, and other platforms to Linux now
more than ever before?

What specific signs do you have, which unconditionally show the
problem you have put forth, to be directly responsible for "killing
it" so to speak? I see no signs of people stopping using Fedora Core
or any other Linux distribution which backs up such a claim.

In reality, more and more people/companies/etc. are using Linux every
day, and that is more likely to increase if anything than to ever
decrease.

I see no "killing it" happening, unless by "it" you mean something other
than Fedora Core or Linux in general, as neither are dying by a long
shot.

[Mauro Mozzarelli]

Post by Mike A. Harris

Post by Kaimano
The package inter-dependency at "RELEASE" level is killing it.

That's kindof funny. ;o) If this is something "killing it" as you
say, then why are the number of people using Linux greater right now
than at any previous time? Why are more and more people/companies

I think that this phrase might have been mis-interpreted, "killing it"
here is meant as making it overly complicated; a fudge without plan, that
is hard to maintain. Of course the end users do not see that, but we are
not in an end-user mailing list.

The concerns are about spending more time for planning and design in order
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

[Rahul Sundaram]

Post by Mauro Mozzarelli

Post by Mike A. Harris

Post by Kaimano
The package inter-dependency at "RELEASE" level is killing it.

That's kindof funny. ;o) If this is something "killing it" as you
say, then why are the number of people using Linux greater right now
than at any previous time? Why are more and more people/companies

I think that this phrase might have been mis-interpreted, "killing it"
here is meant as making it overly complicated; a fudge without plan, that
is hard to maintain. Of course the end users do not see that, but we are
not in an end-user mailing list.

Killing it is a unnecessary dramatic phrase prone to various
interpretations.

Post by Mauro Mozzarelli
The concerns are about spending more time for planning and design in order
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

How are you willing to help?

[Benjy Grogan]

Post by Rahul Sundaram

Post by Mauro Mozzarelli
The concerns are about spending more time for planning and design in

order

Post by Mauro Mozzarelli
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

How are you willing to help?

I think this is the most interesting thing about open source. How do people
get involved in open source projects? It would be great to hear some of the
stories. I'm sure there are many more people out there who would like to
help and have the technical wherewithal to help but simply can't find a way
to get started.

I'd like to hear about people who in the last two or three years got
involved in a certain project. I realize there are those who have been
around for ten or more years and actually started some of the projects. But
how are newcomers helping out in software development?

Benji
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20060220/70f907fd/attachment.html

[Rudolf Kastl]

Post by Benjy Grogan

Post by Rahul Sundaram

Post by Mauro Mozzarelli
The concerns are about spending more time for planning and design in

order

Post by Rahul Sundaram

Post by Mauro Mozzarelli
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

How are you willing to help?

I think this is the most interesting thing about open source. How do people
get involved in open source projects? It would be great to hear some of the
stories. I'm sure there are many more people out there who would like to
help and have the technical wherewithal to help but simply can't find a way
to get started.
I'd like to hear about people who in the last two or three years got
involved in a certain project. I realize there are those who have been
around for ten or more years and actually started some of the projects. But
how are newcomers helping out in software development?

This is a fedora unspecific list of things you can do to get there:

1. getting involved as developer:
grab cvs of <insert_application_or_library_here>.

fix up compile errors/compiler warnings...

diff -u oldfile newfile > patchfile

and then email the patch to the upstream author ;))

-> you are involved ;)


2. getting involved as non programmer:

2.1 translating applications -> look for localisation projects etc or
just grab an app and translate it. tools are available.
2.2 documentation -> write good documentation covering certain topics
of interest
2.3 artwork -> make nice artwork (themes, 3d models, textures etc) for
already existing projects (app themes, games, etc) and submit it
upstream or publish it yourself while licensing it under a free
license ;)
2.4 sound -> create desktop sounds, startup sounds, notifications
sounds, oss game sfx/music) and send it upstream or publish it
yourself under a free license.
2.5 submit good feedback to upstream developers (note: sounds easier than it is)

regards,
rudolf kastl


----> to get involved all you have to do is actually _do_ something.

Post by Benjy Grogan
Benji
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Rudolf Kastl]

Post by Benjy Grogan

Post by Rahul Sundaram

Post by Mauro Mozzarelli
The concerns are about spending more time for planning and design in

order

Post by Rahul Sundaram

Post by Mauro Mozzarelli
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

How are you willing to help?

I think this is the most interesting thing about open source. How do people
get involved in open source projects? It would be great to hear some of the
stories. I'm sure there are many more people out there who would like to
help and have the technical wherewithal to help but simply can't find a way
to get started.
I'd like to hear about people who in the last two or three years got
involved in a certain project. I realize there are those who have been
around for ten or more years and actually started some of the projects. But
how are newcomers helping out in software development?

This is a fedora unspecific list of things you can do to get there:

1. getting involved as developer:
grab cvs of <insert_application_or_library_here>.

fix up compile errors/compiler warnings...

diff -u oldfile newfile > patchfile

and then email the patch to the upstream author ;))

-> you are involved ;)


2. getting involved as non programmer:

2.1 translating applications -> look for localisation projects etc or
just grab an app and translate it. tools are available.
2.2 documentation -> write good documentation covering certain topics
of interest
2.3 artwork -> make nice artwork (themes, 3d models, textures etc) for
already existing projects (app themes, games, etc) and submit it
upstream or publish it yourself while licensing it under a free
license ;)
2.4 sound -> create desktop sounds, startup sounds, notifications
sounds, oss game sfx/music) and send it upstream or publish it
yourself under a free license.
2.5 submit good feedback to upstream developers (note: sounds easier than it is)

regards,
rudolf kastl


----> to get involved all you have to do is actually _do_ something.

Post by Benjy Grogan
Benji
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Benjy Grogan]

Post by Rahul Sundaram

Post by Mauro Mozzarelli
The concerns are about spending more time for planning and design in

order

Post by Mauro Mozzarelli
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

How are you willing to help?

I think this is the most interesting thing about open source. How do people
get involved in open source projects? It would be great to hear some of the
stories. I'm sure there are many more people out there who would like to
help and have the technical wherewithal to help but simply can't find a way
to get started.

I'd like to hear about people who in the last two or three years got
involved in a certain project. I realize there are those who have been
around for ten or more years and actually started some of the projects. But
how are newcomers helping out in software development?

Benji
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20060220/70f907fd/attachment-0002.html

[Rahul Sundaram]

Post by Mauro Mozzarelli

Post by Mike A. Harris

Post by Kaimano
The package inter-dependency at "RELEASE" level is killing it.

That's kindof funny. ;o) If this is something "killing it" as you
say, then why are the number of people using Linux greater right now
than at any previous time? Why are more and more people/companies

I think that this phrase might have been mis-interpreted, "killing it"
here is meant as making it overly complicated; a fudge without plan, that
is hard to maintain. Of course the end users do not see that, but we are
not in an end-user mailing list.

Killing it is a unnecessary dramatic phrase prone to various
interpretations.

Post by Mauro Mozzarelli
The concerns are about spending more time for planning and design in order
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

How are you willing to help?

[Mauro Mozzarelli]

Post by Mike A. Harris

Post by Kaimano
The package inter-dependency at "RELEASE" level is killing it.

That's kindof funny. ;o) If this is something "killing it" as you
say, then why are the number of people using Linux greater right now
than at any previous time? Why are more and more people/companies

I think that this phrase might have been mis-interpreted, "killing it"
here is meant as making it overly complicated; a fudge without plan, that
is hard to maintain. Of course the end users do not see that, but we are
not in an end-user mailing list.

The concerns are about spending more time for planning and design in order
to move towards a really open platform, otherwise the risk is to end up
with an open source so complicated to maintain that it would not make any
difference if it was proprietary and secret.

[sean]

On Mon, 20 Feb 2006 11:56:07 -0000 (GMT)

Post by Kaimano
I hope not. The point of Linux is freedom and independence, not being just
"free". On the contrary, personally I spent more with Linux (if I value my
time) than with any other OS I used.

To be realistic, Linux is still essentially in early public beta mode (at
best) in regard to the desktop. Eventually the churn will slow down, but
not until a fair bit more development is done. Expectations of Linux
desktop users need to be set appropriately. Hand wringing about the
current state of affairs ignores the fact that massive amounts of energy
are being poured into making it better.

Post by Kaimano
Anyway, I would like to focus more on the way we can improve it, starting
from taking a step back and looking at the core architecture.
The package inter-dependency at "RELEASE" level is killing it.

There is no evidence that Linux is dying.

Post by Kaimano
Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.
Too much is now changed from release to release only because of the lack
of proper planning and design of the interfaces.

There is no practical way to demand, force, cajole, or beg everyone who
contributes to the evolution of Linux to conform to some grand roadmap or
to always maintain backward compatibility. Even if there were, it would
just create a different set of tradeoffs from the ones we have today.

Linux isn't a panacea, it's just the best choice you have if you value freedom.
For your needs today you might want to consider using long-lived distributions
such as RHEL that guarantee compatability for five or more years so that you
can be sure you don't need to reinstall. But there are other tradeoffs you
must make if you go down that road.

Sean

[Patrice Dumas]

Post by Kaimano
The package inter-dependency at "RELEASE" level is killing it.
Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.
Too much is now changed from release to release only because of the lack
of proper planning and design of the interfaces.

I think that this issue is not specific of fedora. The issue comes from
upstream where incompatible api or abi are used. And it widely depends on
which package you're looking at. For example glibc is very stable (thanks
to proper use of library versionning), while recently (if I'm not wrong)
gcc has been breaking binary compatibility quite a lot in g++. Other
libraries may benefit from using library versionning (motif comes to my
mind), but it isn't a fedora issue.

Breaking api/abi isn't necessarily bad, as it allows to move on. Fedora
doesn't avoid those changes as the aim of fedora is to use the newest
technologies.

If you want to use stable platforms, there are RHEL and its clones, or
the debian stable, but then you won't be able to upgrade to newest
application versions if the upstream doesn't allow it.

To state it otherwise, if you want improvements in the stability of free
software, then you'll have to help each of the project libraries that don't
have a stable api/abi, but fedora uses what exists and is the most recent.

--
Pat

[Arjan van de Ven]

Post by Kaimano
Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.

but now you're contradicting yourself a bit: First you want to use the
most bleeding edge stuff, and now it's about running old stuff.

You can argue perhaps "but if compat is 100% then I can always just drop
in latest", but that's not realistic in the light of the "different
bugs" argument.

[Mike A. Harris]

Post by Kaimano
I hope not. The point of Linux is freedom and independence, not being just
"free". On the contrary, personally I spent more with Linux (if I value my
time) than with any other OS I used.
Anyway, I would like to focus more on the way we can improve it, starting
from taking a step back and looking at the core architecture.
The package inter-dependency at "RELEASE" level is killing it.

That's kindof funny. ;o) If this is something "killing it" as you
say, then why are the number of people using Linux greater right now
than at any previous time? Why are more and more people/companies
utilizing Linux for more and more jobs/tasks every day? Why are many
people/companies completely migrating away from other operating systems
such as proprietary UNICES, Windows, and other platforms to Linux now
more than ever before?

What specific signs do you have, which unconditionally show the
problem you have put forth, to be directly responsible for "killing
it" so to speak? I see no signs of people stopping using Fedora Core
or any other Linux distribution which backs up such a claim.

In reality, more and more people/companies/etc. are using Linux every
day, and that is more likely to increase if anything than to ever
decrease.

I see no "killing it" happening, unless by "it" you mean something other
than Fedora Core or Linux in general, as neither are dying by a long
shot.

[sean]

On Mon, 20 Feb 2006 11:56:07 -0000 (GMT)

Post by Kaimano
I hope not. The point of Linux is freedom and independence, not being just
"free". On the contrary, personally I spent more with Linux (if I value my
time) than with any other OS I used.

To be realistic, Linux is still essentially in early public beta mode (at
best) in regard to the desktop. Eventually the churn will slow down, but
not until a fair bit more development is done. Expectations of Linux
desktop users need to be set appropriately. Hand wringing about the
current state of affairs ignores the fact that massive amounts of energy
are being poured into making it better.

Post by Kaimano
Anyway, I would like to focus more on the way we can improve it, starting
from taking a step back and looking at the core architecture.
The package inter-dependency at "RELEASE" level is killing it.

There is no evidence that Linux is dying.

Post by Kaimano
Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.
Too much is now changed from release to release only because of the lack
of proper planning and design of the interfaces.

There is no practical way to demand, force, cajole, or beg everyone who
contributes to the evolution of Linux to conform to some grand roadmap or
to always maintain backward compatibility. Even if there were, it would
just create a different set of tradeoffs from the ones we have today.

Linux isn't a panacea, it's just the best choice you have if you value freedom.
For your needs today you might want to consider using long-lived distributions
such as RHEL that guarantee compatability for five or more years so that you
can be sure you don't need to reinstall. But there are other tradeoffs you
must make if you go down that road.

Sean

[Felipe Alfaro Solana]

Post by Erwin Rol
but, but, than you have pay money, and we just switched to Linux
because everything is gratis ;-)

I switched to Linux because of the freedom it gives to me, not only
because it is gratis. You can also have a "gratis" version of any
pirated software.

[Arjan van de Ven]

Post by Felipe Alfaro Solana

Post by Erwin Rol
but, but, than you have pay money, and we just switched to Linux
because everything is gratis ;-)

I switched to Linux because of the freedom it gives to me, not only
because it is gratis. You can also have a "gratis" version of any
pirated software.

sigh... so this goes waaay off to an irrelevant tangent. My point was
that having a bug isn't a valid reason to upgrade to a major new version
(and all the dependency hell that that generates). The more right
solution is to fix the bug if it's important enough.

[Callum Lerwick]

Post by Arjan van de Ven

Post by Felipe Alfaro Solana

Post by Erwin Rol
but, but, than you have pay money, and we just switched to Linux
because everything is gratis ;-)

I switched to Linux because of the freedom it gives to me, not only
because it is gratis. You can also have a "gratis" version of any
pirated software.

sigh... so this goes waaay off to an irrelevant tangent. My point was
that having a bug isn't a valid reason to upgrade to a major new version
(and all the dependency hell that that generates). The more right
solution is to fix the bug if it's important enough.

If that's what you want, go use Debian stable and leave us alone plz kthx.

[Callum Lerwick]

Post by Arjan van de Ven

Post by Felipe Alfaro Solana

Post by Erwin Rol
but, but, than you have pay money, and we just switched to Linux
because everything is gratis ;-)

I switched to Linux because of the freedom it gives to me, not only
because it is gratis. You can also have a "gratis" version of any
pirated software.

sigh... so this goes waaay off to an irrelevant tangent. My point was
that having a bug isn't a valid reason to upgrade to a major new version
(and all the dependency hell that that generates). The more right
solution is to fix the bug if it's important enough.

If that's what you want, go use Debian stable and leave us alone plz kthx.

[Arjan van de Ven]

Post by Felipe Alfaro Solana

Post by Erwin Rol
but, but, than you have pay money, and we just switched to Linux
because everything is gratis ;-)

I switched to Linux because of the freedom it gives to me, not only
because it is gratis. You can also have a "gratis" version of any
pirated software.

sigh... so this goes waaay off to an irrelevant tangent. My point was
that having a bug isn't a valid reason to upgrade to a major new version
(and all the dependency hell that that generates). The more right
solution is to fix the bug if it's important enough.

[Rahul Sundaram]

Post by Erwin Rol

Post by Arjan van de Ven

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

but, but, than you have pay money, and we just switched to Linux because
everything is gratis ;-)

Could be gratis if the source is available under a appropriate license
and you have the resources and time to do it yourself. On many occasions
your expertise is not operating system development or more specifically
not backporting Evolution bug fixes and it works out cheaper to pay a
vendor.

[Kaimano]

Post by Erwin Rol

Post by Kaimano

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on

evolution

Post by Kaimano
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

but, but, than you have pay money, and we just switched to Linux because
everything is gratis ;-)

I hope not. The point of Linux is freedom and independence, not being just
"free". On the contrary, personally I spent more with Linux (if I value my
time) than with any other OS I used.

Anyway, I would like to focus more on the way we can improve it, starting
from taking a step back and looking at the core architecture.

The package inter-dependency at "RELEASE" level is killing it.

Ideally I would start thinking of a real multi-tiered solution with a
clear separation of concerns, and the establishment of core APIs which
first priority should be to maintain the compatibility with previous
releases.
Too much is now changed from release to release only because of the lack
of proper planning and design of the interfaces.

--
Mauro M.

[Felipe Alfaro Solana]

Post by Erwin Rol
but, but, than you have pay money, and we just switched to Linux
because everything is gratis ;-)

I switched to Linux because of the freedom it gives to me, not only
because it is gratis. You can also have a "gratis" version of any
pirated software.

[Thomas M Steenholdt]

Post by Arjan van de Ven

Post by Kaimano
2)
to be able to upgrade the applications I most use without having to
re-install the operating system

that's a hard one, see below
\

Post by Kaimano
firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk
about evolution 2.4 openoffice and KDE just to name some. The dependencies
on a miriad of packages make the effort ridicolously hard.

If you want to use newer version of packages, there are normally no
problems in doing so - The usual problem lies in the fact that the
RAWHIDE packages are intended for newer core packages and components.

You brought firefox 1.5 up, so let me use that as a simple example to
illustrate my point.

It's not possible to build the rawhide firefox packages on FC4, because
they are MADE to REQUIRE cairo, which is not included in FC4.

This does not mean that you cannot run firefox on FC4, though, you just
need a) firefox packages that does not require cairo or b) cairo
installed on your system.

Check out nrpms.net - there are updated gnome/firefox/xx packages
available for FC4 that you can upgrade most of your operating system
without reinstalling.

I'm currently running firefox 1.5.0.1 without cairo with great success
on FC4.

So what you need is a third party repository that give you the updated
(not just security patched) versions of your core components... For most
production (enterprise style) systems this is a bad idea, which is why i
don't think we should ever expect this from a serious distro that should
be usable in those places too.

Hope this helps

/Thomas

[Erwin Rol]

Post by Arjan van de Ven

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

but, but, than you have pay money, and we just switched to Linux because
everything is gratis ;-)

- Erwin

[Thomas M Steenholdt]

Post by Arjan van de Ven

Post by Kaimano
2)
to be able to upgrade the applications I most use without having to
re-install the operating system

that's a hard one, see below
\

Post by Kaimano
firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk
about evolution 2.4 openoffice and KDE just to name some. The dependencies
on a miriad of packages make the effort ridicolously hard.

If you want to use newer version of packages, there are normally no
problems in doing so - The usual problem lies in the fact that the
RAWHIDE packages are intended for newer core packages and components.

You brought firefox 1.5 up, so let me use that as a simple example to
illustrate my point.

It's not possible to build the rawhide firefox packages on FC4, because
they are MADE to REQUIRE cairo, which is not included in FC4.

This does not mean that you cannot run firefox on FC4, though, you just
need a) firefox packages that does not require cairo or b) cairo
installed on your system.

Check out nrpms.net - there are updated gnome/firefox/xx packages
available for FC4 that you can upgrade most of your operating system
without reinstalling.

I'm currently running firefox 1.5.0.1 without cairo with great success
on FC4.

So what you need is a third party repository that give you the updated
(not just security patched) versions of your core components... For most
production (enterprise style) systems this is a bad idea, which is why i
don't think we should ever expect this from a serious distro that should
be usable in those places too.

Hope this helps

/Thomas

[Mauro Mozzarelli]

Rahul,

Post by Rahul Sundaram
Killing it is a unnecessary dramatic phrase prone to various
interpretations.

Please forgive my english that is not my first language and I started
learning it serioulsy only in my late 30s.

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start.
This is a task that requires influencing, management and enterprise
architecture skills other than time. It must be a team work to succeed. Is
there a team that I could join? Would a team have to be formed?

[Rahul Sundaram]

Hi

Post by Mauro Mozzarelli

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start.
This is a task that requires influencing, management and enterprise
architecture skills other than time. It must be a team work to succeed. Is
there a team that I could join? Would a team have to be formed?

I hear a lot of buzzwords. If it requires forming a whole new team you
need to identify specific set of issues and a action plan in which you
can define your own work without getting a lot of other people involved
and then start working on that. If its a good plan and it shows up as
such on your work, I am sure others can get involved.

[Rik van Riel]

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start. This is a
task that requires influencing, management and enterprise architecture
skills other than time. It must be a team work to succeed. Is there a
team that I could join? Would a team have to be formed?

I think the first step would be to describe the problem in
more concrete terms. Actual problems that could be addressed,
instead of vague generalizations that could apply to anything.

Having concrete goals would be good, too.

If the goals and the problem description are interesting and
deemed realistic, then I'm sure developers would join your
effort.

[Mauro Mozzarelli]

Post by Rik van Riel
I think the first step would be to describe the problem in
more concrete terms. Actual problems that could be addressed,
instead of vague generalizations that could apply to anything.
Having concrete goals would be good, too.
If the goals and the problem description are interesting and
deemed realistic, then I'm sure developers would join your
effort.

Here is an outline (anyone is welcome to reviewing it):

Main goal: to build a portable OS platform that allows for application
inter-operability and flexibility in the interchange of core indentifiable
components

Principles:
1) a component can be replaced without impact on other components
2) components' interoperability is defined by a contract (API) that
although can be extended, it cannot change the rules established in
previous baselines.

Main tasks:
1) to identify the core components
2) to identify independently repleceable groups of packages
4) to isolate the core components in replaceable units
5) to influence the development of critical software libraries and
components as services with a defined API that supports backwards
compatibility

This project requires the cooperation of the following roles:
1) OS architects
2) Packagers
3) package designers/developers


TASK 1: to identify core components
Key roles: all

This is a task that could be carried out by everyone through a
proposal/review process. The scope is to identify those components that we
would like to be able to replace (either new releases of the same
component or a different competing component) without impacting on the
integrity of the rest of the system. Core components can be product
suites, like desktop managers, vital libraries like "cairo" or
applications like openoffice.

An example could be:

Xorg
KDE
GNOME
cairo
Openoffice
Firefox
Mozilla
Apache
Java JVM/JDK
gcc
glibc

TASK 2: to identify independently repleceable groups of packages
key roles: packagers

Translating in real terms:
At the base of the success of this project is the cooperation between a
number of different roles that at present might not be happening. An
example could be the packager that takes care of building an "rpm" but is
not involved in the development and design of the packaged component.
The packager in this case would see a shift of his responsibilities from
passive package maker to architect and influencer, feeding specific OS
requirements to the components' designers.

Having that as our goal, we can start with this task that could be carried
out by the packager(s) alone.

The aim is to place the core components identified in TASK 1 in packages
groups.

Definition of package group: those packages that are dependent on each
other at release level and the replacement of one of them has an impact
on(requires the replacement of) one of more of the other packages in the
group.

We can expect that at present we will be able to identify several
intersecting (overlapping) package groups.

The completion of this task will add the following value:

1) to achieve a better understanding of the extent of the problem
2) to allow for an initial identification of packages in groups that if
replaced at once do not have an impact on the rest of the system, thus
enabling their replacement with newer or different groups.

TASK 3 - to isolate the core components in replaceable units
Key roles: OS architects, packagers, package analysts/developers

This is the task where we make significant changes to happen, and really
requires the buy in of all of the key roles.

If we are serious about this project, I propose to get a wiki
page/section, so that we can build and review this and more of the
documentation that we will require, keeping this mailing list as the
communication channel.

Please let me have your comments as soon as possible.

[sean]

On Tue, 21 Feb 2006 14:59:38 -0000 (GMT)

Post by Mauro Mozzarelli
Main goal: to build a portable OS platform that allows for application
inter-operability and flexibility in the interchange of core indentifiable
components
1) a component can be replaced without impact on other components
2) components' interoperability is defined by a contract (API) that
although can be extended, it cannot change the rules established in
previous baselines.
1) to identify the core components
2) to identify independently repleceable groups of packages
4) to isolate the core components in replaceable units
5) to influence the development of critical software libraries and
components as services with a defined API that supports backwards
compatibility

Traditionally the way this is done is to extract common elements into
a library and there are already a fair number of such libraries
provided by Fedora. I guess you're saying that there should be more.
Can you give one concrete example of code that should be pulled out
of some application and put into a library?

Once you've identified the first such oportunity you'll have a better
chance of attracting people who are interested in the specific example
you put forward.

Sean

[sean]

On Tue, 21 Feb 2006 14:59:38 -0000 (GMT)

Post by Mauro Mozzarelli
Main goal: to build a portable OS platform that allows for application
inter-operability and flexibility in the interchange of core indentifiable
components
1) a component can be replaced without impact on other components
2) components' interoperability is defined by a contract (API) that
although can be extended, it cannot change the rules established in
previous baselines.
1) to identify the core components
2) to identify independently repleceable groups of packages
4) to isolate the core components in replaceable units
5) to influence the development of critical software libraries and
components as services with a defined API that supports backwards
compatibility

Traditionally the way this is done is to extract common elements into
a library and there are already a fair number of such libraries
provided by Fedora. I guess you're saying that there should be more.
Can you give one concrete example of code that should be pulled out
of some application and put into a library?

Once you've identified the first such oportunity you'll have a better
chance of attracting people who are interested in the specific example
you put forward.

Sean

[Mauro Mozzarelli]

Post by Rik van Riel
I think the first step would be to describe the problem in
more concrete terms. Actual problems that could be addressed,
instead of vague generalizations that could apply to anything.
Having concrete goals would be good, too.
If the goals and the problem description are interesting and
deemed realistic, then I'm sure developers would join your
effort.

Here is an outline (anyone is welcome to reviewing it):

Main goal: to build a portable OS platform that allows for application
inter-operability and flexibility in the interchange of core indentifiable
components

Principles:
1) a component can be replaced without impact on other components
2) components' interoperability is defined by a contract (API) that
although can be extended, it cannot change the rules established in
previous baselines.

Main tasks:
1) to identify the core components
2) to identify independently repleceable groups of packages
4) to isolate the core components in replaceable units
5) to influence the development of critical software libraries and
components as services with a defined API that supports backwards
compatibility

This project requires the cooperation of the following roles:
1) OS architects
2) Packagers
3) package designers/developers


TASK 1: to identify core components
Key roles: all

This is a task that could be carried out by everyone through a
proposal/review process. The scope is to identify those components that we
would like to be able to replace (either new releases of the same
component or a different competing component) without impacting on the
integrity of the rest of the system. Core components can be product
suites, like desktop managers, vital libraries like "cairo" or
applications like openoffice.

An example could be:

Xorg
KDE
GNOME
cairo
Openoffice
Firefox
Mozilla
Apache
Java JVM/JDK
gcc
glibc

TASK 2: to identify independently repleceable groups of packages
key roles: packagers

Translating in real terms:
At the base of the success of this project is the cooperation between a
number of different roles that at present might not be happening. An
example could be the packager that takes care of building an "rpm" but is
not involved in the development and design of the packaged component.
The packager in this case would see a shift of his responsibilities from
passive package maker to architect and influencer, feeding specific OS
requirements to the components' designers.

Having that as our goal, we can start with this task that could be carried
out by the packager(s) alone.

The aim is to place the core components identified in TASK 1 in packages
groups.

Definition of package group: those packages that are dependent on each
other at release level and the replacement of one of them has an impact
on(requires the replacement of) one of more of the other packages in the
group.

We can expect that at present we will be able to identify several
intersecting (overlapping) package groups.

The completion of this task will add the following value:

1) to achieve a better understanding of the extent of the problem
2) to allow for an initial identification of packages in groups that if
replaced at once do not have an impact on the rest of the system, thus
enabling their replacement with newer or different groups.

TASK 3 - to isolate the core components in replaceable units
Key roles: OS architects, packagers, package analysts/developers

This is the task where we make significant changes to happen, and really
requires the buy in of all of the key roles.

If we are serious about this project, I propose to get a wiki
page/section, so that we can build and review this and more of the
documentation that we will require, keeping this mailing list as the
communication channel.

Please let me have your comments as soon as possible.

[Patrice Dumas]

Post by Mauro Mozzarelli

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start.
This is a task that requires influencing, management and enterprise
architecture skills other than time. It must be a team work to succeed. Is
there a team that I could join? Would a team have to be formed?

As allready said, what needs to be influenced are the individual projects.
There is nothing like a team that tries to help keep api and abi stable
for all the projects and it is dubious that forming one would make sense.

If you find that some library has a stable binary interface that is kept
across versions and is used by most applications, and is mixed with a
changing interface, then you could help by providing library version
scripts to these libraries. This could potentially solve the api/abi
change issue. As I said allready this would, for example benefit to
openmotf/lesstif, because most apps compiled against openmotif use a
stable subset of the api/abi. But openmotif isn't even free software,
so...

Here are sources of information, with the relevant part of the ld manual:

http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html#SEC25

A generic resource I found on that subject:

http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/

There are many other sources of incompatibility than abi/api changes,
but abi/apip changes seemed to be on your list.

--
Pat

[Ralf Corsepius]

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed
source until several years ago, but times are a-changing:

# rpm -q --qf '%{LICENSE}\n' openmotif
Open Group Public License

And lesstif, meanwhile is more or less without any practical importance,
anymore (It's not even part of FC or FE anymore)

Ralf

[Alan Cox]

Post by Ralf Corsepius

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed

OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

[Ralf Corsepius]

Post by Alan Cox

Post by Ralf Corsepius

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed

OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

Ralf

[Alan Cox]

Post by Ralf Corsepius

Post by Alan Cox
OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

I asked the open group long ago and the email reply I got was to the contrary

[Ralf Corsepius]

Post by Alan Cox

Post by Ralf Corsepius

Post by Alan Cox
OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

I asked the open group long ago and the email reply I got was to the contrary

Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.

Also,
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.
* closed source kernel drivers are in existence for quite some time,
some are even being shipped by some Linux vendors, but I've never heard
the OpenGroup trying to enforce the interpretation of their license you
outline.

Furthermore, IIRC, their license originally was intended to prevent
using OpenMotif on "traditional *nixes" which ship with closed source
implementations/derivatives of the old OSF-Motif.

What concerns me much more on Fedora and Linux is OpenMotif's license
not to being [L]GPL compatible.

Ralf

[Patrice Dumas]

Post by Ralf Corsepius
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.

Yep, but in the previous question they explain that the licence isn't
allready OSI compatible:

QUESTION:

Does the Open Group Public License for Motif meet the Open Source Guidelines?

ANSWER:

No. The Open Group Public License for Motif grants rights only to use the software on or with operating systems that are themselves Open Source programs. In restricting the applicability of the license to Open Source platforms this does not meet term 8 of the Open Software Definition (http://www.opensource.org/osd.html).

Post by Ralf Corsepius
What concerns me much more on Fedora and Linux is OpenMotif's license
not to being [L]GPL compatible.

That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence
but is shipped as shared libs.

--
Pat

[Ralf Corsepius]

Post by Patrice Dumas

Post by Ralf Corsepius
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.

Yep, but in the previous question they explain that the licence isn't

They clearly expressed their intention, and thereby significantly weaken
their written license. In front of a German they would be facing very
difficult times because of this.

Post by Patrice Dumas

Post by Ralf Corsepius
What concerns me much more on Fedora and Linux is OpenMotif's license
not to being [L]GPL compatible.

That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence
but is shipped as shared libs.

The GPL doesn't allow this, the LGPL does.

Ralf

[Patrice Dumas]

Post by Ralf Corsepius

Post by Patrice Dumas
That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence
but is shipped as shared libs.

The GPL doesn't allow this, the LGPL does.

What I did understand is that you can dynamically link a GPL code with
a GPL incompatible code, as long as it is the GPL app which is a derived
work of the library and not the reverse. So, for example, you can link
a GPL app against a proprietary libc. So it should be possible to link
GPL apps (or even libraries) against non GPL libraries.

You can not bundle the GPL app and the proprietary lib together however. I
think that bundling together is a matter of interpretation, but what I
have understood, for example is that they cannot be in the same tarball
nor in the same srpm, but they can be in different tarballs on a CD.

--
Pat

[Patrice Dumas]

Post by Ralf Corsepius

Post by Patrice Dumas
That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence
but is shipped as shared libs.

The GPL doesn't allow this, the LGPL does.

What I did understand is that you can dynamically link a GPL code with
a GPL incompatible code, as long as it is the GPL app which is a derived
work of the library and not the reverse. So, for example, you can link
a GPL app against a proprietary libc. So it should be possible to link
GPL apps (or even libraries) against non GPL libraries.

You can not bundle the GPL app and the proprietary lib together however. I
think that bundling together is a matter of interpretation, but what I
have understood, for example is that they cannot be in the same tarball
nor in the same srpm, but they can be in different tarballs on a CD.

--
Pat

[Ralf Corsepius]

Post by Patrice Dumas

Post by Ralf Corsepius
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.

Yep, but in the previous question they explain that the licence isn't

They clearly expressed their intention, and thereby significantly weaken
their written license. In front of a German they would be facing very
difficult times because of this.

Post by Patrice Dumas

Post by Ralf Corsepius
What concerns me much more on Fedora and Linux is OpenMotif's license
not to being [L]GPL compatible.

That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence
but is shipped as shared libs.

The GPL doesn't allow this, the LGPL does.

Ralf

[Alan Cox]

Post by Ralf Corsepius
Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.

It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

Post by Ralf Corsepius
Furthermore, IIRC, their license originally was intended to prevent
using OpenMotif on "traditional *nixes" which ship with closed source
implementations/derivatives of the old OSF-Motif.

I'm just reporting what I was told at the time.

[Jeff Spaleta]

Post by Alan Cox
It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

tetex-xdvi and xpdf

I can not support dropping tetex-xdvi until the fedora packages of
evince turn on the dvi support, which is still marked as
experiemental. I don't produce any dvi anymore thanks to pdflatex..
but fedora core still ships a number of dvi files as part of its own
packages and I think fedora needs to continue to ship a application
which can view those files. Until the fedora maintainers for evince
turns on the dvi support.. tetex-xdvi really needs to stay..which
means unfortunately that openmotif needs to stay.

Feel free to help me convince the evince maintainer to turn on the dvi
support in the Fedora evince package.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173514

-jef

[Patrice Dumas]

Post by Alan Cox

Post by Ralf Corsepius
Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.

It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

It isn't a good extra candidate, because of its licence... Or am I missing
something?

If it turns out that there is no licence issue, I do agree that it would
better be in extras than in core, once it doesn't have any dependencies in
core anymore.

--
Pat

[Joachim Frieben]

Post by Alan Cox
It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

Not that quickly, there are still several applications of general importance
in Fedora Core that use Open Motif:

- ddd GUI for several command-line debuggers,
- tetex-xdvi X viewer for DVI files,
- xpdf PDF file viewer for the X Window System.

"evince" is very slow and rendering is flaky, so even "xpdf" is not
dispensable yet. For the first two items there is no alternative around the
block, unless someone volunteers to port them to "GTK" in the short run.

JF

[Alan Cox]

Post by Joachim Frieben
- ddd GUI for several command-line debuggers,

Obscure and weird

Post by Joachim Frieben
- tetex-xdvi X viewer for DVI files,

Tex belongs in extras, all of it

Post by Joachim Frieben
- xpdf PDF file viewer for the X Window System.

Unusuably bad with most modern pdf files

Post by Joachim Frieben
"evince" is very slow and rendering is flaky, so even "xpdf" is not

Agreed, but kpdf is snappy and except for some nasty printing bugs with
rev 1.6 PDF works well

[Bill Nottingham]

Post by Alan Cox

Post by Joachim Frieben
- tetex-xdvi X viewer for DVI files,

Tex belongs in extras, all of it

This would blow up the entire build chain, though. :/

Bill

[Jeff Spaleta]

Post by Alan Cox
Tex belongs in extras, all of it

Please take a look at the other packages in Core which ship dvi files
as part of their documentation. Its not so simple as to say all of
tetex should be in extras. My concern is that other Core packages ship
dvi files and currently the only viewer in Core that I am aware of
with dvi file support is xdvi. I'd like to see that changed, so at
least tetex-xdvi could be dropped and thus one step closer to dropping
openmotif from Core.

I'd actually agree to move tetex to extras with if it were possible..
but I don't think you can move it wholesale out of core because of
buildrequires in other packages unless the selfhosting constraint on
Core is lifted or you are prepared to drop all documentation which is
generated via tetex as part of Core package build process for a number
of packages. Given the current constraints with regard to packaging
building, I very much doubt tetex will be moving to Core and I think
such a discussion is a non-starter. But I would encourage you to take
a look at the spec files in cvs which ask for latex as part of the
build process and assess how difficult it would be to re-engineer Core
packages so tetex could be moved to Core.


-jef

[Mathieu Chouquet-Stringer]

Post by Alan Cox

Post by Joachim Frieben
- xpdf PDF file viewer for the X Window System.

Unusuably bad with most modern pdf files

Allow me to disagree here, I can forward you quite a bunch of recent pdfs
evince can't read or just render the wrong way.

For example I've got the manual for a Canon camera that has a big "COPY"
sign in the background and that's the only thing evince renders (on all
pages).

[Rahul Sundaram]

Post by Mathieu Chouquet-Stringer

Post by Alan Cox

Post by Joachim Frieben
- xpdf PDF file viewer for the X Window System.

Unusuably bad with most modern pdf files

Allow me to disagree here, I can forward you quite a bunch of recent pdfs
evince can't read or just render the wrong way.
For example I've got the manual for a Canon camera that has a big "COPY"
sign in the background and that's the only thing evince renders (on all
pages).

I think developers in evince list was looking for such test cases.
http://mail.gnome.org/archives/evince-list/

[Alan Cox]

Post by Mathieu Chouquet-Stringer

Post by Alan Cox

Post by Joachim Frieben
- xpdf PDF file viewer for the X Window System.

Unusuably bad with most modern pdf files

Allow me to disagree here, I can forward you quite a bunch of recent pdfs
evince can't read or just render the wrong way.

I didn't say anything about evince, evince sucks too. I can give you pdfs
that xpdf takes a week to render and kdpf renders correctly in 2 seconds.

Post by Mathieu Chouquet-Stringer
For example I've got the manual for a Canon camera that has a big "COPY"
sign in the background and that's the only thing evince renders (on all
pages).

Evince/xpdf/gimp and also print (but not view) in kpdf all mess up pdf files
which contain images with transparent backgrounds for one, so no suprises.

[Rahul Sundaram]

Post by Alan Cox

Post by Mathieu Chouquet-Stringer

Post by Alan Cox

Post by Joachim Frieben
- xpdf PDF file viewer for the X Window System.

Unusuably bad with most modern pdf files

Allow me to disagree here, I can forward you quite a bunch of recent pdfs
evince can't read or just render the wrong way.

I didn't say anything about evince, evince sucks too. I can give you pdfs
that xpdf takes a week to render and kdpf renders correctly in 2 seconds.

Post by Mathieu Chouquet-Stringer
For example I've got the manual for a Canon camera that has a big "COPY"
sign in the background and that's the only thing evince renders (on all
pages).

Evince/xpdf/gimp and also print (but not view) in kpdf all mess up pdf files
which contain images with transparent backgrounds for one, so no suprises.

Curious how KPDF works on files better when Evince doesnt where both of
them use poppler as the underlying library.

[Mathieu Chouquet-Stringer]

Post by Alan Cox
I didn't say anything about evince, evince sucks too. I can give you pdfs
that xpdf takes a week to render and kdpf renders correctly in 2 seconds.

My bad I read your comment as "xpdf sucks more than evince", let's get rid
of it.

Post by Alan Cox
Evince/xpdf/gimp and also print (but not view) in kpdf all mess up pdf files
which contain images with transparent backgrounds for one, so no suprises.

Speaking of which, I can't seem to find kpdf on FC5T3, is it me or?

[Nicolas Mailhot]

Le mardi 21 f?vrier 2006 ? 18:29 +0100, Mathieu Chouquet-Stringer a

Post by Mathieu Chouquet-Stringer

Post by Alan Cox

Post by Joachim Frieben
- xpdf PDF file viewer for the X Window System.

Unusuably bad with most modern pdf files

Allow me to disagree here, I can forward you quite a bunch of recent pdfs
evince can't read or just render the wrong way.

Did you sent them to the evince people ?

I hit quite a few problem pdf when evince was first released. After
reporting them, everything was quickly fixed.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 199 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060221/b452e5ba/attachment.bin

[Alan Cox]

Post by Nicolas Mailhot

Post by Mathieu Chouquet-Stringer
Allow me to disagree here, I can forward you quite a bunch of recent pdfs
evince can't read or just render the wrong way.

Did you sent them to the evince people ?

I think our lawyers would be cross if I did as they are copyrighted material.

Post by Nicolas Mailhot
I hit quite a few problem pdf when evince was first released. After
reporting them, everything was quickly fixed.

www.scalescenes.com freebie building pdf is a good test (shows up the kpdf
print wrong/view right bug and wont load into gimp)

[Nicolas Mailhot]

Post by Alan Cox

Post by Nicolas Mailhot

Post by Mathieu Chouquet-Stringer
Allow me to disagree here, I can forward you quite a bunch of recent pdfs
evince can't read or just render the wrong way.

Did you sent them to the evince people ?

I think our lawyers would be cross if I did as they are copyrighted material.

Post by Nicolas Mailhot
I hit quite a few problem pdf when evince was first released. After
reporting them, everything was quickly fixed.

www.scalescenes.com freebie building pdf is a good test (shows up the kpdf
print wrong/view right bug and wont load into gimp)

Waiting Shelter R001 seems to render and print fine with rawhide evince
(apart from the usual "all the world is a Letter printer - let's f*-up
A4 borders" Gnome print bug)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 199 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060221/18a2f69a/attachment.bin

[Alan Cox]

Post by Nicolas Mailhot
Waiting Shelter R001 seems to render and print fine with rawhide evince
(apart from the usual "all the world is a Letter printer - let's f*-up
A4 borders" Gnome print bug)

Is the graffiti on a black background or on texture that is where the
previous one I tried broke - it should be on texture

[Nicolas Mailhot]

Post by Alan Cox

Post by Nicolas Mailhot
Waiting Shelter R001 seems to render and print fine with rawhide evince
(apart from the usual "all the world is a Letter printer - let's f*-up
A4 borders" Gnome print bug)

Is the graffiti on a black background or on texture that is where the
previous one I tried broke - it should be on texture

I'll check this evening

[Nicolas Mailhot]

Post by Alan Cox

Post by Nicolas Mailhot
Waiting Shelter R001 seems to render and print fine with rawhide evince
(apart from the usual "all the world is a Letter printer - let's f*-up
A4 borders" Gnome print bug)

Is the graffiti on a black background or on texture that is where the
previous one I tried broke - it should be on texture

Damn, you're right :(
-> http://bugzilla.gnome.org/show_bug.cgi?id=332222
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 199 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060222/4ee9eae5/attachment.bin

[Dennis Gilmore]

Post by Alan Cox
Agreed, but kpdf is snappy and except for some nasty printing bugs with
rev 1.6 PDF works well

except at the moment kpdf is not provided in kdegraphics

rpm -q --changelog kdegraphics
* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 7:3.5.1-2.1
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Than Ngo <than at redhat.com> 7:3.5.1-2
- apply patch to fix buffer overflow in kpdf, CVE-2006-0301 (#179425)
- apply patch to fix gcc warning (#169189)


doesnt show its removal but i guess that the patch is bad

[Florian La Roche]

Post by Dennis Gilmore

Post by Alan Cox
Agreed, but kpdf is snappy and except for some nasty printing bugs with
rev 1.6 PDF works well

except at the moment kpdf is not provided in kdegraphics
rpm -q --changelog kdegraphics
* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 7:3.5.1-2.1
- bump again for double-long bug on ppc(64)
* Tue Feb 07 2006 Than Ngo <than at redhat.com> 7:3.5.1-2
- apply patch to fix buffer overflow in kpdf, CVE-2006-0301 (#179425)
- apply patch to fix gcc warning (#169189)
doesnt show its removal but i guess that the patch is bad

Hello Dennis,

kpdf will be back, this is indeed a bad patch.

regards,

Florian La Roche

[Bill Nottingham]

Post by Alan Cox

Post by Joachim Frieben
- tetex-xdvi X viewer for DVI files,

Tex belongs in extras, all of it

This would blow up the entire build chain, though. :/

Bill

[Alan Cox]

Post by Joachim Frieben
- ddd GUI for several command-line debuggers,

Obscure and weird

Post by Joachim Frieben
- tetex-xdvi X viewer for DVI files,

Tex belongs in extras, all of it

Post by Joachim Frieben
- xpdf PDF file viewer for the X Window System.

Unusuably bad with most modern pdf files

Post by Joachim Frieben
"evince" is very slow and rendering is flaky, so even "xpdf" is not

Agreed, but kpdf is snappy and except for some nasty printing bugs with
rev 1.6 PDF works well

[Jeff Spaleta]

Post by Alan Cox
It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

tetex-xdvi and xpdf

I can not support dropping tetex-xdvi until the fedora packages of
evince turn on the dvi support, which is still marked as
experiemental. I don't produce any dvi anymore thanks to pdflatex..
but fedora core still ships a number of dvi files as part of its own
packages and I think fedora needs to continue to ship a application
which can view those files. Until the fedora maintainers for evince
turns on the dvi support.. tetex-xdvi really needs to stay..which
means unfortunately that openmotif needs to stay.

Feel free to help me convince the evince maintainer to turn on the dvi
support in the Fedora evince package.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173514

-jef

[Patrice Dumas]

Post by Alan Cox

Post by Ralf Corsepius
Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.

It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

It isn't a good extra candidate, because of its licence... Or am I missing
something?

If it turns out that there is no licence issue, I do agree that it would
better be in extras than in core, once it doesn't have any dependencies in
core anymore.

--
Pat

[Joachim Frieben]

Post by Alan Cox
It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

Not that quickly, there are still several applications of general importance
in Fedora Core that use Open Motif:

- ddd GUI for several command-line debuggers,
- tetex-xdvi X viewer for DVI files,
- xpdf PDF file viewer for the X Window System.

"evince" is very slow and rendering is flaky, so even "xpdf" is not
dispensable yet. For the first two items there is no alternative around the
block, unless someone volunteers to port them to "GTK" in the short run.

JF

[Arjan van de Ven]

Post by Ralf Corsepius

Post by Alan Cox

Post by Ralf Corsepius

Post by Alan Cox
OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

I asked the open group long ago and the email reply I got was to the contrary

Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.
Also,
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.
* closed source kernel drivers are in existence for quite some time,
some are even being shipped by some Linux vendors,

actually basically all sort-of-big linux vendors stopped shipping them
for "a variety of reasons".

[Patrice Dumas]

Post by Ralf Corsepius
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.

Yep, but in the previous question they explain that the licence isn't
allready OSI compatible:

QUESTION:

Does the Open Group Public License for Motif meet the Open Source Guidelines?

ANSWER:

No. The Open Group Public License for Motif grants rights only to use the software on or with operating systems that are themselves Open Source programs. In restricting the applicability of the license to Open Source platforms this does not meet term 8 of the Open Software Definition (http://www.opensource.org/osd.html).

Post by Ralf Corsepius
What concerns me much more on Fedora and Linux is OpenMotif's license
not to being [L]GPL compatible.

That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence
but is shipped as shared libs.

--
Pat

[Alan Cox]

Post by Ralf Corsepius
Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.

It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

Post by Ralf Corsepius
Furthermore, IIRC, their license originally was intended to prevent
using OpenMotif on "traditional *nixes" which ship with closed source
implementations/derivatives of the old OSF-Motif.

I'm just reporting what I was told at the time.

[Arjan van de Ven]

Post by Ralf Corsepius

Post by Alan Cox

Post by Ralf Corsepius

Post by Alan Cox
OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

I asked the open group long ago and the email reply I got was to the contrary

Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.
Also,
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.
* closed source kernel drivers are in existence for quite some time,
some are even being shipped by some Linux vendors,

actually basically all sort-of-big linux vendors stopped shipping them
for "a variety of reasons".

[Ralf Corsepius]

Post by Alan Cox

Post by Ralf Corsepius

Post by Alan Cox
OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

I asked the open group long ago and the email reply I got was to the contrary

Well, as the same would apply to ATI drivers, this would render
OpenMotif de-facto free of any practical applicability.

Also,
* this doesn't match to their FAQ, where they claim to be wanting to aim
at OSI compatibility.
* closed source kernel drivers are in existence for quite some time,
some are even being shipped by some Linux vendors, but I've never heard
the OpenGroup trying to enforce the interpretation of their license you
outline.

Furthermore, IIRC, their license originally was intended to prevent
using OpenMotif on "traditional *nixes" which ship with closed source
implementations/derivatives of the old OSF-Motif.

What concerns me much more on Fedora and Linux is OpenMotif's license
not to being [L]GPL compatible.

Ralf

[Alan Cox]

Post by Ralf Corsepius

Post by Alan Cox
OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

I asked the open group long ago and the email reply I got was to the contrary

[Ralf Corsepius]

Post by Alan Cox

Post by Ralf Corsepius

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed

OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

Only if you consider Nvidia's drivers to be integral part of the kernel.
I consider them to be optional add-ons/plug-ins.

Ralf

[Patrice Dumas]

Post by Ralf Corsepius

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed

It is not an osi approved licence. I believe that it wouldn't qualify for
being in extras. debian motif is based on lesstif.

Post by Ralf Corsepius
# rpm -q --qf '%{LICENSE}\n' openmotif
Open Group Public License
And lesstif, meanwhile is more or less without any practical importance,
anymore (It's not even part of FC or FE anymore)

I was planning to package lesstif for extras, but it is not obvious, as it
conflicts with openmotif, and isn't binary compatible. It doesn't mean
that there are functionalities in openmotif that are used in motif apps
that are in extras. Indeed, I haven't looked at the details, but it
seems to me that all the motif apps in extras would be happy with lesstif
motif. However, as there is no library versionning coordinated for lesstif
and openmotif, I think it is hopeless.

--
Pat

[Alan Cox]

Post by Ralf Corsepius

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed

OpenMotif is not free software by the FSF test. You can't for example use it
with proprietary Nvidia drivers loaded.

[Patrice Dumas]

Post by Ralf Corsepius

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed

It is not an osi approved licence. I believe that it wouldn't qualify for
being in extras. debian motif is based on lesstif.

Post by Ralf Corsepius
# rpm -q --qf '%{LICENSE}\n' openmotif
Open Group Public License
And lesstif, meanwhile is more or less without any practical importance,
anymore (It's not even part of FC or FE anymore)

I was planning to package lesstif for extras, but it is not obvious, as it
conflicts with openmotif, and isn't binary compatible. It doesn't mean
that there are functionalities in openmotif that are used in motif apps
that are in extras. Indeed, I haven't looked at the details, but it
seems to me that all the motif apps in extras would be happy with lesstif
motif. However, as there is no library versionning coordinated for lesstif
and openmotif, I think it is hopeless.

--
Pat

[Ralf Corsepius]

Post by Patrice Dumas
But openmotif isn't even free software,

Depends on your definition of "free software". Motif had been closed
source until several years ago, but times are a-changing:

# rpm -q --qf '%{LICENSE}\n' openmotif
Open Group Public License

And lesstif, meanwhile is more or less without any practical importance,
anymore (It's not even part of FC or FE anymore)

Ralf

[Rahul Sundaram]

Hi

Post by Mauro Mozzarelli

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start.
This is a task that requires influencing, management and enterprise
architecture skills other than time. It must be a team work to succeed. Is
there a team that I could join? Would a team have to be formed?

I hear a lot of buzzwords. If it requires forming a whole new team you
need to identify specific set of issues and a action plan in which you
can define your own work without getting a lot of other people involved
and then start working on that. If its a good plan and it shows up as
such on your work, I am sure others can get involved.

[Rik van Riel]

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start. This is a
task that requires influencing, management and enterprise architecture
skills other than time. It must be a team work to succeed. Is there a
team that I could join? Would a team have to be formed?

I think the first step would be to describe the problem in
more concrete terms. Actual problems that could be addressed,
instead of vague generalizations that could apply to anything.

Having concrete goals would be good, too.

If the goals and the problem description are interesting and
deemed realistic, then I'm sure developers would join your
effort.

[Patrice Dumas]

Post by Mauro Mozzarelli

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start.
This is a task that requires influencing, management and enterprise
architecture skills other than time. It must be a team work to succeed. Is
there a team that I could join? Would a team have to be formed?

As allready said, what needs to be influenced are the individual projects.
There is nothing like a team that tries to help keep api and abi stable
for all the projects and it is dubious that forming one would make sense.

If you find that some library has a stable binary interface that is kept
across versions and is used by most applications, and is mixed with a
changing interface, then you could help by providing library version
scripts to these libraries. This could potentially solve the api/abi
change issue. As I said allready this would, for example benefit to
openmotf/lesstif, because most apps compiled against openmotif use a
stable subset of the api/abi. But openmotif isn't even free software,
so...

Here are sources of information, with the relevant part of the ld manual:

http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html#SEC25

A generic resource I found on that subject:

http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/

There are many other sources of incompatibility than abi/api changes,
but abi/apip changes seemed to be on your list.

--
Pat

[Russell Harrison]

Post by Kaimano
If I seriously need eclipse, I will go an get the latest JDK from Sun and
the latest eclipse from eclipse.org and run them as such, they install in
minutes and I can update them whenever available. FC5 has created a
massive and unnecessary overhead of work essential to keep up with the
latest releases.

This is exactly the reason we decided to exclude eclipse from our RHEL 4 WS
kickstarts. Engineering will want their own specialized version of eclipse
anyway...

Although I do like having it avalible as a rpm install for my own personal
use.

Assume an hipotetical scenario of an organization that rolled out Linux

Post by Kaimano
desktop to 35000 workstations. The roadmap includes a desktop refresh in
no less than five years due to costs implications.

This is why we went with RHEL instead of Fedora. I really miss my FC4
desktop from my last job but we're asking our users to work with RHEL so I'm
using it as my desktop...

The core e-Mail application is evolution 2.0. A bug is found on evolution

Post by Kaimano
which requires upgrading to the latest 2.4. But ... evolution 2.4 requires
python 2.4, our installed base is on a distribution based on python 2.3
(like FC2) which is...

Yeah, we have to get Red Hat to supply patches for the existing 2.0 branch.
It isn't optimal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20060220/85336cdd/attachment.html

[Ron Yorston]

Post by Alan Cox
It is anyway, does anyone use motif ? as far as I can see its a good
extras candidate

We have millions of lines of code ported over from *nix that use Motif.
And I'm sure we're far from alone in that.

Now, Fedora Core isn't a platform we support, but we do support RHEL.
So, thinking ahead, if OpenMotif is moved to Extras in FC6 or FC7 what
happens to it in RHEL6 (or whatever)?

The Fedora Project doesn't need to worry about supporting Red Hat's
paying customers, but Red Hat does.

Ron

[Bill Nottingham]

Post by Ron Yorston
Now, Fedora Core isn't a platform we support, but we do support RHEL.
So, thinking ahead, if OpenMotif is moved to Extras in FC6 or FC7 what
happens to it in RHEL6 (or whatever)?

Someone from RH almost certainly would pick up a version from Extras
and build it for whatever RHEL release they're developing at the time,
if it's something needed for RHEL.

Bill

[Kaimano]

Hi All,

Just joined this list, I started a topic on fedoraforum.org and I was
suggested to refer my thoughts on this list as well. Sorry, is LONG.

Here is a compendium of the messages I posted:

ONE

Linux represents a greatly stable platform and the FC team is doing a
great work in improving the operating system, however I think that we
should all take a step back and look at what the market and ourselves
really need.

What I am looking for, like, I believe 99% of the user base not involved
with developing the OS, is:

1) to install an OS and forget about re-installs for at least two years 2)
to be able to upgrade the applications I most use without having to
re-install the operating system
3) to include among the applications I most use the following:
* openoffice
* evolution
* http server
* kde
* gnome
* firefox and mozilla
* mysql and postgresql
* eclipse
* java

to name a few.

I am unsure about the real value of building java within the OS, so
tightly that most packages builds depend on them.

If I seriously need eclipse, I will go an get the latest JDK from Sun and
the latest eclipse from eclipse.org and run them as such, they install in
minutes and I can update them whenever available. FC5 has created a
massive and unnecessary overhead of work essential to keep up with the
latest releases.

firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk
about evolution 2.4 openoffice and KDE just to name some. The dependencies
on a miriad of packages make the effort ridicolously hard.

The risk is to alienate potential users by forcing them to re-install
their operating system whenever they/we want to use the latest release of
an application that we really care about.

My proposition is to start thinking of a Linux architecture that allows
the re-build/re-placement of essential packages without having to rebuild
most of the operating system, thus increasing the life-span and viability
of a platform installation that need not to be replaced every year.

TWO

The problem is not updating from one version to the next, the problem is
actually to keep up with updating the most important, though not system
vital applications, without updating the core operating system. One guy
using its own computer can do that accepting some difficulties and risk.

Assume an hipotetical scenario of an organization that rolled out Linux
desktop to 35000 workstations. The roadmap includes a desktop refresh in
no less than five years due to costs implications.

The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4. But ... evolution 2.4 requires
python 2.4, our installed base is on a distribution based on python 2.3
(like FC2) which is deeply rooted in several applications. In addition,
upgrading to python 2.4 involves upgrading also to a later version of db4,
on which several other applications depend. Here we go, the chain is so
long and tight that just a simple upgrade of evolution involves
re-building most of the operating system, or ... rolling out a newer
version. That puts me off recommending Linux Fedora or Red Hat for any
business desktop platform.

Are any of the core Fedora / Red Hat architects watching this forum?

I would like to hear from them on this.

THREE

The good of this distro is right that there are discussions and
participation from the community that can have its input, beside the fact
that I am uncomfortable in participating, because I would be working for
free for Red Hat that holds its fingers deep in the pie. As a matter of
fact I am not particularly content with Fedora's license terms (the
packages are open source, but we hold the rights on the OS structure, not
just the logos, that belongs to us), an american lawyer must be behind
those. To this end I believe that either we all work for free or we all
get a share of the benefits.

Having clarified this, I would like to make my little free contribution by
drawing your attention to the fact that "having the latest version of a
package at all costs" does not bring all the advantages that it could. On
the contrary, I think that this tendency has brought Linux to being worse
than Windows that we all criticized when got IE embedded.

I would rather ensure that more attention is given to the system's
architectural solution that should be based on modular components that,
although interacting with each other, allow for the isolation of the
applications into services that are as much as possible independent from
each other, thus allowing for greater flexibility (in replacing them with
newer or different versions), which in the end would bring to the system
greater stability, lower cost of ownership (maintenance effort), and
eventually deeper market penetration.

If Fedora is what Red Hat will pick from, for their future releases, maybe
Red Hat are missing the point, because their are getting spaghetti code.

FOUR

Originally Posted by greenlead
Libraries and apps need to be written for backwards compatibility. An

older app should still function if an updated library is installed.

Precisely, this is at the foundation of any healthy information system,
but it is not happeining with Linux right now, because of the lack of
planning hidden behind the excuse that software solutions evolve rapidly.

[Arjan van de Ven]

Post by Kaimano
Hi All,
Just joined this list, I started a topic on fedoraforum.org and I was
suggested to refer my thoughts on this list as well. Sorry, is LONG.
ONE
Linux represents a greatly stable platform and the FC team is doing a
great work in improving the operating system, however I think that we
should all take a step back and look at what the market and ourselves
really need.
What I am looking for, like, I believe 99% of the user base not involved
1) to install an OS and forget about re-installs for at least two years

this FC already gives you ;)

Post by Kaimano
2)
to be able to upgrade the applications I most use without having to
re-install the operating system

that's a hard one, see below
\

Post by Kaimano
firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk
about evolution 2.4 openoffice and KDE just to name some. The dependencies
on a miriad of packages make the effort ridicolously hard.
The risk is to alienate potential users by forcing them to re-install
their operating system whenever they/we want to use the latest release of
an application that we really care about.
My proposition is to start thinking of a Linux architecture that allows
the re-build/re-placement of essential packages without having to rebuild
most of the operating system, thus increasing the life-span and viability
of a platform installation that need not to be replaced every year.

I think you are missing something here: these "essential packages" *ARE*
most of the operating system. (If you divide FC into "OS" and
"Applications", the essential packages you speak about fall under "OS",
and are the DNA and fabric of what makes it an operating system).

Post by Kaimano
TWO
The problem is not updating from one version to the next, the problem is
actually to keep up with updating the most important, though not system
vital applications, without updating the core operating system. One guy
using its own computer can do that accepting some difficulties and risk.

again.. it's the same thing!
"I want changes. But I also don't want changes"

Post by Kaimano
The core e-Mail application is evolution 2.0. A bug is found on evolution
which requires upgrading to the latest 2.4.

Why? You have a support contract with the vendor and you make them fix
the bug in version 2.0.

A bug should never ever be a reason to do an upgrade to half the OS.
Missing features, sure, but bugs... no.

[Mauro Mozzarelli]

Rahul,

Post by Rahul Sundaram
Killing it is a unnecessary dramatic phrase prone to various
interpretations.

Please forgive my english that is not my first language and I started
learning it serioulsy only in my late 30s.

Post by Rahul Sundaram
How are you willing to help?

Good question, I thought that this discussion was a start.
This is a task that requires influencing, management and enterprise
architecture skills other than time. It must be a team work to succeed. Is
there a team that I could join? Would a team have to be formed?

[Russell Harrison]

Post by Kaimano
If I seriously need eclipse, I will go an get the latest JDK from Sun and
the latest eclipse from eclipse.org and run them as such, they install in
minutes and I can update them whenever available. FC5 has created a
massive and unnecessary overhead of work essential to keep up with the
latest releases.

This is exactly the reason we decided to exclude eclipse from our RHEL 4 WS
kickstarts. Engineering will want their own specialized version of eclipse
anyway...

Although I do like having it avalible as a rpm install for my own personal
use.

Assume an hipotetical scenario of an organization that rolled out Linux

Post by Kaimano
desktop to 35000 workstations. The roadmap includes a desktop refresh in
no less than five years due to costs implications.

This is why we went with RHEL instead of Fedora. I really miss my FC4
desktop from my last job but we're asking our users to work with RHEL so I'm
using it as my desktop...

The core e-Mail application is evolution 2.0. A bug is found on evolution

Post by Kaimano
which requires upgrading to the latest 2.4. But ... evolution 2.4 requires
python 2.4, our installed base is on a distribution based on python 2.3
(like FC2) which is...

Yeah, we have to get Red Hat to supply patches for the existing 2.0 branch.
It isn't optimal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20060220/85336cdd/attachment-0002.html