Le 6 février dernier le site rpm.org a annoncé que la très attendue version 4.6 du gestionnaire de paquets RPM était disponible au téléchargement. Pendant longtemps le gestionnaire de paquets RPM a stagné sans véritable mainteneur. Cela parait incroyable mais une pièce aussi critique de l'infrastructure des distributions l'utilisant (Red Hat/Fedora, SUSE Linux Enterprise/openSUSE, Mandriva, Yellow Dog, etc.) n'avait pas vraiment de responsable ni de communauté travaillant à son développement et à la correction des bugs.
La situation s'est décantée quand Jeff Johnson, la personne qui était censée être en charge, a été invitée à aller voir ailleurs par Red Hat, son employeur. Connu pour son caractère difficile avec les utilisateurs et son entêtement à refuser de corriger certains bugs, Jeff a décidé de fonder sa propre version de RPM et il a annoncé au début de 2008 la version 5.0 de son fork.
Les distributions utilisant RPM n'ont jamais voulu utiliser la branche de Jeff Johnson et c'est la bonne vieille version 4.4.2 de RPM qui continuait d'être utilisé. En décembre 2006 a été annoncé un projet visant à relancer le développement de RPM sur des bases communautaires. Le tempo de cette reprise a été lent (près d'un an pour prendre en main le code et le nettoyer) mais ensuite les versions de remise à niveau se sont succédées (4.4.2.1, 4.4.2.2, etc.).
Enfin le 6 février a été annoncée la version majeure 4.6 qui apporte beaucoup de nouveautés et permet enfin de dire au revoir à la vieille branche 4.4.x.
- Les paquets de grande taille (jusqu'à 2^64 bits) sont gérés alors que la limite était de 2 Go auparavant ;
- La signature par somme de contrôle ne se limite plus au format de hachage par défaut MD5 mais permet d'utiliser aussi SHA256 ou SHA512. Une nouveauté importante quand on connaît les faiblesses de MD5 ;
- On peut désormais exprimer des dépendances en tenant compte de l'architecture. Cela met fin au bug qui faisait qu'on pouvait avoir le cas d'un paquet qui satisfaisait ses dépendances en allant chercher une bibliothèque existant uniquement sur une autre architecture ;
- Le support de l'algorithme de compression LZMA (désactivé par défaut pour l'instant) fait son entrée dans RPM. Cet algorithme moderne particulièrement performant promet une réduction de poids de 30 % par rapport à gzip ;
- Résolution automatique des verrouillages (locks) de la base de données rpmdb (basée sur BerkeleyDB) ;
- Messages d'erreurs revus pour être plus informatifs et meilleure gestion des erreurs pour éviter les crashs ;
- Rapidité améliorée et consommation mémoire réduite ;
- Support des architectures ARM et SH amélioré.
Aller plus loin
- L'annonce de la sortie (2 clics)
- Les nouveautés de RPM 4.6 (4 clics)
# troll.deb vs troll.rpm
Posté par psychoslave__ (site web personnel) . Évalué à -10.
# C'est utilisé ?
Posté par windu.2b . Évalué à 6.
Y a réellement des paquets de plus de 2Go ? O_o
[^] # Re: C'est utilisé ?
Posté par IsNotGood . Évalué à 9.
http://fr2.rpmfind.net/linux/fedora/releases/10/Everything/s(...)
Si rpm est utilisé pour du contenu et non seulement des programmes, les 2 Go peuvent être dépassé.
[^] # Re: C'est utilisé ?
Posté par liberforce (site web personnel) . Évalué à 4.
[^] # Re: C'est utilisé ?
Posté par Infernal Quack (site web personnel) . Évalué à 10.
# rpm -i fedora.rpm
/o\
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: C'est utilisé ?
Posté par Hippie Geek (site web personnel) . Évalué à 3.
Quand on voit les jeux récents qui tiennent sur un DVD...
[^] # Re: C'est utilisé ?
Posté par windu.2b . Évalué à 3.
[^] # Re: C'est utilisé ?
Posté par nimch . Évalué à 1.
# Re:
Posté par IsNotGood . Évalué à 4.
Sauf Mandriva notablement (et peut-être pld ?).
http://lists.mandriva.com//cooker/2007-05/msg03701.php
Il me semble que c'est dans la semaine de création de rpm5 que Mandriva a décidé d'utiliser rpm5 et abandonner rpm.
Rpm 4.6 est une version de "nettoyage". Mais beaucoup de boulot y a été fait.
Les versions suivantes seront plus innovantes.
En passant F10 a rpm 4.6 (une rc).
[^] # Re: Re:
Posté par thedidouille . Évalué à 7.
# rpm -v
RPM version 4.4.2.3
[^] # Re: Re:
Posté par Benoît Bâlon (site web personnel) . Évalué à 2.
rpm --version[^] # Re: Re:
Posté par Calvin0c7 . Évalué à 2.
-v n'existe pas, et affiche l'équivalent du --help.
[^] # Re: Re:
Posté par cram51 . Évalué à 1.
[moi@localhost ~]$ rpm -v
RPM version 4.4.2.3-rc1
Copyright (C) 1998-2002 - Red Hat, Inc.
Ce programme peut être librement redistribué sous les termes de la licence GNU GPL
alors que --version me renvoie
[moi@localhost ~]$ rpm --version
RPM version 4.4.2.3-rc1
Donc les deux affichent bien la meme chose concernant la version.
(juste pour info, concernant la version de rpm, je suis sous mandriva 2008.1 je ne sais pas pour la 2009)
[^] # Re: Re:
Posté par lolop (site web personnel) . Évalué à 1.
[laurent@localhost ~]$ rpm --version
RPM version 4.4.2.3
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Re:
Posté par thedidouille . Évalué à 5.
C'est rassurant de voir qu'il y a de la relecture de commandes sur Linuxfr.
[^] # Re: Re:
Posté par liberforce (site web personnel) . Évalué à 6.
Tu en doutais ? Parce que c'est pas les pinailleurs qui manquent ici il me semble...
[^] # Re: Re:
Posté par IsNotGood . Évalué à 3.
# fusion des différents RPM
Posté par vida18 . Évalué à 3.
http://linuxfr.org/2008/01/17/23580.html
.
[^] # Re: fusion des différents RPM
Posté par bubar🦥 (Mastodon) . Évalué à -5.
J' avoue ne pas comprendre le "enfin" du titre. Non plus le "a été invitée à aller voir ailleurs par Red Hat", car, c' est une supposition sans fondement, peut être que redhat a voulu créer un vrai rpm communautaire, ou plus de contributeurs pouvaient agir plus simplement (il me semble que les exemples de refus de redhat d' ajout de fonctions et de patchs dans rpm fait par des contributeurs, étaient assez courant :(
Peut être qu' il s' agit d' une stratégie parfaitement entendue entre Jeff Jonhson et Redhat. Peut être que je raconte n' importe quoi.
En tout cas, la dépêche est rédigée par quelqu' un semblant préféré le .deb et ça se ressent. Merci dans tout les cas, ecnore une fois.
Allez encore un effort et on aura peut être ensuite un Urpm pour tous ... :p :p (parceque le yum même en fed 10...) okok je ->
[^] # Re: fusion des différents RPM
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Désolé, je n' avais pas lu la dépêche de Curiousous, ni ton commentaire dedans, Patrick_g.
[^] # Re: fusion des différents RPM
Posté par bubar🦥 (Mastodon) . Évalué à 2.
comme quoi, c' est vraiment perturbant toutes ces histoires autour de rpm
[^] # Re: fusion des différents RPM
Posté par IsNotGood . Évalué à 3.
Non. Jeff Johnson a été viré par Red Hat. Ajoutons que Jeff n'était pas vraiment contre :-)
> peut être que redhat a voulu créer un vrai rpm communautaire
Oui. Mais constatons que ça ne prend pas. Red Hat fait toujours le gros du boulot et a du embaucher spécifiquement pour rpm.
> Peut être qu' il s' agit d' une stratégie parfaitement entendue entre Jeff Jonhson et Redhat. Peut être que je raconte n' importe quoi.
=> n'importe quoi.
> il me semble que les exemples de refus de redhat d' ajout de fonctions et de patchs dans rpm fait par des contributeurs, étaient assez courant :(
Admettons. Rpm est un élément critique et donc tout n'y est pas permis.
Linus aussi refuse beaucoup de chose...
[^] # Re: fusion des différents RPM
Posté par Emmanuel Seyman . Évalué à 3.
> Oui. Mais constatons que ça ne prend pas. Red Hat fait toujours le gros du boulot et a du embaucher spécifiquement pour rpm.
J'ai du mal à imaginer une communauté très actif autour de rpm et je serai très surpris si Red Hat pensait se retrouver avec des centaines de contributeurs.
Le rpm de rpm.org contient des correctifs de Pixel (le mainteneur de rpm dans Mandriva jusqu'à il y a peu) et ceux des mainteneurs rpm de Suse (désolé, pas de noms à fournir). On peut espérer que la version 4.6 sera adoptée par les trois distributions et que tout le monde mutualisera ses efforts de développement autour de celle-ci plutôt que de re-inventer la roue à chaque fois. Si ça se fait, ce sera déjà un grand pas en avant.
[^] # Re: fusion des différents RPM
Posté par IsNotGood . Évalué à 2.
Ben c'est un problème. S'il n'y a pas Red Hat pour "se sortir les doigts du cul", rpm stagne.
Il a été reproché à Red Hat de ne pas avoir réagit assez vite/fort au départ de Jeff Johnson, mais les autres n'ont quasi rien fait...
Notons que du côté de deb/dpkg ce n'est guère mieux. Il y avait un article sur lwn.net à ce propos, mais j'ai la flemme de le chercher.
Certes il y a des contributions de Novell, Mandriva, etc. Mais sans Red Hat il n'y a pas une communauté pour faire vivre le projet.
# Rpm mal fichu?
Posté par reno . Évalué à 3.
Et bien pas du tout en fait!
Et la je ne comprends pas.. Pour moi un rpm, c'est comme une archive tar/cpio avec quelques données en plus (numéro de version, dépendences, etc) qui auraient leur place dans un fichier de description.
Donc s'il y a des experts en rpm, j'aimerai bien une explication: pourquoi est-ce si compliqué de manipuler un rpm?
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . Évalué à 3.
M'enfin, un src.rpm (le paquet source rpm qui crée le paquet installable) peut-être vu comme un tar/cpio.
Si tu veux modifier un .rpm, fait comme tout le monde, prend le src.rpm et reconstruit le paquet.
[^] # Re: Rpm mal fichu?
Posté par reno . Évalué à 5.
Relis mon poste, je parles des informations en plus qu'a un rpm (numéro de version, dépendances, etc) et que toutes ces informations pourraient être stockées dans un fichier.
[[Si tu veux modifier un .rpm, fait comme tout le monde, prend le src.rpm et reconstruit le paquet.]]
1) Ca te parait simple comme manipulation?
Meme quand il s'agit de changer un fichier de données/script inchangé entre le rpm et le src.rpm?
2)Et pourquoi faire une différence entre un src.rpm et un rpm?
Pour moi, les deux devraient avoir une structure identique et juste être différent au niveau du contenu: modifier un src.rpm est simple mais pas un rpm, donc je trouve ça mal fichu..
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . Évalué à 4.
Oui elles pourraient (être exportées dans un fichier). Mais ce n'est pas le cas.
Je n'ai pas dit qu'il y avait des raisons techniques à ça. C'est simplement car ça ne colle pas à l'usage de rpm.
Si tu veux faire un outils qui exporte/importe en fichiers (avec un __META__/* pour tous les trucs qui ne sont pas des fichiers) , n'hésites pas.
Pourquoi ça n'a pas encore été fait ?
Parce que quasiment tout le monde s'en fout.
En passant, il y a rpm2cpio qui n'extrait que les fichiers (pour les fichiers spéciaux il faut être root).
Il y a "rpm -q --dump" pour avoir les attributs des fichiers (mode, doc/config, etc).
Il y a "rpm -q --scripts" pour avoir les scripts.
Il y a "rpm -q --triggers" pour avoir les triggers.
Il y a "rpm -q --requires", "rpm -q --provides" et "rpm -q --conflits" pour les dépendances.
Pour les attributs du paquet (version, licences, date de création, etc), il suffit d'utiliser "rpm --querytags" pour avoir les noms des champs et "rpm -q --queryformat" pour avoir les valeurs.
Tu rassembles tout ça, le passe à la moulinet, et crée un fichier .spec pour... recréer le fichier .src.rpm pour... finir comme tout le monde par utiliser rpmbuild (m'enfin tu n'auras pas besoin de recompiler le paquet).
> 1) Ca te parait simple comme manipulation?
Si tu en es à vouloir modifier un paquet, alors tu ne fais pas un truc simple. Dans ce cas, oui c'est assez simple de modifier le src.rpm. Ça peut par contre bouffer du temps et de l'espace disque.
> Meme quand il s'agit de changer un fichier de données/script inchangé entre le rpm et le src.rpm?
Et ?
Oui parfois on refait un paquet depuis le src.rpm seulement pour un ligne ou car il y a un typo dans ligne.
Mais c'est quoi rpm ? C'est quoi l'objectif ?
C'est, entre autre, d'avoir toutes la procedure de création du paquet. Si tu fais des "bidouilles" avec le paquet à installer, tu perds ça.
Si tu veux bidouiller, utilise un bon vieux "./configure && make ..."
> 2)Et pourquoi faire une différence entre un src.rpm et un rpm?
Ce n'est pas la même chose, la même fonction. Un src.rpm ne s'installe pas, il n'est pas dans base rpm (dans /var/lib/rpm). Un src.rpm n'a pas de dépendance, n'a pas de scripts a exécuter à l'installation, ne demande pas le compte root pour être installé, etc. Bref, sa fonction est bien différente, c'est seulement un conteneur (comme un tar/cpio).
Un paquet rpm est un truc construit par le programme rpm (en fait rpmbuild qui fait aussi divers contrôle) pour être installé sur un système (vérification des dépences, des conflits entre fichiers, définit le propriétaire de fichier (donc doit être root), etc). Le src.rpm est aussi construit par rpmbuild, mais il ne fait rien d'autres que d'"empiler" des fichiers dans un src.rpm. rpm exige d'être root, on peut construire un .rpm sans être root.
D'ailleur on peut faire des rpm depuis un fichier tar (il doit avoir un fichier .spec dedans). Suffit de faire rpmbuild -tb toto.tar. Donc les fichiers sources des rpm pourrait très bien être des tar, pas de problème à ça sauf petites bricoles (pas de signature, etc).
> Pour moi, les deux devraient avoir une structure identique et juste être différent au niveau du contenu
C'est le cas. C'est le même outils pour faire un src.rpm et un rpm.
> modifier un src.rpm est simple mais pas un rpm, donc je trouve ça mal fichu..
Ben modifie un src.rpm...
Et après ?
Ben fait les rpm car ton src.rpm tu ne peux pas l'installer...
> donc je trouve ça mal fichu..
Ben il y en a très très très très peu qui utilise rpm et ont ton "problème".
Mais je pense que tu dois tomber à genoux devant le format .deb qui le permet...
Suffisait de le dire. +0.00001 pour .deb.
[^] # Re: Rpm mal fichu?
Posté par reno . Évalué à 4.
Merci pour cette réponse très détaillée, cela me parait utile de simplifier l'éclatement d'un rpm oui, je connaissais rpm2cpio mais il me manquait la connaissance des options de l'outil rpm pour recuperer tous les attributs, je vais me faire un shell/Perl pour simplifier tout ça.
Et si je suis très courageux, je regarderai a quoi les sources de l'outil rpm ressemblent, peut-être qu'une option supplementaire --extract_all serait la bienvenue?
Modifier un tar est simple, modifier un rpm devrait être (quasiment) aussi simple.
Sinon je ne savais pas que le .deb le permet (ce n'était pas une tentative de troll masqué entre .rpm et .deb) mais je ne peux pas utiliser le .deb car on utilise RedHat ..
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . Évalué à 3.
Désolé alors.
Je crois que les .deb sont des fichiers .ar .
> Dans le cas ou j'ai eu a faire une modif,
T'as raison, pouvoir "exporter/importer" un rpm peut être sympa dans certains cas.
Ce qui m'a énervé est que tu conclus que rpm est "mal foutu" car il ne le permet pas (actuellement).
En passant toutes les distributions permettent de proprement refaire un paquet (c'est fait en chroot). Par exemple sous Fedora pour faire un paquet : "mock --rebuild --arch=fedora-8-i386 --target=i686 paquet.src.rpm".
Pas difficile, mais plus compliqué que ce que tu proposes. Mais ça permet tout.
[^] # Re: Rpm mal fichu?
Posté par Kerro . Évalué à 10.
Ce qui m'a énervé est que tu conclus que rpm est "mal foutu"Ce qui t'a énervé c'est que quelqu'un ait osé émettre une opinion négative en rapport avec RedHat.
N'est ce pas ? :-)
[^] # Re: Rpm mal fichu?
Posté par IsNotGood . Évalué à 0.
[^] # Re: Rpm mal fichu?
Posté par lezardbreton . Évalué à 10.
# Désolé mais ceci n'a aucun sens
Posté par dab . Évalué à 3.
censée est mieux, n'est ce pas ?
[^] # Re: Désolé mais ceci n'a aucun sens
Posté par patrick_g (site web personnel) . Évalué à 3.
Effectivement c'est bien mieux ;-)
# Que ces choses là en termes délicats sont dites...
Posté par yojik77 . Évalué à -1.
> La situation s'est décantée quand Jeff Johnson, la personne qui était censée être en charge, a été invitée à aller voir ailleurs par Red Hat, son employeur.
A mes oreilles peut-être malveillantes, cela ressemble fortement à un bon licenciement façon US, c'est-à-dire sec et brutal dont il n'y aucune raison de se réjouir quel que soit le "bien supérieur" qu'il y avait à voir RPM progresser.
Cela a un côté épouvantablement faux-derche et cela transpose l'inénarrable "We have to let you go !" anglo-saxon avec un zeste de sarcasme frenchy tout à fait déplacé...
Peut-être que je me trompe, peut-être que d'autres tâches lui ont été assignées de manière autoritaire (ce qui au regard du droit du travail français, désuet, touffu et désespèrement protecteur, au regard duquel je persiste à me placer serait déjà un comportement discutable pour un employeur...).
J'ai souvent remarqué que l'esprit "libre" s'accomodait assez bien de comportement qui serait inadmissible dans une société régie parle droit du travail ou des règles élémentaires d'éducation et de respect des "collaborateurs"....
Fraternités cher camarades travailleurs,
Yojik
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Zenitram (site web personnel) . Évalué à 10.
Je suis français (parce que bon, ca y est, on retombe dans les "méchants US", donc autant l'afficher), mais je trouve 100% normal que quand un mec n'obéit pas aux injonctions de son employeur (qui le paye pour une prestation, pas pour qu'il fasse ce qu'il a envie), il dégage. En France, ce sera la même chose : l'employeur licencierait pour "insuffisance".
J'ai souvent remarqué que l'esprit "libre" s'accomodait assez bien de comportement qui serait inadmissible dans une société régie parle droit du travail ou des règles élémentaires d'éducation et de respect des "collaborateurs"....
Que vient faire le libre dans l'histoire? Rien. Un employeur et son employé ne s'entendent pas, il "divorcent". Le droit français s'adaptent d'ailleurs, plus besoin de faire un licenciement pour faute pour que l'employé touche l'assurance chômage, maintenant il y a une séparation d'un commun accord rapide et efficace.
Ca n'a rien à voir avec le libre, juste que certaines personnes (dont moi) trouvent normal qu'on vire une personne qui ne fait pas le boulot pour lequel on le paye (mais je suis du mauvais côté, je suis employeur potentiel, ça explique peut-être ma façon de voir qui sait... Désolé, j'avais oublié que tous les libristes étaient sensés être des gentils employés abusés par leur employeur)
Bref, non, désolé, ta réaction est trop stéréotypée gentil employé / méchant employeur, et je trouve que patrick_g a très bien mis en prose la chose, j'ai apprécié lire la dépêche, y compris cette partie (surtout cette partie même).
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à -1.
À ce moment là, tu pourrais préciser que ça fait quelques temps que tu ne bosses plus en France et qu'à mon avis ta concecption du travail est plutôt influencée par les lois allemandes.
je trouve 100% normal que quand un mec n'obéit pas aux injonctions de son employeur [...] , il dégage
D'un coté, ton assertion a l'air évidente pour tout le monde. Mais ce n'est pas en simplifiant ainsi la définition des relations employeurs/employés que tu feras avancer le débat. Je pense que ce que voulait dire l'auteur original du commentaire, c'est qu'on ne connaît pas vraiment les conditions de ce "départ", et que les gens (à priori au moins l'auteur de la dépêche, patrick_g) présentent ça d'une manière hypocrite et peut-être malsaine dans son orientation (être "invité à aller voir ailleurs", je trouve ça assez méprisant).
Alors voilà, je ne me prononce pas pour cette histoire, je ne la connais pas bien (j'ai juste vu son entêtement sur les bugs report, mais rien par rapport à son départ). Mais je pense qu'il faut arrêter de prendre ces relations de subordination comme "évidentes" : le salariat existe parce que des gens ont _voulu_ se subordonner à leur employeur, en échange de certaines conditions, y compris la sécurité de l'emploi : faire une erreur, c'est humain. Et la société en général même a aidé à garantir une indemnité à ceux qui sont au chômage.
Je voudrais pas dire, mais ça vous plairait de travailler avec la peur du couperet qui s'abat sur vous à la moindre bévue ? OK, il faut faire des nuances, il y a bien sûr des cas d'abus qui sont sanctionnés par le licenciement pour faute. Mais ici, qui connaît assez bien l'histoire pour juger ?
Franchement, ces déclarations à l'emporte pièce, ça me fait penser à ceux qui veulent mettre tous les "méchants" en prison (un peu comme notre cher président) : je vous signale que ce sont des hommes/femmes comme vous et moi, et que ce n'est pas en en foutant encore plus en taule qu'on va régler les problèmes de notre société. Au contraire, c'est plutôt un signe que ça va plus mal. Le but c'est quand même qu'on arrive à vivre ensemble dans le bonheur et la volupté, non ?... Donc ce n'est pas en désignant des "moutons noirs" au travail qu'on va faire avancer notre société. Qu'on discute, qu'on juge sur des faits, pourquoi pas, mais qu'on mette cette idée nauséabonde dans la tête des gens qu'il existe certaines personnes supérieures à d'autres sans autre forme de débat, c'est moche.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par pasBill pasGates . Évalué à 6.
L'etat ou je bosses est un etat ou l'emploi est "at will" comme on dit aux USA : tu peux quitter ton job du jour au lendemain, et ton boss est sense pouvoir te dire de partir du jour au lendemain. Niveau droit du travail c'est le plus liberal que tu puisse avoir aux USA.
Sur le papier, tu lis ca et tu te dis "merde, ca craint".
Maintenant, le truc est qu'il y a aussi tout le cote licenciement abusif qui entre en jeu. Je connais plusieurs cas ici chez MS ou des gens qui etaient incompetents ont mis environ 1 an a partir, en comptant depuis le moment ou ils ont ete averti la 1ere fois. C'etait le temps necessaire pour documenter le fait qu'ils ne repondaientt pas aux attentes et meritaient de se faire virer.
Il y a bien entendu le cas ou le gars se fait virer immediatement pour faute grave, mais ces cas ce sont des cas ou c'est clair et net et facile a prouver.
Bref, je doutes que Redhat ait decide de le virer du jour au lendemain juste parce que sa tete ne leur plaisait pas... Les risques pour eux sont trop eleves.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par patrick_g (site web personnel) . Évalué à 8.
Cela n'avait rien de méprisant de ma part. J'ai pris grand soin de mettre des liens dans la news vers toutes les informations pertinentes et si tu clique sur le lien se trouvant derrière l'expression "pas vraiment de responsable" tu verra une déclaration de Greg DeKoenigsberg (bossant chez Red Hat) qui parle de jbj (Jeff Johnson).
Pour t'éviter ce travail je te colle le minuscule bout de phrase :
"When we fired jbj"
Donc voilà. Est-ce que selon toi je suis coupable d'avoir écrit "Jeff Johnson, la personne qui était censée être en charge, a été invitée à aller voir ailleurs par Red Hat, son employeur" alors que j'aurai du m'en tenir à la traduction littérale "Jeff Johnson, la personne qui était censée être en charge, a été virée par Red Hat, son employeur" ?
C'est un peu dérisoire comme reproche non ?
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à 1.
Après, je fais peut-être de l'enculage de mouche (et encore, ce n'était qu'une remarque dans mon commentaire, le reproche principal n'était pas pour toi) mais dire que quelqu'un a été "invité à aller voir ailleurs", oui c'est méprisant, c'est utiliser un euphémisme pour montrer sous un mauvais jour la personne a qui c'est arrivé. Je n'aurais quand même pas utilisé le mot "viré" qui est effectivement la traduction littérale, mais alors plutôt "licencié".
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Zenitram (site web personnel) . Évalué à 3.
Dans ce cas, tu fais une fausse traduction, et tu travestis les propos de Redhat.
Le mec a bien dit "viré" (fired), et non pas licencié ("dismissed" ou "to let somebody go").
"invité à aller voir ailleurs" est donc bien plus proche de ce que pensait RedHat quand il l'a viré, que ta traduction.
Après, je fais peut-être de l'enculage de mouche
Surtout tu veux adoucir un propos qui n'est pas doux : il a bel est bien été viré, pas licencié.
A choisir, je préfère le propos de Partick_g plus réaliste que ta mauvaise traduction, désolé.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par yojik77 . Évalué à -1.
Bonsoir à tous les contributeurs qui se sont exprimés posément sur mon malheureux post,
D'abord, urbi et orbi, je suis ravi qu'un commentaire absolument sans intérêt provoque une telle succession de messages. Oui c'est un sarcasme puisque le résultat de cette excellente attitude (je dois pointer à -2 en cet instant) est que je ne suis même pas sûr d'être lisible avec ce nouveau post. La chasse aux sorcières comme moyen de réplique des analphabètes et des immatures va finir par m'éloigner une bonne fois pour toute de linuxfr. C'était HS mais ça soulage...
1ère clarification : je ne visais aucunement Patrick de manière personnelle dans mon post. Je critiquais un comportement auquel s'est livré Patrick et que je désapprouve totalement, l'euphémisation des rapports de force et de la violence sociale au travail. Ceux qui ne saisisse pas la nuance peuvent aller s'occuper autrement, la suite ne les intéressera pas plus. Sur ce point, j'y reviendrai...
2ème clarification : je ne visais pas les USA, j'ai passé l'âge. De la même façon qu'il faut laisser la peur du rouge aux bêtes à cornes, j'apprécierais de ne pas être assimilé aux anti-américanistes primaires qui sévissent ici et là. Pour donner un exemple, la "liberté d'expression" et la "privacy" étaient bien mieux garantis aux USA qu'en France ou qu'en Angleterre. Donc merci aux spécialistes des amalgames poisseux de passer leur chemin.
Je parlais d'un mode de fonctionnement qui n'existe plus en France que pour certains types de postes (administrateurs et dirigeants des sociétés congédiables ad nutum (= d'un signe de tête), collaborateur politiques, postes de cabinet dans la haute fonction publique), c'est-à-dire un départ sans préavis et peu ou pas indemnisé .
C'était schématique mais, en aparte, ce qu'indique pasBillpasGates n'est pas significatif de la généralité des entreprises aux USA à ma connaissance: il s'agit plus d'un choix généreux de son employeur (comme le recours aux "packages" lors d'un licenciement par exemple). Pour les SSII ou pour Wal-Mart, mon intuition est que l'on ne prend pas forcément toujours des gants. Ceci étant je n'irais pas lire dans l'USC les lois fédérales du travail ce soir, donc je passe sur un débat que je ne voulais pas soulever d'ailleurs.
3ème clarification : Je suis ravi de relever que je suis clairement reconnu pour ce que je suis, à savoir un crypto-communiste, certainement syndiqué et ouvertement pro-grève. cela doit signifier que je suis quelqu'un d'honnête intellectuellement, non ?? Pour parodier les échanges fumeux des gauchistes des années 70, les questions "D'où parles-tu Camarade ?" (sous entendu pour quelle faction, scission, groupuscule...) n'est pas inintéressante, c'est un premier gage d'intégrité intellectuelle qui expose clairement ses "fondamentaux" intellectuels, moraux ou idéologiques. Pour mémoire, et avant toute chose à mon avis, je suis profondément et intrinsèquement un juriste.
4ème clarification : Je n'ai jamais contesté le droit d'un employeur de procéder à un licenciement . C'est une évidence pour tout juriste : un contrat doit pouvoir être rompu (d'où le débat historique sur le mariage, est-ce une institution (= intouchable) ou un contrat (= divorce possible) ? C'est un peu comme si j'interdisais à un employé de démissionner...
Mais l'Humanité ou pour éviter les associations malheureuses, le "Respect sacré qui est du à un être humain" fait, exige, devrait rendre évident que l'on ne peut pas traiter une personne sensible comme un ordinateur amorti comptablement et en bout de course matériellement. C'est à dire que l'exercice du pouvoir de licenciement doit être encadré (extrêmement encadré de mon point de vue) et qu'il soit assorti de justes compensations proportionnées au sérieux des motifs ayant justifié qu'il soit mis au contrat.
Ayant un score de 3:1 (3 dém' ; 1 licenciement), je peux vous dire qu'un licenciement fait plus de mal et plus durablement à un humain qu'une démission ne bouleverse une entreprise. Je ne vous souhaite pas de le vivre mais la dépression, le divorce, le suicide sont réellement des conséquences usuelles de licenciements, économiques ou non.
Je vous épargne les considérations marxistes inactuelles mais pourtant promises à une nouvelle évidence dans les prochains mois selon lesquelles les chômeurs constituent l'armée de réserve des employeurs (plus de chômeurs, moins de revendications salariales, moins de contestation, possibilité de remplacer à vil prix des employés, etc.).
Donc le coeur du débat, c'est quoi ??
C'est qu'il y a actuellement une forte tendance à truquer les termes du débat sur la relation Employeurs-Employés. Un contrat de travail entre une structure et un Humain n'est pas un achat de'un bien consommable car, entre autres choses, l'Humain a le droit au Respect et à ce que soit préservée sa Dignité.
Parmi ces dévoiements, un discours aigri assez récurrent existe chez des gens qui n'auraient jamais le courage de faire grève, de déposer un témoignage pour soutenir un collègue aux Prud'hommes ou de se rebiffer sur des humiliations petites ou grandes, c'est de reprocher à ceux qui ont ce courage, qui n'ont pas abdiqué tout sens de la Dignité d'être des "preneurs d'otages" des usagers, des "grandes gueules", des "fouteurs de merde", bref des cgt-syndicalistes...
Pour tout dire, et justement pour éviter que Patrick ne puisse penser à une attaque ad hominem le visant (j'ai déjà du marquer une fois ou deux des déssacords avec lui, ça pourrait légitimement nourrir un soupçon de vendetta délirante de ma part), j'ai volontairement omis un autre épisode qui m'avait marqué : c'était à l'occasion de la rituelle dépèche de sortie de Noyau : il faisait état en termes assez détendus de la façon dont un développeur du noyau qui s'était consacré pendant plusieurs mois sur un nouvel ordonannceur avait vu son projet dégagé d'un claquement de doigt ou peu s'en faut par l'arbitraire de Linus T. himself. Tout celà assorti de commentaires de posteurs du genre, "c'est ça aussi le libre", "c'est la sélection des meilleurs projets", patati-patata.
Non, ça c'était du darwinisme social parfaitement rustique et c'est, de mon point de vue, parfaitement déguelasse.
Je suis, à tous égards, très loin d'être une petite chose fragile mais je sais que d'autres sont plus fragiles que moi et même si je ne l'espère pas je pourrais moi aussi, un jour, être fragilisé. Mais même si ce n'était jamais le cas, le respect que je ressens à défaut de le devoir pour tout autre hominidé fait que je ne lui souhaite ni souffrances, ni malheur. Mieux, même si je me sens sûr de ma force, de mon talent et de mon génie, winner parmi les winner jamais je ne m'abaisserais à une telle attitude envers un prétendu loser. C'est fleur-bleue et naïf pour ceux qui se planquent derrière un faux cynisme moderne (les vrais cyniques se pendent).
Mais c'est ça qui est en jeu, affaiblir notre sensibilité aux destins de nos congénères, s'habituer à la violence sociale et morale, pire la banaliser avant, en toute bonne conscience, de la reproduire...
Le rapport entre un employeur et ses subordonnés est un rapport juridique mais aussi un rapport de force et, comme dans tout lieu de pouvoir, il y a de nombreux abus de pouvoirs en entreprise sans qu'il soit souhaitable ou légitime de les banaliser ou de les masquer derrière des formules camouflages. A la rigueur, la froide honnêteté du gus de Red Hat est intègre et sincère : ils en avaient le pouvoir, ils avaient un motif légitime, ils l'ont fait et ils assument. Pas d'enjolivage, pas de pipeau.
Pour donner d'autres exemples de banalisation contre lesquelles je m'insurge :
- "pousser vers la sortie" ; "mettre au placard", ça peut avoir un autre nom juridiquement : du harcèlement moral...
- considérer qu'une telle ne "progresse plus" et percute le "plafond de verre", mais que "c'est normal tu comprends, depuis qu'elle a des gosses..."....
- dernier exemple, comme le disait l'affreux Filoche dans le canard de Siné il y a quelques semaines, le terme "collaborateurs" est une autre escroquerie intellectuelle. Le contrat de travail se traduit par un lien de subordination qui se manifeste notamment par l'autorité de l'employeur et l'existence d'un pouvoir disciplinaire, lequel ne peut être contesté a priori mais seulement a posteriori devant les juges.
Donc loin de l'agressivité de pacotilles, je vous invite seulement à être attentifs, jusqu'en dans vos termes, à la dignité de vos frères d'espèce et de ne pas abdiquer totalement devant l'individualisme obligatoire et forcené que l'on cherche à nous inculquer...
Bon soir & à tous mais toujours très fraternellement,
Yojik
--
--
ps : comme les surintérprétations de mes quelques lignes sont quand même assez prodigieuses, je vous invite à lire successivement, le Meurtre de Roger Ackroyd d'Agatha Christie et "Qui as tué Roger Ackroyd" de M. Bayard aux éditions de Minuit qui expose au passage et magistralement ce qu'est une "lecture délirante" d'éléments factuels...
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à 3.
Juste en passant sur cette remarque, M. Filoche est inspecteur du travail, et son article est vraiment très intéressant, pour ceux qui ont pu avoir ce canard en main (celui du 7 janvier, je l'ai retrouvé).
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par patrick_g (site web personnel) . Évalué à 3.
No problemo je ne suis pas paranoïaque ;-)
>>> Je critiquais un comportement auquel s'est livré Patrick et que je désapprouve totalement, l'euphémisation des rapports de force et de la violence sociale au travail.
Désolé si je t'ai donné cette impression car ce n'était pas mon intention d'euphémiser ces "rapports de force". Dans mon esprit c'était juste un synonyme pour virer et je ne suis pas allé chercher plus loin. Je vais réfléchir a ton argumentaire....mais je ne promet pas que je vais m'y rallier !
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Zenitram (site web personnel) . Évalué à 4.
Je n'ai même pas le courage à te contre-argumenter sur ta vision stéréotypée méchant employeur / gentil employé tellement c'est gros (tu parles toujours du gentils employé que le méchant employeur veut virer alors que l'employé n'a "rien fait de mal", ne t'arriverai-t-il jamais de penser au méchant employé qui fait vivre un enfer à l'employeur en utilisant les lois du travail absurdes françaises?), je réagirai sur l'attaque personnelle : pour ton information, je n'ai jamais professionnellement quitté la France. J'y travaille toujours, bien que passé indépendant je paye toujours mes cotisations sociales en France, et je suis soumis à la loi française. En effet, tu mélanges mon lieu d'habitation 6 mois moins 1 jour dont il m'arrive de parler ici avec mon lieu d'habitation 6 mois et 1 jour ainsi que mon lieu de travail 365 jours par an. En effet, la magie d'Internet fait qu'on peut travailler à distance, oh miracle. Et il y a plein de monde en France qui travaille de chez lui aujourd'hui, si si! Ca ne fait pas des personnes déconnectées du monde du travail français (au contraire)
Alors, bon, si il faut que tu utilises des attaques personnelles sous-entendant ma non connaissance de la réalité du monde du travail français pour fournir des "arguments", c'est que tu n'as pas grand chose en poche pour argumenter sur ta vision des choses.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à 2.
Par contre, j'aurais plutôt voulu débattre sur le fond, ce que tu as l'air de vouloir éviter ... Mais saches que quelles que soient les relations employeur/employés, légalement, ton employeur a du pouvoir sur toi. Rien que ça signifie qu'il y a une différence de considération entre les deux, et que quelle que soit la manière dont un employé "fait chier" son employeur, c'est toujours le second qui a plus de pouvoir que le premier. Enfin bon, tout le monde croit que les relations au travail sont immuables, qu'il y a les forts et les faibles. Au début du XXième siècle, les ouvriers c'était du bétail, mais ils ont réussi à changer un peu le rapport de force. Aujourd'hui, ça peut nous paraître désuet, d'autant plus que la majorité des gens ici (je suppose) ont une position pas du tout inconfortable à leur travail (y compris moi), mais c'est important de rappeler que les rapports de forces bougent tout le temps et que défendre ses positions à chaque instant est indispensable.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Zenitram (site web personnel) . Évalué à 2.
Accepté :).
Par contre, j'aurais plutôt voulu débattre sur le fond,
Puisque c'est demandé, j'y vais alors :)
La législation du travail actuelle (que ce soit en France ou en Allemagne, au niveau contrat c'est à peu prêt pareil même si il est vrai c'est un peu plus à l'avantage de l'employeur en Allemagne) ne convient ni à l'employé, ni à l'employeur : l'employé y voit pas assez de protection, l'employeur trop de protection. Dans les deux cas la loi est utilisée pour faire chier l'autre.
tu pars du postulat que le gentil employé Jeff Johnson s'est fait jeté comme un malpropre.
A cela déja il y a un problème :
- Jeff Johnson a été loin d'être gentil, du seul fait de n'en faire qu'à sa tête. Jeff Johnson ne se paye pas lui-même, il avait un patron, qui le paye pour une seule chose : qu'il fasse ce qu'il demande.
- il a été viré, oui, mais il avait du temps pour se faire une assurance chômage (c'est certes optionnel aux US, mais rien ne t'empêche d'épargner pour tes jours un peu plus foireux!). Ce n'est donc pas la mort.
Tu vois la relation employé-employeur comme si l'employeur avait signé un contrat à vie. Non, et heureusement. Le divorce est accepté de nos jour pour la vie personnelle, mais ne l'est pas encore pour la vie professionnelle, c'est un peu bizarre.
légalement, ton employeur a du pouvoir sur toi
Légalement, l'employé a un putain de pouvoir aussi sur l'employeur. Tu vois que le côté "employé" des loi, met-toi un peu à la place de l'employeur : un CDI, ca veut dire quoi? Ca veut dire que l'employeur ne peut pas divorcer facilement, sauf à payer genre 1 an de salaire pour partir. Par contre, côté employé, hop préavis d'un mois "je me casse connard". le pouvoir est 100% côté employé! Est-ce normal que dans un "couple" l'un ai plus de droits que l'autre? Non. Il faut un équilibre. Toi tu vois que l'employé peut être oppréssé, moi je vois que l'employé peut se tourner les pouces, bien faire attention de ne pas faire de faute grave, et attendre que l'employeur craque et propose 1 an, 2 ans de salaire pour que l'employé se casse. J'imagine? Non, tiré de faits réels. Tu vois l'employé oppressé, je vois l'employeur oppressé.
De pluxs la vision "française" (européenne) n'est plus à jour : la vie de couple toute une vie, c'est terminé. Et la, les US sont bien meilleurs : une personne licencié n'est pas vu comme une punition, mais comme un nouveau départ.
Et au final, un CDI blindé comme il est à l'avantage de l'employé, ça donne quoi? Ca donne qu'un employeur va utiliser un max de CDD, ne plus embaucher la personne au bout de 2 CDD car risque de procès, même si l'employeur aurait bien voulu continuer avec lui. Ben oui, s'engager ensuite sur un CDI alors qu'on n'est pas sûr d'avoir la prolongation du gros contrat dans 3 mois, c'est un peu dangereux, donc pas de prise de risque, pas d'engagement en RH.
La protection actuelle des employés empêche tout simple la création d'emploi. De la même manière que la protection des locataires empêche la mise en location d'appart qui restent alors vide. Dans les deux cas, mêmes symptômes : à force de vouloir trop protéger un camp, l'autre camp ne s'engage plus.
Et tant qu'on empêchera en France un employeur de divorcer de son employé plus facilement, l'employeur aura du mal d'employer sans prendre plein de précautions. Car l'employeur n'a qu'une peur : que ce putain d'employé fasse semblant pendant la période d'essai, et n'en foute pas une ensuite.
J'ai vu suffisamment de personnes profitant du système de protection des employé pour en être dégouté. Les syndicats s'amusant à les protéger en plus (d'ailleurs, regardez un peu qui est syndiqué en France, qui prend des postes syndicaux... Et vous trouverez pas mal de gens "glandeurs", forcement c'est invirable alors pourquoi bosser quand on peut boire le café tranquille?).
Bref, en tant qu'employeur potentiel, je me promet une chose : éviter les CDI au maximum, avoir plutôt des Freelances payés à la prestation. C'est bien moins chiant. Sans compter que ça ne fait pas chier à ne pas vouloir bosser le dimanche pour des raisons à la con par exemple, ou parce que le mec que j'aurai embauché va me trouver une petite faute que j'ai pas mis son outil de travail de telle façon etc... Et si il ne fait pas ce pour quoi je le paye, bye, tout simplement. Pas que je ne veuille pas les payer, je suis prêt à payer, juste que les prendre en CDI fait que je dois respecter une loi qui est disproportionnée contre l'employeur.
D'ailleurs, tu remarqueras que sur le web, l'open-source, ça marche beaucoup en Free-lance, et ça ne déplait pas beaucoup au "employés" de ne pas avoir de protection : il est payé à l'acte, très bien, quand il fait du bon boulot. Et ce genre de "contrat" va être la norme dans quelques années, tous freelances, préparez-vous, pour la bête raison que les autres contrats (CDI...) ne sont plus du tout adaptés et que les syndicats n'ont aucune envie de s'adapter au monde réel, celui qui bouge.
Je suis d'accord sur le fait qu'il y a des employeurs qui abusent de leur situation, mais la protection actuelle des employés amène son lot de parasites, mais c'est un sujet tabou tellement la culture Française est "les gentils employés oppressés et seulement eux".
Oui, j'aime la philosophie US de ce côté : tu merdes, tu dégages, tu retrouve du boulot le lendemain sans problème car un employeur peut "tenter" avec toi sans risque. Et comme l'a dit pasBillpasGates, tu ne peux quand même pas virer à la tête du client comme tu as le préjugé : Jeff Johnson s'est fait viré pour raison très légitime (il ne faisait pas le travail demandé), aucune pitié pour lui, c'est tout, pourquoi vouloir le traité de "pauvre petit qui a été abusé par son employeur"?
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à 1.
Déjà, on part mal. Je ne voulais pas dire ça, j'ai vu son comportement et il avait l'air assez obtu. Ce que je reproche c'est la manière dont tout le monde acquiesce son "licenciement" comme une punition méritée, et que tous ceux qui oseraient faire la même chose devraient subir le même sort. Je parle en fait dans un contexte plus large que ce licenciement en lui même.
- il a été viré, oui, mais il avait du temps pour se faire une assurance chômage
OK, comme je disais avant, nous on peut faire nos malins avec nos boulots d'ingés (j'ai pris deux mois de "chômage" sans ASSEDIC après ma démission, je peux me le permettre) mais tout le monde n'est pas dans ce cas. Pour certains, épargner est un mot inconnu et le fait de se retrouver au chômage signifie être très mal barré si on ne retrouve pas très vite un job. Et bien sûr, cela amène à accepter tout et n'importe quoi.
Tu vois la relation employé-employeur comme si l'employeur avait signé un contrat à vie.
Non, pas du tout, mais du fait que l'employeur a un pouvoir supérieur à celui de l'employé, je vois que la loi essaye de donner plus de "droits" à l'employé ainsi subordonné.
Le divorce est accepté de nos jour pour la vie personnelle, mais ne l'est pas encore pour la vie professionnelle, c'est un peu bizarre.
Heu, non, je ne trouve pas, pour la raison que le mariage est (normalement ...) un contrat d'égal à égal, ce qui n'est pas le cas d'un contrat salarié. Et justement, quand une des deux parties abuse de son pouvoir, c'est normalement dans ce cas là qu'on parle de rompre le contrat.
Légalement, l'employé a un putain de pouvoir aussi sur l'employeur. Tu vois que le côté "employé" des loi, met-toi un peu à la place de l'employeur : un CDI, ca veut dire quoi? Ca veut dire que l'employeur ne peut pas divorcer facilement, sauf à payer genre 1 an de salaire pour partir.
Attend, t'as oublié un petit détail : l'employé doit faire ce que l'employeur lui dit, alors que l'employé ne peut pas donner d'ordre à son employeur ! Tu ne vois pas une petite différence de pouvoir, là ? Et pourtant, ce sont deux être humains qui, d'après la constitution, son égaux en droit !
Est-ce normal que dans un "couple" l'un ai plus de droits que l'autre? Non.
Nan mais reviens un peu sur Terre ! Dans un couple, une des deux parties est-elle subordonnée à l'autre ? (encore une fois, en théorie ...) Non. Cela n'a rien à voir.
moi je vois que l'employé peut se tourner les pouces, bien faire attention de ne pas faire de faute grave, et attendre que l'employeur craque et propose 1 an, 2 ans de salaire pour que l'employé se casse. J'imagine? Non, tiré de faits réels.
Et bien moi j'imagine très bien le cas inverse. Après, comment faire ? Et bien on regarde lequel est le plus préjudiciable par rapport à l'autre. Figure toi que toutes ces loi que tu trouves trop contraignantes ont été votées car avant les employeurs abusaient largement de leur employés ! Donc en gros, tu dis que la balance penche trop de l'autre coté aujourd'hui et qu'il faudrait rétablir l'équilibre ? Je suis désolé, mais tu vois quelle proportion de patrons aujourd'hui dans la merde par rapport aux employés ? C'est clair que si tu calcules en "valeur" ça se vaut, mais en être humain, le déséquilibre est flagrant.
la vie de couple toute une vie, c'est terminé.
Sans commentaire.
Et au final, un CDI blindé comme il est à l'avantage de l'employé, ça donne quoi? Ca donne qu'un employeur va utiliser un max de CDD, ne plus embaucher la personne au bout de 2 CDD car risque de procès, même si l'employeur aurait bien voulu continuer avec lui.
Et donc ça montre quoi au final ? Que c'est l'employeur qui a le pouvoir sur qui il embauche, et comment ! Tu montres toi-même le déséquilibre de pouvoir dans tes exemples.
De la même manière que la protection des locataires empêche la mise en location d'appart qui restent alors vide.
Encore sans commentaires, je laisse à d'autres se faire un avis sur ta manière de penser.
Dans les deux cas, mêmes symptômes : à force de vouloir trop protéger un camp, l'autre camp ne s'engage plus.
L'autre camp _se permet_ de ne plus s'engager, nuance. Tu crois que les employés qui ne se font pas embaucher ont la vie rose ? Alors qu'un patron qui n'embauche pas a toujours sa place de patron ...
que ce putain d'employé fasse semblant pendant la période d'essai, et n'en foute pas une ensuite.
Ha ouai, les employés c'est vraiment la pire race qui existe, il cherchent toujours à niquer tout le monde, alors que les patrons sont tous des gentils. Je caricature, mais tu fais des généralités assez désobligeantes pour le "bas peuple". Oui, il y a des employés cons, comme il y a des patrons cons. Après, lesquels font le plus de mal à la société ?
[je zappe le passage sur les syndicalistes, c'est vraiment trop gros]
[je zappe même un bout de la suite]
D'ailleurs, tu remarqueras que sur le web, l'open-source, ça marche beaucoup en Free-lance, et ça ne déplait pas beaucoup au "employés" de ne pas avoir de protection : il est payé à l'acte, très bien, quand il fait du bon boulot. Et ce genre de "contrat" va être la norme dans quelques années, tous freelances, préparez-vous, pour la bête raison que les autres contrats (CDI...) ne sont plus du tout adaptés et que les syndicats n'ont aucune envie de s'adapter au monde réel, celui qui bouge.
Alors oui ça marche peut-être dans notre monde de petits riches, mais je ne dirais pas que c'est la panacée, comme tu as l'air de l'annoncer.
Bon, je n'ai pas le courage pour la suite, sauf :
tu merdes, tu dégages, tu retrouve du boulot le lendemain sans problème car un employeur peut "tenter" avec toi sans risque.
Donc en gros, tu donnes tout le pouvoir aux employeurs, c'est eux qui décident de qui va avoir du boulot, ou pas ; qui va manger, ou pas. Ça résume bien ton exposé.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Zenitram (site web personnel) . Évalué à 2.
Par contre, j'aurais plutôt voulu débattre sur le fond, ce que tu as l'air de vouloir éviter ...
Du coup j'avais passé du temps à écrire. Je n'écrirai plus des trucs aussi long pour expliquer le point de vue de l'employeur, puisqu'il reste à tes yeux "le méchant employeur qui peut jouer à Dieu avec son employé et qui n'a aucune problème financier" alors que l'employé dont le mot "épargner" est un mot inconnu a le droit à toute ta sympathie (pour moi, c'est un con, et il y en a partout, même cadre c'est ça le pire, pour qui un manque de paye à la fin du mois est un catastrophe "tous mes prêts").
Le monde change.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à 2.
Le problème, c'est que tu fais dans le manichéen, et que si je ne suis pas d'accord avec toi, c'est que je suis forcément un extrémiste de l'autre bout. Non, relis mes arguments.
N'empêche qu'au final, j'ai l'impression que t'as envie que la société se plie à ta vision des employés modèles au service des patrons modèles. Désolé, mais la vie ce n'est pas ça, il faut s'accomoder de toutes les tares qui affectent l'homme, même si on doit faire le "maximum" pour qu'elles ne pèsent pas non plus trop sur cette société.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Zenitram (site web personnel) . Évalué à 3.
Le soucis c'est que je l'ai déjà entendu trop de fois cet argumentaire du pauvre employé qu'il faut protéger à tous prix, qu'un mec viré c'est la mort pour l'employé etc... Alors bon.
N'empêche qu'au final, j'ai l'impression que t'as envie que la société se plie à ta vision des employés modèles au service des patrons modèles.
Mais parler des employés modèles au service des patrons horribles, est-ce plus réaliste? Je ne pense pas.
La seule chose que gagnent les syndicats et employés engourdis dans leurs idées est que les employés qui travaillent créent leur Entreprise individuelle pour arrêter que son travail n'aide à payer le voisin qui est au café 8h/jour. A trop vouloir protéger, on sanctionne les "gentils" (je te renvoie à mon argumentation sur les locataires : à trop vouloir protéger les mauvais payeurs, les bons locataires se retrouvent avec des loyers trop chers faute d'offre car ils faut bien compenser les risques des mauvais payeurs, est-ce le but?)
Et pour en revenir à la personne qui est le sujet de la discussion, c'est bien le méchant employé (qui n'a pas fait ce pourquoi son employeur le payait) et le gentil employeur (qui a attendu un paquets de mois avant de le virer), donc pas de raison d'avoir la moindre pitié pour le mec : il a choisi de faire le nécessaire pour être viré. Et comme il l'assume lui-même, ce n'est pas négatif, c'est un nouveau départ (alors que c'est vu comme un échec en France, question de mentalité.)
PS : je travaille actuellement avec un petit groupe d'américains, qui quand ils se sont fait jeté de leur boite où ils travaillaient tous, on fait une chose à la place de se lamenter sur leur sort : ils ont créé leur propre boite ensemble avec les sous mis de côté lors des jours heureux. Et cette boite a réussi à lever des fonds même en cette période de crise. La est la différence de vision sur un licenciement.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par IsNotGood . Évalué à 4.
Sauf si on est fonctionnaire, ça ne prète pas vraiment à discussion.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par IsNotGood . Évalué à 3.
Il n'y avait pas accord en Jeff Johnson et Red Hat et les parties se sont séparées sans heurt.
Bref, Jeff Johnson reste quelqu'un de très respectable.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à 2.
Par contre, pourquoi ta dernière remarque ?
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par IsNotGood . Évalué à 2.
Principalement car je ne comprennais pas ton raisonnement qui était d'accuser avant même d'avoir creusé le problème. Je me suis dit que tu avais une "culture" fonctionnaire. Dans le privé, globalement, on exige un minimum dans les prestations de l'employer. Chez les fonctionnaires on insite à la bonne prestation, c'est moin une exigence.
J'ai déjà bossé dans des administrations publics, et la culture y est "bizarre".
[^] # Ah... Les fonctionnaires!
Posté par Zenitram (site web personnel) . Évalué à 2.
Il faut toutefois noter que ce n'est pas vraiment la faute des "employés", fonctionnaires si c'est bizarre.
Suffit de se prendre quelques claques quand on y rentre pour après faire comme les autres :
- Grouillot de base, que tu bosses ou pas, c'est le même salaire, le même risque de se faire virer, alors pourquoi s'emmerder à bosser? Putain de conscience que certains ont, ça fait que les hôpitaux tournent avec ceux qui ont la conscience pas tranquille de laisser mourir les gens, pendant que ceux qui n'ont pas de conscience sont payés autant que toi mais sans la dépression qui va avec le boulot.
- Si tu bosses, c'est mal vu parce que bon ça veut dire qu'on pourrait diminuer le nombre de personnes dans ton services, alors que l'objectif du chef c'est d'avoir un max de personnes pour se faire bien voir et pouvoir ensuite aller ailleurs avec une prime. Quoi? Je fabule? Euh... Non.
Le "formatage" fonctionnaire est fait par "en haut", pas par les gens qui y sont, c'est ça le pire...
(pour me défendre, j'ai fait du 100% public, j'ai fait du 100% privé, j'ai fait du "grosse boite qui ressemble au public du coup, bref j'ai vu les bons et mauvais côtés de chaque "camp"...)
[^] # Re: Ah... Les fonctionnaires!
Posté par IsNotGood . Évalué à 3.
Bof. Par en haut et par en bas. Quand t'as un mec en haut qui veut faire bouger les choses (sans brutalité, juste faire bouger les choses à leur rythme normal), t'as les gens en bas qui freinent des quatres fers.
Dans mon dernier boulot, j'ai été impressionné par tout le géni, l'initiative, qui est mise par les gens d'en bas (pas tous !) pour être "peu productif" et/ou justifier leur faible productivité. Et ça bouffe du temps en détail insignifiant, à chipoter ici ou là, etc. Ça bosse globalement, mais c'est inéfficace et c'est fait exprès.
Par contre, ceux qui sont en CDD, etc, ils doivent cravacher (pour le confort des autres).
[^] # Re: Ah... Les fonctionnaires!
Posté par boq . Évalué à 3.
Ah bah voui hein! des vrais salauds ces fonctionnaires qui laissent mourir les gens!
Si tu bosses, c'est mal vu parce que bon ça veut dire qu'on pourrait diminuer le nombre de personnes dans ton services, alors que l'objectif du chef c'est d'avoir un max de personnes pour se faire bien voir et pouvoir ensuite aller ailleurs avec une prime. Quoi? Je fabule? Euh... Non.
Ben Si. Tu fabule. Je sais pas ou tu es tombé mais ça ne m'étonnerait pas qu'entre toutes les administrations, voir même entre les services, de france et de navarre il puisse (peut- être hein je sais pas, je voudrai pas non plus trop m'avancer ...) y avoir des disparités.
Y'a des fonctionnaires qui font le poireau devant la pointeuse 1/4 d'heure avant de pouvoir se barrer, c'est sûr. Plus que dans le privé à mon avis. Maintenant désolé mais la majorité des fonctionnaires bossent et non, vraiment pas, un fonctionnaire qui bosse ne se fera pas mal voir.
Et je ne sais pas de quand date ton dernier contact avec le secteur public mais de toutes façon il y a de moins en moins de personnes dans les services, restrictions budgétaires obligent, pour la même quantité de travail demandée bien sur. Mais bon comme c'est des fonctionnaires ça doit juste vouloir dire qu'ils glandent jusqu'à plus tard le soir au bureau non?
[^] # Re: Ah... Les fonctionnaires!
Posté par boq . Évalué à 2.
Ce que je voulais dire:
Malgré les apparences, les fonctionnaires sont des gens normaux :)
Le public a tendance à attirer plus de glandeurs que le privé, mais dans l'ensemble, ça tourne assez bien et les gens bossent. (expérience pas perso du tout mais je connais un certain nombre de fonctionnaires)
Le service où tu as débarqué est à mon avis plutôt une exception (et les exceptions c'est fait pour confirmer la règle comme dirait l'autre :)
Par contre l'exemple des hôpitaux est bien vache.
[^] # Re: Ah... Les fonctionnaires!
Posté par Zenitram (site web personnel) . Évalué à 2.
Euh... Au cas où tu ne m'aurais pas compris, c'est ce que j'ai dit!
Je comprend à 100% la réaction des fonctionnaires, et si je n'avais pas eu envie de faire autre chose, je serai certainement resté et fait comme eux : je n'ai aucune conscience morale ;-), ça ne me dérangeait pas d'en profiter quand j'ai abandonné toute espoir de faire changer les choses de l'intérieur.
Par contre l'exemple des hôpitaux est bien vache.
C'est du vécu, et discuté en direct avec d'autres "petits gens" des hôpitaux. Et je le réaffirme : heureusement pour nous que la plupart ont une conscience morale car avec les salaires de misères et surtout les conditions de travail ainsi que leur interdiction de faire grève..., mais malheureusement leur employeur en abuse tout en ne faisant pas grand chose pour ceux qui profitent du système.
[^] # Re: Ah... Les fonctionnaires!
Posté par boq . Évalué à 2.
J'suis complètement à la ramasse en fait. Je m'énerve alors que je suis d'accord.
Bientôt je vais péter la gueule à ceux qui OSENT me dire bonjour à ce train là :)
Bon ben désolé encore.
J'vais m'coucher moi tient.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par benoar . Évalué à 2.
Si tu parles du milieu du privé comme un endroit où on essaye très vite d'évacuer les problèmes sur quelqu'un sans réfléchir, alors oui, je suis un peu d'accord avec toi.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Sufflope (site web personnel) . Évalué à 1.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par kirikouu . Évalué à 6.
Plus sérieusement, il n'est pas incompétent, puisqu'il a été capable de faire son propre fork.
Apparemment, c'est juste qu'il avait un point de vue différent de ses supérieurs sur comment le boulot devait être fait.
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par Moonz . Évalué à 2.
Être compétent, c'est pas bien faire du code, mais bien faire le boulot demandé :)
(je ne réagis pas sur ce cas en particulier mais sur la remarque d'ordre général)
[^] # Re: Que ces choses là en termes délicats sont dites...
Posté par gemegik . Évalué à 3.
Assigner un employé à un projet différent ? Cela se fait tous les jours sans que la CGT appelle à la grève.
Muter quelqu'un, relocaliser un projet ailleurs ou tout simplement déplacer un boulet dans un projet moins sensible, c'est normal. Heureusement que l'employeur peut choisir à quelle tâche assigner ses ressources humaines.
# usurpation d'identité
Posté par B16F4RV4RD1N . Évalué à 2.
Si on lit le site http://rpm5.org/ on a vraiment l'impression que leur version est utilisée par tout le monde :
"Welcome to the home of the official RPM Package Manager (RPM) code base/.../ Traditionally, RPM is a core component of many Linux distributions, including Red Hat Enterprise Linux, Fedora, Novell SUSE Linux Enterprise, openSUSE, CentOS, Mandriva Linux, and many others./.../Additionally, the RPM archive format is an official part of the Linux Standard Base (LSB)"
Finalement, c'est quoi leur intérêt de continuer si aucune distribution ne l'utilise en fait ? On dirait que cela sert de base à openpk [http://www.openpkg.org/], mais du coup si ce n'est utilisé que là dedans, cela n'a plus vraiment lieu de s'appeler RPM. Red Hat, ou les ayant droit auraient-ils la possibilité d'attaquer rpm5.org pour usurpation d'identité ? Ok pour faire un fork, mais si c'est pour garder le même nom, c'est plus source de confusion qu'autre chose.
Sinon rien à voir, mais vous savez ce que devient xfree86 ? Apparemment ils sortent encore des versions, mais qui l'utilise vraiment ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: usurpation d'identité
Posté par cirdan_elf . Évalué à 1.
Il me semble que netbsd l'utilise dans son système de base, tout en proposant xorg dans les ports, mais j'en suis pas sûr.
[^] # Re: usurpation d'identité
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: usurpation d'identité
Posté par kowalsky . Évalué à 3.
Mais avant aussi, depuis la 2 on pouvait l'utiliser.
[^] # Re: usurpation d'identité
Posté par IsNotGood . Évalué à 2.
Rpm n'est pas une marque déposée (et ne peut plus l'être maintenant).
Enfin Jeff Johnson a énormemment travaillé sur rpm et en a autant la "paternité" que Red Hat.
Il y a eu discussion entre Red Hat et Jeff Johnson sur ce point. Il a dit qu'il laisserait Red Hat tranquille et vice versa.
Ça montre l'importance de déposer une marque... ou l'inverse puisqu'il n'y a pas de gros problèmes pour ce cas.
[^] # Re: usurpation d'identité
Posté par Sufflope (site web personnel) . Évalué à 1.
[^] # Re: usurpation d'identité
Posté par B16F4RV4RD1N . Évalué à 3.
RedHat pourra alors sauter de version et proposer direct RPM6, ce a quoi RPM5 répondra en sortant RPM500 Ultimate Pro(tm).
Quel fork intelligent !
Heureusement que Ian Murdock en entrant chez Sun n'a pas proposé de sortir Debian5...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: usurpation d'identité
Posté par Jean B . Évalué à 3.
La 0.9 et la 2.0 n'ont rien a voir avec la 1.0.
# Et sinon...
Posté par Aefron . Évalué à 6.
Mais il y a un truc qui me gêne profondément avec tous les gestionnaires de paquets qui les utilisent, et que j'ai testés : la suppression des dépendances inutiles.
Genre, j'installe A, qui fait venir B (lui même faisant venir B1, B2, ... Bi, et ainsi de suite) et C. Puis j'installe A', qui fait venir C. Si j'enlève A, je voudrais qu'il enlève automatiquement B, et les dépendances que seul B utilise (B1, B2, ... Bi... et les dépendances que seuls eux utilisent), mais surtout pas C, ni A' (et je ne veux pas entendre parler de machins qui vont rechercher les libs qui ne sont des dépendances de rien... parce que même si je les enlève, il restera, encore, leurs dépendances ; et puis, ça ne résout pas le problème des dépendances qui ne sont pas des librairies : bref, ce n'est pas une solution, c'est de la bidouille, et encore...).
J'avais testé Mandriva, Suse et Fedora il y a à peu près un an, et aucune ne gérait ça. Mandriva parlait d'introduire une gestion des dépendances à la désinstallation, à l'époque, mais je n'ai rien trouvé quant à ce qu'il en est maintenant... donc quid ?
Quitte à le préciser, je ne cherche pas à troller, ou à descendre qui que ce soit : dans l'usage que j'en ai, il fait partie de mes _exigences_ d'avoir un déterminisme carré quant aux paquets installés (apt, aptitude, paludis, ... le permettent - pas moyen de revenir en arrière une fois que j'y ai goûté ; ne pas avoir ça est éliminatoire en ce qui me concerne)... je veux juste savoir ce qu'il en est : pas plus - pas la peine de monter sur des chevaux de quelque taille que ce soit, en m'expliquant comme il a déjà été fait que je dois "dire ce dont j'ai besoin, pour qu'on m'explique en quoi c'est inutile".
Ça l'est sans doute pour certains, mais je ne saurais m'en dispenser... fuite d'informations quant à mes pratiques (avec ça, facile de savoir que j'ai testé la création de CD d'install ou des méthodes de chiffrage sur mon laptop, par exemple), bordel dans /etc ou /usr/share, ... mes raisons sont multiples, et ce n'est pas le "pourquoi" qui m'intéresse dans ce post : juste le "quoi".
[^] # Re: Et sinon...
Posté par reno . Évalué à 0.
Et comme a priori cela ne fait qu'économiser de la place disque, cela ne doit pas être une grosse priorité des dev.
[^] # Re: Et sinon...
Posté par Aefron . Évalué à 3.
Hein ? Par opposition à quoi ?
Un système où on a compilé des choses ?
D'une, on peut compiler pour faire un paquet (c'est même la manière propre de faire, dans quelque distro qui comprennen le concept de dépendance)... donc, là, les dépendances, ça se passe de la même manière que les paquets de la distro.
Et sinon, si on fait avec un make, et bien, on installe manuellement les dépendances, via des paquets, ou en les compilant aussi :
- dans le premier cas, ce sont des paquets installés manuellement (donc, pas de raison de les virer... et pour s'y retrouver, on regarde la base de donnée des paquets, et on voit qu'ils ont été installés manuellement, si celle-ci est capable de faire la différence entre installation manuelle ou automatique)...
- dans le deuxième cas, ça ne regarde pas le gestionnaire de paquets, puisqu'il n'y a pas eu de paquet...
J'ai déjà vu cette "raison" sur le bugzilla de RH... pour moi, c'est bidon. Qu'ils veuillent rester à une gestion arriérée des dépendances (éliminatoire, maintenant que j'ai goûté à une gestion complète), OK... mais ça n'est pas un argument, surtout quand tant d'autres le font.
Et comme je l'ai dit au-dessus, il y a des autres raisons (bien plus valables) que le gain de place...
Bref, pour moi, c'est un bug (et un très très gros)... prétendre que c'est une feature n'y change rien.
[^] # Re: Et sinon...
Posté par reno . Évalué à 2.
>Hein ? Par opposition à quoi ?
>Un système où on a compilé des choses ?
Oui.
Je trouve que tu passe un peu vite sur le premier cas, si tu compile quelque-chose qui dépend d'une libraire installée par une dépendance d'une application existante, alors retirer une application va retirer la dépendance ce qui par effet de bord peut casser ton application installée a la main.
Que cette fonctionnalité manque pour ceux qui font très attention a gérer leur machine et qui veulent des machines 'propres', ok, maintenant je ne sais pas si tout le monde voudrait cela comme comportement par défaut, c'est un changement des habitudes existantes..
[^] # Re: Et sinon...
Posté par Aefron . Évalué à 3.
... donc, pour les dépendances tu es en slip : à toi de gérer ce qui doit et ne doit pas être là... et si tu remplaces une vérification attentive des dépendances utiles par la supposition que "jusqu'ici tout va bien" (alors qu'en fait, que les dépendances soient là n'est juste qu'un heureux concours de circonstance), j'aurais tendance à dire que tu mérites que ça te retombe dessus.
Avec Debian, par exemple, si je compile et installe manuellement quelque chose avec un "configure;make;make install", et qu'il me faut des dépendances, je les installe manuellement : de fait, si je retire quelque chose qui a aussi ces dépendances, vu qu'elles auront été installées manuellement (ou simplement marquées comme installées manuellement : on ne vas pas se prendre la tête si elles sont déjà là), elles ne seront pas retirées, hein...
Maintenant, gérer les dépendances à la main est chiant, et c'est pour ça qu'en ces situations, faire un paquet qui listera les besoins en dépendance, c'est infiniment plus propre.
Bon, après, chacun fait comme il veut : FreeBSD a pkg_deinstall, qui permet la désinstallation automatique des dépendances ; il me semble qu'OpenBSD ne l'a pas... on peut très bien donner le choix à ceux qui veulent crader leur système de ne pas désinstaller les dépendances.
Mais le faire est une bonne pratique... et que ce soit fait automatiquement, une bénédiction. Si je peux comprendre que c'est un changement auquel certains ne sont pas prêts, je ne comprends pas qu'on puisse refuser d'implémenter une chose aussi essentielle, et courante, dans les gestionnaires de paquets modernes.
[^] # Re: Et sinon...
Posté par IsNotGood . Évalué à 1.
Faut pas pousser...
J'ai répondu ailleurs, mais un peu à côté de la plaque.
Ce que tu demandes est réalisable, pas de doute (d'ailleurs ça a été fait...).
Mais c'est compliqué et/ou moche, dangereux, etc.
Pour certains paquets (typiquement les librairies), on pourrait avoir un drapeau qui dit "me supprimer si aucun paquet dépend de moi".
On peut avoir un autre système qui est "ne garder que ce qui est demandé explicitement". Lors de l'installation il pourrait y avoir par défaut des paquets explicitement demandés (vim, etc).
C'est réalisable. Mais l'intérêt est faible et une source possible de problème. Par exemple m4 (ou même wget) est rarement un programme demandé explicitement par l'utilisateur. Donc il peut être supprimé si aucun programme en dépend. Mais m4 est aussi un programme pour utilisateur (comme l'est awk, grep, etc). On pourrait avoir une mise à jour qui vire m4 alors que ce dernier est utilisé par un programme (fait pas l'utilisateur). Et si ce programme est pour un serveur... c'est une catastrophe. Il y a le même problème pour les programmes qui ne sont pas gérés par le gestionnaire de paquet (par exemple l'installation d'un tar.gz).
Bref, la sécurité demande qu'on laisse ces paquets (soit disant inutiles) car ils ne gènent pas.
Il y a aussi d'autre trucs subtils. Par exemple les paquets type desktop-backgrounds . Ces paquets ne sont exigé par aucun paquet. Ben oui, c'est seulement pour faire joli. Que fait-on ? On les mets dans les paquets explicitement demandé à l'installation ? Idem pour, par exemple, gnome-vfs2-smb (utilisé en "plugin") ? On ajoute des dépendances explicites ? Par exemple gnome-desktop dépend de desktop-backgrounds. Mais si un utilisateur veut virer desktop-backgrounds...
C'est lourd à gérer.
Ceci (et on peut trouver d'autres cas où ça sucks (par exemple les paquet *-devel), plus le fait que c'est d'un intérêt très limité et parfois dangereux, fait que pour certains ce n'est pas du tout un "très très gros bug" ni une feature intéressante et donc rien est fait (en tout cas chez Fedora).
Pour toi c'est peut-être une super importante "feature" car tu installes et désintalles plein de programmes. Mais ce n'est pas un usage courrant de GNU/Linux (sauf peut-être pour les moules dlfp).
Le quoi est : on s'en fout.
[^] # Re: Et sinon...
Posté par Aefron . Évalué à 2.
Dans Debian, par exemple, tout ce qui est la base du système est marqué comme installé manuellement (au minimum, "aptitude search ~prequired"... il y a aussi les "~pimportant" et "~pstandard", dans une installation usuelle, mais ils ne sont pas indispensables au bon fonctionnement)... comme ça, pas de mauvaise surprise.
C'est "un peu" le pendant de la séparation système/ports chez BSD...
> gnome-desktop dépend de desktop-backgrounds. Mais si un utilisateur veut virer desktop-backgrounds
Ça, c'est l'affaire des mainteneurs... et leur choix...
Chez Debian, ils ont introduit les Recommends et Suggests, pour faciliter le travail de ceux qui ne veulent pas réfléchir, mais je ne suis pas fan du tout (mais je reconnais l'intérêt pour ceux qui veulent que ça "juste-marche")...
Bon, gérer ça, c'est lourd : complètement d'accord... mais la maintenance de paquets pour une distribution complète est lourde - rien de neuf sous le soleil.
> tu installes et désintalles plein de programmes. Mais ce n'est pas un usage courrant de GNU/Linux (sauf peut-être pour les moules dlfp)
Et comment tu testes des nouveaux paquets ? Dans une VM ? Et pour les trucs qui demandent un accès direct au matos ?
Et, franchement, l'installation frénétique de nouveaux paquets, je le vois tout le temps chez des utilisateurs pas trop expérimentés...
Toutes les machines ne sont pas des bouzins critiques en prod...
> Le quoi est : on s'en fout
Moui... un "quoi" teinté de "pourquoi"... ;) M'enfin, j'avais compris, en zieutant le bugzilla de RH (je n'arrive pas à retrouver la référence, mais le seul message de réponse était un "not a bug").
[^] # Re: Et sinon...
Posté par IsNotGood . Évalué à 1.
M'enfin, pourquoi ?
Le seul intérêt du truc est de gagner quelques Mo sur le disque dur. Il n'y a pas de perte de performance à garder des librairies qui ne servent à rien. Peut-être que le plus pénalisant est la mise à jour de librairie qui ne sont pas utilisée (téléchargement inutile).
L'intérêt est faible et ça peut donner quelques surprises pour ce que n'est pas librairies.
[^] # Re: Et sinon...
Posté par Aefron . Évalué à 2.
Le fait que les librairies restent (et en pratique, pas que les librairies, mais tout ce qui est dépendance... j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation ; en fait, seul le "métapaquet" du groupe d'applis le permettant était désinstallé) peut en dire long sur ce qu'on fait de la machine.
Je ne connais pas l'état exact des dépendances pour kmldonkey sur d'autres distros (et je le cite uniquement à titre d'exemple), mais sous Debian, si on active les Recommends (ce dont je ne suis pas fan du tout), il fait venir mldonkey-server (ce que je trouve particulièrement idiot - mais c'est comme ça , heureusement, par défaut, il n'est pas lancé)... si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Ce genre de choses, ça peut attirer la suspicion... et je n'ai pas envie de donner encore plus de raisons de me faire gratter mon laptop à la sortie de l'avion, juste parce qu'un jour, j'ai testé cryptkeeper ou kmldonkey.
C'est sans doute de la parano, mais je vois la non-désinstallation des dépendances comme une fuite d'informations privées... et je trouve qu'il y en a bien assez comme ça (je fais partie des gens qui adoreraient pouvoir activer un mode "je n'enregistre rien de privé" dans mon environnement de bureau : non ! Je refuse de stocker mes mots de passe, bookmarks, cache, mails et cie en local, sur mes stations à clickodrome - il y a bien assez de manières d'accéder à ça via un partage réseau sécurisé).
En outre, comme je le disais, si on laisse les dépendances s'accumuler, bonjour le bordel à l'autocomplétion (par exemple) dans /etc et /usr/share...
Sans parler de problèmes, fonctionnels ou sécuritaires, qui peuvent arriver quand on laisse les choses s'entasser... il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
Si je veux n'en utiliser qu'une, parce qu'elle a tel ou tel avantage (genre, il me semble que gnutls ne supporte pas de gérer un répertoire de certificats, mais un seul certificat à la fois), ça peut causer un problème si ces libs sont présentes en même temps... au moins me faire perdre du temps, jusqu'à ce que je me rende compte de ce qui coince (autre exemple avec ces deux libs : les noms des méthodes de chiffrage ne sont pas les mêmes - me suis encore cassé les dents dessus ce weekend).
Il y a aussi qu'il est plus pratique de gérer ce qui est installé sur un parc de serveurs, quand la désinstallation des dépendances est déterministe.
En ce moment, je bidouille pas mal CFEngine, et j'apprécie de pouvoir spécifier clairement la liste de ce que je veux qui soit présent sur la machine : pour ce qui est des dépendances et des désinstallations, c'est transparent - je ne spécifie que les paquets que j'aurais installés manuellement... ainsi, si j'installe un truc juste pour voir, je sais que s'il n'est pas listé dans ce qui doit être présent, lui et tout ce qu'il aura fait venir sera nettoyé au prochain fetch de la configuration...
Par contre, si le système ne faisait aucune différence entre paquets demandés, et leurs dépendances, ce serait lourd... très lourd : je serais obligé de spécifier explicitement ce dont je ne veux pas, plutôt que de me contenter de dire ce que je veux (ou alors, inclure la liste des dépendances récursives dans la liste de ce que je veux, voire enlever la gestion des désinstallations de mes scripts... pfff... paye ta galère)...
Bref, gagner quelques Mio, en effet, m'en fous pas mal (et encore, il y a des cas particuliers - j'ai récemment testé de l'OpenVZ dans du Virtualbox, et j'ai eu des tas d'emmerdes parce que pas assez de secteurs dans les disques virtuels, par rapport aux quotas, même s'il y avait largement assez d'espace - j'avais installé plein de trucs, et je me demandais ce qui faisait que je ne pouvais me connecter en SSH dans le conteneur : en fait, la machine ne pouvait plus rien y écrire)... mais ce n'est pas pour ça que je veux une gestion rigoureuse des dépendances installées... ;)
Je sais que ça va contre les anciennes traditions... mais les traditions, ça évolue : et aujourd'hui, moult gestionnaires de paquets supportent ça (et même par défaut). Franchement, j'aimerais vraiment voir cette fonctionnalité supportée dans des distros comme CentOS, parce que, aujourd'hui, c'est peu ou prou tout ce qui m'empêche de les utiliser (comme je le disais, quand on a goûté à quelque chose d'aussi pratique, difficile de revenir en arrière).
Donc, si la seule raison est la tradition, qui demande de moins bonnes pratiques que ce qui se fait maintenant : pourquoi pas ? Que ce soit possible n'est censé empêcher personne de faire comme avant (au moins jusqu'à ce que ça devienne la nouvelle tradition)...
[^] # Re: Et sinon...
Posté par IsNotGood . Évalué à 2.
Il n'y a pas de métapaquet dans Fedora. Il y a un truc de plus haut niveau qui sont les groupes. Oui, ça a le défauts que tu donnes et est principalement intéressant pour l'installation (ça selectionne automatiquement un ensemble de paquet pour un besoin typique de l'utilisateur). NB: c'est un truc que ne voit jamais rpm.
> mais sous Debian, si on active les Recommends
Pour info, Il n'y a pas "Recommends" dans Fedora (suggested a été ajouté à rpm il y a peu, mais Fedora ne l'utilise pas).
> heureusement, par défaut, il n'est pas lancé
Sous Fedora, les serveurs ne sont pas lancés par défaut. Il y a bien quelques exceptions (genre dbus, etc).
> j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation
Ça bouffe de la place disque... Rien d'autres.
> si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
J'ignore les détails, mais ça peut être normal. Par exemple kmldonkey n'est qu'un frontend pour mldonkey-server (ou mldonkey-core). Donc on peut avoir une bécane sans kmldonkey et n'utiliser que mldonkey-server à distance.
En passant, si tu utilises mldonkey, bittorrent, etc qui accèptent des connexions externes, utilises les avec un compte différent que ton compte principal. Linux (X11/tty) c'est nickel pour ça.
Tu peux avoir Firefox sur un serveur. Si tu l'utilise jamais, même si Firefox est ce qu'il y a de pire niveau sécurité (normal vu sa complexité), ce n'est pas un problème.
Si t'as la bétise d'utiliser Firefox, mldonkey, Azureus, etc en root sur un serveur en production... Je ne dis pas que tu le fais, mais la sécurité c'est plus sérieux que de s'assurer que des paquets non utilisés soient désintallés.
> De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Et ?
Je connais mal cryptkeeper, mais je ne vois pas le problème si cryptkeeper utilise encfs. Si c'est pour installer un truc qui ne marchera pas...
Je ne vois pas en quoi l'installation de encfs est un risque ... surtout si tu l'utilises pas. Et pour qu'un crakeur l'utilise, il faut déjà qu'il est cracké ta bécane.
> il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
C'est plus un problème de gestion de la distribution (ou upstream) qu'un problème de gestionnaire de paquet.
Ceci dit, on ne peut pas vraiment te donner tord. Si quelqu'un le fait pour Fedora (je pense plus spécifiquement à PackageKit) ça ne sera peut-être pas refusé.
M'enfin, tu fais de l'"enculage de mouche".
[^] # Re: Et sinon...
Posté par Aefron . Évalué à 2.
C'est pour ça que j'ai mis des guillemets... je savais que c'était un truc un peu différent, mais je ne me souvenais plus du nom - merci pour le rappel.
> on peut avoir une bécane sans kmldonkey et n'utiliser que mldonkey-server à distance
C'est même fait pour ça... Le seul intérêt que j'aie à installer kmldonkey, c'est de me connecter à mon serveur mldonkey, tranquillement installé, tout seul, dans son conteneur (et bien entendu, ne tournant pas avec les droits root - je suis peut-être chiant, mais pas complètement idiot).
Je critiquais juste le choix de "packaging" de Debian en la matière, et en ai profité pour illustrer que la non désinstallation de la "dépendance" qu'est mldonkey-server pourrait être chiante (en fait, c'est un "Recommend"... alors que j'estime que ce devrait être un "Suggest", pour ne pas le voir installé par défaut sur les distros où les "Recommends" n'ont pas été désactivés, typiquement les machines à clickodrome)
> Je ne vois pas en quoi l'installation de encfs est un risque
Je le vois plus comme un risque en ce qu'on pourrait me demander ce que fout un truc pour gérer des partitions chiffrées, ou une appli P2P (pour mldonkey) sur ma machine... et me faire chier avec ça (pas mal de laptops disparaissent aux douanes d'aéroport... je ne pense pas qu'ils aillent jusqu'à vérifier ce qui est installé, mais sait-on jamais, avec ces zozos - bref, vivons heureux, vivons cachés ; la sécurité par l'obscurité ne se suffit jamais, mais il serait bête de s'en passer [sinon, autant balancer ses clés privées et cie])...
Pour moi, le risque est celui de la fuite d'informations quant à mes pratiques - ce qui suffit à me déranger.
> M'enfin, tu fais de l'"enculage de mouche".
Ah, mais, je ne le nie pas, hein. Je reste conscient que la désinstallation automatique des dépendances est "assez récente".
Mais je trouve ça ultra-utile quand même... et j'ai vraiment du mal à m'en passer. Clairement, c'est même le genre de trucs qui me ferait utiliser plus de distros différentes, si c'était plus répandu (CentOS a par exemple un long support [7 ans, je crois, non ?]... mais la gestion non-déterministe des dépendances à la désinstallation me rebute, quant à l'intégration avec mes scripts CFEngine ; je trouve ça trop limité, et pas vraiment gérable).
Bref, quand ça arrivera dans plus de distros, je serai dans les premiers à le saluer.
[^] # Re: Et sinon...
Posté par wismerhill . Évalué à 2.
C'est le cas dans la 2009.0, lorsque tu désinstalle un paquet et qu'il y a des paquets qui avaient été installés automatiquement qui ne sont plus utilisés il te prévient. Tu peux alors utiliser urpme avec l'option --auto-orphan pour les supprimer.
[^] # Re: Et sinon...
Posté par Aefron . Évalué à 2.
Et, ça supprime aussi les dépendances des dépendances (récursivité, quoi) ?
[^] # Re: Et sinon...
Posté par reno . Évalué à 2.
http://www.susegeek.com/utility/rpmorphan-find-delete-orphan(...)
D'après la description cela fait ce que tu recherche, enfin bien sûr il faut utiliser Suse (gros soupir).
[^] # Re: Et sinon...
Posté par Aefron . Évalué à 2.
Pas tout à fait : d'après la description, c'est l'équivalent de deborphan, ou rpm-find-leaves...
... sauf que, justement, je trouve ça trop archaïque : a priori, ça ne liste que ce qui n'est la dépendance de rien ; évidemment, ça pose problème quand on parle de dépendances autres que les librairies...
... parce que si on inclue les exécutables et les choses du genre, il va probablement nous en lister des tonnes qui ne sont pas des dépendances... ainsi, par défaut, le vieux deborphan ne s'occupe que des librairies. Sauf que les dépendances ne sont pas toujours des librairies (et puis, souvent, ce genre d'outils doit être exécuté plusieurs fois successives, pour arriver à tout détecter : un peu lourdingue). Sans parler des librairies qu'on a pu installer à la main, pour des choses qu'on a compilées : et bien là, sans pitié, elles seront listées.
L'équivalent de ce que je recherche, c'est plutôt l'option autoclean d'apt, ou aptitude... a priori, ça suppose de faire la différence entre ce qui est installé automatiquement, et ce qui est installé explicitement - mais ça, je pense que ça doit être intégré au gestionnaire de paquets, et à sa base de données. Un utilitaire externe qui tente de faire une tambouille, c'est malheureusement très loin d'être idéal.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.