Par exemple, même sous linux, en 15 ans, je ne m'en suis jamais servi.
Il y a 18 ans, je travaillais sous Windows NT 4, et j’avais ajouté un shareware (dont j’ai oublié le nom, mais que j’avais même payé) pour avoir des bureaux virtuels.
Il y a 20 ans, je travaillais sous un terminal X connecté à un serveur sous DEC OSF/1 (renommé par la suite Digital Unix, puis Tru64 Unix) et j’avais remplacé le gestionnaire de fenêtres d’origine (celui de Motif) par ctwm, l’un des premiers si ce n’est le premier à offrir des bureaux virtuels.
Je ne suis venu à Linux qu’ensuite…
Enfin tout ça pour dire que je ne considère pas qu’un système sans bureaux virtuels soit un environnement de travail correct.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ben chez moi, dans les applications Qt, quand je fais Ctrl-C ou Ctrl-V dans un champ de texte, au lieu de copier ou de coller le texte, il fait comme si j’avais pas appuyé sur la touche contrôle (donc il insère/remplace la sélection par la lettre c ou v)
Juste pour être sûr : n’essaies-tu pas de taper tes raccourcis avec le Ctrl droit en utilisant la disposition Azerty dite « fr oss » ?
La touche Ctrl droit a été sabotée dans cette disposition il y a déjà un certain temps.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Quand est-ce que l’informatique cessera de mettre des bâtons dans les roues des utilisateurs?
Ça a été pire. Vers 1993, il restait des serveurs mails qui pourrissaient le 8ème bit — avec du code exprès pour ça — parce que les développeurs américains avaient décidé que le reste du monde (pas que les utilisateurs de Bépo) pouvait aller se faire f… (oui, bon, il y a certains trucs qui ne permettaient la transmission que sur 7 bits… il y a encore bien plus longtemps).
Même encore maintenant, sur un *BSD brut d’installation, tu as des risques que les caractères accentués ne passent pas. Éventuellement, il gère ta disposition clavier sans problème… et te remplace « é » par « \351 » ou « 'e »). Cela dit, les développeurs des *BSD pourraient profiter du fait qu’ils n’ont pas encore atteint les 8 bits pour passer directement de l’ASCII à l’UTF-8.
Le problème actuel sous Linux, c’est que les développeurs de plusieurs toolkits sont convaincus qu’ils sauraient bien mieux gérer le clavier que ça n’est fait dans X et qu’ils le font chacun de leur côté dans leur toolkit. Même s’ils avaient raison, ce serait merdique dès que tu n’utilises pas que des logiciels développés avec le même toolkit. D’un autre côté, il me semble que quelqu’un écrivait récemment ici que l’interface graphique des logiciels Gnome devient inutilisable sous d’autres environnements, alors pas sûr que les choses soit parties pour s’arranger…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Des décorations de fenêtres qui remplacent celles Xfwm4/KWin4 !
Pour ma part, j’utilise des applications de MATE avec Xfce, ça s’intègre très bien, pas uniquement les décorations, mais même le thème (MATE utilisant encore Gtk 2). Et par rapport à des applications KDE, ça évite le lancement de services en tâche de fond qui restent quand on quitte les applications.
Évidemment, il y a des risques que ça se dégrade lorsque MATE passera à Gtk 3 (au moins pour le thème), mais ça restera sûrement plus utilisable que les applications Gnome 3…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Un exemple comme ça : supposons, je surfe, je clique sur un lien pas à jour (ça arrive) et je tombe sur une page 404, sans lien dessus (cas classique).
Que fais-je ?
Eh bien j’édite la barre d’URL pour enlever tout ou partie de la partie adresse sur le site pour essayer d’arriver si possible un peu plus haut dans la hiérarchie du site ou à défaut à sa racine.
Le navigateur merdique qui équipe mon téléphone con oblige à retaper une URL en entier plutôt que de permettre d’éditer l’URL courante et crois-moi, c’est vraiment pénible !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
« Regroupant », c’est le mot clé.
L’ensemble des « journaux » au sens LinuxFr mériterait le nom de journal, même l’ensemble des publications d’un utilisateur donné, mais chaque publication mériterait au mieux le terme d’« article »… sauf que sur LinuxFr c’est déjà pris pour les articles « officiels ».
Tout ce qui m’est venu d’autre, c’est billet, parce que ça peut désigner dans un journal papier un article moins formel, comme dans le terme « billet d’humeur ». Je ne dis pas qu’il n’y a pas mieux. Il y aurait aussi « Entrée de journal », mais ce serait à mon avis moins bien, parce que c’est une traduction mot à mot qui n’est utilisée qu’en informatique.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Par exemple, si un fichier est modifié dans deux profils, les heuristiques de synchronisation simplettes de type «prendre le fichier les plus récent» mènent à des pertes de données mais Unison détecte un conflit et demande l'assistance de l'utilisateur pour gérer ce cas difficile — ce qui est la seule méthode possible pour résoudre le conflit.
Oui, mais ça pourrait être découplé (ils me semble que Coda et Intermezzo font ou faisaient quelque chose dans le genre) :
– un système de fichier qui fait la synchronisation automatiquement en renommant en cas de conflit le fichier le plus ancien avec un suffixe spécifique et qui inscrit le conflit dans un journal ;
– une application lancée à l’ouverture de session qui présente les conflits inscrits dans le journal et offre de les résoudre.
L’avantage d’une telle solution est que ce n’est pas bloquant, comme Unison où il faut bien faire la synchronisation et régler les conflits avant de travailler sur le répertoire.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Tant qu'à avoir de la haute dispo, autant partir sur du CEPH-FS ou truc du genre non ?
J’en connais qui ont mis en place Ceph sur une grosse infrastructure.
D’après eux, Ceph est maintenant stable (il y a un an ou deux seulement, ils ont encore eu une perte totale des données du système de fichier suite à un bug — enfin ils ont des sauvegardes), mais CephFS pas encore.
Après, tu peux faire du NFS sur XFS sur Ceph (il me semble que c’est ce qu’ils font)…
Sinon, leur conclusion est que Ceph permet d’économiser sur le stockage (pas la peine de payer cher pour la performance, la parallélisation s’en charge), mais pas sur le réseau (10 Gb/s indispensables entre les nœuds Ceph pour une organisation d’une certaine taille).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J'ai utilisé un simple script bash, appelé depuis le gestionnaire lightdm. Le script utilise la variable $USER qui lui est passée, est synchronise le dossier de l'utilisateur avec un serveur rsync (debian)
À la réflexion, il manque un détail pour comprendre ta solution : quand fais-tu la synchronisation ?
Si tu la fais dans les deux sens à l’ouverture de session, -u évite d’écraser des fichiers plus récents, mais tu ne peux pas faire de --delete, donc tous les fichiers effacés reviennent.
Si tu la fais dans le sens serveur → station de travail à l’ouverture de session et station de travail → serveur à la fermeture de session, il y a un cas qui va être problématique : le plantage de X ou la coupure de courant. À l’ouverture de session qui suivra, la synchro sera faite depuis le serveur alors qu’elle n’a pas été faite dans l’autre sens. Si tu utilises l’option --delete, ça veut dire que les nouveaux fichiers seront effacés. Si tu ne l’utilises pas, ça veut dire que les fichiers effacés reviendront tout le temps.
Par ailleurs, -u dépend pour fonctionner correctement d’une date correcte sur les machines. NTP fortement conseillé !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Quelle différence par rapport à utiliser l'installateur ?
Il ne demande pas d’investir du temps pour le maîtriser.
Je ne l’utilise même pas une fois par version de la distribution : je mets à jour mon système type.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Si tu fait des trucs comme "installer des tas de machines", il y Kickstart, tout comme dans la doc de RHEL.
Je n’aime pas trop miser sur des outils spécifiques : je peux être amené à changer de distribution et par ailleurs, on n’est jamais sûr qu’ils ne disparaissent pas brusquement.
Et puis, le dialogue que tu cherches existe encore, il est passé à firstboot, la 2nd partie de l'installeur
Je me suis dit « Hein ??? QUELLE seconde partie ??? ». Je sais bien qu’il y en avait une, mais quand j’ai testé une Fedora 20, je n’en ai pas eu.
J’ai refait le test (sur une machine virtuelle) ; pas mieux.
J’ai vérifié les dépôts, il n’y a plus de paquet firstboot sur la Fedora 20 (il existait encore sur la 19).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J’ai un plutôt l’impression qu’actuellement, Ubuntu et Fedora visent surtout les portables. Je ne dis pas que c’est aberrant, après tout, ça se vend plus que les machines de bureau.
Par ailleurs, il y a desktop et desktop. La configuration n’est pas la même sur une machine du boulot avec tout centralisé sur le serveur que sur une machine perso autonome.
Imagine une Fedora d’avant la 18 (neuneuïsation de l’installeur).
L’installeur te donnait la possibilité de configurer directement la base d’utilisateurs sur LDAP ou NIS (avec éventuellement authentification sur Kerberos) avec pour LDAP récupération du certificat et d’un point de vue général tout bien configuré : pam, nsswitch.conf, ldap.conf ou yp.conf… et autofs qui marche directement.
Des trucs que j’avais passé pas mal de temps à configurer correctement lors du passage à LDAP en 2002 (il faut dire qu’à l’époque, les distributions ne prévoyaient pas encore trop ça, et les docs n’indiquaient pas les bons attributs LDAP, il avait fallu que je trace les accès au serveur pour savoir quoi y mettre), que même mon collègue incompétent (actuellement en reconversion professionnelle après un éclair de lucidité) pouvait ainsi configurer correctement en peu de temps.
Avec Ubuntu, il n’y a pas ça (avec les versions récentes de Fedora non plus…). Je ne peux pas être sûr que je n’aie pas raté un outil génial pour le faire après l’installation, mais autofs n’est même pas prévu pour démarrer après le réseau. Je t’invites à vérifier toi-même /etc/init/autofs.conf.
Compare par exemple avec /etc/init/ypbind.conf (paquet nis), qui lui est bien prévu pour démarrer après le réseau (enfin ce n’est pas clair que ça marche si le réseau est configuré avec NetworkManager ou en DHCP, cela dit).
Tu pourras au passage constater que démarrer un service après le réseau est moins trivial qu’avec une init System V ou systemd…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Contrairement à Coda, Intermezzo fonctionnait avec les systèmes de fichiers (disque) existants.
Malheureusement ses développeurs ont été embauchés pour développer Lustre et Intermezzo est tombé à l’eau.
Ce type de projet doit exister, non?
En espace utilisateur, il y a les outils de synchronisation courants, mais pas automatisés, du coup.
Par exemple, Unison peut fonctionner sur une liaison ssh (à condition d’utiliser le port ssh standard).
rsync, si on modifie indépendamment un fichier des deux côtés, ça va être problématique.
csync est peut-être à voir.
Cela dit, ces outils imposent une copie complète du répertoire, ce qui n’est pas envisageable dans un environnement où les utilisateurs se connectent indifféremment sur n’importe quelle machine d’un parc.
Pour autant que je sache, ce n’est (était) pas le cas de Coda ou Intermezzo (correctement paramétrés).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Je ne dis pas que le projet est réellement actif, mais Coda est toujours disponible sur Fedora, par exemple.
Intermezzo est mort et enterré, malheureusement.
C’est quand même dingue que des systèmes de fichiers réseau qui répondent bien mieux aux besoins actuels que NFS ou CIFS ne soient pas plus soutenus et utilisés…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Finalement, lorsqu'on a une centaine d'utilisateurs, l'espace disque sur une station est infini comparé à la bande passante d'une réseau, même en 1G.
cachefilesd, un cache en lecture en complément à NFS, permet de limiter l’usage de la bande passante et d’améliorer la réactivité.
Il est déjà empaqueté pour certaines distributions.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Et donc la rapidité de systemd est juste une preuve que toutes les features sont implémentées correctement.
Vu comme ça, quand je me prends un blocage d’un quart d’heure ou plus à l’arrêt de la machine (montages NFS avec autofs, unités systemd non modifiées), ça doit bien prouver qu’il y a des trucs pas correctement implémentés…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ceci dit, mon coloc semble aussi se plaindre d'autofs qui segfault et se vautre.
Du coup, ça ne marche pas trop…
Donc j'aurais tendance plus à dire que c'est un souci spécifique à autofs.
Oui, mais lié à systemd.
Avec systemd, autofs se retrouve dans un CGroup spécifique alors qu’il est sensé monter des répertoires pour des utilisateurs qui sont dans un autre ; c’est ça qui fait foirer. Les versions récentes de systemd intègrent un contournement spécifique (peut-être était-il déjà dans les versions précédentes sauf qu’il plantait).
Si ton colloc passe à une version de systemd (donc à la verstion de Mageia qui la contient, vu que changer de version de systemd n’est pas forcément trivial) égale ou supérieure à 195, le problème devrait disparaître (… sauf s’il a un autre problème).
Tu as utilisé l'implémentation dans systemd ?
Ce gadget ne joue pas dans la même cour qu’autofs : il ne permet pas d’utiliser une table d’automontage située sur un serveur (LDAP ou NIS).
C’est le souci avec les services qui gravitent autour de systemd : ils se multiplient mais ne font qu’une partie du boulot des services qu’ils sont sensés remplacer (à l’exception peut-être de journald).
À court ou moyen terme, on devrait avoir un stockage centralisé (suffisant) pour tous nos utilisateurs, donc je devrais pouvoir me passer de la table d’automontage et utiliser pam_mount. Pas sûr que le démontage et donc l’arrêt du système fonctionneront mieux pour autant…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Mais c'est quand même une drôle d'idée d'utiliser Fedora si on ne veut pas beaucoup bidouiller.
Quelle distribution suggères-tu ?
J’ai des utilisateurs qui veulent des versions récentes d’un tas de trucs, ça élimine CentOS et Debian stable.
Par rapport à des distributions plus confidentielles, Fedora et Ubuntu ont l’avantage que beaucoup de choses sont déjà empaquetées pour elles. Ça fait gagner pas mal de temps.
D’autres utilisateurs (ou quelquefois les mêmes) veulent continuer à utiliser des logiciels commerciaux dont on n’a que de vieilles versions (faute d’avoir payé la maintenance), du coup le fait que Fedora fournisse un certain nombre de bibliothèques de compatibilité (contrairement à Ubuntu) est un avantage.
Jusqu’à la version 14, Fedora était bien adaptée à un fonctionnement en machine cliente, contrairement à Ubuntu (depuis qu’elle n’a plus le même système d’init que Debian).
Avant systemd, contourner les éventuels bugs de la Fedora était moins lourd que de transformer Ubuntu en système client fonctionnel.
Alors maintenant, je changerais bien, mais comme toutes les distributions qui disposent d’un large choix de paquets sont déjà dans le Borg ou sur la voie de l’assimilation…
Si je comprends bien la doc, il faut mettre NFS dans After et dans Require pour qu'il attende complètement qu'il soit démarré/arrêté.
Ça, c’est la théorie. Dans la pratique, j’ai pour l’arrêt des traces comme quoi le démontage des partitions NFS est bien lancé avant l’arrêt du réseau, sauf qu’il n’est pas fini quand l’arrêt du réseau est lancé.
Si j'ai bien compris ta situation, sans systemd, tu te traînerais des processus qui ne se terminent pas à la fermeture de la session.
L’un fait partie de systemd. L’autre de Gnome, mais si on lui laissait un poil de temps avant de tout remballer, il se terminerait probablement normalement. D’ailleurs si je ferme la session sans lancer l’arrêt, il disparaît.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J’ai la joie d’administrer des postes en réseau avec des Fedora (donc systemd) en poste client (j’ai des utilisateurs qui veulent des versions récentes d’un certain nombre de trucs) et des services Unix classiques : NFS, autofs…
Bon, j’ai dû laisser tomber pour la Fedora 17, la version de systemd qui était dessus plantait complètement autofs. Et là, je n’en étais pas à résoudre le problème moi-même comme à l’époque des scripts bash, alors que les développeurs de Fedora eux-mêmes n’ont pas réussi avant la sortie de la 18 (en rétroportant une correction ; mêmes eux n’ont pas les compétences pour le corriger eux-mêmes).
La Fedora 19 marchait correctement au début (peut-être après ajout d’une dépendance sur un des services systemd, mais ça restait raisonnable).
J’ai fait une mise à jour (à la suite de la faille sur OpenSSL) et là, c’est le drame, l’arrêt qui se remet à merder complètement s’il est lancé directement depuis une session utilisateur : blocages de l’ordre du quart d’heure ou plus, dus en particulier aux partages NFS qui sont démontés après l’arrêt du réseau et systemd qui les attend… longtemps.
Alors, j’ai configuré logind pour qu’il tue les processus de l’utilisateur à la fermeture de session (sinon, il traînait des processus qui bloquaient le montage, en particulier un de Gnome et un de… systemd).
J’ai ajouté un pseudo-service intermédiaire démontant (lors de l’arrêt) les partitions NFS et définissant surtout des dépendances avec autofs d’un côté et le réseau de l’autre pour s’assurer de l’ordre.
J’ai aussi ajouté une temporisation de quelques secondes à l’arrêt du service autofs.
Alors, ça marche moyennement (entre 30 s à 1 minute pour l’arrêt, pas mieux que le démarrage), mais ça remerde bien plus si je retire n’importe laquelle de mes modifs.
À voir les traces, systemd essaye de faire un arrêt très rapide… en lançant les arrêts des services dans l’ordre des dépendances, mais pour certains (notamment autofs et les démontages NFS) en parallèle, sans attendre que l’arrêt du service soit fini pour commencer l’arrêt de celui dont il dépend. C’est quand même génial !
Sur un système client typique avec répertoires sur NFS, c’est la catastrophe.
Même Slackware avec son arrêt sauvage type BSD à l’ancienne s’en sortirait mieux.
Pour l’arrêt, il envoie un Ctrl-C aux processus, puis les tue salement après quelques secondes s’ils ne se sont pas terminés, mais avant tout cela… il démonte les partitions NFS !
Le seul argument que j’aie à la décharge de systemd, c’est qu’après avoir configuré une Ubuntu 12.04 de la même manière, je sais qu’Upstart en est à un stade encore pire : il lance autofs avant le réseau, donc même le démarrage rate (l’intérêt d’autofs, c’est d’aller chercher la table de montage sur le serveur avec LDAP ou NIS). Pour que ça marche, il faut rajouter les dépendances soi-même, sauf que c’est moins pratique à configurer qu’avec systemd et mal documenté…
Alors évidemment, systemd, ça marche sur un ordinateur portable, donc autonome. Des systèmes grand public (dans le mauvais sens du terme) comme Ubuntu et Windows aussi.
Et pour démarrer aussi vite que systemd sur un portable, pas besoin de quelque chose d’aussi compliqué. Sur une Arch avant systemd, je lançais dbus et un autre service puis quasiment tous les autres en parallèle sans aucun problème et le démarrage était aussi rapide.
Partant d’un a priori positif sur systemd du point de vue de la conception avant que Fedora ne l’utilise vraiment, mon avis devient de plus en plus négatif (ça se voit au fil des posts).
Mais le temps que je perds dessus se cumule et son fonctionnement ne s’améliore pas réellement (par rapport à la Fedora 17, si, mais la version qui était dessus était bien pire que les précédentes).
En tant qu’administrateur système, Systemd est la plus grosse plaie que j’aie eu récemment.
Et que fait un système avec systemd qui me manquerait sans ? Rien !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # USA
Posté par Arthur Accroc . En réponse à la dépêche Tails 1.1 est disponible. Évalué à 4.
Bah, on sait déjà qu’il n’en faut pas plus pour se retrouver en taule dans le « pays de la Liberté ».
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Bureaux virtuels
Posté par Arthur Accroc . En réponse au journal Windows est il prêt pour le Desktop ? . Évalué à 5.
Il y a 18 ans, je travaillais sous Windows NT 4, et j’avais ajouté un shareware (dont j’ai oublié le nom, mais que j’avais même payé) pour avoir des bureaux virtuels.
Il y a 20 ans, je travaillais sous un terminal X connecté à un serveur sous DEC OSF/1 (renommé par la suite Digital Unix, puis Tru64 Unix) et j’avais remplacé le gestionnaire de fenêtres d’origine (celui de Motif) par ctwm, l’un des premiers si ce n’est le premier à offrir des bureaux virtuels.
Je ne suis venu à Linux qu’ensuite…
Enfin tout ça pour dire que je ne considère pas qu’un système sans bureaux virtuels soit un environnement de travail correct.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Fable
Posté par Arthur Accroc . En réponse au journal Zut alors, rien à vendre ?. Évalué à 5.
Une version plus courte est racontée dans « Mon nom est Personne ».
C’est sympa en rimes, mais il y a une erreur sémantique dans l’avant-dernière strophe :
Écrit comme ça, c’est le renard qui veut remercier son sauveur…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Ctrl
Posté par Arthur Accroc . En réponse au journal Défouloir, pamphlet, troll: Chromium, Bépo et NIH. Évalué à 4.
Juste pour être sûr : n’essaies-tu pas de taper tes raccourcis avec le Ctrl droit en utilisant la disposition Azerty dite « fr oss » ?
La touche Ctrl droit a été sabotée dans cette disposition il y a déjà un certain temps.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Pas d’aujourd’hui…
Posté par Arthur Accroc . En réponse au journal Défouloir, pamphlet, troll: Chromium, Bépo et NIH. Évalué à 10.
Ça a été pire. Vers 1993, il restait des serveurs mails qui pourrissaient le 8ème bit — avec du code exprès pour ça — parce que les développeurs américains avaient décidé que le reste du monde (pas que les utilisateurs de Bépo) pouvait aller se faire f… (oui, bon, il y a certains trucs qui ne permettaient la transmission que sur 7 bits… il y a encore bien plus longtemps).
Même encore maintenant, sur un *BSD brut d’installation, tu as des risques que les caractères accentués ne passent pas. Éventuellement, il gère ta disposition clavier sans problème… et te remplace « é » par « \351 » ou « 'e »). Cela dit, les développeurs des *BSD pourraient profiter du fait qu’ils n’ont pas encore atteint les 8 bits pour passer directement de l’ASCII à l’UTF-8.
Le problème actuel sous Linux, c’est que les développeurs de plusieurs toolkits sont convaincus qu’ils sauraient bien mieux gérer le clavier que ça n’est fait dans X et qu’ils le font chacun de leur côté dans leur toolkit. Même s’ils avaient raison, ce serait merdique dès que tu n’utilises pas que des logiciels développés avec le même toolkit. D’un autre côté, il me semble que quelqu’un écrivait récemment ici que l’interface graphique des logiciels Gnome devient inutilisable sous d’autres environnements, alors pas sûr que les choses soit parties pour s’arranger…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Applications MATE
Posté par Arthur Accroc . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 5.
Pour ma part, j’utilise des applications de MATE avec Xfce, ça s’intègre très bien, pas uniquement les décorations, mais même le thème (MATE utilisant encore Gtk 2). Et par rapport à des applications KDE, ça évite le lancement de services en tâche de fond qui restent quand on quitte les applications.
Évidemment, il y a des risques que ça se dégrade lorsque MATE passera à Gtk 3 (au moins pour le thème), mais ça restera sûrement plus utilisable que les applications Gnome 3…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: bof...
Posté par Arthur Accroc . En réponse au journal [ HS ][elections européennes] : Je suis surpris . Évalué à 10.
Justement !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: CQFD ?
Posté par Arthur Accroc . En réponse au journal GNOME Web, alias Epiphany : un navigateur que je trouve élégant. Évalué à 6.
Un exemple comme ça : supposons, je surfe, je clique sur un lien pas à jour (ça arrive) et je tombe sur une page 404, sans lien dessus (cas classique).
Que fais-je ?
Eh bien j’édite la barre d’URL pour enlever tout ou partie de la partie adresse sur le site pour essayer d’arriver si possible un peu plus haut dans la hiérarchie du site ou à défaut à sa racine.
Le navigateur merdique qui équipe mon téléphone con oblige à retaper une URL en entier plutôt que de permettre d’éditer l’URL courante et crois-moi, c’est vraiment pénible !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: « Journal »
Posté par Arthur Accroc . En réponse au journal GNOME Web, alias Epiphany : un navigateur que je trouve élégant. Évalué à 3.
« Regroupant », c’est le mot clé.
L’ensemble des « journaux » au sens LinuxFr mériterait le nom de journal, même l’ensemble des publications d’un utilisateur donné, mais chaque publication mériterait au mieux le terme d’« article »… sauf que sur LinuxFr c’est déjà pris pour les articles « officiels ».
Tout ce qui m’est venu d’autre, c’est billet, parce que ça peut désigner dans un journal papier un article moins formel, comme dans le terme « billet d’humeur ». Je ne dis pas qu’il n’y a pas mieux. Il y aurait aussi « Entrée de journal », mais ce serait à mon avis moins bien, parce que c’est une traduction mot à mot qui n’est utilisée qu’en informatique.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # « Journal »
Posté par Arthur Accroc . En réponse au journal GNOME Web, alias Epiphany : un navigateur que je trouve élégant. Évalué à 5.
C’est l’utilisation du terme « journal » faite sur LinuxFr qui n’est pas très appropriée (choix de la mauvaise traduction d’un terme anglais ?).
« Billet » par exemple serait mieux.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Comment ?
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 2.
Du coup, si quelqu’un utilise deux machines, il doit effacer les fichiers deux fois de suite (sinon la deuxième machine les remettra sur le serveur).
Ça peut aussi valoir le coup d’exclure de la synchronisation les caches de navigateurs ou autres répertoires de scories sans intérêt.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Unison
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 3.
Oui, mais ça pourrait être découplé (ils me semble que Coda et Intermezzo font ou faisaient quelque chose dans le genre) :
– un système de fichier qui fait la synchronisation automatiquement en renommant en cas de conflit le fichier le plus ancien avec un suffixe spécifique et qui inscrit le conflit dans un journal ;
– une application lancée à l’ouverture de session qui présente les conflits inscrits dans le journal et offre de les résoudre.
L’avantage d’une telle solution est que ce n’est pas bloquant, comme Unison où il faut bien faire la synchronisation et régler les conflits avant de travailler sur le répertoire.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Ceph(FS)
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 3.
J’en connais qui ont mis en place Ceph sur une grosse infrastructure.
D’après eux, Ceph est maintenant stable (il y a un an ou deux seulement, ils ont encore eu une perte totale des données du système de fichier suite à un bug — enfin ils ont des sauvegardes), mais CephFS pas encore.
Après, tu peux faire du NFS sur XFS sur Ceph (il me semble que c’est ce qu’ils font)…
Sinon, leur conclusion est que Ceph permet d’économiser sur le stockage (pas la peine de payer cher pour la performance, la parallélisation s’en charge), mais pas sur le réseau (10 Gb/s indispensables entre les nœuds Ceph pour une organisation d’une certaine taille).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Comment ?
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 3.
À la réflexion, il manque un détail pour comprendre ta solution : quand fais-tu la synchronisation ?
Si tu la fais dans les deux sens à l’ouverture de session, -u évite d’écraser des fichiers plus récents, mais tu ne peux pas faire de --delete, donc tous les fichiers effacés reviennent.
Si tu la fais dans le sens serveur → station de travail à l’ouverture de session et station de travail → serveur à la fermeture de session, il y a un cas qui va être problématique : le plantage de X ou la coupure de courant. À l’ouverture de session qui suivra, la synchro sera faite depuis le serveur alors qu’elle n’a pas été faite dans l’autre sens. Si tu utilises l’option --delete, ça veut dire que les nouveaux fichiers seront effacés. Si tu ne l’utilises pas, ça veut dire que les fichiers effacés reviendront tout le temps.
Par ailleurs, -u dépend pour fonctionner correctement d’une date correcte sur les machines. NTP fortement conseillé !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Fedora
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
Il ne demande pas d’investir du temps pour le maîtriser.
Je ne l’utilise même pas une fois par version de la distribution : je mets à jour mon système type.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Fedora
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
Je n’aime pas trop miser sur des outils spécifiques : je peux être amené à changer de distribution et par ailleurs, on n’est jamais sûr qu’ils ne disparaissent pas brusquement.
Je me suis dit « Hein ??? QUELLE seconde partie ??? ». Je sais bien qu’il y en avait une, mais quand j’ai testé une Fedora 20, je n’en ai pas eu.
J’ai refait le test (sur une machine virtuelle) ; pas mieux.
J’ai vérifié les dépôts, il n’y a plus de paquet firstboot sur la Fedora 20 (il existait encore sur la 19).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Il y a desktop et desktop.
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
J’ai un plutôt l’impression qu’actuellement, Ubuntu et Fedora visent surtout les portables. Je ne dis pas que c’est aberrant, après tout, ça se vend plus que les machines de bureau.
Par ailleurs, il y a desktop et desktop. La configuration n’est pas la même sur une machine du boulot avec tout centralisé sur le serveur que sur une machine perso autonome.
Imagine une Fedora d’avant la 18 (neuneuïsation de l’installeur).
L’installeur te donnait la possibilité de configurer directement la base d’utilisateurs sur LDAP ou NIS (avec éventuellement authentification sur Kerberos) avec pour LDAP récupération du certificat et d’un point de vue général tout bien configuré : pam, nsswitch.conf, ldap.conf ou yp.conf… et autofs qui marche directement.
Des trucs que j’avais passé pas mal de temps à configurer correctement lors du passage à LDAP en 2002 (il faut dire qu’à l’époque, les distributions ne prévoyaient pas encore trop ça, et les docs n’indiquaient pas les bons attributs LDAP, il avait fallu que je trace les accès au serveur pour savoir quoi y mettre), que même mon collègue incompétent (actuellement en reconversion professionnelle après un éclair de lucidité) pouvait ainsi configurer correctement en peu de temps.
Avec Ubuntu, il n’y a pas ça (avec les versions récentes de Fedora non plus…). Je ne peux pas être sûr que je n’aie pas raté un outil génial pour le faire après l’installation, mais autofs n’est même pas prévu pour démarrer après le réseau. Je t’invites à vérifier toi-même /etc/init/autofs.conf.
Compare par exemple avec /etc/init/ypbind.conf (paquet nis), qui lui est bien prévu pour démarrer après le réseau (enfin ce n’est pas clair que ça marche si le réseau est configuré avec NetworkManager ou en DHCP, cela dit).
Tu pourras au passage constater que démarrer un service après le réseau est moins trivial qu’avec une init System V ou systemd…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Intermezzo…
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 2.
Contrairement à Coda, Intermezzo fonctionnait avec les systèmes de fichiers (disque) existants.
Malheureusement ses développeurs ont été embauchés pour développer Lustre et Intermezzo est tombé à l’eau.
En espace utilisateur, il y a les outils de synchronisation courants, mais pas automatisés, du coup.
Par exemple, Unison peut fonctionner sur une liaison ssh (à condition d’utiliser le port ssh standard).
rsync, si on modifie indépendamment un fichier des deux côtés, ça va être problématique.
csync est peut-être à voir.
Cela dit, ces outils imposent une copie complète du répertoire, ce qui n’est pas envisageable dans un environnement où les utilisateurs se connectent indifféremment sur n’importe quelle machine d’un parc.
Pour autant que je sache, ce n’est (était) pas le cas de Coda ou Intermezzo (correctement paramétrés).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: l'interet par rapport à NFS ?
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 2.
Je ne dis pas que le projet est réellement actif, mais Coda est toujours disponible sur Fedora, par exemple.
Intermezzo est mort et enterré, malheureusement.
C’est quand même dingue que des systèmes de fichiers réseau qui répondent bien mieux aux besoins actuels que NFS ou CIFS ne soient pas plus soutenus et utilisés…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: l'interet par rapport à NFS ?
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 5.
cachefilesd, un cache en lecture en complément à NFS, permet de limiter l’usage de la bande passante et d’améliorer la réactivité.
Il est déjà empaqueté pour certaines distributions.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: l'interet par rapport à NFS ?
Posté par Arthur Accroc . En réponse au journal profils itinérants, version Linux. Évalué à 2.
Coda ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: If it works, don't fix it.
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 8.
Vu comme ça, quand je me prends un blocage d’un quart d’heure ou plus à l’arrêt de la machine (montages NFS avec autofs, unités systemd non modifiées), ça doit bien prouver qu’il y a des trucs pas correctement implémentés…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Lennux Is Not UniX
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 7.
Du coup, ça ne marche pas trop…
Oui, mais lié à systemd.
Avec systemd, autofs se retrouve dans un CGroup spécifique alors qu’il est sensé monter des répertoires pour des utilisateurs qui sont dans un autre ; c’est ça qui fait foirer. Les versions récentes de systemd intègrent un contournement spécifique (peut-être était-il déjà dans les versions précédentes sauf qu’il plantait).
Si ton colloc passe à une version de systemd (donc à la verstion de Mageia qui la contient, vu que changer de version de systemd n’est pas forcément trivial) égale ou supérieure à 195, le problème devrait disparaître (… sauf s’il a un autre problème).
Ce gadget ne joue pas dans la même cour qu’autofs : il ne permet pas d’utiliser une table d’automontage située sur un serveur (LDAP ou NIS).
C’est le souci avec les services qui gravitent autour de systemd : ils se multiplient mais ne font qu’une partie du boulot des services qu’ils sont sensés remplacer (à l’exception peut-être de journald).
À court ou moyen terme, on devrait avoir un stockage centralisé (suffisant) pour tous nos utilisateurs, donc je devrais pouvoir me passer de la table d’automontage et utiliser pam_mount. Pas sûr que le démontage et donc l’arrêt du système fonctionneront mieux pour autant…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Lennux Is Not UniX
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 4.
Quelle distribution suggères-tu ?
J’ai des utilisateurs qui veulent des versions récentes d’un tas de trucs, ça élimine CentOS et Debian stable.
Par rapport à des distributions plus confidentielles, Fedora et Ubuntu ont l’avantage que beaucoup de choses sont déjà empaquetées pour elles. Ça fait gagner pas mal de temps.
D’autres utilisateurs (ou quelquefois les mêmes) veulent continuer à utiliser des logiciels commerciaux dont on n’a que de vieilles versions (faute d’avoir payé la maintenance), du coup le fait que Fedora fournisse un certain nombre de bibliothèques de compatibilité (contrairement à Ubuntu) est un avantage.
Jusqu’à la version 14, Fedora était bien adaptée à un fonctionnement en machine cliente, contrairement à Ubuntu (depuis qu’elle n’a plus le même système d’init que Debian).
Avant systemd, contourner les éventuels bugs de la Fedora était moins lourd que de transformer Ubuntu en système client fonctionnel.
Alors maintenant, je changerais bien, mais comme toutes les distributions qui disposent d’un large choix de paquets sont déjà dans le Borg ou sur la voie de l’assimilation…
Ça, c’est la théorie. Dans la pratique, j’ai pour l’arrêt des traces comme quoi le démontage des partitions NFS est bien lancé avant l’arrêt du réseau, sauf qu’il n’est pas fini quand l’arrêt du réseau est lancé.
L’un fait partie de systemd. L’autre de Gnome, mais si on lui laissait un poil de temps avant de tout remballer, il se terminerait probablement normalement. D’ailleurs si je ferme la session sans lancer l’arrêt, il disparaît.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Lennux Is Not UniX
Posté par Arthur Accroc . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
J’ai la joie d’administrer des postes en réseau avec des Fedora (donc systemd) en poste client (j’ai des utilisateurs qui veulent des versions récentes d’un certain nombre de trucs) et des services Unix classiques : NFS, autofs…
Bon, j’ai dû laisser tomber pour la Fedora 17, la version de systemd qui était dessus plantait complètement autofs. Et là, je n’en étais pas à résoudre le problème moi-même comme à l’époque des scripts bash, alors que les développeurs de Fedora eux-mêmes n’ont pas réussi avant la sortie de la 18 (en rétroportant une correction ; mêmes eux n’ont pas les compétences pour le corriger eux-mêmes).
La Fedora 19 marchait correctement au début (peut-être après ajout d’une dépendance sur un des services systemd, mais ça restait raisonnable).
J’ai fait une mise à jour (à la suite de la faille sur OpenSSL) et là, c’est le drame, l’arrêt qui se remet à merder complètement s’il est lancé directement depuis une session utilisateur : blocages de l’ordre du quart d’heure ou plus, dus en particulier aux partages NFS qui sont démontés après l’arrêt du réseau et systemd qui les attend… longtemps.
Alors, j’ai configuré logind pour qu’il tue les processus de l’utilisateur à la fermeture de session (sinon, il traînait des processus qui bloquaient le montage, en particulier un de Gnome et un de… systemd).
J’ai ajouté un pseudo-service intermédiaire démontant (lors de l’arrêt) les partitions NFS et définissant surtout des dépendances avec autofs d’un côté et le réseau de l’autre pour s’assurer de l’ordre.
J’ai aussi ajouté une temporisation de quelques secondes à l’arrêt du service autofs.
Alors, ça marche moyennement (entre 30 s à 1 minute pour l’arrêt, pas mieux que le démarrage), mais ça remerde bien plus si je retire n’importe laquelle de mes modifs.
À voir les traces, systemd essaye de faire un arrêt très rapide… en lançant les arrêts des services dans l’ordre des dépendances, mais pour certains (notamment autofs et les démontages NFS) en parallèle, sans attendre que l’arrêt du service soit fini pour commencer l’arrêt de celui dont il dépend. C’est quand même génial !
Sur un système client typique avec répertoires sur NFS, c’est la catastrophe.
Même Slackware avec son arrêt sauvage type BSD à l’ancienne s’en sortirait mieux.
Pour l’arrêt, il envoie un Ctrl-C aux processus, puis les tue salement après quelques secondes s’ils ne se sont pas terminés, mais avant tout cela… il démonte les partitions NFS !
Le seul argument que j’aie à la décharge de systemd, c’est qu’après avoir configuré une Ubuntu 12.04 de la même manière, je sais qu’Upstart en est à un stade encore pire : il lance autofs avant le réseau, donc même le démarrage rate (l’intérêt d’autofs, c’est d’aller chercher la table de montage sur le serveur avec LDAP ou NIS). Pour que ça marche, il faut rajouter les dépendances soi-même, sauf que c’est moins pratique à configurer qu’avec systemd et mal documenté…
Alors évidemment, systemd, ça marche sur un ordinateur portable, donc autonome. Des systèmes grand public (dans le mauvais sens du terme) comme Ubuntu et Windows aussi.
Et pour démarrer aussi vite que systemd sur un portable, pas besoin de quelque chose d’aussi compliqué. Sur une Arch avant systemd, je lançais dbus et un autre service puis quasiment tous les autres en parallèle sans aucun problème et le démarrage était aussi rapide.
Partant d’un a priori positif sur systemd du point de vue de la conception avant que Fedora ne l’utilise vraiment, mon avis devient de plus en plus négatif (ça se voit au fil des posts).
Mais le temps que je perds dessus se cumule et son fonctionnement ne s’améliore pas réellement (par rapport à la Fedora 17, si, mais la version qui était dessus était bien pire que les précédentes).
En tant qu’administrateur système, Systemd est la plus grosse plaie que j’aie eu récemment.
Et que fait un système avec systemd qui me manquerait sans ? Rien !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone