Vroum a écrit 137 commentaires

Il existe des hébergements pour de la vente en ligne comme Etsy.

Cela peut être une solution clé-en-main temporaire le temps de mûrir votre projet de site web (design, choix visuel, hébergement).

On est loin du logiciel libre ici mais cela peut aider à mieux définir ses besoins en attendant de choisir la solution libre la plus adaptée.

Vu dernièrement à une install party, Handylinux s'installe sur du matériel plutôt ancien (qui ne gérait pas le flag PAE du CPU). C'est basé sur Debian et propose un XFCE de base. Très intéressant également au niveau du forum et des ressources en français.

En relisant le man de xauth, il semble que la commande generate soit préférable dans ce cas:

xauth generate $DISPLAY .
xauth extract /tmp/bob.xauth $DISPLAY

puis:

xauth merge /tmp/bob.xauth

Savez-vous ensuite si la configuration xhost est prise en compte? Notamment si un xhost - a été fait sur la machine par bob ?

Vérifie bien que ton fichier de script est en utf8. Au pire, tu peux changer de mailer et tpasser par mutt pour gérer les pièces-jointes en MIME (option -a).

Merci d'avoir poster l'origine du problème.

Tout d'abord, je ne comprends pas bien l'intérêt du ${BIN} mais tu dois avoir une raison de tout surcharger et notamment sur le fait d'avoir les coreutils (sleep, mount, …) dans /usr/bin plutôt que dans /bin.

Tu as peut-être un problème de locale. Essaye d'exporter LC_ALL en début de script.
Ou sinon dans un premier temps, commence par ajouter les options -v et -d à ta commande mail.

Ce serait mieux avec ta règle udev au complet et éventuellement les logs syslog s'il y en a…

Je n'ai jamais eu l'occasion de tester mais certains utilisent le format UDF comme système de fichier.

Si d'autres ont un retour d'expérience notamment sur la possibilité de remplacer vfat et la compatibilité avec les autres OS, merci à eux.

Tu décris ici le paradoxe de Monty Hall:

https://fr.wikipedia.org/wiki/Probl%C3%A8me_de_Monty_Hall

À noter que les pigeons font mieux que les humains sur ce paradoxe:

http://www.livescience.com/6150-pigeons-beat-humans-solving-monty-hall-problem.html

Si tu as mailx tu peux remplacer "-a FROM" par -r .
Comme précisé précédemment $USERNAME est root a priori mais je laisse la variable au cas où.
Mettre la date à ton fichier est hasardeux car tu as déjà l'information et tu risques d'écraser les précédentes tentatives. Voir l'option "cp -b -S" pour un usage plus poussé

        #!/bin/bash

        # Exit immédiatement si quelque chose de non prévu arrive. ça peut éviter un effet boule de neige
        set -e

        CIFS_FILE=$HOME/.cifspasswd
        MOUNT_LOG=/tmp/mount.log
        USERNAME=$(id -un)
        HOSTNAME=$(hostname -f)
        FS_MOUNTS="//fileserver/share\t/mount/share"

        _mail () {
            cat $MOUNT_LOG | mail -s "[$HOSTNAME] $USERNAME: $1" -r "$USERNAME@mycompany.com" it@mycompany.com
        }

        read -p "Put your windows login? " login
        read -s -p "Now put your windows password (*hidden*)? " password

        # Vérifie les droits de création
        touch $CIFS_FILE
        chmod 600 $CIFS_FILE

        # Ecrase le ficher s'il existe (n'ajoute pas à la fin)
        echo -e "username=$login\npassword=$password\ndomain=dom.local" > $CIFS_FILE

        # L'option -u t'évitera d'écraser ta sauvegarde
        cp -u -p -b -S "_$(date +%F)" fstab fstab.back

        # Créé un bloc de texte à copier (plus simple à adapter au besoin)
        cat <<EOD >>/tmp/fstab
        # ADDED BY $0 ($(date))
        $FS_MOUNTS\tcifs\t_netdev,users,rw,auto,users,credentials=$CIFS_FILE,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0"
        # END
        EOD

        # Crée les répertoires en remplaçant d'abord la tabulation en espace pour la commande mkdir
        mkdir -p $(tr "\t" " " <<<$FS_MOUNTS)

        # Envoie le résultat par mail
        if ! mount -va > $MOUNT_LOG
        then
            _mail "FSTAB ERROR"
        else
            _mail "fstab ok"
        fi

        # On garde la trace de la dernière exécution dans /tmp au cas où...
        # ... sinon rm -f $MOUNT_LOG

