barmic a écrit 10455 commentaires

Il y a différents shunit, shunit2. Ils n'ont rien de bien révolutionnaires, ils (du moins tout ce que j'ai pu voir) se contentent d’exécuter des méthode préfixées par test_ et de mettre à disposition des assertions.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

sans se prendre trop la tête

Et sinon tu as essayé LaTeX ? J'aime beaucoup hein, mais je serais très loin de dire que c'est "sans prise de tête".

Perso à choisir j'écris dans un markup langage, puis je génère le tex au dernier moment quand je regarde la mise en page et que je n'ai plus qu'à faire des retouches du contenu.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

L'option "-x" ne sert qu'a afficher la commande exécutée, c'est ça?

Ça montre les commandes (réelles) et les sous shell créés.

Enfin, on est loin d'un réel débogage tout de même.

Je en dis pas le contraire.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Pas aussi bien. Il peut avoir une syntaxe à la pipe (mais qui se lie à l'envers, mais les appels de programmes externes ne sont pas aussi agréables (et tu n'a pas la parallélisation).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est un module de zsh. Tu peux trouver des exemples là et là et la doc dans man zshcontrib.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

En fait il veut dire que tu peut tester chaque méthode séparément, parce qu'elles ont des entrées et des sorties bien définies (tu peut forger les entrées de tes fonctions).

Pour le debuging de script shell, l'option -x est utile sans être génial. bash permet de faire un trap en DEBUG pour exécuter du code après chaque instruction ça peut être pratique aussi (jamais essayé mais tu peut peut être mettre un read pour faire une pause à chaque fois). Tu peux aussi mettre des fonctions pour remplacer tes pipes par des pipes avec tee pour mieux voir ce qui se passe.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'ai mis la version java uniquement parce que c'est une approche totalement différente des autres. Pour s'en servir, il faudrait utiliser l'API à travers groovy, scala ou clojure (je pense que c'est faisable).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

La version java est plus embrouillee (getName, c'est du babillage administratif, i.e. du bruit).

Je comprendrais cette remarque pour les toString(), mais pour les getName(), je ne vois pas. Le getName(), permet de récupérer le nom du fichier pointé plutôt que le chemin complet.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

On n'a pas la même façon de voir clair…

Personnellement je parlais du plus lisible des 4 premiers.

A force, on va arriver à Java, ou… à Python comme la personne à qui tu reprochais de ne pas connaitre le shell ;-).

Je ne connais pas d'autres langages qui utilise une API comme nio/nio2 pour la gestion de fichier. Je ne dis pas que ça n'existe pas, mais je ne les connait pas (il y a boost je crois). python utilise des chaines de caractères dont tu as quelque chose que awk ou zsh.

Note que java est un très mauvais candidat pour pleins de raison (il est compilé, il est lent à démarrer). Perso pour faire ce boulot, c'est zmv que le privilégierais, il est littéralement fait pour.

Note : dans tous les cas, ça manque de commentaires ;-).

Personnellement, j'essaie d'en mettre de moins en moins, par exemple avec la version java je ne vois pas l'intérêt de mettre un commentaire pour décrire la transformation (il suffit de lire), j'expliquerais juste quoi on a besoin de se format final.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Il y a quand même pleins de façon plus lisibles de faire ça :

sed 's@.*/\([^/]\+\)/\([^/]\+\)@&|\1-\2@' # version sed

awk -F/ '{print $0"|"$(NF-1)"-"$NF}' # version awk

