Oui mais justement, tous les pays n'ont pas signé tous les accords internationaux. Et entre signer, et ratifier, il y a encore une marge...
De plus, la Loi n'est pas rétroactive (à l'exception notable de la Loi définissant le crime contre l'humanité). Donc les faits ne sont pas jugés de la même manière s'ils ont eu lieu avant ou après la ratification d'un traité... et un traité tout le monde ne le signe pas en même temps.
Ainsi, la convention de Berne, relative à la protection des oeuvres a été signée par la France en 1887, les USA l'ont signée plus d'un siècle après en 1989...
A ma connaissance, des pays comme l'afghanistan ou l'irak ne l'ont pas encore signée...
Quand tu signes un contrat, par exemple pour la vente d'une machine à laver au supermarché du coin, ce contrat est régit par le droit français (code de la consommation, code civil etc.) parce que ce contrat concerne 2 parties qui se trouvent en France, donc pas de problème.
Dans le cadre d'un contrat international, par définition les 2 parties ne sont pas dans le même pays, il faut donc bien se mettre d'accords pour savoir sur les lois duquel des deux pays on se base. Ne serait-ce que pour savoir quel tribunal est compétent pour trancher un éventuel litige.
Le problème qui peut apparaître, c'est qu'il y a des pays pour lesquels la notion de "copyright" est des plus floue. Si une entreprise chinoise par exemple récupère le code de Apache pour en faire un logiciel propriétaire, je ne pense pas que le problème puisse être résolu par la voie juridique.
Pour moi ça a l'air correct, m'enfin j'ai pas encore lu mot par mot :-)
2 petites remarques en passant :
1) Les termes y sont clairement défini (travail dérivé, source, objet etc.) C'est effectivement le B-A-BA d'un contrat de licence, et de ce point de vue, cette licence est bien mieux écrite que la (L)GPL...
2) A moins que j'ai raté un passage, il ne me semble pas qu'ils indiquent de quelles Loi de quel pays ils font référence lorsqu'ils parlent de "copyright". C'est à mon avis une erreur, puisque normalement il faut indiquer sur un contrat international à quel pays on fait référence. Mais j'ai peut-être loupé un détail...
Le notion de vente liée, ce n'est pas de vendre un PC avec Windows, MS-Office, 3 jeux et 2 DVD Walt-Disney.
La vente-liée c'est le fait de ne pas autoriser l'achat du PC sans toutes ces conneries dont ne veut éventuellement pas l'acheteur.
D'après la Loi, quand tu achètes ce genre de produit, tu devrais avoir une facture du genre :
PC xxxx à 2,3 GHz, 256 Mo de RAM............... 600 EUR
Ecran RTC, 39 Cm de diagonale, SVGA............ 150 EUR
Windows XP Ed. Familiale OEM .................. 90 EUR
MS-Office personnel OEM ....................... 100 EUR
JEUX xxx ...................................... 45 EUR
Blanche neige DVD .............................. 15 EUR
Cendrillon DVD ................................. 15 EUR
TOTAL 1015 EUR
Comme ça, si tu ne veux pas des DVD, ce qui est ton droit, tu sais combien tu te feras rembourser.
Non, mais à linuxfrench on a reçu ça, et j'imagine que c'est pareil pour LinuxFr :
De : "xxxx" <xxxx.XXXXX@agriculture.gouv.fr>
À : <redaction@linuxfrench.net>
Date : Aujourd'hui 12:11:53
Bonjour,
Suite à l'évolution de notre schéma directeur national, nous souhaitons
communiquer sur le choix de notre nouveau client de messagerie. Nous
pensons que, si il est bien d'utiliser les logiciels libres il est aussi
normal de le faire savoir.
Vous trouverez ci dessous l'article validé par le Ministère.
merci de me faire savoir si vous souhaitez publier cette information.
Cordialement
--- ARTICLE ---
Le Ministère de l'Agriculture adopte MOZILLA comme client de messagerie
à la place de Netscape 4.7
Etc.
Je suis entré en contact avec la personne qui nous a envoyé cela, et je confirme que cela émane bien du Ministère de l'Agriculture.
L'offre de reprise est juridiquement tout à fait logique.
Un contrat n'a pas été respecté (clauses du contrat permettant le remboursement). Donc, du coup le client est en droit de demander l'annulation de la vente.
Fort logiquement, HP propose donc d'appliquer les clauses du contrat qui n'avaient jusque là pas été appliquée, ou bien d'annuler la vente. C'est normal.
De la même manière, si sur une pub on vout dit "La baril de lessive de 1Kg est à 5EUR", et que tout compte fait, le baril de lessive en question ne fait que 500g, vous pouvez demander à ce qu'on vous rembourse 50% du prix du baril de lessive, ou bien faire annuler la vente (on vous le rembourse intégralement).
Accessoirement, vous pouvez aussi aller en justice pour publicité mensongère, et/ou bien saisir la DGCCRF pour affichage des prix incorrect.
Il sont passés en 700 Mo pour les versions betas de la 9.0, et j'avais ralé auprès de MDK, parce que les CD-RW à 700 Mo, à l'époque c'était un peu galère à trouver, et ça m'embetait de devoir regraver un jeux de CD à chaque beta...
Ma «preuve» est le témoignage direct d'un des responsables informatique.
Depuis 6-8 mois à peu près, il se passe des choses «souterraines» dans l'administration. Quand je dis souterraines, je veux dire qu'ils mette de plus en plus de libre (suite à des instructions qui viennent «d'en haut»), mais aucune publicité n'est faite là dessus. J'ai même entendu parler de cas où ils continuaient à payer les licences microsoft. Je n'ai pas vraiment de certitudes, c'est soit par incompétence (c'est possible) voire comme le prétendent d'autre «pour pas que cela se sache».
On pourrait croire que l'administration essaye en catimini d'atteindre une masse critique avant de frapper fort. C'est une supposition de ma part, mais quelques témoignages directs que j'ai reçus me le font croire.
Un exemple : Bull présentait à la Linux Expo des solutions «clef en main» de serveur sous linux avec Apache, PHP, MySQL, Sendmail, SPIP etc.
Les gars de Bull avec qui j'ai discutait m'ont dit que ces produits avait été créés afin de répondre à des directives ministérielles adressées à des administrations...
Parce que justement l'argument n'est pas obsolète. Le prelink a toujours une utilité, ce qui est bien la preuve que GCC est encore loin de faire tout le boulot.
Ensuite, une appli C++ sous linux compilée avec GCC rame au démarrage, alors que ce n'est pas le cas sur les autres plateformes avec d'autres compilateurs.
J'ai toujours écrit que les choses s'amélioraient (depuis que WB a fait l'analyse initiale), mais nous sommes encore très loin du compte. De plus, GCC a ce problème en C++ mais pas en C.
Donc, oui, je critique GCC, et cette critique est toujours d'actualité.
Les choses se sont améliorées, et vont encore s'améliorer, je le sais, et je l'ai toujours dit.
Mon principal message est d'expliquer à ceux qui disent :
- OO c'est nul parce que ça rame au démarrage.
- KDE c'est nul parce que les applis mettent du temps à démarrer.
- C++ c'est nul parce que les applis rament.
Et bien en fait ces gens là ce trompent. Le problème vient du compilateur. Avec d'autres compilateurs, la donne change complètement. Le compilateur s'améliore, et en attendant qu'il se soit suffisamment amélioré, on a des moyens de substitution telles que les bidouilles du prelink, mais aujourd'hui cela reste quand même un problème.
Aujourd'hui, GCC est un mauvais compilateur C++.
C'est pas grave, on fait avec, et ça va changer progressivement.
Actuellement, je ne sais pas comment fonctionnent les dernières versions de prelink, mais la première version faisait une immonde bidouille. Il y avait toujours n entrées dans la V-Tables, mais les entrées identiques pointaient sur un index, qui lui-même pointait sur l'adresse de la fonction.
Ainsi au démarrage, l'adresse n'est calculée (et stockée) qu'une seule fois, au lieu de n fois.
Mais tout le monde est tout à fait d'accord : on peut largement améliorer les choses en intervenant directement sur le compilateur et l'éditeur de lien. Desz choses ont déjà été faites en ce sens, mais il reste encore bcp à faire.
Oups, excuses, je t'avais lu trop rapidement, j'avais cru que tu disais que le prelink gaspillait de la RAM. Désolé pour la remarque dans mon post précédent ;-)
Dans ce débat, il faut d'abord admettre un constat qui fait mal : Une application C++ qui utilise QT (par exemple) et compilée avec VC++ sous Windows démarrera beaucoup plus vite que la même appli sous linux compilée avec GCC.
Comme c'est pas politiquement correct de dire ça, vous allez être des dizaines à «moinsser» ou a dire «on s'en fout paske ce qui n'est pas libre c'est pas bo» etc. Mais cela ne changera rien au fait qu'un appli C++ sous linux compilée avec GCC ramera au démarrage alors que la même appli compilée avec un autre compilo sur une autre plateforme démarrera aussi vite qu'une appli «pure C».
Il y a deux explications à cela :
1) Les V-Tables. Ce sont des tables qui permettent de résoudre dynamiquement les appels à des méthodes. En POO ces tables sont nécessaires afin de résoudre lors de l'exécution les appels polymorphes. GCC ne fait pas d'optimisation à ce niveau, du coup le linker dynamique doit créer une entrée dans la table pour chacune des fois où une même méthode est héritée. Si vous avez un objet Ancetre qui a une méthode getInfo(), que cet objet est hérité par 200 autres classes, et bien la V-Table contiendra 200 entrées pour cette méthode même si ladite méthode n'est jamais surchargée par un des descendants.
Et donc, contrairement à ce que tu dis, le prelink va non seulement accélerer les choses, mais également économiser de la RAM en évitant toutes ces entrées inutiles.
2) Le C++ permettant des résolutions dynamiques, GCC et l'éditeur de liens ne s'emmerdent pas : ils ne résolvent aucun appel. Les symboles seront résolus dynamiquement au démarrage de l'application. (c'est une simplification, mais c'est l'idée générale). Alors que lors de la compilation, il est possible de résoudre l'essentiel des appels aux librairies partagées. Le format de binaires ELF permet en effet de faire un"table d'équivalence" des appels déjà résolus sur une librairie partagée, puisque cette même librairie partagée possède déjà une table de ses symboles. Donc en fait, prelink fait du boulot que l'éditeur de lien (ld) ne veut pas faire... on se demande bien pourquoi.
Depuis que le «problème» a été identifié, un certain nombres de choses ont été faites par l'équipe de dev de GCC (depuis la V3), mais on est encore loin du compte. Faut pas leur en vouloir, c'est seulement que quand on fait ce genre de modifs dans un compilo, il est préférable d'avancer prudemment ;-)
Pour info, voici ci-dessous l'analyse qu'avait faite WB à l'époque où il s'était penché sur le problème (analyse qui a donné naissance au prelink). Mais comme ça parle de KDE, C++ et surtout que ça ose supposer que le sacro-saint GNU-CC n'est pas l'ultime perfection de la galaxie (42), ce post sera sans aucun doute qualifié de «immonde troll» (ce qui est souvent bien pratique) ;-)
Aegir.
Making C++ ready for the desktop.
=================================
Author: Waldo Bastian <bastian@kde.org>
Date: May 9, 2001
Version: 1.2 (See bottom for change history)
In this paper I would like to bring the attention to an important performance
bottleneck in the ld.so linker on GNU/Linux systems wrt C++ programs. I will
try to offer some suggestions for improvement and hope that this paper will
lead to a discussion in the GNU/Linux community that eventually will lead to
a solution that addresses this problem.
It should also be noted that ld.so currently does a fine job for the things
it was designed. The problem is that it wasn't designed for todays Linux
Desktop.
This paper is based on gcc 2.95, many of the issues described here have been
fixed in gcc 3.1.
1. The symptoms
===============
Starting a KDE application from the command line is slow. Slow is a very
subjective term, but when it comes to a graphical user interface, things
are typically perceived as slow when there is a latency of more than 0.3 secs.
between action and reaction. So if I click on a button, it should bring up a
window on my screen within 0.3 secs. If it takes longer, users tend to perceive
the system as slow.
KDE is slow. Since I am very concerned about KDE I have been looking into the
reason why KDE is slow. Obviously there are a number of factors that contribute
to the problem. What we are interested in is the startup-performance which I
would like to define as the time it takes between the moment the binary image
is being executed and the moment the first visual feedback appears on the
screen.
There are 4 major contributors to the startup-performance in a KDE application.
1) Time spent by the linker (ld.so) before main() is called.
2) Initialisation of the X server connection and Qt toolkit.
3) Overhead by the KDE framework
4) Overhead by the application
Since the goal is to bring the startup-performance within 0.3 secs, each
contributor may spent on average 75ms.
I mention 2), 3) and 4) to make clear that the startup-performance is not tied
to a single element. However, each of these contributors places a limit on
the best achievable performance. I will continue to refer to 2), 3) and 4)
wrt performance for reference, but apart from that they are beyond the scope
of this paper.
As an example I have split up the startup times of the 'kedit' application
into 1), 2), 3) and 4), times are measured on a Pentium III running at 500Mhz.
All data is assumed to be already in memory so disk access should not play a
role.
Table1:
Activity Time Spent
Linking 0.65 sec
Qt app. constructor 0.13 sec
KDE app. constructor 0.11 sec
KEdit specific init 0.48 sec
---------------------------------------------
Total 1.37 sec
This illustrates that run-time link performance is the major bottleneck when
it comes to providing a "fast" desktop environment.
The task of the runtime linker is to link an application to the shared libraries
it needs. There are several steps involved in this process. These steps involve:
1) Finding the shared libraries that are needed
2) Loading the shared libraries into the address space of the process.
3) Relocating addresses in the library to reflect the location in the address
space the library was loaded to.
4) Resolving undefined symbols in a library and/or the executable by searching
for these symbols in the other libraries.
All these steps, with exception of step 3, are optimized. It is step 3 that is
causing the problems:
1) Finding shared libraries is optimized by means of the /etc/ld.so.cache. The
ldconfig utility builds an index of all libraries found in the default library
locations and stores this index information in /etc/ld.so.cache. This cache
allows the linker to lookup libraries faster than if it had to search the file
system itself when looking for a certain library. If a library is not found in
the cache, the linker has to search the filesystem anyway.
2) Loading of shared libraries is cached by the Linux kernel. Only the first
application that needs a certain library needs to actually load the library
from disk. Subsequent processes that need the library will make use of the same
copy that already resides in memory.
This is further optimized by the fact that the Linux kernel only loads parts of
the library (on a page by page basis) when these parts are actually used.
4) Not all symbols are resolved at startup. Only when a symbol is used it is
being resolved. This is called lazy binding. By specifying "LD_BIND_NOW=t"
before starting an application, we can instruct the linker not to use lazy
binding and to resolve all symbols at startup. The following table shows
the results of lazy binding for the startup time of KEdit.
Table 2:
Lazy Binding Time needed for linking
On 0.65 sec
Off 1.17 sec
Symbol lookup is further optimized by the use of hash tables which makes the
lookup of symbols very efficient.
Lets now have a closer look at what happens in step 3)
Every library that is needed by an application gets loaded to an address that
is unique within that process. This address may vary each time the library is
loaded. Code that references addresses in the library must be adjusted for the
address the library is loaded to, this is called relocation. As mentioned before,
libraries are shared between different applications and processes. However,
the relocation performed can be different from process to process, as such,
those parts of the library that need to be relocated are not shared.
Let's now have a look at some numbers. When we compile and link the following
very simple application:
main(int argc, char *argv[]) { return 0; }
we will see that the startup time is determined by the number of libraries
this code is linked against. More accurately formulated, the startup time is
largely determined by the number of relocations that have to be performed.
The number of relocations can be counted by setting "LD_DEBUG=statistics".
The number of relocations and the start up time is measured independently
in case measuring the number of relocations slows down the relocation process.
LD_DEBUG=staticstics only counts the number of relocations that require a symbol
lookup.
In the following table, the startup time is listed as a function of the
libraries linked. Since the libraries depend on each other, each line also
implies the libraries listed above it. E.g. all data is cummulative.
Table 3:
Lazy Binding Bind all on startup
Libraries Relocations Time Relocations Time
C++ 945 0.01 1754 0.01
Qt *) 22176 0.12 32892 0.20
DCOP 22407 0.14 33669 0.24
kdecore **) 25095 0.20 39911 0.37
kdeui 42157 0.34 61586 0.60
kio ***) 43739 0.44 64978 0.78
kfile ****) 48915 0.60 73848 1.10
kspell 49366 0.66 74707 1.22
Not only does the relocation take CPU time, it also uses up memory.
Table 4:
Lazy Binding Bind all on startup
Libraries Dirty Pages *) Dirty Pages
C++ 28 28
Qt 135 135
DCOP 137 137
kdecore 162 162
kdeui 189 189
kio 197 197
kfile 211 211
kspell 213 213
*) The last field of /proc//statm. (Linux 2.2.18)
Memory usage seems to be mostly caused by the .data sections of the libraries
which contain the vtables, and to a lesser extend by the .got section.
The following table shows the memory usage split by section. The table lists the 4
biggest libraries. Listed as "kedit" is the sum for all libraries (as well as the kedit
executable itself)
The next table shows the number of relocations per relocation type.
Relocations in the .got section are of type R_386_JUMP_SLOT and R_386_GLOB_DAT.
Relocations in the .data section are of type R_386_32 and R_386_RELATIVE.
Relocations of type R_386_32, R_386_JUMP_SLOT, R_386_GLOB require a symbol
lookup.
Relocations of type R_386_JUMP_SLOT are delayed until needed, unless
"LD_BIND_NOW" is specified.
This shows that on average 100% of the .got section is affected by R_386_JUMP_SLOT
and R_386_GLOB_DAT relocations and 81% of the .data section is affected by R_386_REL
and R_386_32 relocations.
It is interesting to note that multiple R_386_32 entries can point to the same
symbol:
The following table lists the number of total R_386_32 entries per library as
well as the number of unique symbols referenced.
Caching symbol lookups related to R_386_32 relocations might give considerable savings.
Is this a KDE specific problem?
===============================
That depends on how you look at it. The problem of long startup times is caused
by the linker needing to do many relocations. In the case of KDE, these
relocations are for a great deal caused by vtable entries. KDE and Qt make
liberal use of virtual functions and inheritance. In general every class that
inherits from a base class with virtual functions will need to provide a vtable
that covers at least the virtual functions of this base class. It seems that
each vtable entry causes a relocation, and worse, a relocation that can not be
done lazy.
An example:
A class 'base' that defines 10 virtual functions will define a vtable for these
10 functions. All these functions need to be relocated at startup resulting in
10 relocations.
When I now define a class "derive" that inherits "base" and that overrides a
single virtual function, I will get a second vtable. I now need 20 relocations.
Qt is based on two fundamental classes, QObject and QWidget. QObject defines
about 8 virtual functions. QWidget about another 80.
As a test the following (dummy) class was added to a KDE library, the class
overrides an existing virtual function. The class was not used in any way.
By adding this class the number of relocations on startup increased with
110.
class TestClass : public QWidget
{
public:
TestClass() : QWidget() { }
virtual void initMetaObject() { QWidget::initMetaObjet(); }
};
Now it becomes clear why linking kdeui, a library that mostly defines widgets
who all inherit from QWidget, introduces 17000 additional relocations.
So to come back to the question, is this issue specific for KDE? Maybe.
As for a comparison. The GNOME 'gedit' application requires 2043 relocations
with lazy binding versus 9755 relocations with complete binding. It seems
that this application, written in C, takes more advantage of lazy binding
than applications in the KDE framework.
The following code was placed into a library as a test case:
#include <qwidget.h>
template<int T> class testclass : public QWidget
{
public:
virtual void setSizeIncrement(int w, int h) { QWidget::setSizeIncrement(w+T, h+T); }
};
template class testclass<1>;
...
template class testclass;
Note that these classes are not being used in any way. They only get defined.
In the table below the runtime startup performance versus the number of
classes is shown:
Each extra class introduces an extra 109 relocations and such a relocation
takes on average 8e-6 sec (CPU dependent).
4. A dirty hack: kdeinit
========================
Within KDE we have been looking for a solution to this problem. We found a
workable solution ("hack") which addresses the problem but think that a more
generic, fundamental and clean solution is in place.
The kdeinit solution is based on the notion that instead of launching
applications from scratch, we start a process that links against all important
KDE libraries. We then keep this process around in this "preloaded" state and
when we need to start an application, we let this process fork() and start the
application by dlopen'ing the application.
Their are 3 problems with this approach:
1) It is specific for KDE and KDE libraries
2) The application needs to be build as an ELF shared object instead of as a
ELF executable.
3) All your processes are called 'kdeinit'.
The two main advantages are worth this trouble though:
1) Application startup performance is improved with 0.65 sec on average.
(On 500Mhz PIII, this number is highly CPU bound)
2) Memory usage is reduced with about 800kb per process.
5. Suggestions
==============
There are two routes to improvement.
1) Improving efficiency of C++ vtable linking
One solution could be to make run-time
linking of vtables more efficient. If the linking/relocation of vtables could
be postponed till the first object of that class gets constructed, I expect that
the number of relocations during startup will drop dramatically if lazy binding
is enabled. KDE applications show a ratio of about 2:3 between
lazy and non lazy binding. The gedit example had a ratio of 1:5. If lazy binding
of KDE applications can be improved to a ratio of 1:5 the number of relocations
during startup would drop from 49366 to about 15000, which would result in the
link time dropping from 0.65 sec to 0.20 secs if we assume a linear relation.
2) pre-relocation/linking of libraries.
Another solution would be to add support for pre-relocating/linking libraries
in the linker. This solutions is IMO a more correct approach since it solves
the problem in a more fundamental way. The fundamental problem is that we are
doing a large number of relocations, over and over again (each time a KDE
application is started) basically we have a problem and solve that problem
over and over again. If we would solve the problem once and then reuse the
result we can save a lot CPU cycles instead of postponing the use of those
CPU cycles as we would do with solution 1.
There are a few decisions one can make when pre-relocating libraries.
Who will pre-relocate/link and when? Are the results stored on disk or in
memory? Are the results shared between different users?
When linking a library (and to a smaller degree when relocating) the result
is dependent on the other libraries. That means that the validity of a
pre-relocated/linked library depends on the other libraries that it depends on.
With kdeinit this problem is solved in an easy but crude way. When kdeinit
starts the libraries that are to be used are fixated, changes made to a library,
like upgrades, will not take effect until kdeinit is restarted. This way
the pre-relocated/lnked set of libraries will always remain in a consistent
state.
Although I consider this a crude way, it should be noted that most of the time,
especially if the owner of the system is not a KDE developer him or herself,
libraries do not change. Assuming that someone updates his system once a month,
that means that 29 out of 30 days his libraries remain the same.
Added Change History
Added Table numbering
Added Table 5
Version 1.2:
Added Table 4a, 4b and 4c.
Added note that LD_DEBUG=staticstics only counts the number of relocations that
require a symbol lookup.
Added suggestion to cache symbol lookups related to R_386_32 relocations (Table 4d)
Version 1.3:
Added note that this paper describes gcc 2.95.
Added reference to SGI's IRIX.
[^] # Re: L'inventeur du CTRL-ALT-DELETE part à la retraite !
Posté par peau chat . En réponse à la dépêche L'inventeur du CTRL-ALT-DELETE part à la retraite !. Évalué à 1.
[^] # Re: Apache License, Version 2.0
Posté par peau chat . En réponse à la dépêche Apache License, Version 2.0. Évalué à 1.
De plus, la Loi n'est pas rétroactive (à l'exception notable de la Loi définissant le crime contre l'humanité). Donc les faits ne sont pas jugés de la même manière s'ils ont eu lieu avant ou après la ratification d'un traité... et un traité tout le monde ne le signe pas en même temps.
Ainsi, la convention de Berne, relative à la protection des oeuvres a été signée par la France en 1887, les USA l'ont signée plus d'un siècle après en 1989...
A ma connaissance, des pays comme l'afghanistan ou l'irak ne l'ont pas encore signée...
[^] # Re: Apache License, Version 2.0
Posté par peau chat . En réponse à la dépêche Apache License, Version 2.0. Évalué à 4.
Dans le cadre d'un contrat international, par définition les 2 parties ne sont pas dans le même pays, il faut donc bien se mettre d'accords pour savoir sur les lois duquel des deux pays on se base. Ne serait-ce que pour savoir quel tribunal est compétent pour trancher un éventuel litige.
Le problème qui peut apparaître, c'est qu'il y a des pays pour lesquels la notion de "copyright" est des plus floue. Si une entreprise chinoise par exemple récupère le code de Apache pour en faire un logiciel propriétaire, je ne pense pas que le problème puisse être résolu par la voie juridique.
[^] # Re: Apache License, Version 2.0
Posté par peau chat . En réponse à la dépêche Apache License, Version 2.0. Évalué à 3.
2 petites remarques en passant :
1) Les termes y sont clairement défini (travail dérivé, source, objet etc.) C'est effectivement le B-A-BA d'un contrat de licence, et de ce point de vue, cette licence est bien mieux écrite que la (L)GPL...
2) A moins que j'ai raté un passage, il ne me semble pas qu'ils indiquent de quelles Loi de quel pays ils font référence lorsqu'ils parlent de "copyright". C'est à mon avis une erreur, puisque normalement il faut indiquer sur un contrat international à quel pays on fait référence. Mais j'ai peut-être loupé un détail...
[^] # Re: Alternatives, vente liée, Dell et remboursement
Posté par peau chat . En réponse à la dépêche PC sans OS et vente liée: la répression des fraudes indécise. Évalué à 4.
La vente-liée c'est le fait de ne pas autoriser l'achat du PC sans toutes ces conneries dont ne veut éventuellement pas l'acheteur.
D'après la Loi, quand tu achètes ce genre de produit, tu devrais avoir une facture du genre :
PC xxxx à 2,3 GHz, 256 Mo de RAM............... 600 EUR
Ecran RTC, 39 Cm de diagonale, SVGA............ 150 EUR
Windows XP Ed. Familiale OEM .................. 90 EUR
MS-Office personnel OEM ....................... 100 EUR
JEUX xxx ...................................... 45 EUR
Blanche neige DVD .............................. 15 EUR
Cendrillon DVD ................................. 15 EUR
TOTAL 1015 EUR
Comme ça, si tu ne veux pas des DVD, ce qui est ton droit, tu sais combien tu te feras rembourser.
Et SURTOUT tu connais le prix de l'ordinateur.
[^] # Re: PC sans OS et vente liée: la répression des fraudes indécise
Posté par peau chat . En réponse à la dépêche PC sans OS et vente liée: la répression des fraudes indécise. Évalué à 3.
Parce qu'au TGI ça te coûte au moins un avocat.
[^] # Re: GNOME Office 1.0
Posté par peau chat . En réponse à la dépêche GNOME Office 1.0. Évalué à 2.
La vache, je savais pas qu'il y avait autant d'applis KDE sur Windows :-)
[^] # Re: Espaces publicitaires à vendre
Posté par peau chat . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 3.
Je ne sais pas de quel antivirus il s'agit. Peut-être qu'il s'agit d'un antivirus pour protéger Windows, et que ce n'a rien a voir avec Linux.
J'ai demandé à Jacques Le Marois combien il y avait de pubs, où elles étaient, et comment elles étaient.
Pour qui (quelle société, et quel produit précisément) elles étaient, cela ne me regarde pas.
Aegir@LinuxFrench.Net
Ceci dit, à titre personnel, j'espère que c'est pas pour une filliale de la scientologie...
[^] # Re: Espaces publicitaires à vendre
Posté par peau chat . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 1.
[^] # Re: Espaces publicitaires à vendre
Posté par peau chat . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 1.
[^] # Re: Mozilla au Ministère de l'Agriculture
Posté par peau chat . En réponse à la dépêche Mozilla au Ministère de l'Agriculture. Évalué à 5.
De : "xxxx" <xxxx.XXXXX@agriculture.gouv.fr>
À : <redaction@linuxfrench.net>
Date : Aujourd'hui 12:11:53
Bonjour,
Suite à l'évolution de notre schéma directeur national, nous souhaitons
communiquer sur le choix de notre nouveau client de messagerie. Nous
pensons que, si il est bien d'utiliser les logiciels libres il est aussi
normal de le faire savoir.
Vous trouverez ci dessous l'article validé par le Ministère.
merci de me faire savoir si vous souhaitez publier cette information.
Cordialement
--- ARTICLE ---
Le Ministère de l'Agriculture adopte MOZILLA comme client de messagerie
à la place de Netscape 4.7
Etc.
Je suis entré en contact avec la personne qui nous a envoyé cela, et je confirme que cela émane bien du Ministère de l'Agriculture.
Aegir.
[^] # Re: Mozilla au Ministère de l'Agriculture
Posté par peau chat . En réponse à la dépêche Mozilla au Ministère de l'Agriculture. Évalué à 1.
[^] # Re: On peut enfin se faire rembourser les logiciels fournis avec son PC
Posté par peau chat . En réponse à la dépêche On peut enfin se faire rembourser les logiciels fournis avec son PC. Évalué à 7.
Même si on te rembourse intégralement si jamais t'es pas d'accord avec le contrat, tu dois pouvoir le consulter avant d'acheter.
[^] # Re: On peut enfin se faire rembourser les logiciels fournis avec son PC
Posté par peau chat . En réponse à la dépêche On peut enfin se faire rembourser les logiciels fournis avec son PC. Évalué à 4.
Félicitations.
Pour info, c'était à quel Carrouf ?
[^] # Re: On peut enfin se faire rembourser les logiciels fournis avec son PC
Posté par peau chat . En réponse à la dépêche On peut enfin se faire rembourser les logiciels fournis avec son PC. Évalué à 10.
Un contrat n'a pas été respecté (clauses du contrat permettant le remboursement). Donc, du coup le client est en droit de demander l'annulation de la vente.
Fort logiquement, HP propose donc d'appliquer les clauses du contrat qui n'avaient jusque là pas été appliquée, ou bien d'annuler la vente. C'est normal.
De la même manière, si sur une pub on vout dit "La baril de lessive de 1Kg est à 5EUR", et que tout compte fait, le baril de lessive en question ne fait que 500g, vous pouvez demander à ce qu'on vous rembourse 50% du prix du baril de lessive, ou bien faire annuler la vente (on vous le rembourse intégralement).
Accessoirement, vous pouvez aussi aller en justice pour publicité mensongère, et/ou bien saisir la DGCCRF pour affichage des prix incorrect.
[^] # Re: On peut enfin se faire rembourser les logiciels fournis avec son PC
Posté par peau chat . En réponse à la dépêche On peut enfin se faire rembourser les logiciels fournis avec son PC. Évalué à 7.
La nouvelle info, c'est que maintenant ZDNet en parle ;-)
[^] # Re: Noyau 2.6.0-test4
Posté par peau chat . En réponse à la dépêche Noyau 2.6.0-test4. Évalué à 3.
Il sont passés en 700 Mo pour les versions betas de la 9.0, et j'avais ralé auprès de MDK, parce que les CD-RW à 700 Mo, à l'époque c'était un peu galère à trouver, et ça m'embetait de devoir regraver un jeux de CD à chaque beta...
Il reste à trouver les 11 autres personnes... :-)
[^] # Re: Openoffice.org RC3
Posté par peau chat . En réponse à la dépêche Openoffice.org 1.1 RC3. Évalué à 1.
Depuis 6-8 mois à peu près, il se passe des choses «souterraines» dans l'administration. Quand je dis souterraines, je veux dire qu'ils mette de plus en plus de libre (suite à des instructions qui viennent «d'en haut»), mais aucune publicité n'est faite là dessus. J'ai même entendu parler de cas où ils continuaient à payer les licences microsoft. Je n'ai pas vraiment de certitudes, c'est soit par incompétence (c'est possible) voire comme le prétendent d'autre «pour pas que cela se sache».
On pourrait croire que l'administration essaye en catimini d'atteindre une masse critique avant de frapper fort. C'est une supposition de ma part, mais quelques témoignages directs que j'ai reçus me le font croire.
Un exemple : Bull présentait à la Linux Expo des solutions «clef en main» de serveur sous linux avec Apache, PHP, MySQL, Sendmail, SPIP etc.
Les gars de Bull avec qui j'ai discutait m'ont dit que ces produits avait été créés afin de répondre à des directives ministérielles adressées à des administrations...
[^] # Re: Openoffice.org RC3
Posté par peau chat . En réponse à la dépêche Openoffice.org 1.1 RC3. Évalué à 2.
Ensuite, une appli C++ sous linux compilée avec GCC rame au démarrage, alors que ce n'est pas le cas sur les autres plateformes avec d'autres compilateurs.
J'ai toujours écrit que les choses s'amélioraient (depuis que WB a fait l'analyse initiale), mais nous sommes encore très loin du compte. De plus, GCC a ce problème en C++ mais pas en C.
Donc, oui, je critique GCC, et cette critique est toujours d'actualité.
Les choses se sont améliorées, et vont encore s'améliorer, je le sais, et je l'ai toujours dit.
Mon principal message est d'expliquer à ceux qui disent :
- OO c'est nul parce que ça rame au démarrage.
- KDE c'est nul parce que les applis mettent du temps à démarrer.
- C++ c'est nul parce que les applis rament.
Et bien en fait ces gens là ce trompent. Le problème vient du compilateur. Avec d'autres compilateurs, la donne change complètement. Le compilateur s'améliore, et en attendant qu'il se soit suffisamment amélioré, on a des moyens de substitution telles que les bidouilles du prelink, mais aujourd'hui cela reste quand même un problème.
Aujourd'hui, GCC est un mauvais compilateur C++.
C'est pas grave, on fait avec, et ça va changer progressivement.
[^] # Re: Openoffice.org RC3
Posté par peau chat . En réponse à la dépêche Openoffice.org 1.1 RC3. Évalué à 3.
Ainsi au démarrage, l'adresse n'est calculée (et stockée) qu'une seule fois, au lieu de n fois.
Mais tout le monde est tout à fait d'accord : on peut largement améliorer les choses en intervenant directement sur le compilateur et l'éditeur de lien. Desz choses ont déjà été faites en ce sens, mais il reste encore bcp à faire.
[^] # Re: Openoffice.org RC3
Posté par peau chat . En réponse à la dépêche Openoffice.org 1.1 RC3. Évalué à 2.
[^] # Re: Openoffice.org RC3
Posté par peau chat . En réponse à la dépêche Openoffice.org 1.1 RC3. Évalué à 8.
Dans ce débat, il faut d'abord admettre un constat qui fait mal : Une application C++ qui utilise QT (par exemple) et compilée avec VC++ sous Windows démarrera beaucoup plus vite que la même appli sous linux compilée avec GCC.
Comme c'est pas politiquement correct de dire ça, vous allez être des dizaines à «moinsser» ou a dire «on s'en fout paske ce qui n'est pas libre c'est pas bo» etc. Mais cela ne changera rien au fait qu'un appli C++ sous linux compilée avec GCC ramera au démarrage alors que la même appli compilée avec un autre compilo sur une autre plateforme démarrera aussi vite qu'une appli «pure C».
Il y a deux explications à cela :
1) Les V-Tables. Ce sont des tables qui permettent de résoudre dynamiquement les appels à des méthodes. En POO ces tables sont nécessaires afin de résoudre lors de l'exécution les appels polymorphes. GCC ne fait pas d'optimisation à ce niveau, du coup le linker dynamique doit créer une entrée dans la table pour chacune des fois où une même méthode est héritée. Si vous avez un objet Ancetre qui a une méthode getInfo(), que cet objet est hérité par 200 autres classes, et bien la V-Table contiendra 200 entrées pour cette méthode même si ladite méthode n'est jamais surchargée par un des descendants.
Et donc, contrairement à ce que tu dis, le prelink va non seulement accélerer les choses, mais également économiser de la RAM en évitant toutes ces entrées inutiles.
2) Le C++ permettant des résolutions dynamiques, GCC et l'éditeur de liens ne s'emmerdent pas : ils ne résolvent aucun appel. Les symboles seront résolus dynamiquement au démarrage de l'application. (c'est une simplification, mais c'est l'idée générale). Alors que lors de la compilation, il est possible de résoudre l'essentiel des appels aux librairies partagées. Le format de binaires ELF permet en effet de faire un"table d'équivalence" des appels déjà résolus sur une librairie partagée, puisque cette même librairie partagée possède déjà une table de ses symboles. Donc en fait, prelink fait du boulot que l'éditeur de lien (ld) ne veut pas faire... on se demande bien pourquoi.
Depuis que le «problème» a été identifié, un certain nombres de choses ont été faites par l'équipe de dev de GCC (depuis la V3), mais on est encore loin du compte. Faut pas leur en vouloir, c'est seulement que quand on fait ce genre de modifs dans un compilo, il est préférable d'avancer prudemment ;-)
Pour info, voici ci-dessous l'analyse qu'avait faite WB à l'époque où il s'était penché sur le problème (analyse qui a donné naissance au prelink). Mais comme ça parle de KDE, C++ et surtout que ça ose supposer que le sacro-saint GNU-CC n'est pas l'ultime perfection de la galaxie (42), ce post sera sans aucun doute qualifié de «immonde troll» (ce qui est souvent bien pratique) ;-)
Aegir.
Making C++ ready for the desktop.
=================================
Author: Waldo Bastian <bastian@kde.org>
Date: May 9, 2001
Version: 1.2 (See bottom for change history)
In this paper I would like to bring the attention to an important performance
bottleneck in the ld.so linker on GNU/Linux systems wrt C++ programs. I will
try to offer some suggestions for improvement and hope that this paper will
lead to a discussion in the GNU/Linux community that eventually will lead to
a solution that addresses this problem.
It should also be noted that ld.so currently does a fine job for the things
it was designed. The problem is that it wasn't designed for todays Linux
Desktop.
This paper is based on gcc 2.95, many of the issues described here have been
fixed in gcc 3.1.
1. The symptoms
===============
Starting a KDE application from the command line is slow. Slow is a very
subjective term, but when it comes to a graphical user interface, things
are typically perceived as slow when there is a latency of more than 0.3 secs.
between action and reaction. So if I click on a button, it should bring up a
window on my screen within 0.3 secs. If it takes longer, users tend to perceive
the system as slow.
KDE is slow. Since I am very concerned about KDE I have been looking into the
reason why KDE is slow. Obviously there are a number of factors that contribute
to the problem. What we are interested in is the startup-performance which I
would like to define as the time it takes between the moment the binary image
is being executed and the moment the first visual feedback appears on the
screen.
There are 4 major contributors to the startup-performance in a KDE application.
1) Time spent by the linker (ld.so) before main() is called.
2) Initialisation of the X server connection and Qt toolkit.
3) Overhead by the KDE framework
4) Overhead by the application
Since the goal is to bring the startup-performance within 0.3 secs, each
contributor may spent on average 75ms.
I mention 2), 3) and 4) to make clear that the startup-performance is not tied
to a single element. However, each of these contributors places a limit on
the best achievable performance. I will continue to refer to 2), 3) and 4)
wrt performance for reference, but apart from that they are beyond the scope
of this paper.
As an example I have split up the startup times of the 'kedit' application
into 1), 2), 3) and 4), times are measured on a Pentium III running at 500Mhz.
All data is assumed to be already in memory so disk access should not play a
role.
Table1:
Activity Time Spent
Linking 0.65 sec
Qt app. constructor 0.13 sec
KDE app. constructor 0.11 sec
KEdit specific init 0.48 sec
---------------------------------------------
Total 1.37 sec
This illustrates that run-time link performance is the major bottleneck when
it comes to providing a "fast" desktop environment.
2. Run-time linking investigated.
=================================
The task of the runtime linker is to link an application to the shared libraries
it needs. There are several steps involved in this process. These steps involve:
1) Finding the shared libraries that are needed
2) Loading the shared libraries into the address space of the process.
3) Relocating addresses in the library to reflect the location in the address
space the library was loaded to.
4) Resolving undefined symbols in a library and/or the executable by searching
for these symbols in the other libraries.
All these steps, with exception of step 3, are optimized. It is step 3 that is
causing the problems:
1) Finding shared libraries is optimized by means of the /etc/ld.so.cache. The
ldconfig utility builds an index of all libraries found in the default library
locations and stores this index information in /etc/ld.so.cache. This cache
allows the linker to lookup libraries faster than if it had to search the file
system itself when looking for a certain library. If a library is not found in
the cache, the linker has to search the filesystem anyway.
2) Loading of shared libraries is cached by the Linux kernel. Only the first
application that needs a certain library needs to actually load the library
from disk. Subsequent processes that need the library will make use of the same
copy that already resides in memory.
This is further optimized by the fact that the Linux kernel only loads parts of
the library (on a page by page basis) when these parts are actually used.
4) Not all symbols are resolved at startup. Only when a symbol is used it is
being resolved. This is called lazy binding. By specifying "LD_BIND_NOW=t"
before starting an application, we can instruct the linker not to use lazy
binding and to resolve all symbols at startup. The following table shows
the results of lazy binding for the startup time of KEdit.
Table 2:
Lazy Binding Time needed for linking
On 0.65 sec
Off 1.17 sec
Symbol lookup is further optimized by the use of hash tables which makes the
lookup of symbols very efficient.
Lets now have a closer look at what happens in step 3)
Every library that is needed by an application gets loaded to an address that
is unique within that process. This address may vary each time the library is
loaded. Code that references addresses in the library must be adjusted for the
address the library is loaded to, this is called relocation. As mentioned before,
libraries are shared between different applications and processes. However,
the relocation performed can be different from process to process, as such,
those parts of the library that need to be relocated are not shared.
Let's now have a look at some numbers. When we compile and link the following
very simple application:
main(int argc, char *argv[]) { return 0; }
we will see that the startup time is determined by the number of libraries
this code is linked against. More accurately formulated, the startup time is
largely determined by the number of relocations that have to be performed.
The number of relocations can be counted by setting "LD_DEBUG=statistics".
The number of relocations and the start up time is measured independently
in case measuring the number of relocations slows down the relocation process.
LD_DEBUG=staticstics only counts the number of relocations that require a symbol
lookup.
In the following table, the startup time is listed as a function of the
libraries linked. Since the libraries depend on each other, each line also
implies the libraries listed above it. E.g. all data is cummulative.
Table 3:
Lazy Binding Bind all on startup
Libraries Relocations Time Relocations Time
C++ 945 0.01 1754 0.01
Qt *) 22176 0.12 32892 0.20
DCOP 22407 0.14 33669 0.24
kdecore **) 25095 0.20 39911 0.37
kdeui 42157 0.34 61586 0.60
kio ***) 43739 0.44 64978 0.78
kfile ****) 48915 0.60 73848 1.10
kspell 49366 0.66 74707 1.22
*) implies Xext, X11, SM, ICE, Xft, png, z, jpeg, Xrender
**) implies kdefakes, dl
***) implies kdesu, fam
****) implies ksycoca
Not only does the relocation take CPU time, it also uses up memory.
Table 4:
Lazy Binding Bind all on startup
Libraries Dirty Pages *) Dirty Pages
C++ 28 28
Qt 135 135
DCOP 137 137
kdecore 162 162
kdeui 189 189
kio 197 197
kfile 211 211
kspell 213 213
*) The last field of /proc//statm. (Linux 2.2.18)
Memory usage seems to be mostly caused by the .data sections of the libraries
which contain the vtables, and to a lesser extend by the .got section.
The following table shows the memory usage split by section. The table lists the 4
biggest libraries. Listed as "kedit" is the sum for all libraries (as well as the kedit
executable itself)
Table 4a:
.got .data .bss
libqt 44Kb 131Kb 19Kb
libkdecore 15Kb 17Kb 7Kb
libkdeui 24Kb 76Kb 4Kb
libXft 1Kb 5Kb 72Kb
kedit 129Kb 308Kb 160Kb
The next table shows the number of relocations per relocation type.
Relocations in the .got section are of type R_386_JUMP_SLOT and R_386_GLOB_DAT.
Relocations in the .data section are of type R_386_32 and R_386_RELATIVE.
Relocations of type R_386_32, R_386_JUMP_SLOT, R_386_GLOB require a symbol
lookup.
Relocations of type R_386_JUMP_SLOT are delayed until needed, unless
"LD_BIND_NOW" is specified.
Table 4b:
R_386_REL R_386_32 R_386_JUMP_SLOT R_386_GLOB_DAT
libqt 5124 17090 8515 2688
libkdecore 813 1719 3331 499
libkdeui 684 15547 4687 1529
libXft 2074 46 189 34
kedit 21021 43311 25866 7160
Since each relocation modifies 4 bytes of memory, so we can tranlate the above number
to Kb of memory affected:
Table 4c:
R_386_REL R_386_32 R_386_JUMP_SLOT R_386_GLOB_DAT
libqt 20Kb 67Kb 33Kb 10Kb
libkdecore 3Kb 7Kb 13Kb 2Kb
libkdeui 3Kb 61Kb 18Kb 6Kb
libXft 8Kb 0Kb 1Kb 0Kb
kedit 82Kb 169Kb 101Kb 28Kb
This shows that on average 100% of the .got section is affected by R_386_JUMP_SLOT
and R_386_GLOB_DAT relocations and 81% of the .data section is affected by R_386_REL
and R_386_32 relocations.
It is interesting to note that multiple R_386_32 entries can point to the same
symbol:
The following table lists the number of total R_386_32 entries per library as
well as the number of unique symbols referenced.
Table 4d:
R_386_32 Unique Symbols
libqt 17090 4377
libkdecore 1719 806
libkdeui 15547 2518
libXft 46 30
Caching symbol lookups related to R_386_32 relocations might give considerable savings.
Is this a KDE specific problem?
===============================
That depends on how you look at it. The problem of long startup times is caused
by the linker needing to do many relocations. In the case of KDE, these
relocations are for a great deal caused by vtable entries. KDE and Qt make
liberal use of virtual functions and inheritance. In general every class that
inherits from a base class with virtual functions will need to provide a vtable
that covers at least the virtual functions of this base class. It seems that
each vtable entry causes a relocation, and worse, a relocation that can not be
done lazy.
An example:
A class 'base' that defines 10 virtual functions will define a vtable for these
10 functions. All these functions need to be relocated at startup resulting in
10 relocations.
When I now define a class "derive" that inherits "base" and that overrides a
single virtual function, I will get a second vtable. I now need 20 relocations.
Qt is based on two fundamental classes, QObject and QWidget. QObject defines
about 8 virtual functions. QWidget about another 80.
As a test the following (dummy) class was added to a KDE library, the class
overrides an existing virtual function. The class was not used in any way.
By adding this class the number of relocations on startup increased with
110.
class TestClass : public QWidget
{
public:
TestClass() : QWidget() { }
virtual void initMetaObject() { QWidget::initMetaObjet(); }
};
Now it becomes clear why linking kdeui, a library that mostly defines widgets
who all inherit from QWidget, introduces 17000 additional relocations.
So to come back to the question, is this issue specific for KDE? Maybe.
As for a comparison. The GNOME 'gedit' application requires 2043 relocations
with lazy binding versus 9755 relocations with complete binding. It seems
that this application, written in C, takes more advantage of lazy binding
than applications in the KDE framework.
The following code was placed into a library as a test case:
#include <qwidget.h>
template<int T> class testclass : public QWidget
{
public:
virtual void setSizeIncrement(int w, int h) { QWidget::setSizeIncrement(w+T, h+T); }
};
template class testclass<1>;
...
template class testclass;
Note that these classes are not being used in any way. They only get defined.
In the table below the runtime startup performance versus the number of
classes is shown:
Table 5:
Number of Lazy Binding Delta Delta
Classes Relocations Time Relocations Time
1 23128 0.19 0 0.00
2 23237 0.19 109 0.00
3 23346 0.20 218 0.01
5 23564 0.20 436 0.01
10 24109 0.20 981 0.01
20 25199 0.21 2071 0.02
30 26289 0.22 3161 0.03
50 28469 0.23 5341 0.04
100 33919 0.28 10791 0.09
200 44819 0.36 21691 0.17
Each extra class introduces an extra 109 relocations and such a relocation
takes on average 8e-6 sec (CPU dependent).
4. A dirty hack: kdeinit
========================
Within KDE we have been looking for a solution to this problem. We found a
workable solution ("hack") which addresses the problem but think that a more
generic, fundamental and clean solution is in place.
The kdeinit solution is based on the notion that instead of launching
applications from scratch, we start a process that links against all important
KDE libraries. We then keep this process around in this "preloaded" state and
when we need to start an application, we let this process fork() and start the
application by dlopen'ing the application.
Their are 3 problems with this approach:
1) It is specific for KDE and KDE libraries
2) The application needs to be build as an ELF shared object instead of as a
ELF executable.
3) All your processes are called 'kdeinit'.
The two main advantages are worth this trouble though:
1) Application startup performance is improved with 0.65 sec on average.
(On 500Mhz PIII, this number is highly CPU bound)
2) Memory usage is reduced with about 800kb per process.
5. Suggestions
==============
There are two routes to improvement.
1) Improving efficiency of C++ vtable linking
One solution could be to make run-time
linking of vtables more efficient. If the linking/relocation of vtables could
be postponed till the first object of that class gets constructed, I expect that
the number of relocations during startup will drop dramatically if lazy binding
is enabled. KDE applications show a ratio of about 2:3 between
lazy and non lazy binding. The gedit example had a ratio of 1:5. If lazy binding
of KDE applications can be improved to a ratio of 1:5 the number of relocations
during startup would drop from 49366 to about 15000, which would result in the
link time dropping from 0.65 sec to 0.20 secs if we assume a linear relation.
2) pre-relocation/linking of libraries.
Another solution would be to add support for pre-relocating/linking libraries
in the linker. This solutions is IMO a more correct approach since it solves
the problem in a more fundamental way. The fundamental problem is that we are
doing a large number of relocations, over and over again (each time a KDE
application is started) basically we have a problem and solve that problem
over and over again. If we would solve the problem once and then reuse the
result we can save a lot CPU cycles instead of postponing the use of those
CPU cycles as we would do with solution 1.
There are a few decisions one can make when pre-relocating libraries.
Who will pre-relocate/link and when? Are the results stored on disk or in
memory? Are the results shared between different users?
When linking a library (and to a smaller degree when relocating) the result
is dependent on the other libraries. That means that the validity of a
pre-relocated/linked library depends on the other libraries that it depends on.
With kdeinit this problem is solved in an easy but crude way. When kdeinit
starts the libraries that are to be used are fixated, changes made to a library,
like upgrades, will not take effect until kdeinit is restarted. This way
the pre-relocated/lnked set of libraries will always remain in a consistent
state.
Although I consider this a crude way, it should be noted that most of the time,
especially if the owner of the system is not a KDE developer him or herself,
libraries do not change. Assuming that someone updates his system once a month,
that means that 29 out of 30 days his libraries remain the same.
6. Interesting papers
=====================
Dynamic Linking and Loading
http://iecc.com/linker/linker10.html(...)
Cross-Address Space Dynamic Linking
http://www.sun.com/research/techrep/1992/smli_tr-92-2.pdf(...)
High Performance Dynamic Linking Through Caching
http://www.usenix.org/publications/library/proceedings/cinci93/full(...)
Neutrino (R) System Architecture Guide -
Dynamic Linking in Neutrino
http://www.qnx.com/literature/nto_sysarch/dll.html(...)
Linker and Libraries Guide
http://docsun.cso.uiuc.edu:80/cgi-bin/nph-dweb/ab2/coll.45.5/LLM/@A(...))#CHAPTER6-35405?
M. Franz. Dynamic linking of software components.
IEEE Computer, vol 30, no 3, pp 74-81, March 1997.
SGI's IRIX "rebases" libraries which eleviates the need for actual
relocations, as descried by Shankar Unni in the following mail:
http://www.suse.de/~bastian/Export/linking_sgi.msg(...)
7. Change History
=================
Version 1.0:
Initial version
Version 1.1:
Added Change History
Added Table numbering
Added Table 5
Version 1.2:
Added Table 4a, 4b and 4c.
Added note that LD_DEBUG=staticstics only counts the number of relocations that
require a symbol lookup.
Added suggestion to cache symbol lookups related to R_386_32 relocations (Table 4d)
Version 1.3:
Added note that this paper describes gcc 2.95.
Added reference to SGI's IRIX.
[^] # Re: Openoffice.org RC3
Posté par peau chat . En réponse à la dépêche Openoffice.org 1.1 RC3. Évalué à 2.
# Re: Projet de refonte du site Internet de la ville de Lyon
Posté par peau chat . En réponse à la dépêche Projet de refonte du site Internet de la ville de Lyon. Évalué à 7.
[^] # Re: précisions glanées sur slashdot (les copieurs!)
Posté par peau chat . En réponse à la dépêche Le projet Kroupware est achevé : parution de Kolab.. Évalué à 3.
et migrer de SQL-Server vers Sybase est *TRES* facile.
(à l'origine SQL-Server est une version Windows de Sybase).