En jouant un peu avec l'API et en regardant les tests du module, j'en déduit que pas mal de fonctions sont auto-générées.

    my $host = $config->subnets->[1]->add_host( {name => 'pnom6'} );
    $host->add_fixedaddress({value => 'pnom.domain.net'});
    $host->add_hardwareethernet({value => 'D0:AA:12:BC:13:6A'});

A priori, on doit pouvoir ajouter directement des clés/valeurs à la création de l'host mais je ne suis pas sûr que cela soit la bonne manière de faire:

    my $host = $config->subnets->[1]->add_host( {name => 'pnom6', keyvalues => [
            { name => 'hardware ethernet', value => 'D0:AA:12:BC:13:6A'},
            { name => 'fixed-address', value => 'pnom.domain.net'}]
                       });

En espérant que ça t'aide un peu…

Je suis tenté personnellement par la disposition Colemak qui me semble plus simple à apprendre que le dvorak. Avez-vous un retour d'expérience sur cette disposition ? (courbe d'apprentissage vraiment réduite? est-ce que les aller/retours sont facilités ?)

http://colemak.com/

Voir aussi le projet lavaboom en campagne de dons également.

https://lavaboom.com/

Je ne résiste pas de parler également du projet Axiom qui vise à produire une caméra libre de droit. Beaucoup sont encore sceptiques mais le projet continue d'avancer.

https://www.apertus.org/axiom

La variable d'environnement FIGNORE est destinée à ce type de filtrage au moment de la complétion.
Tu peux certainement la réutiliser ici pour l'écriture de ton alias.

Le plus simple est de convertir vers un tableau ce qui facilitera l'expansion de la variable.

Sous Bash:

alias ls="IFS=: read -a fignore <<< $FIGNORE; ls ${fignore[@]/#/--hide=}"

Sous Zsh, le tableau fignore est directement défini, ce qui rend ton alias encore plus concis:

alias ls='/bin/ls --hide=${^fignore}'

Un autre avantage du tableau est qu'il te permet de le modifier facilement à la volée:

fignore+=__pycache__

P.S. Les guillemets simples ou doubles ont leur importance ici.

Je suis exactement comme toi et avec i3 en prime.

Je suis resté très longtemps avec Xterm pour un soucis de compatibilité avec les applis console, c'est-à-dire avec les codes d'échappement.

Et puis finalement, j'ai opté pour rxvt-unicode qui fournissait par défaut un bon nombre de petites choses intéressantes (et difficile à obtenir avec Xterm) et faciles à configurer. Notamment les extensions pour détecter les urls, copier/coller x11, la possibilité d'assombrissement (shading ?) des terminaux non utilisés, un démon permettant d'économiser quelques ressources, une extension "kuake" pour se la pêter.

Il me convient bien même si le mode démon me fait hurler lorsqu'il me plante l'ensemble des terminaux de temps en temps… :-(

L'élément qui me fait rester pour l'instant, c'est la possibilité de mettre en place ses propres extensions. Le code Perl a l'air assez sympa et j'ai toujours eu en tête de pouvoir lire des documents dans un nouvel Xembed (avec l'extension tabbed) créé à partir du terminal qui a lancé la commande (typiquement run-mailcap).

