« Le but est d’aller le plus vite et le plus loin possible en direction de l’open source » explique la chancelière d’Etat Anja Wyden Guelpa (…) La Chancellerie doit également étudier le risque qu’un concurrent utilise son code, notamment une entreprise mandatée par un autre canton.
Hum, c'est moi où ils n'ont rien compris aux principes du logiciel libre ? L'idée est de donner la possibilité à n'importe qui de réutiliser le code, y compris des entreprises qui gagneraient de l'argent dessus. Arf.
Bon, après il y a "open source" et "open source" ;-)
En ce qui concerne la gestion de l'intégrité des fichiers, c'est un peu le boulot du système de fichiers, non ?
Hum oui, sauf qu'il n'y en a que peu qui supportent cette fonctionnalité. Btrfs peut stocker un hash et plusieurs versions d'un fichier. En cas d'erreur, on peut récupérer une vieille version du fichier. ZFS sait aussi stocker le hash d'un fichier.
ext4 et XFS ne savent pas stocker le hash d'un fichier par exemple.
Pour moi la question est plutôt d'être avertit quand un fichier est corrompu. Je vois mal Btrfs envoyer un rapport par email ou l'afficher dans une interface graphique.
Note: depuis récemment, ext4 supporte le checksum sur les métadonnées des fichiers, mais pas sur leur contenu.
« Dans le cadre de sa démarche d’ouverture des données publiques, la DILA a souhaité aller plus loin en stimulant la communauté de réutilisateurs des données juridiques. Elle a co-organisé le 30 octobre 2014 avec l’Open World Forum, le NUMA et Etalab, un projet d’innovation collaborative afin d’encourager la réutilisation des données juridiques ouvertes et en faire profiter le service public de la diffusion du droit. Ce projet s’inscrit sur le long terme pour encourager les initiatives. »
Oh, le titre de la conférence suivante « Guix-tox, une version fonctionnelle de tox » prête à confusion :-) tox fonctionne et est Guix qui est fonctionnel :
GNU Guix est un gestionnaire de paquets fonctionnel (comme dans "programmation fonctionnelle") basé sur Nix.
Je ne sais pas quelle est l'orientation exacte la remarque, mais si c'est pour la maintenabilité, j'ai déjà pensé à le réécrire dans un autre langage. J'avais d'ailleurs commencé en OCaml, mais ça stagne depuis quelques mois, problème de temps disponible, comme toujours :-(
Question facilité d'installation, j'aime bien Python car Python est maintenant disponible de base sous Linux et Mac OS X. Pour ma part, quand j'arrive sous un Windows, j'installe directement Python :-) Donc j'ai Python disponible partout, il n'y a pas besoin de compilation et Python fournit beaucoup d'outils "shell" (modules os & shutil notamment).
Il m'arrive parfois de lancer mon outil scm.py sous Windows, je crois que ça marche :-D Mais mon utilisation est super limitée sous Windows, en général j'utilise directement hg ou git en ligne de commande.
J'ai écrit un outil scm.py dans un ancien boulot pour pouvoir mettre à jour une dizaine de dépôts Mercurial en une seule commande. Puis j'ai eu besoin de gérer des dépôts Git. Petit à petit, j'ai ajouté plein de commandes pour mes besoins. Je n'ai jamais trop fait de pub car je ne crois pas que ça intéresse beaucoup de monde.
scm.py semble offrir les même fonctionnalités que gws. Il fonctionne sur Python (2 et 3, au choix).
C'est une petite surcouche à hg/git pour améliorer un peu la sortie. Par exemple, "scm.py st" ignore de base les fichiers temporaire ".swp" de vim et le fichier "tags" (pour ctags), et adapte la sortie pour le dossier courant (alors que "hg st" affiche toujours le chemin depuis la racine du dépôt). De même, "scm.py grep PATTERN" ne recherche que dans le dossier courant (et les sous-dossiers), pas tout le dépôt.
Pour limiter la casse en cas de conflit, les opérations qui modifient le dépôt (pull, histedit, …) mettent les modifications locales de côté sous forme d'un patch (commande stash). Ca aide un peu quand y'a plein de conflits.
J'ai ajouté des petits trucs comme "scm.py remove_untracked" pour supprimer les fichiers que j'ai crée pendant le dev, et que je veux supprimer pour revenir à un dépôt propre. Ou encore "scm.py info" qui affiche l'URL du dépôt. Je préfère cette sortie à aller chercher dans .hg/hgrc ou .git/config.
En espérant que ça serve…
PS: Vu que je passe très peu de temps à développer sur ce projet, ça ne m'intéresse pas trop à contribuer à des projets similaires. De plus, j'ai un peu implémenté ma manière de développer (ex: pull utilise --rebase) et je ne cherche pas à l'imposer à d'autres. Je ne me suis jamais pris la peine d'extraire ce script dans un dépôt dédié pour faciliter les contributions.
Bah justement, selon le 1er commentaire ce n'est pas une faille qui cible Linux/Intel, mais plutôt Android avec Linux/ARM:
It's not an SELinux exploit. It's fi01's put_user() exploit: https://github.com/fi01/libput_user_exploit
This is an exploit for an almost two year old vulnerability in the Linux kernel where pointers passed from userland were not validated properly on some ARM platforms.
Pour moi, s'il n'y a pas de rootkit et d'exploits pour Linux, c'est que Linux n'est pas assez rentable en terme de cibles potentielles. Je ne pense pas que ça soit un problème technique, des failles, y'en a à tous les niveaux et sur tous les OS. Mais ça coûte du temps (donc de l'argent) de les rechercher puis d'écrire des exploits fiables pour les utiliser.
Ou alors il y a vraiment un problème technique pour écrire des rootkits "portables" d'une distribution Linux à l'autre ?
Je ne sais pas. Ma question de base est : ai-je raison de me sentir protégé sous Linux, ou bien est-ce de l'inconscience de ne pas installer de parefeu et d'antivirus sur mon poste de travail ?
Github offre un mini serveur web pour servir des pages HTML. guake.org ne semble n'être qu'une simple page HTML. À quoi sert le nom de domaine guake.org ? L'URL importe peu tant que le site est bien référencé dans Google.
Ça en où de l'intégration de D-Bus dans le micronoyau ? Côté Linux, ça traine, ça traine : The kdbuswreck (hop je vous file un lien LWN gratuit car je vous aime les copaings, j'adore LWN, j'y suis abonné depuis 2 ans).
The Spartan rendering engine (edgehtml.dll) is a new component and separate from Trident (mshtml.dll). The new engine began as a fork of Trident, but has since diverged rapidly over the past many months, similar to how several other browser engines have started as forks prior to diverging. The new rendering engine is also being built with a very different set of principles than Trident - for example: a focus on interoperability and the removal of document modes.
Le moteur de rendu de Spartan est basé sur le moteur de rendu d'Internet Explorer 11, mais le code a "rapidement" divergé. (En tout cas, les perfs JavaScript semblent meilleures.)
Et sinon :
Today's IE Blog post also confirms what my sources told me in late December: Internet Explorer is not going away.
Tiens, dans le rayon des projets avec un nom bizare, j'ai vu passer xonsh : http://xonsh.org/
"xonsh is a Python-ish, BASHwards-compatible shell language and command prompt. The language is a superset of Python 3.4 with additional shell primitives that you are used to from BASH and IPython. xonsh is meant for the daily use of experts and novices alike."
J'ai jeté un oeil et je reste un peu sceptique. Je ne sais pas si ça tourne sous Windows :-p
Espérons que ça ne finisse pas à la façon Free, où le procès a été abandonné en plein milieu après un accord non divulgué et où donc on ne sait toujours pas si les arguments avancés par les défenseurs de la GPL se tiennent.
Je connais mal les solutions de stockage en ligne de type Dropbox ou iCloud, je vais plutôt parler du cloud que je connais : OpenStack.
Pour moi, les principes d'OpenStack sont que le matériel casse souvent et que les mises à jour ne doivent pas interrompre un service. La promesse du cloud est que les ressources sont illimitées, la limite est votre compte en banque :-) Techniquement, OpenStack apporte :
migration d'une machine virtuelle en cours de fonctionnement d'un serveur physique vers un autre, pour pouvoir mettre à jour un serveur (mise à jour OpenStack, noyau, remplacement d'un matériel défectueux, etc.)
stockage distribué : Ceph permet de créer un SAN moins cher (pas besoin de matériel réseau ultra rapide) et plus solide (pas de single point of failure, c'est plus distribué à l'échelle de tout le datacenter)
création hyper facile d'une nouvelle machine virtuelle : couplé à un peu d'intelligence, ça permet d'augmenter automatiquement le nombre de serveurs (machines virtuelles) d'un service en cas de forte charge (passer de 3 à 50 serveurs Apache/MySQL le temps d'un événement sportif/culturel, puis détruire les serveurs devenus inutiles quelques jours plus tard)
D'un point de vue sysadmin, l'impression que j'ai est que le cloud oblige à vraiment tout automatiser. Un déploiement doit être automatisé car il va être reproduit plusieurs fois, régulièrement. Sans ça, il n'est pas possible de rajouter automatiquement un nouveau serveur en cas de forte charge. Du coup, ça se cale bien avec la montée en puissance de puppet, ansible, salt stack, etc.
On passe d'un serveur qu'il ne faut surtout pas éteindre car plus personne ne sait comment il fonctionne, à des serveurs qui ont une durée de vie assez courte.
La meilleure illustration de l'ensemble est une infrastructure d'intégration continue pour tester un logiciel. La CI va créer une nouvelle infrastructure, avec une installation entièrement automatisée et sur de machine virtuelles, les tests sont joués, on récupère les rapports de tests, puis on supprime l'infrastructure. L'infrastructure peut avoir une durée de vie inférieure à une heure, même si elle est composée de plus de 10 VMs. Il y a quelques années, il était beaucoup plus difficile d'avoir rapidement une infrastructure reproductible. Il fallait par exemple sauvegarder le système de fichier puis le restaurer. On était plus dépendant du système d'exploitation et du matériel.
Bonjour Nicolas, oui c'est faisable. Le truc c'est que Open Stack est assez complexe a mettre en oeuvre et que peu d'acteur le font. (la replication)
(…)
Là, vous êtes proche d'une techno à la Google, où le logiciel est complètement décorrélé de la machine qui l’exécute (des machines tombent tout les jours dans leur cluster, ils ne les changent pas). Pour ça, il utilise leur techno de système de fichier distribué, de big table et map/reduce.
Intégré à OpenStack, il permet d'avoir un stockage distribué avec réplication (on peut perdre 2 machines sur 3 sans perdre de données) avec de bonnes performances. Ceph peut-être utilisé pour fournir des block devices à Cinder, et après on monte le système de fichier de son choix par dessus (ext4, btfs, xfs, ntfs, etc.).
On peut également utiliser Ceph directement depuis une application comme object storage, dans quel cas l'aspect redondance permet aussi de gagner en performances. Quand un objet est accédé très souvent, le nombre de réplicat augmente, et donc la vitesse de lecture.
Il y a quelques mois, c'était encore un peu galère d'installer et configurer Ceph. C'est plus facile aujourd'hui.
Note : La société Inktank derrière le projet Ceph a été rachetée par Red Hat. Avec le force de frappe de Red Hat, ça devrait accélérer un peu plus le développement du projet Ceph !
Note 2 : Je suis étonné qu'on déploie OpenStack sans stockage distribué :-p La sécurité des données (empêcher la perte) est plus importante que les performances, et les perfs de Ceph sont très bonnes.
L'accès aux locaux d'un datacenter est habituellement protégé par plusieurs contrôles. Ici le serveur est posé dehors. Suffit de tirer fort pour arracher les câbles (ou de les enlever délicatement si on n'est pas pressé), de porter la boîte à l'aide des poignées, et hop, on vole plusieurs téraoctets de données confidentielles non chiffrées.
Cinder (composant qui gère les "block devices" dans OpenStack) gère le chiffrement des block devices, mais je doute que ça soit systématiquement utilisé (voir que la fonction soit utilisée tout court).
Salut, c'est marrant, j'ai codé la même chose :-) J'ai commencé à écrire scm.py il y a 2 ou 3 ans quand je devais cloner puis mettre à jour une dizaine de dépôts Mercurial au boulot. Ensuite, j'ai ajouté le support de Git car je ne me souvenais jamais si tel projet utilisait git ou mercurial, là j'ai une CLI unifiée pour les commandes les plus courantes. Petit à petit, j'ai ajouté une vingtaine de commandes pour mes besoins :
Comme ça m'est arrivé plusieurs fois de perdre des modifications locales avec git et mercurial, scm.py commence par sauvegarder puis annuler les modifications locales avant les opérations qui modifient le dépôt. Du coup, je ne perds plus jamais mes modifications locales. Si réappliquer les modifications échouent, pas grave, je les ai dans un fichier (.hg/stash, .git/stash) sous forme d'un patch.
J'ai aussi ajouté des avertissements là où git supprime sans crier gare.
Quelques exemples :
scm.py pull : mettre à jour une vingtaine de dépôt git. continue en cas d'erreur : liste les erreurs à la fin. => à utiliser avant de prendre le train/avion sans internet ;-)
scm.py clean : supprime tous les fichiers .pyc, .orig, .swp, etc. récursivement dans les sous-dossiers
scm.py grep PATTERN : c'est tout con, recherche dans tous les fichiers suivi par git/hg (je n'ai jamais compris à quoi sert à la commande "hg grep" :-)), évite de taper "grep PATTERN $(find . -name *.py|grep -v test)" par exemple (d'autres outils comme ack le font, mais je n'installe jamais ack)
scm.py revert : supprime toutes les modifications locales et revient à un état normal (rebase en cours, merge en cours, etc. => hop, annulé)
Bien sûr, scm.py pull et scm.py push utilisent rebase pour garder un historique linéaire !
--
Au passage, j'ai écrit un petit outil par dessus la commande patch : apply_patch.py. C'est tout con : ça devine le paramètre -p pour éviter de mal appliquer un patch, et ça évite évite d'appliquer un patch s'il y a des erreurs (demande confirmation dans ce cas). Ca évite de pourrir un dépôt avec plein de fichiers .bak, .rej, .orig, etc. Je crois que apply_patch.py ne fonctionne pas sous FreeBSD qui malheureusement ne gère pas patch --dry-run.
PS : j'utilise aussi scm.py sous Windows où le shell est plutôt pauvre… (Comment on tape find -name ".orig" -o -name ".rej" -delete sous Windows ? :-p scm.py clean)
--
Ouais, y'a des outils "similaires". Similaires, donc différents. J'ai vraiment "implémenté" ma manière de manipuler le code dans scm.py, donc il me convient parfaitement :-) Et puis je passe peu de temps à le maintenir (qq. heures par mois max). Le plus pénible récemment était de gérer Python 2 et Python 3, ça devraient maintenant être bon ;-) (Ne gérer que l'un ou l'autre n'est pas pratique dans un virtualenv où "python" peut être l'un ou l'autre).
# SOS
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Écrire son OS - Partie 2 : configurer ses outils. Évalué à 5.
Moi ça me rappelle le projet SOS de Thomas Petazzoni ;-) http://sos.enix.org/fr/PagePrincipale
[^] # Re: Autre lien
Posté par Victor STINNER (site web personnel) . En réponse au journal L'ordinateur qui a effacé cinq voix. Évalué à 6.
Hum, c'est moi où ils n'ont rien compris aux principes du logiciel libre ? L'idée est de donner la possibilité à n'importe qui de réutiliser le code, y compris des entreprises qui gagneraient de l'argent dessus. Arf.
Bon, après il y a "open source" et "open source" ;-)
[^] # Re: Système de fichiers ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 3.
Hum oui, sauf qu'il n'y en a que peu qui supportent cette fonctionnalité. Btrfs peut stocker un hash et plusieurs versions d'un fichier. En cas d'erreur, on peut récupérer une vieille version du fichier. ZFS sait aussi stocker le hash d'un fichier.
ext4 et XFS ne savent pas stocker le hash d'un fichier par exemple.
Pour moi la question est plutôt d'être avertit quand un fichier est corrompu. Je vois mal Btrfs envoyer un rapport par email ou l'afficher dans une interface graphique.
Note: depuis récemment, ext4 supporte le checksum sur les métadonnées des fichiers, mais pas sur leur contenu.
# Libre/Open Source, Open Law
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche « Student Demo Cup » : Étudiant, lance ton projet libre. Évalué à 3.
Hum, c'est un peu dommage que ça ne soit pas "Libre" tout court. "Open Source" est un poil plus laxiste et peut poser des soucis :
Il serait bon d'indiquer des références vers les termes :
Je n'avais jamais entendu parler d' « open law ». À priori, c'est un peu la variante « open data » dans le monde juridique. Ca semble assez sérieux, le site web du premier ministre français en parle : http://www.dila.premier-ministre.gouv.fr/activites/experimentations/programme-open-law-le-droit-ouvert
« Dans le cadre de sa démarche d’ouverture des données publiques, la DILA a souhaité aller plus loin en stimulant la communauté de réutilisateurs des données juridiques. Elle a co-organisé le 30 octobre 2014 avec l’Open World Forum, le NUMA et Etalab, un projet d’innovation collaborative afin d’encourager la réutilisation des données juridiques ouvertes et en faire profiter le service public de la diffusion du droit. Ce projet s’inscrit sur le long terme pour encourager les initiatives. »
[^] # Re: tox est amour
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Programme de la PyConFR 2015. Évalué à 3.
Oh, le titre de la conférence suivante « Guix-tox, une version fonctionnelle de tox » prête à confusion :-) tox fonctionne et est Guix qui est fonctionnel :
[^] # Re: Il est temps de te mettre a haskell
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 2.
Question facilité d'installation, j'aime bien Python car Python est maintenant disponible de base sous Linux et Mac OS X. Pour ma part, quand j'arrive sous un Windows, j'installe directement Python :-) Donc j'ai Python disponible partout, il n'y a pas besoin de compilation et Python fournit beaucoup d'outils "shell" (modules os & shutil notamment).
Il m'arrive parfois de lancer mon outil scm.py sous Windows, je crois que ça marche :-D Mais mon utilisation est super limitée sous Windows, en général j'utilise directement hg ou git en ligne de commande.
# Autre outil : scm.py
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 4.
Salut,
J'ai écrit un outil scm.py dans un ancien boulot pour pouvoir mettre à jour une dizaine de dépôts Mercurial en une seule commande. Puis j'ai eu besoin de gérer des dépôts Git. Petit à petit, j'ai ajouté plein de commandes pour mes besoins. Je n'ai jamais trop fait de pub car je ne crois pas que ça intéresse beaucoup de monde.
scm.py semble offrir les même fonctionnalités que gws. Il fonctionne sur Python (2 et 3, au choix).
C'est une petite surcouche à hg/git pour améliorer un peu la sortie. Par exemple, "scm.py st" ignore de base les fichiers temporaire ".swp" de vim et le fichier "tags" (pour ctags), et adapte la sortie pour le dossier courant (alors que "hg st" affiche toujours le chemin depuis la racine du dépôt). De même, "scm.py grep PATTERN" ne recherche que dans le dossier courant (et les sous-dossiers), pas tout le dépôt.
Pour limiter la casse en cas de conflit, les opérations qui modifient le dépôt (pull, histedit, …) mettent les modifications locales de côté sous forme d'un patch (commande stash). Ca aide un peu quand y'a plein de conflits.
J'ai ajouté des petits trucs comme "scm.py remove_untracked" pour supprimer les fichiers que j'ai crée pendant le dev, et que je veux supprimer pour revenir à un dépôt propre. Ou encore "scm.py info" qui affiche l'URL du dépôt. Je préfère cette sortie à aller chercher dans .hg/hgrc ou .git/config.
En espérant que ça serve…
PS: Vu que je passe très peu de temps à développer sur ce projet, ça ne m'intéresse pas trop à contribuer à des projets similaires. De plus, j'ai un peu implémenté ma manière de développer (ex: pull utilise --rebase) et je ne cherche pas à l'imposer à d'autres. Je ne me suis jamais pris la peine d'extraire ce script dans un dépôt dédié pour faciliter les contributions.
[^] # Re: C'est vexant
Posté par Victor STINNER (site web personnel) . En réponse au journal [HackingTeam] Oui, il est possible de se rendre davantage ridicule qu'avec le nom de sa société .... Évalué à 8.
Bah justement, selon le 1er commentaire ce n'est pas une faille qui cible Linux/Intel, mais plutôt Android avec Linux/ARM:
https://www.reddit.com/r/linux/comments/3cegok/unknown_selinux_exploit_found_in_the_hacking/
Pour moi, s'il n'y a pas de rootkit et d'exploits pour Linux, c'est que Linux n'est pas assez rentable en terme de cibles potentielles. Je ne pense pas que ça soit un problème technique, des failles, y'en a à tous les niveaux et sur tous les OS. Mais ça coûte du temps (donc de l'argent) de les rechercher puis d'écrire des exploits fiables pour les utiliser.
Ou alors il y a vraiment un problème technique pour écrire des rootkits "portables" d'une distribution Linux à l'autre ?
Je ne sais pas. Ma question de base est : ai-je raison de me sentir protégé sous Linux, ou bien est-ce de l'inconscience de ne pas installer de parefeu et d'antivirus sur mon poste de travail ?
# C'est vexant
Posté par Victor STINNER (site web personnel) . En réponse au journal [HackingTeam] Oui, il est possible de se rendre davantage ridicule qu'avec le nom de sa société .... Évalué à 10.
Il n'y a pas d'exploit pour Linux ? (j'exclus volontairement Android de "Linux".) Est-ce que ça veut dire que Linux n'est pas prêt pour le desktop ?
# Intérêt d'un nom de domaine ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Histoire d'un vol de domaine. Évalué à 2.
Github offre un mini serveur web pour servir des pages HTML. guake.org ne semble n'être qu'une simple page HTML. À quoi sert le nom de domaine guake.org ? L'URL importe peu tant que le site est bien référencé dans Google.
# Plus sérieusement
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche GNU Hurd 0.6. Évalué à 10.
Ça en où de l'intégration de D-Bus dans le micronoyau ? Côté Linux, ça traine, ça traine : The kdbuswreck (hop je vous file un lien LWN gratuit car je vous aime les copaings, j'adore LWN, j'y suis abonné depuis 2 ans).
(et systemd sinon ?)
# Rappel
Posté par Victor STINNER (site web personnel) . En réponse au journal [ HS ] Journée de la procrastination.. Évalué à 4.
Il ne faut jamais reporter à demain ce qu'on peut faire le surlendemain.
# Nouveau, nouveau....
Posté par Victor STINNER (site web personnel) . En réponse au journal Internet Explorer is about to be bronsonised. Évalué à 3.
"il semblerait que MS ait fait table rase des héritages lourdingues et ait amélioré grandement les performances"
Mouais. Microsoft a écrit :
Le moteur de rendu de Spartan est basé sur le moteur de rendu d'Internet Explorer 11, mais le code a "rapidement" divergé. (En tout cas, les perfs JavaScript semblent meilleures.)
Et sinon :
et dans cet article :
# Old!
Posté par Victor STINNER (site web personnel) . En réponse au journal Internet Explorer is about to be bronsonised. Évalué à 10.
Windows 10 – Internet Explorer change de nom pour devenir « Google Chrome Installator »
http://www.legorafi.fr/2015/02/24/windows-10-internet-explorer-change-de-nom-pour-devenir-google-chrome-installator/
# Xonsh
Posté par Victor STINNER (site web personnel) . En réponse au journal Batsh - Scripting Bash, et Windows. Évalué à 4.
Tiens, dans le rayon des projets avec un nom bizare, j'ai vu passer xonsh : http://xonsh.org/
"xonsh is a Python-ish, BASHwards-compatible shell language and command prompt. The language is a superset of Python 3.4 with additional shell primitives that you are used to from BASH and IPython. xonsh is meant for the daily use of experts and novices alike."
J'ai jeté un oeil et je reste un peu sceptique. Je ne sais pas si ça tourne sous Windows :-p
[^] # Re: Fonctionnalites manquantes
Posté par Victor STINNER (site web personnel) . En réponse au journal Fermeture progressive de Google Code. Évalué à 2.
Oups, y'a une typo : c'est Read The Fucking Doc, rtfd. Exemple : http://trollius.rtfd.org/ redirige vers http://trollius.readthedocs.org/
[^] # Re: Fonctionnalites manquantes
Posté par Victor STINNER (site web personnel) . En réponse au journal Fermeture progressive de Google Code. Évalué à 2.
Avant je détestais écrire de la doc. Ensuite j'ai découvert Sphinx. Depuis, je monte un "site web" par projet. Le site web est en fait la doc. Exemple :
* Site/doc : http://trollius.readthedocs.org/
* Source : https://bitbucket.org/enovance/trollius/src/1f99b6967b418c0d4575f2c47c90b7b0c71f25d7/doc/?at=trollius
Merci à readthedocs.org pour héberger gratuitement la doc en offrant une URL courte (projet.rtfc.org et projet.readthedocs.org).
[^] # Re: Framasoft va lancer son instance de Gitlab
Posté par Victor STINNER (site web personnel) . En réponse au journal Fermeture progressive de Google Code. Évalué à 3.
Oui enfin, c'est un peu le cas quand même… (remplacer Google Code)
[^] # Re: Sourceforge
Posté par Victor STINNER (site web personnel) . En réponse au journal Fermeture progressive de Google Code. Évalué à 10.
Ca existe encore Sourceforge ? Je croyais que c'était devenu un site qui rajoute des malwares dans les exécutables Windows :-)
[^] # Re: Déjà posté deux journaux plus bas
Posté par Victor STINNER (site web personnel) . En réponse au journal Fermeture progressive de Google Code. Évalué à 10.
Euh, si ça parle de la même chose, il faudrait utiliser un titre plus clair :-p
[^] # Re: Pas compris !
Posté par Victor STINNER (site web personnel) . En réponse au journal VMWare poursuivi pour non-respect de la GPL. Évalué à 3.
C'était la FSF qui avait intenté un procès à Free pour non respect de la GPL :
http://fsffrance.org/news/article2011-09-14.fr.html
Je n'ai pas compris que le procès a été abandonné, mais qu'un accord a été trouvé.
Dépêche que j'avais écrite à ce sujet en septembre 2011 :
http://linuxfr.org/news/free-publie-enfin-ses-patchs-sur-les-logiciels-libres
[^] # Re: Peux pas répondre :(
Posté par Victor STINNER (site web personnel) . En réponse au sondage Quel est le bon prix pour le cloud ?. Évalué à 9.
Je connais mal les solutions de stockage en ligne de type Dropbox ou iCloud, je vais plutôt parler du cloud que je connais : OpenStack.
Pour moi, les principes d'OpenStack sont que le matériel casse souvent et que les mises à jour ne doivent pas interrompre un service. La promesse du cloud est que les ressources sont illimitées, la limite est votre compte en banque :-) Techniquement, OpenStack apporte :
migration d'une machine virtuelle en cours de fonctionnement d'un serveur physique vers un autre, pour pouvoir mettre à jour un serveur (mise à jour OpenStack, noyau, remplacement d'un matériel défectueux, etc.)
stockage distribué : Ceph permet de créer un SAN moins cher (pas besoin de matériel réseau ultra rapide) et plus solide (pas de single point of failure, c'est plus distribué à l'échelle de tout le datacenter)
création hyper facile d'une nouvelle machine virtuelle : couplé à un peu d'intelligence, ça permet d'augmenter automatiquement le nombre de serveurs (machines virtuelles) d'un service en cas de forte charge (passer de 3 à 50 serveurs Apache/MySQL le temps d'un événement sportif/culturel, puis détruire les serveurs devenus inutiles quelques jours plus tard)
D'un point de vue sysadmin, l'impression que j'ai est que le cloud oblige à vraiment tout automatiser. Un déploiement doit être automatisé car il va être reproduit plusieurs fois, régulièrement. Sans ça, il n'est pas possible de rajouter automatiquement un nouveau serveur en cas de forte charge. Du coup, ça se cale bien avec la montée en puissance de puppet, ansible, salt stack, etc.
On passe d'un serveur qu'il ne faut surtout pas éteindre car plus personne ne sait comment il fonctionne, à des serveurs qui ont une durée de vie assez courte.
La meilleure illustration de l'ensemble est une infrastructure d'intégration continue pour tester un logiciel. La CI va créer une nouvelle infrastructure, avec une installation entièrement automatisée et sur de machine virtuelles, les tests sont joués, on récupère les rapports de tests, puis on supprime l'infrastructure. L'infrastructure peut avoir une durée de vie inférieure à une heure, même si elle est composée de plus de 10 VMs. Il y a quelques années, il était beaucoup plus difficile d'avoir rapidement une infrastructure reproductible. Il fallait par exemple sauvegarder le système de fichier puis le restaurer. On était plus dépendant du système d'exploitation et du matériel.
[^] # Re: cloud avec garanti sur les données
Posté par Victor STINNER (site web personnel) . En réponse au sondage Quel est le bon prix pour le cloud ?. Évalué à 6.
Je vous conseille vivement de regarder du côté de l'object storage Ceph : https://en.wikipedia.org/wiki/Ceph_%28software%29
Intégré à OpenStack, il permet d'avoir un stockage distribué avec réplication (on peut perdre 2 machines sur 3 sans perdre de données) avec de bonnes performances. Ceph peut-être utilisé pour fournir des block devices à Cinder, et après on monte le système de fichier de son choix par dessus (ext4, btfs, xfs, ntfs, etc.).
On peut également utiliser Ceph directement depuis une application comme object storage, dans quel cas l'aspect redondance permet aussi de gagner en performances. Quand un objet est accédé très souvent, le nombre de réplicat augmente, et donc la vitesse de lecture.
Il y a quelques mois, c'était encore un peu galère d'installer et configurer Ceph. C'est plus facile aujourd'hui.
Note : La société Inktank derrière le projet Ceph a été rachetée par Red Hat. Avec le force de frappe de Red Hat, ça devrait accélérer un peu plus le développement du projet Ceph !
Note 2 : Je suis étonné qu'on déploie OpenStack sans stockage distribué :-p La sécurité des données (empêcher la perte) est plus importante que les performances, et les perfs de Ceph sont très bonnes.
# Accès physique aux données
Posté par Victor STINNER (site web personnel) . En réponse au sondage Quel est le bon prix pour le cloud ?. Évalué à 7.
L'accès aux locaux d'un datacenter est habituellement protégé par plusieurs contrôles. Ici le serveur est posé dehors. Suffit de tirer fort pour arracher les câbles (ou de les enlever délicatement si on n'est pas pressé), de porter la boîte à l'aide des poignées, et hop, on vole plusieurs téraoctets de données confidentielles non chiffrées.
Cinder (composant qui gère les "block devices" dans OpenStack) gère le chiffrement des block devices, mais je doute que ça soit systématiquement utilisé (voir que la fonction soit utilisée tout court).
# scm.py et apply_patch.py
Posté par Victor STINNER (site web personnel) . En réponse au journal Gérer son espace de travail git avec "gws". Évalué à 4.
Salut, c'est marrant, j'ai codé la même chose :-) J'ai commencé à écrire scm.py il y a 2 ou 3 ans quand je devais cloner puis mettre à jour une dizaine de dépôts Mercurial au boulot. Ensuite, j'ai ajouté le support de Git car je ne me souvenais jamais si tel projet utilisait git ou mercurial, là j'ai une CLI unifiée pour les commandes les plus courantes. Petit à petit, j'ai ajouté une vingtaine de commandes pour mes besoins :
https://bitbucket.org/haypo/misc/src/tip/bin/scm.py
Comme ça m'est arrivé plusieurs fois de perdre des modifications locales avec git et mercurial, scm.py commence par sauvegarder puis annuler les modifications locales avant les opérations qui modifient le dépôt. Du coup, je ne perds plus jamais mes modifications locales. Si réappliquer les modifications échouent, pas grave, je les ai dans un fichier (.hg/stash, .git/stash) sous forme d'un patch.
J'ai aussi ajouté des avertissements là où git supprime sans crier gare.
Quelques exemples :
Bien sûr, scm.py pull et scm.py push utilisent rebase pour garder un historique linéaire !
--
Au passage, j'ai écrit un petit outil par dessus la commande patch : apply_patch.py. C'est tout con : ça devine le paramètre -p pour éviter de mal appliquer un patch, et ça évite évite d'appliquer un patch s'il y a des erreurs (demande confirmation dans ce cas). Ca évite de pourrir un dépôt avec plein de fichiers .bak, .rej, .orig, etc. Je crois que apply_patch.py ne fonctionne pas sous FreeBSD qui malheureusement ne gère pas patch --dry-run.
https://bitbucket.org/haypo/misc/src/tip/bin/apply_patch.py
PS : j'utilise aussi scm.py sous Windows où le shell est plutôt pauvre… (Comment on tape find -name ".orig" -o -name ".rej" -delete sous Windows ? :-p scm.py clean)
--
Ouais, y'a des outils "similaires". Similaires, donc différents. J'ai vraiment "implémenté" ma manière de manipuler le code dans scm.py, donc il me convient parfaitement :-) Et puis je passe peu de temps à le maintenir (qq. heures par mois max). Le plus pénible récemment était de gérer Python 2 et Python 3, ça devraient maintenant être bon ;-) (Ne gérer que l'un ou l'autre n'est pas pratique dans un virtualenv où "python" peut être l'un ou l'autre).