GeneralZod a écrit 2316 commentaires

Au temps pour moi. :)

debian, Maemo, ChromeOS (d'ailleurs James Scott Remnant le mainteneur d'Upstart a été embauché par Google), etc… La plupart des distros majeures ont une intégration satisfaisante d'Upstart même si pas toujours par défaut.
Pour opensuse, ça s'est joué au fil du rasoir, quand l'intégration d'Upstart a été jugé mature pour passer en production, ils ont décidés de passer à systemd. Idem pour d'autres distros qui ont pas mal lanternés (Frugalware entre autre) et qui du coup sont passés directement à systemd.

https://bugzilla.redhat.com/show_bug.cgi?id=612712 (le ticket Fedora correspondant a désormais plus de 2 ans)

Ça fait plus d'un an que j'utilise systemd et tmux et je n'ai jamais rencontré ce problème, j'ouvre/je ferme des sessions X, aucun soucis avec les sessions tmux démarrés sous tty ou X.
Par défaut, systemd ne tue pas les processus utilisateurs (pam_systemd permet de le configurer plus finement, mais il y a une clé de configuration globale dans systemd-logind.conf Cf. man), donc c'est probablement un problème de configuration.

Si on parle de la maturité de systemd, je rappelerais que quand la majorité des distros Linux l'ont adopté, Upstart était loin d'être parfait non plus (c'est d'ailleurs un demi-succès puisqu'en dehors d'Ubuntu personne n'utilise les jobs Upstart natifs)
Je comprends pas qu'on puisse regretter init SysV, avec le pare-feu, c'est l'un des deux trucs qui me font préférer les systèmes *BSD (IPtables, ça aussi c'est de la belle merde)

Le but de Fedora c'est de faire ce que veut faire la communauté Fedora.
Contrairement à d'autres distros, nous n'avons pas de dictateur à vie qui décide pour nous -contributeurs- et toutes les décisions techniques sont prises par le Fesco qui est entièrement élu par les contributeurs actifs.
Dire que Fedora fait de l'intégration pour RedHat, c'est aussi vrai que de dire que Debian fait de l'intégration pour Ubuntu & cie.

Pourquoi ne pas utiliser un pipe à la place de zeromq ?

Je te concéde que pour cet exemple particulier, ça n'a pas tellement d'intérêt.
Néanmoins l'avantage de ZeroMQ est de pouvoir passer à l'échelle plus tard, si tu as bien architecturé ton application que tes workers soient des threads, des process locaux ou distants (voire les mixer), tu as très peu de retouches à apporter à ton code.
Sans compter que zeromq offre également des patterns de communications de plus haut-niveau (ie: pub-sub, distribution de jobs dans un pool de workers etc …).

Par simple curiosité, je ne te moinsserais pas -voire plusserais si ton argumentaire tient la route- mais j'aimerais que tu élabores.

Il s'agit de conventions, pas de normes. L'utilisation de sighup pour recharger la config est un hack. C'est d'ailleurs mentionné dans le texte

Je suis d'accord avec toi sur le fond (c'est la raison pour laquelle j'ai utilisé le verbe "senser" et non pas "devoir"). Le problème c'est que si tu ne normalises pas un minimum le comportement des daemons, ça devient rapidement le foutoir.

Nginx redémarre tous les workers en cas de changement de config, qu'il soit en mode proxy ou non

Le truc c'est que Nginx se débrouille pour se comporter comme un daemon unix "bien élevé".

Haproxy est très correctement écrit, il a des perfs monstrueuses, fonctionne sans failles connues depuis 2002, est utilisé par des milliers de serveurs à travers le monde etc.

Sans rien enlever à ses mérites, en tant que daemon unix il est mal architecturé, certes, il n'y a pas de normes à ce sujet mais il y a quand même un certains nombres de conventions qui sont globalement bien respectés depuis plusieurs décennies.
Si HAProxy se fout d'être un daemon unix correct, c'est leur problème, pas celui de l'init (ça doit être bien dégueulasse le script sysV pour le coup, parce que là, même avec les cgroups, on arrive à paumer le daemon en cours de route)

