Ubuntu-fr

neeux

Re : Linux Comment Ca Marche ?

C'est marrant je me suis posé les mêmes questions quand j'ai démarré sous Linux...

Pour ajouter un réponse à ta question sur les dépendances. Les dpendances sont directement liées au principe de logiciel libre.
Prenons un exemple bidon:
- Sous Windows avec photoshop tu as la possibilité de convertir une image jpeg en png.
PaintShop Pro t'offre la même possibilité. Mais les deux programmes utilisent un code qui leur est propre pour faire cette même tâche.  En effet Adobe ne donnera certainement pas une partie de son code à son rival...

- Sous Linux tu as la librairie Libjpegtopng (c'est un exemple bidon hein...) que tous les prog de retouche d'image peuvent utiliser puisque cette librairie est un logiciel libre.
Pourquoi les logiciels qui en ont besoin ne l'integrent pas? Pour éviter les conflits... Si le prog1 installe la version1.1 et le prog2 la version1.2 ca risque de poser des problèmes...

- Moralité les développeur ne se prennent pas (trop) la tête à réinventer la roue, ils utilisent ce que d'autre ont déjà fait. Elle est pas belle la vie.

<AvisPerso>Selon moi cette façon de faire est un gage de qualité</AvisPerso>

En ce qui concerne tes questions sur le blackberry et le mode push pour des terminaux WM. Ils n'y a pas de solution libre 100% miracle.

La meilleur solution est selon moi sync4j: http://www.funambol.com/opensource/

Par contre pas de mode push. C'est du manuel. Mais c'est libre avec un client BlackBerry, WindowsMobile, Outlook etc... Ils peut se synchroniser avec le groupware libre Kolab.

J'ai testé cette solution il y a un an environ, Ca marche vraiment bien et c'est très agréable à l'utilisation et l'administration. De plus le développement autour de c est assez simple car c'est du syncml

kilhian

Re : Linux Comment Ca Marche ?

en parlant de GPO (Group Policy Object)
c'est la façon de gerer les utilisateurs/ordinateurs par groupe.

Un strategie qui permet de dire par exemple le fond d'ecran par defaut sera xxx.jpg
l'installation des imprimantes
Activer/Desactiver les macros par defauts
Donner des droits ou en enlever...
ca remplace avantageusement le login script ...

aleph

Re : Linux Comment Ca Marche ?

> neeux
Le problème des bibliothèques, je préfère ce mot à dépendance, n'a pas grand chose à voir avec le logiciel libre, c'est un aspect inhérent à tous les OS que ce soit Linux, Windows, Mac OS X ou un BSD.

Ce n'est pas un sujet simple. Ta vision est correcte, mais mérite d'être complétée et nuancée.
Pour prendre ton exemple et en laissant de côté les problèmes de licences, de brevets, etc., c'est justement pour être indépendants de Libjpegtopng que Photoshop ou Paint Shop Pro ont leur propre bibliothèque. Autrement dit, une modification de Libjpegtopng ne nécessite pas de modification de Paint Shop Pro ou Photoshop.

Si tu as 10 applications, A, B, C... qui utilisent Libjpegtopng, il faut que A, B, C, ... et Libjpegtopng soient "au même niveau". Une modification de Libjpegtopng implique une modification de toutes les dix applications, c'est un peu le cauchemar de tout développeur.

Grosso modo, c'est ce qui se passe dans un dépôt d'une distribution Linux, toutes les applications sont et doivent être au même niveau, d'où l'énorme travail de maintenance des dépôts.

Le côté un peu pervers des dépôts vient de la multiplication des distributions de Linux. Dans la pratique et toujours pour reprendre ton exemple, il se trouve que les distributions Linux n'utilisent pas toutes la même version de Libjpegtopng, ce qui implique qu'il est nécessaire d'avoir des dépôts parallèles.

Un point qui n'est pas souvent mentionné et qui complique la situation. Les bibliothèques tierces ou externes qui ne seront jamais intégrées dans un dépôt parce ce que trop spécifiques ou d'une utilité générale faible, à quelle version de Libjpegtopng doivent-elles faire référence ?

Tu vois, il y a du pain sur la planche. Tout dépend, si l'on se place du côté utilisateur ou développeur.

Le sujet a été discuté pour la n-ième fois sur osnews. Il y a de très bonnes interventions.
http://www.osnews.com/comment.php?news_id=16176&limit=no&threshold=-1

Pascal S

Re : Linux Comment Ca Marche ?

Grosso modo, c'est ce qui se passe dans un dépôt d'une distribution Linux, toutes les applications sont et doivent être au même niveau, d'où l'énorme travail de maintenance des dépôts.

Une question de béotien pour rebondir sur ce point : pourquoi plusieurs versions d'une bibliothèque ne pourraient-elles pas coexister dans les dépôts et ainsi permettre la présence d'applications de niveaux différents. Evidemment ça compliquerait quelque peu la gestion des dépendances, mais rien d'insoluble pour des outils comme aptitude je pense.

Exemple :
On installe l'application A1.2 qui utilise la bibliothèque B2.6
On veut ensuite installer l'application C6.0 qui utilise B2.8
Dans le système actuel (si j'ai bien compris) il faut donc mettre à jour B2.6 vers B2.8
Manque de chance A1.2 ne fonctionne pas avec B2.8
---> on est coincé
Dans un système plus souple :
On installe B2.8 en parallèle de B2.6
--> on peut utiliser A1.2 et C6.0
Le jour où on passe à A1.3 qui fonctionne avec B2.8, le gestionnaire de paquets détecte que B2.6 n'est plus utile et le désinstalle éventuellement (un peu comme deborphan).

Cela dit, je débarque et tout ça a sûrement déjà été pensé, évoqué, réfléchi puis réfuté. Mais je ne vois pas pourquoi ça ne marcherait pas. La seule difficulté que j'imagine par rapport à l'exemple est que A1.2 doit contenir l'info qu'elle n'est pas compatible avec B2.8 (qui n'existe pas encore quand A1.2 est développée !). La solution serait de mettre cette information dans B2.8 (qui doit savoir qu'elle ne respecte pas la compatiblité ascendante).

Qu'en pensez-vous ?

Dernière modification par Pascal S (Le 17/10/2006, à 11:53)

LR

Re : Linux Comment Ca Marche ?

J'aimerais juste ajouter mon grain de sel sur l'installation/désinstallation pour confirmer que le système de gestion des paquets marche super bien et que c'est certainement plus propre de l'utiliser que de compiler soi-même.

J'utilise principalement synaptic mais tu peux tout faire en ligne de commande. Dans synaptic, tu peux connaitre exactement les fichiers qui ont été installés en regardant les propriétés du paquet.

Ensuite, si tu veux vraiment un truc qui n'existe pas en paquet ou dont la version que tu veux n'existe pas, fais-en un paquet. C'est relativement complexe mais c'est propre, facile à distribuer et surtout à désinstaller.

Pour gérer les profils utilisateurs, il y a un truc qui s'appelle sabayon. J'avais essayé rapidement et ça avait l'air pas mal. Tu peux créer des profils basés sur un profil standard.

Sinon, il faut aussi regarder bash-profile mais je ne connais pas suffisamenent...

En tout cas, comme spécialiste des solutions microsoft qui se met à linux, tu fais plaisir à voir

---

La goutte d'eau de pluie

bergi

Re : Linux Comment Ca Marche ?

aleph tu connais les dll. Tu dois donc aussi connaitre le problème de programme qui te change une dll et qui fait planté d'autre programme. Personne n'a trouvé de solution miracle aux problèmes de dépendance.

Le côté un peu pervers des dépôts vient de la multiplication des distributions de Linux. Dans la pratique et toujours pour reprendre ton exemple, il se trouve que les distributions Linux n'utilisent pas toutes la même version de Libjpegtopng, ce qui implique qu'il est nécessaire d'avoir des dépôts parallèles.

Je ne te suis pas ? Dans Linux il ne faut pas oublier GNU car avec Linux tu ne fais rien. C'est bien le travail des ditribs d'organisées les dépots. Donc c'est tout à fait normal d'avoir des dépots différent suivant le choix des distributions et c'est aussi pourquoi il faut tjs préférer les logiciels qui sont dans les depots.

Dernière modification par bergi (Le 17/10/2006, à 13:15)

neeux

Re : Linux Comment Ca Marche ?

Pour prendre ton exemple et en laissant de côté les problèmes de licences, de brevets, etc., c'est justement pour être indépendants de Libjpegtopng que Photoshop ou Paint Shop Pro ont leur propre bibliothèque. Autrement dit, une modification de Libjpegtopng ne nécessite pas de modification de Paint Shop Pro ou Photoshop.

Dans ce cas pourquoi des logiciels libres comme Gimp (pour reprendre l'exemple photosop et cie) ne souhaiteraient pas aussi rester indépendant??
Rien ne les empêches d'utiliser une version qui leur convient. Et d'adapter leur logiciel lors de leur prochaine release.
Je  ne connais pas du tout le cycle de developpement de gros logiciel comme photoshop et cie.. Mais j'imagine que si il pouvait récupérer des lib à droite et à gauche ca leur serait bénéfique financièrement. (mais bon c'est une hypothèse perso, je ne connais pas du tout le systeme de fonctionnement des gros éditeur de logiciels)...

Mais comme tu dis très justement, c'est un sujet très vaste sans réponse parfaite.

Merci pour le lien

aleph

Re : Linux Comment Ca Marche ?

> Une question de béotien pour rebondir sur ce point : pourquoi plusieurs versions
> d'une bibliothèque ne pourraient-elles pas coexister dans les dépôts et ainsi
> permettre la présence d'applications de niveaux différents. Evidemment ça
> compliquerait quelque peu la gestion des dépendances, mais rien d'insoluble
> pour des outils comme aptitude je pense...

La réponse est à la fois simple et complexe si je puis dire.

Techniquement, rien n'interdit d'avoir plusieurs versions de la même biblio-
thèque sous des noms différents, ex. LibjpegtopngV1, LibjpegtopngV2 etc. et chaque
applications utilise la bibliothèque qui lui convient.

Humainement, d'autres arguments interviennent. Il y a des gens qui pensent
qu'avoir plusieurs versions d'une bibliothèque qui doit faire le même travail est
un gaspillage de resource.
D'autres pensent qu'il faut si possible une version idéalement unique à laquelle
toutes les applications se tiennent. L'inconvénient étant principalement ici,
le fait qu'un changement de bibiothèques implique un changement dans toutes
applications utilisatrices.

Pour compliquer le tout, les bibliothèques à disposition ne sont pas toutes considérées
comme d'égale importance. Il y a des bibliothèques qui sont plus vitales à un OS que
d'autres, les bibliothèques sans lesquelles l'os ou l'interface graphique ne pourrait
pas fonctionner, par ex gdi32.dll sous Windows ou les bibliothèques de base de gtk
pour Ubuntu.

La discipline face à ces bibliothèques varient fortement d'os à l'autre. Les BSD
ont un ensemble de bibliothèques de base très rigide. Linux ou les Linux sont plus
souples. Cet ensemble varie fortement d'un distribution à l'autre.
Sous Windows, le cas est plus nébuleux. Dans l'exemple gdi, il y a des applications
qui utilisent directement gdi32.dll et des applications qui utilisent
des bibliothèques graphiques que dépendent de gdi32.dll. Ce sont générallement
ces dernières qui posent des problèmes.

Il y a des logiciels (applications ou bibliothèques) qui proposent le choix de la
bibiothèque, parce que les développeurs l'ont voulu ainsi. Pas exemple, il est
possible avec wxPython ou pyGTK de choisir la version utilisée, c'est le
"multiversioning". Il faut bien sûr que ces bibliothèques soient toutes disponibles.

> Exemple :
> On installe l'application A1.2 qui utilise la bibliothèque B2.6...

Tu as tout compris.

>Cela dit, je débarque et tout ça a sûrement déjà été pensé, évoqué, réfléchi
puis réfuté.

Oui. Comme expliqué ci-dessus ou dans mon précédent message, cela dépend plus
de la volonté et de la discipline des développeurs que d'un choix technique. Il y
des discussions assez soutenues entre les défenseurs des deux camps. Voir,
par ex, les discussions à propos des .pbi utilisées avec PC-BSD.

> J'aimerais juste ajouter mon grain de sel sur l'installation/désinstallation
> pour confirmer que le système de gestion des paquets marche super bien
> et que c'est certainement plus propre de l'utiliser que de compiler soi-même.

Entièrement d'accord avec, toi. Le but est d'utiliser un dépôt et uniquement
celui-ci. Dans le sens, un/le dépôt dédié à une distibution.
L'ensemble des applications disponibles devant/pouvant servir à "l'utilisateur
moyen" (quelle terme assez vague!).

> J'utilise principalement synaptic ...
Ici, l'on parle d'autre chose. Le déploiement des bibliothèques citées plus haut,
et non pas des bibliothèques elles-mêmes. C'est un autre domaine, quoique très
fortement lié.

> En tout cas, comme spécialiste des solutions microsoft qui se met à linux,
> tu fais plaisir à voir.
Microsoft ou Linux n'ont pas grand chose à voir là-dedans. J'exprime (dû moins
je l'espère) une compréhension que tout développeur devrait avoir et qui est
indépendante des os. Cela dit, j'ai bossé longtemps sous Unix (Ultrix pour
être précis).

> aleph tu connais les dll. Tu dois donc aussi connaitre le problème de
> programme qui te change une dll et qui fait planté d'autre programme.
Bien sûr. Là, il faut voir deux problèmes distincts.
1) Les versions des dll.
2) Et leurs utilisations par l'application appelante. Ce qu'il faut
comprendre est le concept de "userland" des applications. Dans les versions,
win 3.1, 95, ... une dll est utilisée et partagée par plusieurs applications.
Sous Windows 2000, xp, les "userland" de chaque application sont séparés, quitte
à ce qu'une dll soir chargée plusieurs fois dans la mémoire. Explication très
schématique, ce qui explique pourquoi sous win 3.1, 95... une application
peut faire planter tout le système. Beaucoup plus rare sous Windows 2000
et xp.

