Moonz a écrit 3657 commentaires

Non. Et alors ? on parlait des scripts d’init dans le sysv des distribs Linux des années 2000 non ?

Par curiosité, c’est quoi l’intérêt de lancer Firefox avec systemd ?

Plains toi aux autotools pour avoir lancé cette « mode » (probablement pour pouvoir tourner sur des systèmes antédiluviens). [ "$VAR" = "" ] ça marche très bien (et tu as un raccourci [ -z "$VAR" ] si tu as une âme de perleux).

Je tourne sous ArchLinux et j’avais ce bug jusqu’à la semaine dernière (bon, pas une journée, mais plusieurs minutes quand même pour l’arrêt)

Pour faire tourner un site statique avec Apache, il y aura uniquement les PID d'Apache dans votre containers et rien de plus (dans d'init, pas de Bash, de SSH…)

Est-ce que le processus qui tourne dans le conteneur est le PID 1 ? Si oui, je suppose qu’il est possible de lancer systemd ?

En fait ma question est plus : si on suppose que mon application est un service PHP/nginx/postgres, est-ce que je dois distribuer trois conteneurs (myapp-phpfpm, myapp-postgres, myapp-nginx) ou un seul myapp ?

Un container contient le binaire, pour le reste, il est préférable d'injecter la configuration, de monter de l'extérieur les répertoires contenant les données (DB généralement) et les logs

Est-ce que ce n’est pas un peu opposé à l’idée « déploiement en une commande » ?

Peu etre par ce que ces projets avaient d'autres problemes ?

launchd et smf étaient utilisés par Apple et Sun (oui, quand ils s’appelaient encore Sun). initng était parfaitement utilisable et très bien supporté par certaines distribs comme Gentoo.

Peu etre par ce que systemd ne fonctionne pas sur BSD, et par ce que personne n'a encore pris le temps d'implementer un equivalent ?

initng et launchd fonctionnaient sous BSD avant même que la première ligne de code de systemd soit écrite…

Et qu'ils ont d'autres raisons cachées ?

Pourquoi cachées ?

systemd gère mieux les cgroups et le multi-seat que n’importe quel autre de ses concurrents. Il a un système de templating extrêmement pratique. Il est aussi le projet qui exporte le plus de choses aux autres applications, d’où l’utilisation de cette API par Gnome, d’où une meilleure expérience utilisateur sur le desktop avec systemd.

Ça en fait des raisons largement suffisantes pour expliquer sont adoption massive, sans avoir à aller chercher des raisons comme « maintenir des scripts shell c’était trop dur », tu ne penses pas ?

Il y avait des tas de projets d’init bien avant systemd qui avaient pour simple but de remplacer les scripts init par des fichiers de conf et qui n’ont pas été adoptés par les mainteneurs (smf, launchd, upstart, pour n’en citer que les plus connus). Si la raison pour laquelle les mainteneurs ont choisi systemd c’est la simplicité de la maintenance des scripts, explique moi donc :

• pourquoi ils n’ont pas choisi un de ces projets il y a des années ? parce que le bash de 2009 était maintenable mais le bash de 2014 ne l’est plus ?
• pourquoi slackware, maintenu par une seule personne donc en première ligne pour les questions de difficulté de maintenance, veut retarder le plus possible son adoption ? masochisme ?
• pourquoi les BSD n’abandonnent pas les initscripts si c’est une telle charge de travail à maintenir ?

Vraiment, j’aimerais que tu m’expliques comment tu arrives à réconcilier ta théorie « les distribs migrent vers systemd parce que les .unit c’est plus maintenable que des scripts bash » avec ces faits.

Je vois que vous avez une haute estime des mainteneurs

Il ne t’est pas venu à l’esprit que ceux qui ont décidé de passer à systemd l’ont fait pour d’autres raisons que « c’est trop dur de maintenir des scripts shell » ?

(semi-troll: de toute façon c’est pas un pauvre script shell qui va faire peur à quelqu’un qui maintient des paquets deb/rpm quand on voit la simplicité de ces derniers…)

Oh mon Dieu, des bugs et des failles dans un logiciel, quelle horreur qui n’arrive que dans les projets inmaintenables !

Heureusement que systemd, étant bien codé lui, n’a aucun bug ni aucune faille de sécurité.

Aucun souci, sauf quand il faut tuer le processus. Oups, un zombie.

Heu, par définition (ou à moins d’un très grave bug dans le pid 1), si tu as un zombie c’est que ton processus est pas géré par le système d’init…

Aucun souci, sauf quand t'as oublié de gérer les fichues runlevels (heureusement qu'on n'utilise plus ça avec systemd)

Tu as les target qui ont exactement le même « problème » (qui n’en est pas un : si tu spécifies pas quand tu veux que ton script démarre ça me paraît normal que le système d’init le démarre pas, que ce soit systemd ou sysvinit)

Moi, j'en ai marre qu'on dise qu'avant c'était trop génial, que c'était simple et que ça faisait tout ce qu'on attend d'un OS moderne, non ça ne n'était pas simple, au contraire, et non ça ne faisait pas ce qu'on attend d'un OS moderne.

Il faut arrêter avec la mauvaise foi un peu.

Les initscripts ont été maintenus pendant des dizaines d’années sans aucun souci. Les BSD d’ailleurs n’ont pas l’air d’avoir envie de s’en départir, on devrait en déduire que ce sont des gros masochistes qui aiment le code inmaintenable ? (dans ce cas il faudra m’expliquer la décision de OpenBSD de sortir apache pour des raisons de trop grossos difficultés niveau maintenabilité tout en ne disant rien pour les initscripts…) Sans compter Slackware, distribution d’une seule personne qui a maintenu sans aucun souci tous les initscript de la distrib sans gros souci…

C’est pas parce que t’aime pas le shell que c’est pas maintenable, désolé. Sinon moi aussi je peux le faire : SAP essaie de s’éloigner de Windows donc j’en déduis qu Windows c’est pas maintenable.

Alors que les commandes de cron, à chaque je dois relire le manuel tellement c'est cryptique.

Je vois pas en quoi @hourly /usr/local/bin/myjob c’est cryptique.

Et je vois encore moins en quoi séparer ça en deux fichiers de plusieurs lignes est une avancée pour la simplicité d’utilisation et la maintenabilité.

Chaînes immutables = obligation d'en créer une nouvelle si on veut la modifier, pas d'effet de bord entre les fonctions ou entre les threads

Cet argument pourrait s’appliquer à tout objet…

Grosso modo le dispatch se fait par flux.

Tu as

rss http://linuxfr.org/news.atom DLFP

Qui revient à

command 2000 "rss2json http://linuxfr.org/news.atom | ua-inline | maildir-put -folder DLFP"

Qui dit de mettre le flux des actualités de linuxfr dans le dossier DLFP.

Par contre tous les items du flux sont forcément dans DLFP. Avec grep tu devrait être capable de séparer les deux, par exemple séparer les articles firefox du reste :

command 2000 "rss2json http://linuxfr.org/news.atom | grep -i firefox | ua-inline | maildir-put -folder DLFP/Firefox"
command 2000 "rss2json http://linuxfr.org/news.atom | grep -vi firefox | ua-inline | maildir-put -folder DLFP"

cssselect je le trouve vraiment désagréable à l’utilisation, mais c’est peut-être une question de goût.

J’ai pas regardé côté browser 2, mais en fait ce que je voulais dire c’est qu’il aurait été plus logique (enfin, de mon point de vueu) d’« hériter » de PyQuery (qui « hérite » de lxml.etree) plutôt que directement de lxml.etree.

(j’utilise « hérite » entre guillemets parce que je sais pas si vous faites de l’héritage ou de la composition)

Les extensions, ce n'est pas non plus ce qui manque à la concurrence!

Bof. Vu que Firefox bug aléatoirement chez moi toutes les quelques heures, j’ai décidé d’essayer sérieusement Chrome (plus sérieusement que mon précédent essai qui était là juste par curiosité et qui n’a pas duré plus de quelques heures). Deux trois trucs qui le rendent complètement inutilisable à mes yeux :

• ScriptSafe désactive aussi le javascript des autres extensions si jamais tu désactives sur le domaine principal. Conclusion : Vrome ou ScriptSafe, il faut choisir. Sous Firefox j’ai aucun souci à utiliser en parallèle Vimperator et NoScript.
• Les extensions sont désactivées sur chrome://. Détestable avec Vrome puisque désactivé sur tous les nouveaux onglets…
• Personnalisation ultra-limitée : jamais réussi à faire en sorte que chromium ne quitte pas quand je fais un "C-w" malheureux sur le dernier onglet, malgré l’installation de l’extension "Last Tab Standing" (vraiment, une extension pour une option aussi bête ?) qui prétendent faire ça.

PyQuery ce n’est pas que des sélecteurs, c’est aussi des outils pour manipuler plus facilement le DOM, exactement dans l’idée des fonctions type CleanText. C’est à ça que je faisais référence quand je parlais de pyquery, pas du boulot autour de ListElement qui me semble effectivement une bonne idée

Et les sélecteurs CSS c’est quand même vachement plus pratique que xpath dans 99% des cas :)

Sinon, pourquoi ne pas avoir tout simplement utilisé PyQuery ? Typiquement, en PyQuery,