J'aime bien st pour sa simplicité et je testerai bien Final Term pour son côté innovant. Le test qui tue, c'est souvent mutt dans un tmux (mais là c'est souvent à cause de la valeur du $TERM qui dépend de screen).

P.S. D'habitude, je ne vois pas trop l'intérêt des sondages mais cette fois-ci c'est sympa de découvrir des terminaux qui m'avait échappé jusqu'à maintenant.

Merci pour tout !

Pour ce logiciel qui sera bientôt incontournable, c'est sûr!
Pour ton enthousiasme et ta motivation dédiés au libre
Pour ce billet très bien rédigé et passionnant

Longue vie à G'MIC !

Il est possible de restreindre vos raccourcis pour une application donnée. Je vous laisse quelques exemples.

$if Bash
    # Edit the path
    "\C-xp": "PATH=${PATH}\e\C-e\C-a\ef\C-f"
    # Insert open and close double quotes
    "\C-x\"": "\"\"\C-b"
    # Insert a backslash (testing backslash escapes in sequences and macros)
    "\C-x\\": "\\"
    # Quote the current or previous word
    "\C-xq": "\eb\"\ef\""
    # Add a binding to refresh the line, which is unbound
    "\C-xr": redraw-current-line
    # Edit variable on current line.
    "\M-\C-v": "\C-a\C-k$\C-y\M-\C-e\C-a\C-y="
    # Non-incremental style of history completion
    "\ep": history-search-backward
    "\en": history-search-forward
$endif

$if Python
    # http://albatross.dnsdojo.net/apache2-default/wiki/index.php/Python_Readline_Completions
    ...
$endif
$if Mysql
    "\C-xc": "SELECT count(*) FROM "
    "\C-d": "desc "
    "\C-l": "show tables;\n"
$endif
$if Lftp
    "\C-g": "lftp   "
$endif
$if Ftp
    "\C-xg": "get \M-?"
    "\C-xt": "put \M-?"
    "\M-.": yank-last-arg
$endif

Vous pouvez également le faire par mode:

    $if mode=vi
       ...
    $endif

http://www.ted.com/talks/marcin_jakubowski

Pour la simplicité en mode ligne de commande, il existe aussi pass:
http://www.passwordstore.org/

Et tu n'as toujours pas répondu : mal gaulé ça n'avance pas à grand chose comme argument.

C'était pourtant le but du paragraphe qui suivait:

SOAP n'a pas été correctement pensé. Au tout début, il a réglé des problèmes simples (comme pouvait le faire XML-RPC) et à proposer ensuite un maquis d'extensions pour boucher les trous. Tout cela a été péniblement intégré dans la pile WS-I. Côté serveur: seul Java me semble aujourd'hui capable de traiter du SOAP correctement (j'imagine que .NET aussi après tout). De plus le support client SOAP est loin d'être complet dans la plupart des langages de programmation ce qui pose quand même un problème sur sa pérennité et son idéal agnostique.

Pour être plus précis, SOAP est vendu comme solution de SOA mais très souvent tu n'as même pas de WSDL qui va bien ou un registre UDDI correct. On te vend une complexité superflue là où du XML-RPC ou du REST peuvent très souvent faire l'affaire.
SOAP est trop souvent utilisé comme un bus logiciel alors que c'est exactement là où il est le plus inefficace (en terme de charge réseau ou de puissance de calcul nécessaire pour le parsing).
Les normes des extensions sont exclusivement poussées par les grands éditeurs qui font en sorte de protéger leurs logiciels maisons. Au final, très peu de compatibilité et de coopération possible.

Pour les alternatives, j'en donne quelques-unes plus bas dans le fil.

Le fait qu'il soit Turing-Complet veut surtout dire que tu peux exprimer tous les problèmes à résoudre. En ce sens, XSLT n'est pas limité à certaines tâches (comme par exemple faire seulement du templating) mais il peut couvrir tous les besoins programmables.

XSLT aurait eu un sens à une époque où les langages haut niveau n'existaient pas. De nos jours, je ne vois pas l'intérêt de XSLT (bizarre, verbeux, super-limité) face à l'écriture d'une moulinette en Python par exemple.

Pour des documents lourds et complexes, tu risques fort de semer une multitude de bugs avec une approche impérative sur des documents XML. Outre le fait que tu devras passer par du SAX car les parsers DOM seront trop lents, tu auras certainement la joie de baigner dans un code très difficilement maintenable.

Je ne doute pas que tu puisses écrire une «moulinette» bien foutue mais j'envisage plutôt le cas général avec des équipes de développement qui ne sont pas toutes core-dev de python.

Qu'est ce qui remplace SOAP pour du SOA aujourd'hui ?

Pour les cas les plus simples, il y a évidemment REST mais évidemment on se retrouve avec pas mal de choses à gérer au niveau serveur HTTP (authentification, signature, …). Mais j'imagine que ça couvre un bon nombre des cas usuels en B2B.

Sinon, je pensais surtout aux middlewares à la AMPQ ou même quelques projets comme XMPP. Dans le monde Java, je regarderais du côté des services Jini et/ou OSGi. Après il y aurait tout un tas de projets à évaluer comme ZeroC, Apache Thrift, …

Pour du M2M (model tout model) tu as ATl oub xTend de open architectureware (sous eclipse maintenant). Pour du model to text: oaw xPand, Acceleo,…