> Personne n'a trouvé de solution miracle aux problèmes de dépendance.
Hélas oui.

>Je ne te suis pas ? Dans Linux il ne faut pas oublier GNU car avec Linux
tu ne fais rien.
Je mets Linux et GNU/Linux dans le même paquet.

> C'est bien le travail des ditribs d'organisées les dépôts. Donc c'est
> tout à fait normal d'avoir des dépots différent suivant le choix des
> distributions et c'est aussi pourquoi il faut tjs préférer les
> logiciels qui sont dans les depots.
Oui je suis bien d'accord. Le gros problême étant de savoir ce que
les mainteneurs de dépôts veulent bien mettre et maintenir.
Dans l'idéal tout; dans la pratique c'est un peu plus compliqué, on
ne peut pas prétendre maintenir une cohésion pour un nombre infini
d'applications. Le cas est particulièrment aigu avec les bibliothèques
ou applications tierces; qui doit faire le travail ? les mainteneurs
du dépôt ou les développeurs des applications ?
Que faire face au nombre croissant d'applications. Si 50 millions
d'applications existent pour Ubuntu dans 50 millions de dépôts
différents, devrais-je mettre 50 millions de lignes dans mon
source.list ? Et le problème des versions des bibliothèques
n'est toujours pas réglé.
C'était le thème de la "keynote presentation" de Mark Shuttleworth
à l'Eurooscon (bien mal relayé d'ailleurs).