CleanText('.//span[@id="title1"]')

c’est

doc(".title1").text()

Et les trucs spécifiques que PyQuery sait pas faire par défaut (typiquement: regex) peuvent parfaitement être implémentés dans PyQuery.fn

Un producer pour boobank est déjà prévu ;)

Pour parser du JSON vers une structure native au langage (généralement dictionnaire ou objet anonyme + liste), c’est à peu près une ligne de code de type json_decode dans quasiment tous les langages, le plus souvent intégré dans la lib standard. Pour RSS/Atom c’est déjà plus compliqué, surtout que chacun de ces deux formats a plusieurs version. Et à l’intérieur d’une seule version d’un format tu as des subtilités peu intéressantes que je ne veux pas me trimballer d’un bout à l’autre du pipe (par exemple la différence entre publication date, creation date et modification date: typiquement un truc que le producteur veut abstraire pour simplifier tout le reste de la chaine de traitement).

Niveau production, le JSON est tout aussi simple, un json_encode d’une structure langage du standard (la même que json_decode) et c’est plié.

Par comparaison avec RSS/Atom, dans la plupart des langages dans la lib standard tu as au mieux une API type DOM pour faire du XML. Et lire/produire du RSS/Atom à partir d’une simple API type DOM, ce n’est certes pas la fin du monde, mais c’est infiniment plus compliqué et ce n’est certainement pas quelque chose que tu veux refaire n fois un dans un projet composé d’une multitude d’exécutables différents et indépendants et même écrits dans des langages différents.

tl;dr: haters gonna hate, mais aujourd’hui en 2014 JSON a gagné haut la main et c’est LE langage d’interopérabilité par excellence. On ne devrait plus justifier l’utilisation de JSON mais bien plutôt sa non-utilisation, et dans le cas de la non-utilisation la justification devrait être solide.

Il prendrait un slot effectivement, mais vu que le nombre de workers est configurable ce n’est pas un vraiment un problème.

Vu que le nombre de workers par défaut est 5, il suffit d’ajouter workers=6 dans le fichier de conf :)

(ou de se dire que 4 pour le reste des processus est suffisant)

Je suppose qu'il est ensuite relativement facile de créer un 2em "consommateur" qui génère des rss normalisés?

Oui, même si j’ai du mal à voir l’intérêt, ça donnerait rss2json http://linuxfr.org/news.atom | json2rss :)

Est-ce facile d'écrire une telle chose avec un flux rss par input? ou tag/catégorie que des inputs ou filtres pourraient créer?

Je ne suis pas sûr d’avoir bien compris ta question…

Pour les input en temps réel il « suffirait » de coder un pubsubhubhub2json qui fasse un flux continu. Grosso-modo ça donnerait:

 timeout=0 command 0 "pubsubhubhub2json | ua-inline | maildir-put"

où pubsubhubhub2json serait un serveur web qui enverrait sur stdout et dans le bon format toutes les notifications qu’il reçoit.

Donc pour la première question oui c’est possible, pour la seconde question (prévu à court terme) très certainement que non, vu qu’à ma connaissance les seuls services proposant pubsubhubhub sont des agrégateurs qui font eux-même du polling, ce qui limite fortement l’intérêt de la chose :)

Pour les output c’est effectivement le rôle du serveur IMAP de gérer ça ; je sais pas comment c’est implémenté dans dovecot mais il le fait très bien : dès que j’ajoute un mail il apparait dans mon client mail.

Ça marche aussi sous Python 2.7 pourtant:

Python 2.7.6 (default, Feb 26 2014, 12:07:17) 
[GCC 4.8.2 20140206 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> method = "strip"
>>> obj = " foo "
>>> print(getattr(obj, method)())
foo

Pas toi ? :)

Python 3.3.5 (default, Mar 10 2014, 03:21:31) 
[GCC 4.8.2 20140206 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> method = "strip"
>>> obj = " foo "
>>> print(getattr(obj, method)())
foo

François a raison, en Python les méthodes sont des attributs comme les autres. Tu peux même faire des trucs rigolo comme

myobj.square = lambda (self): self*self
myobj.square()

L'un des intérêts en ruby est qu'on peut appeler des méthodes dynamiquement sans faire appel à Eval : c'est dans un cas de ce genre que ceux-ci m'ont manqués.

Faisable en Python sans symboles :

method = "strip"
obj = " foo "
print(getattr(obj, method)())

C’est en gros une string, notée :foo au lieu de "foo", avec juste une ou deux différences avec une string normale:

• Seuls les identifiants (au sens nom de variable) sont possibles
• Le type est Symbol, pas String
• Deux symbole identiques ont la garantie d’être portés par le même objet (en termes Python, pour les symboles, == implique is)