Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

pidgin et googletalk

17 réponses
Avatar
Jo Engo
Bonjour, excusez le léger HS, je n'ai pas trouvé de forum adéquat, mais
la solution que je cherche est sous linux, donc…

j'essaie de me connecter à googletalk avec pidgin et ça coince (pidgin
envoie du xmpp à google qui apparamment n'aime pas) , y a-t-il un truc ?
Quelle autre messagerie instantanée puis-je utiliser éventuellement ?

Heu déjà le divorce entre google et xmpp est consommé :
FAQ: Open Communications | Google Talk for Developers ...
We announced a new communications product, Hangouts, in May 2013.
Hangouts will replace Google Talk and does not support XMPP.

--
On peut avoir des if imbriqués mais pas de Else imbriqués.
-- Jayce - Limitations --

7 réponses

1 2
Avatar
Philippe Weill
Le 10/11/2018 à 10:44, zeLittle a écrit :
Le Sat, 10 Nov 2018 10:16:37 +0100, Pierre www.aribaut.com a écrit:
J'aurais pensé qu'un fichier d'installation au format .deb cela marche sur debian ET dérivés.

Avec mes petites compétences des *nix, je réponds: .deb marche sous Debian et dérivés (je dirais même plus, il existe des programmes
pour transformer un paquet red hat - .rpm, je crois - en .deb, et inversement.

alien pour transformer rpm en . deb
maintenant pour le fond du probleme , je ne dirais pas ".deb marche sous Debian"
quand on commence a faire cela il n'y a plus beaucoup de garantie
les systemes de package sont fait pour gérer des dépendances entre les différents paquetages
donc en installant un package qui proviens d'une autre distribution
il peut refuser de s'installer( si tu trouve une solution pour passer outre en général tu arrive au point suivant
il peut s'installer mais (ne pas ou mal ) fonctionner
enfin eventuellement s'installer et fonctionner
attention aussi au niveau de version des distributions
le .deb de l'ubuntu 18 tu auras du mal à le mettre sur une debian 6
En passant: le top pour installer un *.deb sous xUbuntu, c'est de le télécharger, de se rendre - via la console si nécessaire dans
ce répertoire ("$ cd /.../.../archives"), et d'utiliser l'application gdebi (faire "$ sudo apt-get install gdebi", si elle n'est pas
présente sur ton poste; je ne sais pas si elle a une interface graphique).
Avatar
Jo Engo
Le Sat, 10 Nov 2018 10:55:43 +0100, Pierre www.aribaut.com a écrit :
Je ne suis pas encore assez geek pour dire "moi je ne veux que de la
ligne de commande" ;)

Personnellement je trouve plus simple :
$ cd /path-to-deb/
$ sudo dpkg -i
que lancer /explorer / ; cliquez droit puis clicliclicker, je préfère le
cli (/command line interface /)
Parce que si _en plus_ il faut ouvrir un /explorer / je dis pouce.
--
PHILOSOPHIE : Toujours en ricaner.
-+- Gustave Flaubert, Dictionnaire des idées reçues -+-
Avatar
zeLittle
Le Sat, 10 Nov 2018 10:56:52 +0100, Jo Engo a écrit:
Le Sat, 10 Nov 2018 10:44:11 +0100, zeLittle a écrit :
application gdebi

ça roxe mieux que 'dpkg -i' ?

Perso., y' des .deb que je n'ai jamais réussi à installer avec 'dpkg -i'
(rares, mais ça m'est arrivé). Alors que je n'ai jamais é té bloqué avec
'gdebi' (je touche du bois).
Avatar
Doug713705
Le 2018-11-10, zeLittle nous expliquait dans
fr.comp.os.linux.configuration
() :
J'aurais pensé qu'un fichier d'installation au format .deb cela marche
sur debian ET dérivés.


Arretez de "penser que", documentez-vous et éventuellement expérimentez
dans une VM.
Avec mes petites compétences des *nix, je réponds: .deb marche sous Debian
et dérivés (je dirais même plus, il existe des programmes pour transformer
un paquet red hat - .rpm, je crois - en .deb, et inversement.

Probablement un des meilleurs outils pour flinguer un système, qu'il soit
RedHat ou Debian.
Avant d'utiliser ce genre d'outil il convient de *bien* avoir compris ce
que sont les bibliothèques dynamiques partagées (les fameux fichier *.so)
et comment elles peuvent être liées entre elles (les fameuses
dépendences) pas uniquement en fonction de leur nom mais aussi en
fonction de leur numéro de version.
Installer un RPM issu de RedHat en le convertissant en .deb et espérer
que tout fonctionne revient à allumer un cièrge à Lourdes en espérant
que le monde s'améliore.
En passant: le top pour installer un *.deb sous xUbuntu, c'est de le
télécharger, de se rendre - via la console si nécessaire dans ce
répertoire ("$ cd /.../.../archives"), et d'utiliser l'application gdebi
(faire "$ sudo apt-get install gdebi", si elle n'est pas présente sur ton
poste; je ne sais pas si elle a une interface graphique).

Ça aussi c'est n'importe quoi (enfin pas que mais quand même).
Si le paquet n'est pas disponible dans les dépôts officiels, il y a
probablement une bonne raison (projet pas mûr dans la version souhaité,
incompatibilité avec d'autres composants fournis par la distribution,
problème de licence, etc).
Dans certain cas, il est possible d'installer un .deb "à la main" mais
s'il vient d'une autre version ou d'une autre distribution il y a toutes
les chances que rien ne fonctionne voire que le système soit détruit par
des modifications de certains fichiers de configuration.
Les paquets .deb, .rpm et compagnie embarquent certains scripts qui sont
executés avant et/ou après l'installation du paquet. Ces scripts seront
executés en tant que root et peuvent embarquer des commandes totalement
inadaptées à la situation. Je te laisse imaginer les dégats possibles
dans ces conditions.
Il est un cas qui nécessite l'installation manuelle, ce sont les
logiciels *directement* fournis leur éditeur et non inclus dans la
distribution (souvent des logiciels payants et non libres).
Les installer comporte un risque mais ce risque est en partie de la
responsabilité de l'éditeur.
Ne reproduisez pas sous Linux les comportements qui vous ont été
inculqués lors de vos années sous Windows.
Sauf cas particuliers:
- Vous n'avez pas besoin de la dernière version du logiciel à la mode
- Vous n'avez pas besoin du dernier noyau à la mode
- Vous n'avez pas besoin d'installer des applications tierces qui ne
seraient pas les dépôts d'une grande distribution comme RedHat ou
Debian dont les dépôts dégueulent de paquets en tout genre
- et surtout, vous n'avez pas besoin de télécharger des paquets à partir
de sites plus ou moins douteux pour les installer sur votre système.
Encore moins si ces paquets ne sont pas initialement prévus pour votre
distribution (et penser qu'un deb pour stretch fonctionnera sur wheezy
(ou le contraire) et également une erreur).
Ppur tous les autres cas, téléchargez les sources, compilez les et
empaqueter le produit de compilation en suivant les règles de l'art
fournies par votre distribution.
C'est beaucoup plus simple qu'il n'y paraît, vous aurez appris quelque
chose qui vous ouvrira à tout un nouveau champs de compréhension et vous
ne casserez pas votre système.
--
Bourlinguer... errer,
Errer humanum est.
-- H.F. Thiéfaine, Errer humanum est
Avatar
Doug713705
Le 2018-11-11, zeLittle nous expliquait dans
fr.comp.os.linux.configuration
() :
*.so == *.dll.
Sous Windows, on parlait et parle toujours de l' "enfer des dll" ( car
celui peu scrupuleux, celui qui installe le dernier sa version de dll
partagée pour faire fonctionner son logiciel, quitte à ce que d'autres
logiciels ne fonctionnent plus... a gagné. D'où la nécessité de toujours
faire en sorte d'installerprivilégier l'installation de *.dll*.so de
programmes utilitaires dans le même répertoire que le logiciel et de les
coupler avec ledit programme - via son fichier de configuration - quitte à
dupliquer la même *.dll*.so avec des versions différentes pour chaque
programme l'utilisant :- ).
Le partage de code entre programmes via ces librairies, rencontre les
mêmes problèmes sous tous les OS.

Sous Linux les bibliothèques sont insatllées dans l'un des chemins
référencés dans /etc/ld.so.conf.
Lorsque ce fichier est mis à jour il est nécessaire de lancer
l'utilitaire ldconfig afin que ces chemins soient pris en compte par le
système.
D'autres astuces existent également pour précharger certaines
bibliothèques ou faire d'autres opérations.
man ld.so
man ldconfig
man ldd
Installer les applications avec leur bibliothèques dans un répertoire
spécifique à chaque application comme le fait flatpack va à l'encontre
de l'idée d'objet partagé (SO = Shared Object) dont le but est justement
de faire en sorte qu'une même bibliothèque n'ait pas besoin d'être
installée N fois pour N applications si N > 1.
Ce point est une question de philosophie. Les deux solutions ont leurs
avantages et incovénients.
Les différentes versions d'une même bibliothèque peuvent être installées
conjointement. Une convention de nommage et ensemble de liens symboliques
permettent à chaque application de s'y retrouver.
Cependant un administrateur peu regardant qui aurait l'idée d'installer
un paquet d'origine peu sûre (!= de ceux proposés par les dépôts
officiels) s'expose à ce que certaines bibliothèques soient remplacées,
que certains liens soient cassés ou plus simplement que la version
nécessaire d'une bibliothèque soit manquante sur le système.
Ces problèmes ne surviennent *jamais* si les dépôts officiels sont
utilisés. C'est précisément l'un des objectifs des dépôts centralisés
et des outils tels que apt-get, synaptic, yum, et compagnie.
Si malgré tout ce genre de soucis arrivent en utilisant les dépôts
officiels, changer de distribution devient une urgence.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Avatar
Nicolas George
Doug713705 , dans le message <psa62t$ji0$, a
écrit :
Cependant un administrateur peu regardant qui aurait l'idée d'installer
un paquet d'origine peu sûre (!= de ceux proposés par les dépôts
officiels) s'expose à ce que certaines bibliothèques soient remplacées,
que certains liens soient cassés ou plus simplement que la version
nécessaire d'une bibliothèque soit manquante sur le système.

C'est vrai, mais si la bibliothèque elle-même a des développeurs
vaguement compétents, alors soit les versions seront compatibles, soit
elles pourront s'installer en parallèle. Donc ce n'est pas le plus gros
problème avec les paquets tiers.
Le gros problème, c'est que si le paquet précise une dépendance à une
bibliothèque en insistant sur une version trop précise, cette dépendance
peut bloquer la mise à jour de la bibliothèque, et en conséquence
d'autres programmes qui en dépendent. Y compris des mises à jour de
sécurité.
Avatar
Doug713705
Le 2018-11-11, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5be8ac80$0$21584$) :
Doug713705 , dans le message <psa62t$ji0$, a
écrit :
Cependant un administrateur peu regardant qui aurait l'idée d'installer
un paquet d'origine peu sûre (!= de ceux proposés par les dépôts
officiels) s'expose à ce que certaines bibliothèques soient remplacées,
que certains liens soient cassés ou plus simplement que la version
nécessaire d'une bibliothèque soit manquante sur le système.

C'est vrai, mais si la bibliothèque elle-même a des développeurs
vaguement compétents,

Un "si" représente déjà un risque.
alors soit les versions seront compatibles, soit
elles pourront s'installer en parallèle. Donc ce n'est pas le plus gros
problème avec les paquets tiers.
Le gros problème, c'est que si le paquet précise une dépendance à une
bibliothèque en insistant sur une version trop précise, cette dépendance
peut bloquer la mise à jour de la bibliothèque, et en conséquence
d'autres programmes qui en dépendent. Y compris des mises à jour de
sécurité.

Cas auquel je n'avais pas pensé et régulièrement rencontré pour les paquets
fournis par certains éditeurs tiers pour des logiciels souvent payants.
--
Mais la brume est tombée trop vite
En oubliant les chats perdus.
-- H.F. Thiéfaine, La môme kaléïdoscope
1 2