> Dans ce cas pourquoi des logiciels libres comme Gimp (pour reprendre
l'exemple photosop et cie) ne souhaiteraient pas aussi rester indépendant??

C'est le choix du/des développeurs de Gimp. A noter, que le cas est un
peu particulier. Gimp, à la base, c'est deux choses, un toolkit et une
application. Le toolkit a été repris et optimisé par la suite pour
devenir le toolkit de GNOME (GTK == Gimp Tool Kit).

> Rien ne les empêches d'utiliser une version qui leur convient.
> Et d'adapter leur logiciel lors de leur prochaine release.
Comme dit plus haut, l'adaptation des logiciels à un changement de bibliothèques
est très souvent un gros travail.

::: expérience personnelle :::
J'ai l'intention de porter toutes mes applications sous Python 2.5 et wxPython 2.7
(voire 2.8). Il y en a pour des mois. Il est à noté qu'une grande partie, de
ces applications ne tourneraient pas sous Linux, les bibliothèques n'existant plus
et ayant été modifiées. Grâce à la "magie" des liaisons statiques toutes les
applications fonctionnent. Il y en a qui utilisent encore Python 2.1 !
::::::

> Mais j'imagine que si il pouvait récupérer des lib à droite et à gauche ca
> leur serait bénéfique financièrement.
Pas nécessairement. Une bibliothèque peut-ètre utilisée par plusieurs procduits.
Avoir un contrôle de sa bibliothèque est parfois plus aisé. Dans l'idée, un tien
vaut mieux que deux tu l'auras.
Pour une application grosse et complexe, il est parfois très agréable d'avoir
le plus grand contrôle possible, quitte à utiliser une bibliothèque considérée
comme dépassée.
Il faut aussi savoir et réaliser que la plupart - pour ne pas dire la majorité - des
applications logiciels n'atteignent jamais le grand public et sont utilisées en "interne".

>Mais comme tu dis très justement, c'est un sujet très vaste sans réponse parfaite.
Eh, oui.

PS J'ai composé ce document hors-ligne et ne suis pas au courant des derniers
commentaires.