# version pure shell
while read line ; do
  project=${line##*/}
  usr=${line%/*}
  usr=${usr##*/}
  echo "${line}|$usr-$project"
done

# version zsh
while read ; do
  tab=( "${(s:/:)REPLY}" )
  echo "${REPLY}|${(j:-:)tab[${#tab[@]}-1,${#tab[@]}]}"
done

Ma version sed, demande à connaître les expressions régulières ce qui est largement plus courant que le langage sed et qui est plus visuel aussi.

La version awk (la plus lisible des 4 AMHA) demande à savoir comment fonctionne awk (-F pour découper les lignes et le bloc s'execute pour chaque ligne).

La version zsh consiste à découper la ligne sur les / et à concaténer les deux derniers éléments avec un - (c'est l'opérateur j pour join).

Il y a, je pense, 4 façons générales de le faire :

• la tienne que je comprends pas (je connais pas le sed)
• les expressions régulières (ma version sed, plus ou moins la version shell)
• le découpage sur les / (les versions awk et zsh)
• dans les langages évolués interpréter l'ensemble comme un chemin de fichier et le manipuler par exemple en Java :

while (scanner.hasNextLine()) {
    Path p = Paths.get(scanner.nexLine());
    System.out.println(String.format("%s|%s-%s", p.toString(),
                                                 p.getParent().getName().toString(),
                                                 p.getName().toString()));
}

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

La façon normale ou du moins celle qui est prônée pour l'avenir c'est QML avec QtQuick. Il y a autant de rapport entre QML est le web qu'entre glade et le web.

D'ailleurs Qt n'est pas le seul à avoir pris json comme format de description des interfaces, c'est aussi le cas des EFLs (je n'ai plus en tête le nom exacte de la lib).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Techniquement il est possible de faire une xslt qui produit du json, mais ça n'a que peu d'intérêt vu qu'il va de toute manière falloir tout reprendre car les concepts sont différents (le format json de QML pouvant contenir des bouts de javascript).

Ils peuvent par exemple le faire à l'occasion d'une réécriture de l'interface (pour passer à ruban par exemple :p).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça a était nécessaire un jour ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Si un jour ils passent à Qt, j'espère plutôt qu'ils vont directement choisir QML pour décrire leurs interfaces.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Michael Meeks est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur Collabora.
[…] Cette dépêche est une traduction de son article initialement publié dans le domaine public ou licence CC0, comme indiqué au bas de l'article.

Donc oui c'est technique, c'est fait pour.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

la simplicite est un argument completement pipeau.

Je ne sais pas et je me fou de savoir si systemd est plus simple, mais le fait que l'utilisateur soit un sysadmin ne rend pas la simplicité inutile. Ça peut lui permettre d'être plus rapide ou plus efficace en évitant les erreurs et/ou en simplifiant ces procédures (que ce soit des doc ou des recette ansible/chef/puppet/etc).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'aime beaucoup le shell, mais bon… un jour on se met a en utiliser un qui rend vraiment les choses simples (et donc permet de rendre les choses très complexes accessibles) :

zmv -p git -o "clone --bare" "$basedir/(*)/(*).git" "$1-$2.git"

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Où est-ce que j'ai dis que ça couvrait tous les usages ? Le fait que ce soit limité n'empêche pas de dire que ça existe.

Pour le cas spécifique du PrivateTmp, tu dois pouvoir te démerder avec les diversions pour faire un wrapper aux scripts d'init qui fait le job (mais c'est très crade).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça c'est un aigri ou alors je ne m'y connaît pas.

Tu reproche aux gens de ne pas utiliser de méthode formelle et tu reproche aux gens de s'y mettre avec l'existant.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est une erreur s/LSM/DSL/

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je pense que si ces messieurs et ces dames peuvent retirer du code spécifique entre BSD et linux ils ne s'en porteraient que mieux.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

la catégorie "pas secure" pour les gens sérieux

Ouai enfin faut se détendre aussi un peu.

Capsicum n'adresse absolument pas la même problématique que les hyperviseurs et les containers. C'est pas les même personnes qui s'en servent et ils ne s'en servent pas pour faire la même chose. Tu peut détourner l'un et l'autre pour leur faire faire la même chose, mais ça ne sera pas efficace (autant d'un point de vu performance que pour le coté pratique).

Capsicum est un outil pour développeurs. Il incite assez peu à "réachitecturer" les appli parce qu'il est fait justement pour éviter de se fader des sécurités basés sur des processus (ce qui est souvent fait dans les projets OpenBSD par exemple). Par exemple avec capsicum apache httpd, peut garder mod_php en son seins, plutôt que d'utiliser une solution type (f)cgi/fpm. Tu ne pourra jamais te baser sur capsicum pour faire de lé sécurité basée sur des hyperviseurs ça n'a rien avoir.

Quant à la bagarre conteneur/hyperviseur, je ne connais pas bien les hyperviseurs, mais je me méfis des gens qui me disent que magiquement parce que c'est un hyperviseur c'est d'un coup hypersécurisé. Des failles dans les hyperviseurs ça existe aussi. C'est peut être plus sécurisé, mais je ne m'en méfierais pas moins qu'autre chose (que ce soit à cause de véritables failles, des failles liées à des configurations mal fichues, des administrations mal foutue (mauvais dimensionnement des VM par rapport aux machines physiques par exemple et hop le déni de service),…).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Un des soucis non résolu de sysvinit etait le fait que tout etait dans /etc/init.d, marqué (dans les distributions rpms) comme fichier de configuration. Et donc, la moindre modif impliquait de perdre le nouveau fichier à l'update et donc de passer à coté de corrections de bugs ( parfois ).

Sur les systèmes dérivés de Debian, il demande de résoudre le conflit. Mais Debian cherche à limité au maximum ce genre de choses et la plupart des actions demandent plutôt à aller taper dans /etc/defaults et les scripts d'init se basent là dessus.

Si vraiment tu veux modifier un fichier système (normalement géré par apt/dpkg) tu peut utiliser les diversions.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Pour la sécurité, je veux bien… que tu développes un peu plus.

systemd rend facilement accessible des fonctions de sécurité (cgroup, namespace,…). Très rare sont les scripts d'init qui s'en servaient et maintenant c'est suffisamment simple (et reproductible entre distribution) pour être intégré de base.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Et puis c’est pas comme si systemd était compatible avec rien: il peut fonctionner sur toutes les distributions GNU/Linux!

D'autant que la compatibilité de sysv avec autre choses que les distributions linux est toute théorique.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)