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).
systemd-networkd sert à configurer les interfaces réseaux. Ca peut être pratique que cet outil gère l'option IP forward et le NAT. Par contre, l'article Phoronix ne parle pas d'une réimplémentation du parefeu ni d'outil pour manipuler iptables ou nftables. Extrait :
Also added on Tuesday was minimal firewall manipulation helpers for systemd's networkd.
Et puis bon, Phoronix n'est pas la meilleure source qui existe…
Le module distutils.version qui fait parti de distlib implémente cette PEP. C'est-à-dire qu'on peut valider qu'un numéro de version respecte une PEP, mais surtout comparer deux numéros de version.
Il est maintenant plus fiable de mettre à jour des modules dans un environnement virtuel géré par pip (le gestionnaire de modules Python de référence).
Vu la longueur de la PEP, on se rend compte de l'originalité dont font preuve les développeurs pour numéroter leurs logiciels !
A priori, le test compare des images dont la taille en octet est quasiment identique : "Images were first encoded with bpgenc at 25 QP/CRF. Everything else was matched to +/- 2.5% filesize.".
Je ne suis pas sûr que le temps de décompression soit pertinent vu que certaines décodeurs sont implémentés dans le navigateur web alors que d'autres sont implémentés en Javascript, du moins pour le cas précis de cette page web. Mais oui, les temps de compression et décompression m'intéressent.
Pour moi, le décodeur Javascript est plutôt un contournement temporaire en attendant que les formats WebP et BPG soient gérés nativement dans les navigateurs webs les plus populaires (Chrome, Firefox, Safari, IE). Chrome et Opera gèrent nativement les images WebP : http://caniuse.com/#feat=webp
Je crains que le principal frein à l'adoption du format BPG, notamment dans les navigateurs web, soit les sulfureux brevets. Je vois mal une société comme Apple ou Microsoft payer des brevets pour un gain discutable (taille des images). De plus, utiliser des codecs matériels pour HEVC dans un navigateur web peut poser de gros soucis de portabilité. Par exemple, le support H.264 dans Firefox semble encore incomplet sur plusieurs plateformes (Linux: Firefox sait utiliser GStreamer, Cisco paie la licence H.264 et fournit un codec binaire à Firefox, etc.). Sur ma Fedora 20 avec Firefox 32, je dois encore utiliser des lecteurs Flash pour regarder les vidéos Youtube (bien que https://www.youtube.com/html5 me dise que Firefox gère H.264 et WebM VP8, en pratique ça déconne), quelle tristesse…
Mais les images ne sont utilisées dans dans les navigateurs web. Stocker des photos au format BPG plutôt que JPEG sur une appareil photo numérique (APN) serait très intéressant pour pouvoir stocker beaucoup de photos sans trop rogner sur la qualité. Je ne parle pas des photographes amoureux de la technique qui stockent en RAW, mais le commun des mortels qui appuyent sur le bouton et ne vont jamais dans les menus régler la qualité du stockage des photos. Si HEVC est effectivement déjà supporté en hardware pour la vidéo, c'est tout à fait pertinent de réutiliser le hardware pour stocker également des photos. Il existe déjà des hacks pour les APN, par exemple CHDK pour Nikon. Voir aussi The Ultimate Custom Firmware For Any Camera Roundup (je doute que tous ces logiciels soient libres).
Salut, j'ai appris à programmer en C++ en codant sur le jeu Wormux sur lequel on a bossé à plusieurs. Le développement a duré plusieurs années. Problèmes rencontrés pendant le dev :
bibliothèque de jeu ClanLib qui subissait de lourde modifications internes, API instable
j'ai passé 3 mois à porter tout le jeu de ClanLib 0.6 à 0.7. Finalement, tout le jeu a été réécrit pour SDL
le moteur physique a été codé à partir de nos cours de physique au lycée : le moteur était plutôt bancal, instable et bogué
le réseau est arrivé très tard dans le jeu et fonctionnait mal sur Internet (bien en local avec une très faible latence)
on a passé une grosse partie du temps à s'occuper des aspects qui n'ont pas de lien avec le jeu directement : pile graphique, réseau, entrées-sorties, etc.
Si c'était à refaire :
Développer le réseau dès le premier jour
Penser le réseau pour Internet : latence importante (50 ms à 500 ms ?) et perte de paquet
Choisir une bibliothèque qui gère la majorité des aspects du jeu et qui est réputée stable : je ne sais quoi conseiller en 2014
Il y a 10 ans, les bibliothèques de jeu n'était pas bien packagé sous Linux, les pilotes graphiques libres était très lents, et une nouvelle version mettait plusieurs mois à être disponible dans les distributions Linux. La distribution était un gros problème.
Sourceforge n'est qu'un exemple parmi malheureusement beaucoup d'autres. Déjà que ça me les brises, je n'avais pas envie de dresser une liste exhaustive des sites Internet exigeant mon consentement pour utiliser ces cookies.
Bon allez, je lâche quelques noms :
*.google.* : petit bandeau qui ne propose pas directement de refuser les cookies
http://www.ibm.com/ : grosse popup TRUSTe (mal)… qui permet de configurer (bien!)
http://www.cisco.com/ : petit bandeau qui ne propose qu'une croix pour la cacher (et comment on les refuser !?)
http://slashdot.org/ : énorme popup qui prend tout simplement l'intégralité de la page, impossible de voir le contenu. Il est impossible de refuser les cookies à priori, on est obligé de cliquer sur "Accepter les Cookies" (mal). C'est exactement la même popup que sourceforge.net. L'image (drapeau français) vient de fsdn.com. Allez, j'accepte les cookies => redirection vers http://beta.slashdot.org/ qui m'affiche exactement le même bandeau. Dis moi, tu me prendrais pas pour un jambon par hasard ? 2e clic : grosse popup TRUSTe, woh putain…
www.free.fr : petit bandeau qui propose de configurer (bien)
Bien sûr, tu peux boycotter tous ces sites, mais je n'ai donné que quelques exemples. Si tu veux boycotter tous les sites qui affichent ces popups, bonne chance.
Ma principale critique est que dans la majorité des cas, on ne peut pas refuser les cookies d'un simple clic. Pardon, aucun site ne permet de refuser les cookies en un simple clic.
Et puis souvent, même en acceptant les cookies, on me repose la question plusieurs fois par mois, voir plusieurs fois par jour… Je suppose qu'il faut accepter le cookie qui permet de se souvenir qu'on accepte les cookies. Hein quoi ? Je m'y perds.
[^] # 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).
# Journal approximatif
Posté par Victor STINNER (site web personnel) . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 7.
systemd-networkd sert à configurer les interfaces réseaux. Ca peut être pratique que cet outil gère l'option IP forward et le NAT. Par contre, l'article Phoronix ne parle pas d'une réimplémentation du parefeu ni d'outil pour manipuler iptables ou nftables. Extrait :
Also added on Tuesday was minimal firewall manipulation helpers for systemd's networkd.
Et puis bon, Phoronix n'est pas la meilleure source qui existe…
[^] # Re: Crédibilité ?
Posté par Victor STINNER (site web personnel) . En réponse au journal 4,3 millions d'euros volés à la plate-forme d'échange de bitcoins Bitstamp. Évalué à 2.
Bitcoin a un intérêt limité sans les plateformes d'échanges, non ? Il est nécessaire d'avoir confiance dans ces plateformes pour les utiliser.
# PEP 440 - Version Identification and Dependency Specification
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Gestion sémantique de version. Évalué à 10.
Pendant ce temps dans la communauté Python, un document écrit en mars 2013 normalise les numéros de version :
https://www.python.org/dev/peps/pep-0440/
Le module
distutils.versionqui fait parti de distlib implémente cette PEP. C'est-à-dire qu'on peut valider qu'un numéro de version respecte une PEP, mais surtout comparer deux numéros de version.Il est maintenant plus fiable de mettre à jour des modules dans un environnement virtuel géré par pip (le gestionnaire de modules Python de référence).
Vu la longueur de la PEP, on se rend compte de l'originalité dont font preuve les développeurs pour numéroter leurs logiciels !
[^] # Re: javascript rules
Posté par Victor STINNER (site web personnel) . En réponse au journal Nouveau format d'image BPG. Évalué à 6.
Il manque la taille des images
A priori, le test compare des images dont la taille en octet est quasiment identique : "Images were first encoded with bpgenc at 25 QP/CRF. Everything else was matched to +/- 2.5% filesize.".
Je ne suis pas sûr que le temps de décompression soit pertinent vu que certaines décodeurs sont implémentés dans le navigateur web alors que d'autres sont implémentés en Javascript, du moins pour le cas précis de cette page web. Mais oui, les temps de compression et décompression m'intéressent.
Pour moi, le décodeur Javascript est plutôt un contournement temporaire en attendant que les formats WebP et BPG soient gérés nativement dans les navigateurs webs les plus populaires (Chrome, Firefox, Safari, IE). Chrome et Opera gèrent nativement les images WebP : http://caniuse.com/#feat=webp
Je crains que le principal frein à l'adoption du format BPG, notamment dans les navigateurs web, soit les sulfureux brevets. Je vois mal une société comme Apple ou Microsoft payer des brevets pour un gain discutable (taille des images). De plus, utiliser des codecs matériels pour HEVC dans un navigateur web peut poser de gros soucis de portabilité. Par exemple, le support H.264 dans Firefox semble encore incomplet sur plusieurs plateformes (Linux: Firefox sait utiliser GStreamer, Cisco paie la licence H.264 et fournit un codec binaire à Firefox, etc.). Sur ma Fedora 20 avec Firefox 32, je dois encore utiliser des lecteurs Flash pour regarder les vidéos Youtube (bien que https://www.youtube.com/html5 me dise que Firefox gère H.264 et WebM VP8, en pratique ça déconne), quelle tristesse…
Mais les images ne sont utilisées dans dans les navigateurs web. Stocker des photos au format BPG plutôt que JPEG sur une appareil photo numérique (APN) serait très intéressant pour pouvoir stocker beaucoup de photos sans trop rogner sur la qualité. Je ne parle pas des photographes amoureux de la technique qui stockent en RAW, mais le commun des mortels qui appuyent sur le bouton et ne vont jamais dans les menus régler la qualité du stockage des photos. Si HEVC est effectivement déjà supporté en hardware pour la vidéo, c'est tout à fait pertinent de réutiliser le hardware pour stocker également des photos. Il existe déjà des hacks pour les APN, par exemple CHDK pour Nikon. Voir aussi The Ultimate Custom Firmware For Any Camera Roundup (je doute que tous ces logiciels soient libres).
# Conseils d'un ancien programmeur de jeu
Posté par Victor STINNER (site web personnel) . En réponse au journal Dead Pixels Society. Évalué à 10.
Salut, j'ai appris à programmer en C++ en codant sur le jeu Wormux sur lequel on a bossé à plusieurs. Le développement a duré plusieurs années. Problèmes rencontrés pendant le dev :
Si c'était à refaire :
Il y a 10 ans, les bibliothèques de jeu n'était pas bien packagé sous Linux, les pilotes graphiques libres était très lents, et une nouvelle version mettait plusieurs mois à être disponible dans les distributions Linux. La distribution était un gros problème.
[^] # Re: Et la crémière
Posté par Victor STINNER (site web personnel) . En réponse au journal Marre des popups qui obligent à accepter les cookies. Évalué à 10.
Sourceforge n'est qu'un exemple parmi malheureusement beaucoup d'autres. Déjà que ça me les brises, je n'avais pas envie de dresser une liste exhaustive des sites Internet exigeant mon consentement pour utiliser ces cookies.
Bon allez, je lâche quelques noms :
Bien sûr, tu peux boycotter tous ces sites, mais je n'ai donné que quelques exemples. Si tu veux boycotter tous les sites qui affichent ces popups, bonne chance.
Ma principale critique est que dans la majorité des cas, on ne peut pas refuser les cookies d'un simple clic. Pardon, aucun site ne permet de refuser les cookies en un simple clic.
Et puis souvent, même en acceptant les cookies, on me repose la question plusieurs fois par mois, voir plusieurs fois par jour… Je suppose qu'il faut accepter le cookie qui permet de se souvenir qu'on accepte les cookies. Hein quoi ? Je m'y perds.
# libinput
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 7.
Je vous conseille la lecture de l'article http://who-t.blogspot.fr/2014/09/libinput-common-input-stack-for-wayland.html qui explique d'où vient le projet libinput et à quoi il sert.