Ca serait mieux si on pouvait passer des commandes aux serveurs directement via systemctl (des commandes non interprétées je veux dire) mais ca n'est pas possible

C'est un choix qui a été fait, pour éviter les abus et tout les hacks sales des init sysV.
Y a pleins de raisons pour critiquer systemd mais c'est très souvent les mauvaises qui sont invoqués (celle-là est pas mal dans le genre), et ça devient agaçant hors vendredi.

Merci, j'ai lu la même page man que toi.
Tu fais exprès ou t'as jamais lu le "Advanced Programming in the Unix Environment" de feu Dr Stevens ?
Un daemon unix est sensé recharger sa configuration quand on lui envoie le signal SIGHUP, et pas se saborder de manière ésotérique (en plus, y a des stratégies plus intelligentes que ça, Cf. Nginx)
Quand au chroot, c'est un faux argument, systemd n'a aucun problème avec les daemons chrootés correctement écrits, par exemple: Bind, Postfix, OpenSSH, Avahi, etc… idem quant aux daemons tournant dans un chroot.

Extrait la page man de haproxy:

-sf
Send FINISH signal to the pids in pidlist after startup. The processes which receive this >signal will wait for all sessions to finish before exiting. This option must be specified last, >followed by any number of PIDs. Technically speaking, SIGTTOU and SIGUSR1 are sent.

Évidemment, si HAProxy ne se comporte pas comme un daemon unix bien élevé, ça aide pas … Plutôt que faire une n-ième rustine, pourquoi ne pas corriger la conception défectueuse de HAProxy ?

+1 pour la version C++/Mindroid pourrite.
En C++11 avec zeromq, du coup, on fait exactement la même chose qu'en go, de la concurrence par passage de messages, le sucre syntaxique en moins (mais le sucre ça fait des caries)

#include <iostream>
#include <thread>
#include <zmq.hpp>


int main() {
  zmq::context_t ctx(1);

  std::thread t1([&] {
      zmq::socket_t sock1(ctx, ZMQ_REQ);
      sock1.connect("tcp://localhost:5555");

      for (int i = 0; i < 1000; ++i) {
        std::cout << "Hello ";
        zmq::message_t request(2);
        memcpy(static_cast<void *>(request.data()), "OK", 2);
        sock1.send(request);
        zmq::message_t reply;
        sock1.recv(&reply);
      }
      zmq::message_t request(2);
      memcpy(static_cast<void *>(request.data()), "KO", 2);
      sock1.send(request);
    });

  std::thread t2([&] {
      zmq::socket_t sock2(ctx, ZMQ_REP);
      sock2.bind("tcp://*:5555");

      while(true) {
        zmq::message_t request;
        sock2.recv(&request);
        std::string msg(static_cast<char*>(request.data()), request.size());
        if (msg == "KO")
          break;
        std::cout << "World\n";
        zmq::message_t reply(2);
        sock2.send(reply);
      }
    });

  t1.join();
  t2.join();
}

Si tu cherches une alternative plus légère en terme de ressources, il y a RhodeCode.
Certes, c'est un poil moins joli, mais en plus de Git, ça gère également Mercurial.

PS: pour l'avoir testé, ça tourne sur un Raspberry PI (sans le Full Text Search pour être honnête)
PPS: si on était vendredi, j'aurais également signalé que RhodeCode est en Pylons. ;)

de quel avatar parles-tu ?

Il n'a qu'à venir mouler icitte plus souvent ! :P

L'intérêt c'est de fournir également les fondations pour construire des outils de plus haut-niveau par dessus comme virtualenvwrapper & cie …

Merci, j'étais déjà au courant (depuis quoi ? plus d'un an maintenant) mais ça n'est qu'une partie de Ubuntu One.

Je n'ai fait que lever une ambiguité sans aucun jugement de valeur, mais c'est étrange comme certains se sentent obligés d'essayer de perpétuer cette ambiguité …

Bah alors Amazon S3 est libre, le protocole est librement documenté et il y a une dizaines d'implémentations libres dispos (Ceph/Rados, Swift, Walrus, Cumulus, vBlob etc …).
Sans aucun jugement de valeur, Ubuntu One n'est pas libre donc on évite de faire croire (volontairement ou involontairement) qu'il est, alors que c'est confus pour un grand nombre de personnes period