(Ok merci, tombé sur http://wiki.eclipse.org/index.php/Modeling_Project grâce à toi)

Ces outils ne reposent-ils pas tous sur du XML et in-fine sur des transformations XSLT ?

On parle ici d'un langage de transformation et pas d'un langage de programmation. Et j'ai quand même l'impression qu'XSLT est très efficace pour ce genre de transformations même si pas forcément compréhensible de prime abord. Tu ne m'enlèveras pas de l'esprit que c'est bien grâce à la plasticité du XML que ce langage est systématiquement choisi comme langage pivot aux applications et qu'il n'existe pas vraiment d'alternative à cela aujourd'hui.

Donc XSLT est tellement incompréhensible qu'il faut passer par des outils pour pouvoir l'utiliser. Ça démontre bien la simplicité de "truc".

En même temps vu l'ambition (démesurée) du «Model-Driven», ce n'est pas ce que j'appelle la voie de la simplicité. XSLT me semble être un mal nécessaire pour ces masochistes du MDA!

Tu te rends bien compte que tu pourrais dire la même chose des développeurs qui se permettent d'utiliser des outils RAD pour développer leurs interfaces utilisateurs au lieu de prendre quelque chose de "plus simple".

Le seul cas de «Model-driven» que je connaisse concerne le MDA et le format d'échange est du XML (XMI). Je serais bien curieux de connaître des alternatives ceci dit.

XSLT ne me semble pas une hérésie. Il ressemble à un langage fonctionnel tout en bénéficiant des mêmes avantages que les autres dialectes XML. Après il n'est pas super sexy mais à la différence d'autres langages, il est bien souvent généré par des interfaces utilisateurs qu'écrit directement à la main.

SOAP n'a pas été correctement pensé. Au tout début, il a réglé des problèmes simples (comme pouvait le faire XML-RPC) et à proposer ensuite un maquis d'extensions pour boucher les trous. Tout cela a été péniblement intégré dans la pile WS-I. Côté serveur: seul Java me semble aujourd'hui capable de traiter du SOAP correctement (j'imagine que .NET aussi après tout). De plus le support client SOAP est loin d'être complet dans la plupart des langages de programmation ce qui pose quand même un problème sur sa pérennité et son idéal agnostique.

Heureusement, on a trouvé largement mieux que SOAP pour faire du SOA aujourd'hui. Enfin, je ne connais pas assez CORBA pour avoir un avis tranché mais il me semble que la version 3 améliorait pas mal les choses.

Très honnêtement je pense que le succès de SOAP vient essentiellement du fait qu'il passait les pare-feux. C'est assez triste à dire et trollivore mais je te laisse le week-end pour en découdre :-)

Rien de nouveau dans ce que je rajoute ici mais c'est juste pour souligner les arguments déjà mentionnés.

Le langage XML n'est qu'un format de fichier qui règlent déjà deux points extrêmement pénibles: la sérialisation et l'encodage (non, l'UTF8 n'est pas la panacée).

Au délà du langage, c'est bien la validation du document (DTD ou XML Schema) qui me semble super profitable. Car non seulement le code du parseur existe (avec les librairies externes) mais aussi tout le code nécessaire à la validation! Vous pouvez alors très facilement (et sans risque) changer les spécifications de données tout en restant rétro-compatible.
La transformation des documents étant assurée par XSLT, plus besoin des infâmes "moulinettes" toutes pourries qu'on peut trouver dans la plupart des projets de reprise. Ok, pas si simple à écrire le XSLT, mais ça vaut souvent le coup d'apprendre (d'autant plus que c'est un vrai langage Turing complet).
La plasticité du XML permet d'inclure plusieurs types de documents ensemble avec des espaces de noms séparés et accessibles depuis XPATH ou XQUERY bien supérieurs à la recherche "full-text".

Ce qui me semble important à retenir, c'est qu'XML n'est que le format. La vraie utilité ce sont les autres dialectes XML qui se fondent dessus.
Et chaque dialecte devient un outil extrêmement puissant et rarement comparable en terme de fonctionnalités par rapport à des formats à plat.
Forcément, si le seul but est juste d'avoir un format de configuration, alors évidemment on ne parle pas du tout de la même chose…

Pour l'efficacité de stockage, ce n'est pas vraiment un argument. La plupart du temps, l'ensemble fourni est recompressé (ex: formats OpenOffice).

Après, je comprends le ras-le-bol de certains après avoir subi la mode XML dans les fichiers de conf (à la Apache ou Zope…) et aussi le péché originel avec cette machine à gaz qui est SOAP.

Le fait que tous ces fichiers soient lisibles en partie par l'humain me semble anecdotique. Je ne suis pas sûr non plus que ce soit un des buts d'origine.