Un petit exemple de ma config (basé sur une extension, shifty) :
quand j'appuie sur la touche « XF86Mail » je demande l'affichage du tag « mail » Dans la définition de ce tag, il est demandé de lancer mon client mail à la création.
Résultat, si l'appli est déjà lancée, elle s'affiche, si elle n'est pas lancée, elle va se lancer automatiquement. Cela permet d'être sûr que l'application ne sera lancée qu'une fois, et laisser awesome s'occuper de la lancer ou non. (au final, ça n'occupe pas mon écran puisqu'elle est lancée dans une étiquette part).
Autre exemple : gimp. On dit souvent que Gimp possède mauvaise une interface graphique. J'ai configuré awesome pour que la fenêtre Gimp n'utilise que 15% de l'écran, en laissant le reste pour la fenêtre du dessin. Une image valant mieux qu'un discourt, voici le placement par défaut :
Le but étant de ne pas avoir à me soucier de placer les fenêtres quand je lance une application, tout est géré de manière automatique…
Alors, je vais essayer de répondre de la même manière, en restant aussi objectif que possible.
En premier lieu, il faut savoir que Awesome est livré avec une configuration de base. Elle est cohérente et fonctionne bien. Ça permet déjà de se familiariser avec le WM sans perdre trop de temps, et déjà avoir une prise en main.
Après c'est comme tout, c'est standard, c'est pas parfait, et il y a toujours des points qui ne nous correspondent pas. Par exemple, dans la config par défaut, le raccourci clavier pour fermer un client est « Mod4 + SHIFT + c ». Ça faisait beaucoup de touches pour une mes petits doigts, et j'ai modifié ça en « Mod4 + c ». C'est pas grand chose, mais une fois qu'on a commencé à modifier la configuration, c'est difficile de s'arrêter là.
Le fait d'avoir un fichier de configuration qui fonctionne aide beaucoup quand on se plonge dedans : au lieu d'avoir la page blanche, on a un déjà une base qui fonctionne, et que l'on peut modifier petit à petit. Même si l'on ne connait pas lua, et le langage n'est pas compliqué — du moins tant qu'on ne cherche pas à l'interfacer avec du C — si l'on se contente de rester bas niveau, il s'apparente à du script/objet (en fait c'est de la Programmation_orientée_prototype) et l'on se plonge assez rapidement dedans.
Pour ma part, je trouve ça très puissant : je vois l'informatique comme un outil, est pouvoir l'adapter et l'utiliser comme bon me semble donne une autre dimension à l'application. Je ne sais pas si tu utilise déjà Vim ou Emacs, mais si c'est le cas, tu devrais déjà ressentir ce que je suis en train de dire.
L'inconvénient est que ça demande du temps. Mais c'est largement rentabilisé à l'usage, crois-moi !
Merci beaucoup pour ta participation à la dépêche vlamy !
Le problème de la réécriture de la config se pose surtout pour ceux qui ont écrit leur propres scripts, c'est vrai qu'en restant proche de la config initiale, ça ne pose pas de problème.
Dans tout les cas, c'est dommage de casser l'API, mais c'est parfois nécessaire, et comme toujours, si on su faire le boulot une fois, l'adapter ne devrait pas poser de problème…
Tout d'abord, je reconnais que le code n'est pas pur dans le sens où son exécution produit des effets de bord dans la fermeture. Mais cela est causé par la manière dont je compte m'en servir : la liste d'appel à concat sera remplacé par un gestionnaire SAX. Je doit donc être capable de traiter les informations au fur et à mesure de leur arrivée.
Sinon il est vrai que mettre en place une structure de données n'a pas grand chose à voir avec de l'objet, mais j'aurai aimé ne pas utiliser la fermeture comme une structure.
Histoire de me prendre la tête, j'ai essayé une solution sans utiliser de fermeture, et l'autre solution trouvée aurait été d'utiliser un yield (comme en python) pour interrompre le traitement, ce qui ne semble pas possible en OCaml. (J'ai essayé de le simuler en retournant une fonction partielle dans un code récursif sans succès).
Bon, je vais continuer d'expérimenter tout ça, finalement mon exemple me semble suffisamment riche pour que je puisse essayer différentes approches
Imaginons que tu distribue ton application (le cas de la licence ne se pose pas si l'application reste dans son coin) :
tu peux très bien ne fournir que le cœur de ton appli, et laisser au client le soin d'installer par lui même la librairie itext. Tant que tu n'es pas statiquement lié a cette librairie, je ne vois pas où est le problème…
La version 3.7, celle qui inclue le support du multiprocessing et qui permettra de diminuer le temps de rendu par le le nombre de processeurs de ta machine, n'est pas packagée pour debian.
Vu l'avancée de la version, ça n'est pas prendre un risque que de l'installer. Par contre il faut compiler à la main…
J'avais essayé également funambol, mais ai abandonné à cause d'un grand nombre de contraintes :
nécessite java et tomcat
pas de paquets officiels sur ma debian
je ne trouvais pas de clients pour thunderbird
Finalement owncloud est sorti peut de temps après, et a fonctionné immédiatement. J'ai des clients pour mon téléphone (n900), thunderbird, et je n'ai besoin d'aucune autre dépendances supplémentaires.
C'est bien de voir que les offres commencent à se diversifier, pendant longtemps synchroniser les agendas sous linux a été très douloureux…
Ce sont des travaux de compilation classiques non?
Ok, je donne un exemple un peu plus précis. Récemment je voulais générer un graphe dot, dont chaque nœud est une image. Les images devant être générées dynamiquement.
Les outils du shell me servent de liant pour extraire le nom de chaque nœud et y associer l'image que je veux générer
Grâce aux dépendances de make, je génère le fichier povray quivabien (en remplaçant une chaine de texte dans mon source) :
Il ne me reste plus qu'à lancer dot, en faisant quelques substitutions pour référencer les images qui viennent d'être générées.
Au final toutes mes images ont été générées via make. Grand luxe, make me supprime même les fichiers povray puisqu'il a détecté qu'il s'agit de fichiers intermédiaires, n'ayant aucune utilité dans mon rendu final ! Et en mettant à jour mon fichier dot, les nouvelles images sont automatiquement générées.
C'est vrai que ça vision du makefile est intéressante. Aujourd'hui je l'utilise (aussi) pour faire des scènes povray, faire un pdf à partir d'un texte balisé…
J'ai l'impression que tu mélange « béta » et « obsolescence », les deux concepts ne sont pas synonymes ! Une analyse un peu plus neutre peut être trouvée ici : http://blog.octo.com/la-beta-perpetuelle/
Par contre c'est vraiment quelque chose qui ne s'improvise pas, il faut vraiment assurer le suivi client derrière pour que le produit « béta » ne se transforme pas en produit « non-fini » et sur ce point je ne suis pas d'accord avec l'article de la dépêche : le fait de développer en béta ne doit pas toucher à la stabilité du produit.
Attention, on commence petit (un serveur web ne demande pas grand chose comme machine), et puis on trouve qu'avoir une machine allumée 24/24 est quand même pratique :
On y met un cache dns parce que c'est quand même vachement pratique
On y branche une bonne installation audio, et voila mpd, pulseaudio…
On trouve que c'est bien d'avoir un espace centralisé pour échanger les fichiers : rsync, samba
Éventuellement un client bittorent qui tourne en continue,
Un serveur mail,
Et puis on voit une dépêche sur la sortie de privoxy, hop, on installe aussi
Et puis on voit un article pour héberger firefox sync chez soi,
Et puis,
Et puis,
…
Au final la petite machine rend tellement de service qu'elle n'en est plus si petite que ça.
Donc :
quel est le budget que tu compte mettre dans la machine ? (maximum)
est-ce que tu veux la réserver uniquement à du web, ou en faire une machine internet plus générale ?
es-tu seul à en profiter, ou est-ce que tu comptes rendre des services locaux également ?
Vu le prix que coute un investissement, autant se poser la question de ce que va devenir la machine dans les prochaines années…
Je vois sur les captures d'écran un calendrier que je n'avais jamais vu avant. Est-ce qu'il y a des options de synchronisation ICalendar, où est-ce que ça passe par un plugin ?
Vi, c'est pas vraiment fait pour être utilisé en dessous de 960px…
Le problème avec les écrans larges, c'est qu'ils sont trop larges pour utiliser les fenêtres en plein écran, et quand on divise l'écran en deux, on se retrouve avec une surface qui n'a pas pas été prévue par l'application…
En cas de largeur limitée de la fenêtre, on se retrouve avec une page blanche ne contenant que la sidebar, et l'ensemble du contenu est « poussé » en dessous.
Voici une capture d'écran pour aider à comprendre.
Je n'ai pas de logiciel de traduction automatique, je suis juste allé voir sur le site pour lire un peu le blog, et ai trouvé la ressemblance avec la dépêche interpellante.
En cherchant un peu plus loin sur le net, j'ai trouvé une copie conforme de la dépêche, tous ces éléments ne semblant pas reliés entre eux (je n'ai pas fait le lien entre ton compte perso ici et ton blog).
Tout ça me paraissait étrange, d'autant plus que je ne voyais pas version officielle du site (et je n'ai pas fait attention à la licence). Mais comme dit plus haut, je n'avais pas vu que la même personne était à l'origine du travail.
Merci pour la dépêche et la traduction (qui m'a donné envie de fouiller un peu plus avant, d'où mon message précédent), et toutes mes excuses si le message précédent a pu paraître agressif, ça n'était pas le cas.
C'est amusant de comparer les réactions quand linuxfr présente un contenu original mais non neutre , ou un contenu identique à ce qu'on peut trouver ailleurs mais neutre, comme ici.
Pour ma part, ce deuxième point me gène davantage, on dilue l'information un peu partout, sans qu'il y ait réellement de valeur ajoutée à celle-ci (et la source n'est même pas citée…).
Est-ce qu'il y a eu annonce officiel ? Je retrouve la même traduction sur un blog…
Mais dmenu permet de ne saisir qu'une partie du nom, ou d'utiliser les flèches, home, fin pour se déplacer dans la liste. On perd l'historique des commandes c'est vrai; en échange on gagne en vitesse quand on a une mémoire de l'action (je sais pas trop comment appeller ça : savoir qu'il faut faire « xt » puis « end » pour lancer son appli)
C'est rudement efficace quand on a pris l'habitude…
Je l'ai mappé sur modkey + « down », ce qui assez pratique d'accès également.
Le monde de l'autohébergement étant un petit monde, ta documentation pourra intéresser du monde sur le wiki correspondant.
C'est en tout cas une très bonne idée de noter tout ça… Quand on ne passe toute la journée à administrer des machines, ça permet d'éviter de se demander comment regénérer les certificats expirés. (Dont tu ne parles pas d'ailleurs…)
Après l'auto hébergement, c'est aussi avoir un serveur chez soi : samba, cache dns, privoxy, et j'en oublie…!
[^] # Re: vs fluxbox ?
Posté par chimrod (site web personnel) . En réponse à la dépêche Awesome 3.5. Évalué à 3.
Un petit exemple de ma config (basé sur une extension, shifty) :
quand j'appuie sur la touche « XF86Mail » je demande l'affichage du tag « mail » Dans la définition de ce tag, il est demandé de lancer mon client mail à la création.
Résultat, si l'appli est déjà lancée, elle s'affiche, si elle n'est pas lancée, elle va se lancer automatiquement. Cela permet d'être sûr que l'application ne sera lancée qu'une fois, et laisser awesome s'occuper de la lancer ou non. (au final, ça n'occupe pas mon écran puisqu'elle est lancée dans une étiquette part).
Autre exemple : gimp. On dit souvent que Gimp possède mauvaise une interface graphique. J'ai configuré awesome pour que la fenêtre Gimp n'utilise que 15% de l'écran, en laissant le reste pour la fenêtre du dessin. Une image valant mieux qu'un discourt, voici le placement par défaut :
Le but étant de ne pas avoir à me soucier de placer les fenêtres quand je lance une application, tout est géré de manière automatique…
[^] # Re: Pas très power user mais… ou pas!!!
Posté par chimrod (site web personnel) . En réponse à la dépêche Awesome 3.5. Évalué à 2.
Alors, je vais essayer de répondre de la même manière, en restant aussi objectif que possible.
En premier lieu, il faut savoir que Awesome est livré avec une configuration de base. Elle est cohérente et fonctionne bien. Ça permet déjà de se familiariser avec le WM sans perdre trop de temps, et déjà avoir une prise en main.
Après c'est comme tout, c'est standard, c'est pas parfait, et il y a toujours des points qui ne nous correspondent pas. Par exemple, dans la config par défaut, le raccourci clavier pour fermer un client est « Mod4 + SHIFT + c ». Ça faisait beaucoup de touches pour une mes petits doigts, et j'ai modifié ça en « Mod4 + c ». C'est pas grand chose, mais une fois qu'on a commencé à modifier la configuration, c'est difficile de s'arrêter là.
Le fait d'avoir un fichier de configuration qui fonctionne aide beaucoup quand on se plonge dedans : au lieu d'avoir la page blanche, on a un déjà une base qui fonctionne, et que l'on peut modifier petit à petit. Même si l'on ne connait pas lua, et le langage n'est pas compliqué — du moins tant qu'on ne cherche pas à l'interfacer avec du C — si l'on se contente de rester bas niveau, il s'apparente à du script/objet (en fait c'est de la Programmation_orientée_prototype) et l'on se plonge assez rapidement dedans.
Pour ma part, je trouve ça très puissant : je vois l'informatique comme un outil, est pouvoir l'adapter et l'utiliser comme bon me semble donne une autre dimension à l'application. Je ne sais pas si tu utilise déjà Vim ou Emacs, mais si c'est le cas, tu devrais déjà ressentir ce que je suis en train de dire.
L'inconvénient est que ça demande du temps. Mais c'est largement rentabilisé à l'usage, crois-moi !
[^] # Re: Pas très power user mais…
Posté par chimrod (site web personnel) . En réponse à la dépêche Awesome 3.5. Évalué à 3.
Merci beaucoup pour ta participation à la dépêche vlamy !
Le problème de la réécriture de la config se pose surtout pour ceux qui ont écrit leur propres scripts, c'est vrai qu'en restant proche de la config initiale, ça ne pose pas de problème.
Dans tout les cas, c'est dommage de casser l'API, mais c'est parfois nécessaire, et comme toujours, si on su faire le boulot une fois, l'adapter ne devrait pas poser de problème…
# c'est utiliser un bulldozer pour écraser une mouche
Posté par chimrod (site web personnel) . En réponse au journal Écrire une page web de nos jours. Évalué à 7.
J'ai peut être tort, mais je n'ai sûrement pas tord …
[^] # Re: Sonar
Posté par chimrod (site web personnel) . En réponse au message Outils d’audit de code (java) et de génération de rapport (sous debian). Évalué à 2.
Oui, sonar, xradar, squale
Les outils d'analyse ne manquent pas en java…
# Merci
Posté par chimrod (site web personnel) . En réponse au message Paradigme fonctionnel : juste un habillage ?. Évalué à 2.
Merci à tous pour vos réponses.
Tout d'abord, je reconnais que le code n'est pas pur dans le sens où son exécution produit des effets de bord dans la fermeture. Mais cela est causé par la manière dont je compte m'en servir : la liste d'appel à concat sera remplacé par un gestionnaire SAX. Je doit donc être capable de traiter les informations au fur et à mesure de leur arrivée.
Sinon il est vrai que mettre en place une structure de données n'a pas grand chose à voir avec de l'objet, mais j'aurai aimé ne pas utiliser la fermeture comme une structure.
Histoire de me prendre la tête, j'ai essayé une solution sans utiliser de fermeture, et l'autre solution trouvée aurait été d'utiliser un yield (comme en python) pour interrompre le traitement, ce qui ne semble pas possible en OCaml. (J'ai essayé de le simuler en retournant une fonction partielle dans un code récursif sans succès).
Bon, je vais continuer d'expérimenter tout ça, finalement mon exemple me semble suffisamment riche pour que je puisse essayer différentes approches
# À priori non
Posté par chimrod (site web personnel) . En réponse au message java, jar, application web, agpl et itext. Évalué à 1.
Imaginons que tu distribue ton application (le cas de la licence ne se pose pas si l'application reste dans son coin) :
tu peux très bien ne fournir que le cœur de ton appli, et laisser au client le soin d'installer par lui même la librairie itext. Tant que tu n'es pas statiquement lié a cette librairie, je ne vois pas où est le problème…
# Gebull
Posté par chimrod (site web personnel) . En réponse au message Linux en mileu rural. Évalué à 3.
Tu as Gebull à Bressuire (je ne connais pas, on m'a juste remonté l'information), mais c'est peut être un peu loin.
Tu peux les contacter, au moins pour connaître le maillage associatif dans le coin…
# facile ! (ou j'ai pas compris)
Posté par chimrod (site web personnel) . En réponse au message comparaison de deux fichiers. Évalué à 3.
# De toute façon
Posté par chimrod (site web personnel) . En réponse au message Pov-Ray dans debian ?. Évalué à 2.
La version 3.7, celle qui inclue le support du multiprocessing et qui permettra de diminuer le temps de rendu par le le nombre de processeurs de ta machine, n'est pas packagée pour debian.
Vu l'avancée de la version, ça n'est pas prendre un risque que de l'installer. Par contre il faut compiler à la main…
http://povray.org/beta/
# Owncloud est bon aussi
Posté par chimrod (site web personnel) . En réponse au journal synchro Thunderbird sans Google. Évalué à 3.
J'avais essayé également funambol, mais ai abandonné à cause d'un grand nombre de contraintes :
Finalement owncloud est sorti peut de temps après, et a fonctionné immédiatement. J'ai des clients pour mon téléphone (n900), thunderbird, et je n'ai besoin d'aucune autre dépendances supplémentaires.
C'est bien de voir que les offres commencent à se diversifier, pendant longtemps synchroniser les agendas sous linux a été très douloureux…
# Change de clavier
Posté par chimrod (site web personnel) . En réponse au journal Clavier-décharge : du danger de manger devant l'ordi. Évalué à 10.
Achète toi un clavier avec une housse, ça n'arrivera plus !
[^] # Re: un exemple en passant
Posté par chimrod (site web personnel) . En réponse au journal Tu souhaites apprendre à programmer en shell. Évalué à 5.
Ok, je donne un exemple un peu plus précis. Récemment je voulais générer un graphe dot, dont chaque nœud est une image. Les images devant être générées dynamiquement.
Les outils du shell me servent de liant pour extraire le nom de chaque nœud et y associer l'image que je veux générer
Grâce aux dépendances de make, je génère le fichier povray quivabien (en remplaçant une chaine de texte dans mon source) :
temp/%.pov: board.pov
cat board.pov | sed -e "s/\$${config}/$(patsubst temp/%.pov,%,$@)/" > $@
(Je vois au passage un joli uuoc. Écrire le commentaire m'aura permis de me relire :))
Je génère ensuite l'image par povray :
img/%.png: temp/%.pov
${POVRAY} +A0.3 +W250 +H250 $(patsubst img/%.png,temp/%.pov,$@)
mv $(patsubst img/%.png,%.png,$@) img
Il ne me reste plus qu'à lancer dot, en faisant quelques substitutions pour référencer les images qui viennent d'être générées.
Au final toutes mes images ont été générées via make. Grand luxe, make me supprime même les fichiers povray puisqu'il a détecté qu'il s'agit de fichiers intermédiaires, n'ayant aucune utilité dans mon rendu final ! Et en mettant à jour mon fichier dot, les nouvelles images sont automatiquement générées.
[^] # Re: un exemple en passant
Posté par chimrod (site web personnel) . En réponse au journal Tu souhaites apprendre à programmer en shell. Évalué à 4.
À noter qu'il est disponible en français sous le titre « Admin'sys : Gérer son temps ».
C'est vrai que ça vision du makefile est intéressante. Aujourd'hui je l'utilise (aussi) pour faire des scènes povray, faire un pdf à partir d'un texte balisé…
[^] # Re: Un monde en bêta...
Posté par chimrod (site web personnel) . En réponse à la dépêche Revue de presse de l'April pour la semaine 31 de l'année 2012. Évalué à 1.
J'ai l'impression que tu mélange « béta » et « obsolescence », les deux concepts ne sont pas synonymes ! Une analyse un peu plus neutre peut être trouvée ici : http://blog.octo.com/la-beta-perpetuelle/
Par contre c'est vraiment quelque chose qui ne s'improvise pas, il faut vraiment assurer le suivi client derrière pour que le produit « béta » ne se transforme pas en produit « non-fini » et sur ce point je ne suis pas d'accord avec l'article de la dépêche : le fait de développer en béta ne doit pas toucher à la stabilité du produit.
# Par expérience
Posté par chimrod (site web personnel) . En réponse au message Achat d'ordinateur de bureau qui me fera office de serveur web. Évalué à 4.
Attention, on commence petit (un serveur web ne demande pas grand chose comme machine), et puis on trouve qu'avoir une machine allumée 24/24 est quand même pratique :
On y met un cache dns parce que c'est quand même vachement pratique
On y branche une bonne installation audio, et voila mpd, pulseaudio…
On trouve que c'est bien d'avoir un espace centralisé pour échanger les fichiers : rsync, samba
Éventuellement un client bittorent qui tourne en continue,
Un serveur mail,
Et puis on voit une dépêche sur la sortie de privoxy, hop, on installe aussi
Et puis on voit un article pour héberger firefox sync chez soi,
Et puis,
Et puis,
…
Au final la petite machine rend tellement de service qu'elle n'en est plus si petite que ça.
Donc :
Vu le prix que coute un investissement, autant se poser la question de ce que va devenir la machine dans les prochaines années…
# Calendrier ?
Posté par chimrod (site web personnel) . En réponse à la dépêche Sortie de Roundcube 0.8. Évalué à 3.
Je vois sur les captures d'écran un calendrier que je n'avais jamais vu avant. Est-ce qu'il y a des options de synchronisation ICalendar, où est-ce que ça passe par un plugin ?
[^] # Re: Petit bug
Posté par chimrod (site web personnel) . En réponse au journal linuxfr-solarized : nouvelle version. Évalué à 2.
Le problème avec les écrans larges, c'est qu'ils sont trop larges pour utiliser les fenêtres en plein écran, et quand on divise l'écran en deux, on se retrouve avec une surface qui n'a pas pas été prévue par l'application…
# Petit bug
Posté par chimrod (site web personnel) . En réponse au journal linuxfr-solarized : nouvelle version. Évalué à 2.
En cas de largeur limitée de la fenêtre, on se retrouve avec une page blanche ne contenant que la sidebar, et l'ensemble du contenu est « poussé » en dessous.
Voici une capture d'écran pour aider à comprendre.
[^] # Re: Copié / collé ?
Posté par chimrod (site web personnel) . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 4.
Merci pour les réponses.
Je n'ai pas de logiciel de traduction automatique, je suis juste allé voir sur le site pour lire un peu le blog, et ai trouvé la ressemblance avec la dépêche interpellante.
En cherchant un peu plus loin sur le net, j'ai trouvé une copie conforme de la dépêche, tous ces éléments ne semblant pas reliés entre eux (je n'ai pas fait le lien entre ton compte perso ici et ton blog).
Tout ça me paraissait étrange, d'autant plus que je ne voyais pas version officielle du site (et je n'ai pas fait attention à la licence). Mais comme dit plus haut, je n'avais pas vu que la même personne était à l'origine du travail.
Merci pour la dépêche et la traduction (qui m'a donné envie de fouiller un peu plus avant, d'où mon message précédent), et toutes mes excuses si le message précédent a pu paraître agressif, ça n'était pas le cas.
# Copié / collé ?
Posté par chimrod (site web personnel) . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à -2.
Cette dépêche est la copie conforme de celle présentée sur le site officiel: http://blog.movim.eu/and-here-is-movim-0-5-snowball/ .
C'est amusant de comparer les réactions quand linuxfr présente un contenu original mais non neutre , ou un contenu identique à ce qu'on peut trouver ailleurs mais neutre, comme ici.
Pour ma part, ce deuxième point me gène davantage, on dilue l'information un peu partout, sans qu'il y ait réellement de valeur ajoutée à celle-ci (et la source n'est même pas citée…).
Est-ce qu'il y a eu annonce officiel ? Je retrouve la même traduction sur un blog…
[^] # Re: encfs
Posté par chimrod (site web personnel) . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 3.
Tu trouveras ce qu'il te faut ici :
http://thoughtsbyclayg.blogspot.fr/2008/02/how-to-delete-last-command-from-bash.html
[^] # Re: Owncloud
Posté par chimrod (site web personnel) . En réponse au message Gestionnaire de bookmark pour auto-hebergement. Évalué à 2.
Bof, ça serait bien si on pouvait écrire un petit commentaire à côté du lien pour se souvenir du pourquoi du bookmark.
Là je trouve que ça n'est pas très pratique.
[^] # Re: Awesome
Posté par chimrod (site web personnel) . En réponse au message Cherche WM utilisable au clavier + solutions pour tout gérer au clavier. Évalué à 1.
Tout à fait.
Mais dmenu permet de ne saisir qu'une partie du nom, ou d'utiliser les flèches, home, fin pour se déplacer dans la liste. On perd l'historique des commandes c'est vrai; en échange on gagne en vitesse quand on a une mémoire de l'action (je sais pas trop comment appeller ça : savoir qu'il faut faire « xt » puis « end » pour lancer son appli)
C'est rudement efficace quand on a pris l'habitude…
Je l'ai mappé sur modkey + « down », ce qui assez pratique d'accès également.
# À diffuser !
Posté par chimrod (site web personnel) . En réponse au journal Tutoriel d'autohébergement. Évalué à 4.
Le monde de l'autohébergement étant un petit monde, ta documentation pourra intéresser du monde sur le wiki correspondant.
C'est en tout cas une très bonne idée de noter tout ça… Quand on ne passe toute la journée à administrer des machines, ça permet d'éviter de se demander comment regénérer les certificats expirés. (Dont tu ne parles pas d'ailleurs…)
Après l'auto hébergement, c'est aussi avoir un serveur chez soi : samba, cache dns, privoxy, et j'en oublie…!