1. beaucoup croient à tort que Ubuntu One est libre
2. la formulation prête à confusion, mettant à égalité les offre libres qu'on ne mentionne même pas (Sparkleshare, OwnCloud, etc…) Donc non, ça me semble pertinent de le faire remarquer.

Aux dernières nouvelles, c'est toujours sapusaipalibre

De toute façon, il se passe jamais rien au-delà de Paris, RP. hein

Effectivement, il y a eu de belles réussites technologiques quand l'Etat se donnait les moyens mais le succès commercial lui a rarement été au rendez-vous.
Enfin, le minitel a été un succès commercial mais uniquement en France, on ne s'est jamais donné pour objectif de l'exporter ! Ce fut une erreur stratégique irréversible, le minitel ne pouvait que se faire écraser par le rouleau compresseur internet qui a vu les débits et le matériel évoluer de manière exponentielle alors que le minitel a stagné pendant longtemps (car restreint à un marché pas concurrentiel).

C'est une vaste blague, la plupart des investissements étatiques en France dans R&D finit dans la poche de grandes entreprises qui ont largement les moyens de financer leur propre R&D.
Le pire étant que ça aboutit souvent à des projets au mieux médiocre, au pire à rien, le but étant de capter un maximum d'argent public pour un minimum d'efforts.
Ce pognon aurait été mieux dépensé pour financer des PME ou startups innovantes ou un projet cohérent (pas juste un tas de papiers chié par des entreprises sclérosées et incapables d'être compétitives sans argent public). Foutrebleu, ce n'est pas les projets avec les plus beaux "powerpoint" ou ceux présentés par celui qui a le costume le plus seyant qui devrait l'emporter !
Il faut encourager les projets audacieux et pragmatiques, pourquoi le cloud à la française ? Pourquoi ne pas s'appuyer sur la multitude de moteurs de cloud open source (OpenStack, OpenNebula -issu d'un projet de recherche européen !-, CloudStack, etc …) ? Pourquoi il n'y a pas un seul hébergeur dans les deux consortiums ? Avec 5x moins de pognon, on a largement de quoi faire avancer le schmilblick en créant de nouveaux emplois (rémunérateur et pas des emplois assistés payés le SMIC voire moins)

Ça montre l'incompétence et la courte vue des personnes qui décident de l'attributions des investissements public (et de leurs conseillers), voire de leurs collusions.

Faudrait mentionner quelque part de manière explicite (comme le recommande judicieusement le Zen Python => python -m this) ce qu'est Pythran … De préférence au début du nourjal.

Distribution: RHEL

La bonne façon de faire sur les distros Fedora-based c'est de créer des groupes de paquets. Les méta-paquets sont déconseillés (la seule exception admise étant pour les paquets générés à partir du même src.rpm)
Pour ça, tu édites un fichier comps.xml qui doit ressembler à ça

<comps>
<group>
<id>machin</id><!-- identifiant du groupe -->
<name>machin truc bidule</name><!-- nom du groupe -->
<default>false</default>
<uservisible>true</uservisible><!-- visibilité dans les outils d'installation -->
<packagelist><!-- liste des paquets du groupe -->
<packagereq type="default">machin</packagereq><!-- paquet installé par défaut à l'installation du groupe -->
<packagereq type="optional">machin-truc</packagereq><!-- paquet non installé par défaut -->
</group>
...
</comps>


à la création du dépôt: createrepo -g comps.xml /chemin/vers/mon/dépôt (man createrepo)

parce que personne (y compris RedHat) n'a fait l'effort (c'est chiant, il faut bosser) de mettre sa clé dans la liste des clé pour les fabriquant (et donc : ben tu veux pas mettre ta clé, normal qu'il faille devoir désactiver la fonctionnalité).

C'est faux, RH a démarché la plupart des constructeurs et ont reçu pas mal de réponses positives. Si RH a abandonné cette voie, c'est que certains ont refusés, d'autres ont imposés des conditions inadmissibles rendant impossible la mise à disposition de clés pour les autres distros (notamment dérivées).