Ce me semble loin de la facilité d'nedit. Ctrl+Souris bouton gauche et tu es en sélection carré. To changement de mode fait qu'en pratique, pas grand monde doit l'utiliser.
Bref, avec nedit, la sélection carré, c'est comme une sélection classique mais avec la touche Ctrl appuyé.
Après, il y a d'autres éditeurs qui le font mais je ne l'ai jamais vu avec cette souplesse.
Je suis d'accord avec toi. Lorsque je lis PHP et ensuite que ce n'est pas POSIX, je trouve les comparatifs quand même plus qu'osés...
Maintenant, pour être vraiment généralisable, il faut pouvoir monter le système de fichier et le tester de manière classique. Sinon, cela restera un produit de niche.
Attention, je ne dis pas que XSLT est une mauvaise chose. Ce type de programmation, de type moteur d'inférence (prolog, make) sont géniaux pour certaines taches.
C'est uniquement la syntaxe qui est lourding pour un langage de programmation. Sans IDE qui complète ou sans copier-coller de bout de code d'un fichier dans un autre, c'est hyper chiant... C'est uniquement ce point là qui me gène.
Tu veux dire que l'emacsien est plongé dans sa doc pour retrouver le control qui va lui permettre de quitter emacs sans perdre son boulot de l'après midi et donc qu'il n'a pas le temps de venir sur dlfp ?
Il est bien mais aussi sobre que nedit. J'aime mieux la police de caractère de nedit. Mais surtout, il est nul en sélection carré... et j'en ai besoin souvent.
tout comme toi. De plus en plus de vim mais historiquement du nedit, notament pour ce que tu as dis : rapidité, simple et lisible, selection carré ultra efficasse...
Mon soucis, je cherche de plus en plus dans nedit avec / et je evux aller à la ligne 123 en 123G ! Bref, je veux un mode vi dans nedit !
Je crois qu'il y a des schémas YAML mais je n'ai jamais utilisé. Ce que je veux dire, c'est que YAML tout comme XML ne sont qu'une représentation d'un arbre. Ton validateur, si ce n'est pas du SAX mais du DOM charge tout. Dans le cas d'un fichier de config, c'est pas illogique. Donc tu valides un DOM et non directement un XML. Du coup, valider un DOM écrit en YAML plutot qu'en XML ne pose pas de problème puisque la transformation YAML->XML est facile.
Bref, pour moi, c'est des mauvaises raisons pour ne pas développer d'autres backend au DOM et vouloir du XML partout.
Un exemple pour moi de folie, c'est le XSLT... Vouloir faire des programmes, en plus de type moteur d'inférence, en XML, c'est grandiose ;-)
Sinon, au niveau des fichiers de conf, je parlais de modif de dernières minutes fait à l'arrache avec vi ou a une conf propagé par cfengine... Il arrive de se planter... donc le serveur doit valider son fichier de conf au chargement. A vrai dire, c'est pas cela qui lui prends non plus des heures.
Si tu fait un programme qui génère du code, tu n'est plus réellement dans l'admniistration système mais dans la partie dev. Tu tomberas un jour ou l'autre à générer un arbre avec une syntaxe ayant des subtilités. Cela peut êre pénible à faire mais c'est un développement comme un autre.
Après, c'est vrai que le format SVG n'est pas simple...
Tu n'es jamais assuré que le fichier n'a pas été modifié avant de relancer le serveur donc ton serveur doit vérifier le fichier. La validation qu'a priori est une erreur et dans la conception de site web, amène a de grave erreur si on ne vérifie pas sur le serveur tous les paramêtres POST et GET.
Donc, une fonction check sur le serveur est absolument nécessaire. Ce check peux te prendre le YAML, te le transformer en XML (binaire - mémoire / comme cela, il n'y a pas de XML fichier si cela te va mieux) et le valider ainsi. En fait, tu n'en seras rien. Ce n'est pas ton problème, toi tu es utilisateurs, tout cela est programmé / scripté.
Ensuite, je veux un éditeur sans X-Window. Je ne veux pas de l'erreur de Windows d'imposer le graphique sur les serveurs. Et puis, je ne vois pas pourquoi on ne pourrait pas complèter du YAML puisque ce n'est qu'une autre manière d'écrire un arbre...
Je répondrais rapidement car l'heure est avancé...
Je préfère le YAML ou le JSON lorsque j'édite les fichiers à la main. Les fichiers XML sont très pénible à faire à la main. D'ailleurs tu le sous entend toi même en parlant d'éditeur spécialisé.
La règle numéro un devrait être de rester simple et donc de pouvoir faire tourner un serveur sans X. Les éditeurs en question ont besoin de X je suppose.
La règle numéro deux voudrait qu'on puisse configurer directement sans passer par un méta outil parfois web pour configurer...
Le YAML, pour quasiment une grande partie des fichiers de config (qui reste en général simple) se travaille très bien avec grep, sed, cfengine. C'est important pour faire des scripts sur un parc conséquent.
Je n'ai plus en tête les fichiers Tomcat car dès que je vois un serveur en java avec Tomcat, je choisis une solution équivalente sans Tomcat. Je n'en ai plus sous la main. En gros, si mes souvenirs sont bons, c'est un arbre donc en YAML, c'est juste un arbre sous forme
clef: valeur
Pas besoin de <> et "" qui alourdissent sans rien apporter. Remarque, le JSON me convient tout à fait mais la news parle de YAML...
Donc pour finir "En quoi YAML est plus adapté qu'XML pour le META.yml ? " Tout simplement parce que j'écris ce fichier à la main, que je le modifie à la main... C'est comme un Makefile, c'est fait pour être manipuler par des êtres humains.
Avec la folie du XML, l'idée est de simplifier la vie de la machine et de mettre l'homme dans une syntaxe rigide et absolument lourde. Lex et Yac ont été inventé il y a longtemps, c'est pas un soucis pour la machine de lire autre chose que du XML.
Mauvais exemple... un fichier inkscape n'est pas un fichier de configuration donc il n'y a pas besoin de l'éditer à la main sauf en cas de deboguage pour les développeurs du logiciel. Donc on est sur un autre problème ou justement le XML est tout aussi bien que le YAML puisqu'on serialize puis de-sérialize. On pourrait utiliser le YAML si cela apportait un plus dans ce cas. A priori, comme cela, il n'y a pas de plus donc l'un ou l'autre me sont indifférents.
Ces programmes ont été conçu pour éviter les scripts "crades" avec les mots de passe en clair. Donc ils lisent le tty et non l'entrée standard.
Après, il y a moyen de tricher pour faire croire à un tty, expect en est un bon exemple. Mais lorsqu'on fait cela, on est conscient de tricher avec la philosophie du concepteur du programme.
En tant que responsable d'un service informatique, je commence par appliquer les règles venant d'au dessus à mon même ;-)
Pour les fenêtres flotantes, tous ces gestionnaires de fenêtres sont mauvais (pour simplifier). Le problème est que ces gestionnaires de fenetres sont principalement utilisé par des admins systèmes et réseau ou par des développeurs. Un de mes soucis est que l'application cluster-ssh est indispensable sur un parc conséquent et qu'elle permet de paver la totalité des écrans avec des xterm... S'il y a un mode compatible entre cluster-ssh et i3, alors vous allez faires beaucoup d'heureux ;-)
En fait, au niveau des flotants, il faut bien gérer le multi écran (pas le cas de wmii aujourd'hui) et garder un fonctionnement basique. La seule idée nouvelle que j'ai eu serait de pouvoir stacker les fenêtres flotantes mais là, on doit pouvoir reprendre le code de la partie tabulée pour la gestion de la pile. Pour la gestion de l'accrochage, à la souris, c'est identique au déplacement d'une fenêtre d'un pile dans une autre en environnement tabulé. Donc ce n'est pas non plus révolutionnaire et peut donner une touche geek par rapport aux autres window manager du même type ;-)
Pour la gestion des kill, j'ai le souvenir que xkill (sous fvwm donc cela remonte à loin chez moi) tuait l'application instantanément... J'aurais dis que c'était du kill -9 brut de brut, donc pas très gentil avec la fenêtre.
Sinon, il y a les formats comme NetCDF (limité mais simple) ou HDF qui sont fait pour cela.
Comme je l'ai déjà il y a quelques temps ici, on aurait mis un toute petite partie de l'énergie mis sur XML a faire une API équivalente a celle d'XML sur le format HDF (ou un autre équivalent), on aurait aujourd'hui un XML binaire...
En effet, le XML est mauvais dans les fichiers de conf mais a du bon dans d'autres cas d'utilisation, et souvent, dans ces cas la, on aurait un arbre binaire que ce serait pas plus mal.
Je ne sais pas de quand cela date mais tous les modules Perl dans le CPAN ont un fichier de spécification en YAML. Je pense que le CPAN est donc l'utilisateur numéro 1 du YAML.
Après, je vois que les fanatiques de java et de Tomcat trouvent leur fichier XML lisible et super. Je voudrais voir un serveur d'application Tomcat avec autant de module que le CPAN ;-)
Moi j'ai horreur du XML dans le fichiers de conf (merci Red-Hat et Novell de nous en mettre plein en ce moment)...
Pour la config, je ne me fait pas de soucis pour la refaire... C'est plus que au vu des liens avec wmii, autant reprendre les mêmes raccourcis lorsqu'il sont bien.
Merci de faire remonter cela. Demain, je doit préparer mes vacances et donc la doc du SI en cas de panne. La mise à jour va me prendre toute la journée ;-(
* J'ai pas encore tout compris au fonctionnement sur ma debian (paquet dans sid sous lenny). Je n'arrive pas dimensionner les fenetres sous le mode par défaut.
Sinon, l'idée de mettre la pile en haut et non la fenetre courante au milieu de la pile comme wmii, je pense que cela peut être plutot bien.
* J'ai réussi à avoir des trous vide, chose quasiment impossible avec wmii. Donc on va pouvoir mettre des choses en fond d'écran ? Pourquoi pas un nautilus sur un bureau x, ainsi lorsque les utilisateurs voient mon bureau et que la clef USB ne se monte pas sur le bureau, une bonne partie, je le sens, ne se sente pas rassuré par linux.
* Un raccourci très bien de wmii est le Mod+p plus le début d'une commande. Génial... J'ai pas vu pour le moment.
* Très bien le Mod+Shift+q pour killer mais je ferais un kill gentils avec Mod+Shift+C et un kill méchant (-9) avec un Mod+Shift+q. C'est plus proche du shell.
* Sur les fenetres flotantes, souvent ce genre de gestionnaire est faible... (dont wmii). Pourquoi ne pas reprendre les bonnes idées de pwm d'accrocher les fenêtres ensemble mais, non pas en faisant des onglets mais en gardant l'idée de la pile.
Je glisse la fenetre B flotante sur la fenetre A et hop, j'ai une pile de fenetre flotante. Double click sur la barre et hop cela s'enroule pour ne garder que le titre.
* Dans ion3, les bureaux en multi écran était indépendant. C'était assez pratique au final. Mais si on avait des bureaux flottant a droite et à gauche, l'ouverture des 20 fenetres flotantes les disposaient sur les deux écrans (cas deux écrans). Très pratique pour cluster-ssh qui a besoin de fenetre flotante... Cela marchait bien sous sarge si mes souvenir sont bons mais très mal après (d'ou mon passage à wmii).
En effet, je n'utilise que les piles fixes mais pour cluster-ssh, je fais du synchrone sur n machines en même temps, n pouvant dépasser 50. C'est super mais il faut que le gestionnaire gère l'ouverture des 50 terminals en // (wmii sous lenny du mal alors que sous etch, cela passait mieux) et que cette ouverture puisse se faire sur plusieurs écrans (là, ion3 était plus fort car les fenetres n'étaient jamais a cheval sur deux écrans, ions positionnait les fenêtres sur tous les écrans mais chacun gèrait localement les positions des terminaux (d'ailleurs sous lenny, lorsqu'on quitte le workspace et que l'on revient, il réagence les fenetres flotantes de cluster-ssh, ce qui n'étais pas le cas sous etch et est très pénible).
* Dans wmii, il n'y a pas vraiment de notion de workspace mais de tag (Mod+Shift+t) du coup une fenetre peut avoir plusieurs tag. En pratique, pour l'utilisateur lambda, c'est pareil et l'utilisateur avancé peut avoir la même fenetre sur n bureau. C'est donc mieux. Le bureau (tag) n'ont pas forcément des noms en numéro. C'est bien mais pas souvent utilisé.
* Ce dernier amène le suivant. wmii perds la position des piles de fenêtres. Normal dans sa philosphie mais en multi-écran, c'est chiant car il faut tout refaire à chaque session. ion3 pour cela était plus pratique. En plus, cela doit être plus facile de paramêtrer l'ouverture d'une aplication directement ou on le veut si le gestionnaire de fenetres se souvient de la postion des piles d'une fois sur l'autre.
D'ailleurs, on ferait Mod+Shift+o et hop, on sauve l'endroit ou la fenetres s'ouvre pour la fois suivante (les tags associés et la position dans les piles des différets tag) suite à un lancement via Mod+p (par exemple). Il pourrait mettre un petit symbol dans la barre du titre pour dire que cette application est lié.
Dans mon cas, je ferais
- Mod+p iceweasel -> ecran 2 pile 1 tag 1
- mod+p cssh -> ecran 1 et 2 tag 4 pile 1 flotant
...
J'ai été sur le site, le contact renvoi a un autre site en allemand... Bref, j'ai préféré faire cela ici en francais. Mais je suis dispo pour en parler plus longuement hors antenne (sauf vacances aout !).
Voila, cela me plait beaucoup de voir une suite a wmii qui reste dans cette notion de pile que j'ai adopté.
Je trouve cela une très bonne idée. Refaire un serveur qui marche tous les 3 ans, voire mois, c'est casse-pied... Un dhcp qui marche, pour l'upgrader trop souvent.
Donc, une mise à jour de sécurité réduite, je suis sur que cela marche.
Dans le même ordre d'idée, avoir quelques logiciels typé bureau qui évoluerait, ce serait aussi pas mal... Si les dépendances sont faibles, le risque est aussi limité. On fait avec les backports mais c'est pas officiel du coup, lors des upgrades, il y a parfois des difficultés. Et puis jouer avec les pinnings n'est pas toujours faciles.
Enfin, les dernières n'ont pas été gelée en décembre... Pour lenny, la sortie était pour septembre mais personne n'y croyais.
Moi, avec un gel en décembre, on aura un sortie au mieux pour l'été. Sauf si la LTS d'unbuntu est calé sur le même rythme alors on aura convergence des efforts. Tant mieux.
L'objectif n'est pas non plus la dispersion et s'il y a convergence, c'est mieux pour tous. Plus il y a de remonté d'unbuntu dans debian, mieux c'est. Cela veut dire que le courant passe et que l'organisation sociale marche. Dans le cas contraire, on dirait qu'ubuntu pompe sans rien donner en échange...
Ubuntu a ses propres problématiques, debian a les siennes, notamment le grand nombre d'architecture. Chacun fait avancer l'autre.
[^] # Re: Configuration des noeuds
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
[^] # Re: alternative?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche GNU Emacs 23.1 sort sous le soleil. Évalué à 2.
Bref, avec nedit, la sélection carré, c'est comme une sélection classique mais avec la touche Ctrl appuyé.
Après, il y a d'autres éditeurs qui le font mais je ne l'ai jamais vu avec cette souplesse.
# Configuration des noeuds
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 6.
http://code.google.com/p/finefs/wiki/InstallationInstruction(...)
C'est un peu pénible d'avoir un fichier différent pour chaque noeud. Cela signifie que ce fichier ne peut pas être déployés brut de brut.
Le serveur ne pourrait-il pas détecter que peers[]=arnold, c'est lui même et transformer cette ligne en local=arnold ?
[^] # Tahoe
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 4.
http://allmydata.org/trac/tahoe
Qu'elle est la particularité de FineFS par rapport à Tahoe ?
[^] # Re: GlusterFS ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 6.
Maintenant, pour être vraiment généralisable, il faut pouvoir monter le système de fichier et le tester de manière classique. Sinon, cela restera un produit de niche.
[^] # Re: CPAN de Perl
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 2.
C'est uniquement la syntaxe qui est lourding pour un langage de programmation. Sans IDE qui complète ou sans copier-coller de bout de code d'un fichier dans un autre, c'est hyper chiant... C'est uniquement ce point là qui me gène.
[^] # Re: Remarque
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche GNU Emacs 23.1 sort sous le soleil. Évalué à 6.
[^] # Re: alternative?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche GNU Emacs 23.1 sort sous le soleil. Évalué à 3.
[^] # Re: alternative?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche GNU Emacs 23.1 sort sous le soleil. Évalué à 2.
Mon soucis, je cherche de plus en plus dans nedit avec / et je evux aller à la ligne 123 en 123G ! Bref, je veux un mode vi dans nedit !
[^] # Re: CPAN de Perl
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 2.
Bref, pour moi, c'est des mauvaises raisons pour ne pas développer d'autres backend au DOM et vouloir du XML partout.
Un exemple pour moi de folie, c'est le XSLT... Vouloir faire des programmes, en plus de type moteur d'inférence, en XML, c'est grandiose ;-)
Sinon, au niveau des fichiers de conf, je parlais de modif de dernières minutes fait à l'arrache avec vi ou a une conf propagé par cfengine... Il arrive de se planter... donc le serveur doit valider son fichier de conf au chargement. A vrai dire, c'est pas cela qui lui prends non plus des heures.
[^] # Re: Exemple
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 2.
Après, c'est vrai que le format SVG n'est pas simple...
[^] # Re: CPAN de Perl
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 1.
Donc, une fonction check sur le serveur est absolument nécessaire. Ce check peux te prendre le YAML, te le transformer en XML (binaire - mémoire / comme cela, il n'y a pas de XML fichier si cela te va mieux) et le valider ainsi. En fait, tu n'en seras rien. Ce n'est pas ton problème, toi tu es utilisateurs, tout cela est programmé / scripté.
Ensuite, je veux un éditeur sans X-Window. Je ne veux pas de l'erreur de Windows d'imposer le graphique sur les serveurs. Et puis, je ne vois pas pourquoi on ne pourrait pas complèter du YAML puisque ce n'est qu'une autre manière d'écrire un arbre...
[^] # Re: CPAN de Perl
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 2.
Je préfère le YAML ou le JSON lorsque j'édite les fichiers à la main. Les fichiers XML sont très pénible à faire à la main. D'ailleurs tu le sous entend toi même en parlant d'éditeur spécialisé.
La règle numéro un devrait être de rester simple et donc de pouvoir faire tourner un serveur sans X. Les éditeurs en question ont besoin de X je suppose.
La règle numéro deux voudrait qu'on puisse configurer directement sans passer par un méta outil parfois web pour configurer...
Le YAML, pour quasiment une grande partie des fichiers de config (qui reste en général simple) se travaille très bien avec grep, sed, cfengine. C'est important pour faire des scripts sur un parc conséquent.
Je n'ai plus en tête les fichiers Tomcat car dès que je vois un serveur en java avec Tomcat, je choisis une solution équivalente sans Tomcat. Je n'en ai plus sous la main. En gros, si mes souvenirs sont bons, c'est un arbre donc en YAML, c'est juste un arbre sous forme
clef: valeur
Pas besoin de <> et "" qui alourdissent sans rien apporter. Remarque, le JSON me convient tout à fait mais la news parle de YAML...
Donc pour finir "En quoi YAML est plus adapté qu'XML pour le META.yml ? " Tout simplement parce que j'écris ce fichier à la main, que je le modifie à la main... C'est comme un Makefile, c'est fait pour être manipuler par des êtres humains.
Avec la folie du XML, l'idée est de simplifier la vie de la machine et de mettre l'homme dans une syntaxe rigide et absolument lourde. Lex et Yac ont été inventé il y a longtemps, c'est pas un soucis pour la machine de lire autre chose que du XML.
[^] # Re: Exemple
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 4.
[^] # Re: CPAN de Perl
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 3.
Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.
Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !
[^] # Re: kdesu ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Alan Cox jette l'éponge. Évalué à 4.
Ces programmes ont été conçu pour éviter les scripts "crades" avec les mots de passe en clair. Donc ils lisent le tty et non l'entrée standard.
Après, il y a moyen de tricher pour faire croire à un tty, expect en est un bon exemple. Mais lorsqu'on fait cela, on est conscient de tricher avec la philosophie du concepteur du programme.
[^] # Re: Comportement
Posté par Sytoka Modon (site web personnel) . En réponse au journal i3 recherche un contributeur pour son logo. Évalué à 2.
Pour les fenêtres flotantes, tous ces gestionnaires de fenêtres sont mauvais (pour simplifier). Le problème est que ces gestionnaires de fenetres sont principalement utilisé par des admins systèmes et réseau ou par des développeurs. Un de mes soucis est que l'application cluster-ssh est indispensable sur un parc conséquent et qu'elle permet de paver la totalité des écrans avec des xterm... S'il y a un mode compatible entre cluster-ssh et i3, alors vous allez faires beaucoup d'heureux ;-)
En fait, au niveau des flotants, il faut bien gérer le multi écran (pas le cas de wmii aujourd'hui) et garder un fonctionnement basique. La seule idée nouvelle que j'ai eu serait de pouvoir stacker les fenêtres flotantes mais là, on doit pouvoir reprendre le code de la partie tabulée pour la gestion de la pile. Pour la gestion de l'accrochage, à la souris, c'est identique au déplacement d'une fenêtre d'un pile dans une autre en environnement tabulé. Donc ce n'est pas non plus révolutionnaire et peut donner une touche geek par rapport aux autres window manager du même type ;-)
Pour la gestion des kill, j'ai le souvenir que xkill (sous fvwm donc cela remonte à loin chez moi) tuait l'application instantanément... J'aurais dis que c'était du kill -9 brut de brut, donc pas très gentil avec la fenêtre.
[^] # Re: Il y a quelques trucs qui me chiffonnent
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 5.
Comme je l'ai déjà il y a quelques temps ici, on aurait mis un toute petite partie de l'énergie mis sur XML a faire une API équivalente a celle d'XML sur le format HDF (ou un autre équivalent), on aurait aujourd'hui un XML binaire...
En effet, le XML est mauvais dans les fichiers de conf mais a du bon dans d'autres cas d'utilisation, et souvent, dans ces cas la, on aurait un arbre binaire que ce serait pas plus mal.
[^] # CPAN de Perl
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche YAML 1.2 est disponible !. Évalué à 5.
Après, je vois que les fanatiques de java et de Tomcat trouvent leur fichier XML lisible et super. Je voudrais voir un serveur d'application Tomcat avec autant de module que le CPAN ;-)
Moi j'ai horreur du XML dans le fichiers de conf (merci Red-Hat et Novell de nous en mettre plein en ce moment)...
[^] # Re: Comportement
Posté par Sytoka Modon (site web personnel) . En réponse au journal i3 recherche un contributeur pour son logo. Évalué à 2.
Pour la config, je ne me fait pas de soucis pour la refaire... C'est plus que au vu des liens avec wmii, autant reprendre les mêmes raccourcis lorsqu'il sont bien.
Merci de faire remonter cela. Demain, je doit préparer mes vacances et donc la doc du SI en cas de panne. La mise à jour va me prendre toute la journée ;-(
[^] # Re: MD6
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 1.
C'est pour cela que j'imposais un mot de passe compliqué sur les 8 premières lettres. Imposer plus de 16 lettres, cela devient dur...
[^] # Re: Go-OO dans les distros
Posté par Sytoka Modon (site web personnel) . En réponse au journal Go-OO. Évalué à 7.
Je trolle sur linuxfr !
# Comportement
Posté par Sytoka Modon (site web personnel) . En réponse au journal i3 recherche un contributeur pour son logo. Évalué à 2.
* Pourquoi ne pas avoir repris les raccourcis de wmii ?
Mod+s -> stack
Mod+m -> maximize
Mod+d -> display ? fenetre homogene
Par contre le Mod+f, c'est très bien.
* J'ai pas encore tout compris au fonctionnement sur ma debian (paquet dans sid sous lenny). Je n'arrive pas dimensionner les fenetres sous le mode par défaut.
Sinon, l'idée de mettre la pile en haut et non la fenetre courante au milieu de la pile comme wmii, je pense que cela peut être plutot bien.
* J'ai réussi à avoir des trous vide, chose quasiment impossible avec wmii. Donc on va pouvoir mettre des choses en fond d'écran ? Pourquoi pas un nautilus sur un bureau x, ainsi lorsque les utilisateurs voient mon bureau et que la clef USB ne se monte pas sur le bureau, une bonne partie, je le sens, ne se sente pas rassuré par linux.
* Un raccourci très bien de wmii est le Mod+p plus le début d'une commande. Génial... J'ai pas vu pour le moment.
* Très bien le Mod+Shift+q pour killer mais je ferais un kill gentils avec Mod+Shift+C et un kill méchant (-9) avec un Mod+Shift+q. C'est plus proche du shell.
* Sur les fenetres flotantes, souvent ce genre de gestionnaire est faible... (dont wmii). Pourquoi ne pas reprendre les bonnes idées de pwm d'accrocher les fenêtres ensemble mais, non pas en faisant des onglets mais en gardant l'idée de la pile.
Je glisse la fenetre B flotante sur la fenetre A et hop, j'ai une pile de fenetre flotante. Double click sur la barre et hop cela s'enroule pour ne garder que le titre.
* Dans ion3, les bureaux en multi écran était indépendant. C'était assez pratique au final. Mais si on avait des bureaux flottant a droite et à gauche, l'ouverture des 20 fenetres flotantes les disposaient sur les deux écrans (cas deux écrans). Très pratique pour cluster-ssh qui a besoin de fenetre flotante... Cela marchait bien sous sarge si mes souvenir sont bons mais très mal après (d'ou mon passage à wmii).
En effet, je n'utilise que les piles fixes mais pour cluster-ssh, je fais du synchrone sur n machines en même temps, n pouvant dépasser 50. C'est super mais il faut que le gestionnaire gère l'ouverture des 50 terminals en // (wmii sous lenny du mal alors que sous etch, cela passait mieux) et que cette ouverture puisse se faire sur plusieurs écrans (là, ion3 était plus fort car les fenetres n'étaient jamais a cheval sur deux écrans, ions positionnait les fenêtres sur tous les écrans mais chacun gèrait localement les positions des terminaux (d'ailleurs sous lenny, lorsqu'on quitte le workspace et que l'on revient, il réagence les fenetres flotantes de cluster-ssh, ce qui n'étais pas le cas sous etch et est très pénible).
* Dans wmii, il n'y a pas vraiment de notion de workspace mais de tag (Mod+Shift+t) du coup une fenetre peut avoir plusieurs tag. En pratique, pour l'utilisateur lambda, c'est pareil et l'utilisateur avancé peut avoir la même fenetre sur n bureau. C'est donc mieux. Le bureau (tag) n'ont pas forcément des noms en numéro. C'est bien mais pas souvent utilisé.
* Ce dernier amène le suivant. wmii perds la position des piles de fenêtres. Normal dans sa philosphie mais en multi-écran, c'est chiant car il faut tout refaire à chaque session. ion3 pour cela était plus pratique. En plus, cela doit être plus facile de paramêtrer l'ouverture d'une aplication directement ou on le veut si le gestionnaire de fenetres se souvient de la postion des piles d'une fois sur l'autre.
D'ailleurs, on ferait Mod+Shift+o et hop, on sauve l'endroit ou la fenetres s'ouvre pour la fois suivante (les tags associés et la position dans les piles des différets tag) suite à un lancement via Mod+p (par exemple). Il pourrait mettre un petit symbol dans la barre du titre pour dire que cette application est lié.
Dans mon cas, je ferais
- Mod+p iceweasel -> ecran 2 pile 1 tag 1
- mod+p cssh -> ecran 1 et 2 tag 4 pile 1 flotant
...
J'ai été sur le site, le contact renvoi a un autre site en allemand... Bref, j'ai préféré faire cela ici en francais. Mais je suis dispo pour en parler plus longuement hors antenne (sauf vacances aout !).
Voila, cela me plait beaucoup de voir une suite a wmii qui reste dans cette notion de pile que j'ai adopté.
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Debian adopte une nouvelle stratégie pour les "freeze". Évalué à 2.
Donc, une mise à jour de sécurité réduite, je suis sur que cela marche.
Dans le même ordre d'idée, avoir quelques logiciels typé bureau qui évoluerait, ce serait aussi pas mal... Si les dépendances sont faibles, le risque est aussi limité. On fait avec les backports mais c'est pas officiel du coup, lors des upgrades, il y a parfois des difficultés. Et puis jouer avec les pinnings n'est pas toujours faciles.
[^] # Re: la fin de Debian ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Debian adopte une nouvelle stratégie pour les "freeze". Évalué à 4.
Moi, avec un gel en décembre, on aura un sortie au mieux pour l'été. Sauf si la LTS d'unbuntu est calé sur le même rythme alors on aura convergence des efforts. Tant mieux.
L'objectif n'est pas non plus la dispersion et s'il y a convergence, c'est mieux pour tous. Plus il y a de remonté d'unbuntu dans debian, mieux c'est. Cela veut dire que le courant passe et que l'organisation sociale marche. Dans le cas contraire, on dirait qu'ubuntu pompe sans rien donner en échange...
Ubuntu a ses propres problématiques, debian a les siennes, notamment le grand nombre d'architecture. Chacun fait avancer l'autre.