diorcety a écrit 155 commentaires

Ouai et on voit ce que cela donne sur les sujets que l'on connait (hadopi, lopsi, …)

Je pense notamment au DHCP(http://www.phoronix.com/scan.php?page=news_item&px=MTY1Mjc). Alors on va me sortir qu'ils n'ont pas trouvé de bibliothèque avec toutes les fonctionnalités, que c'est un petit truc, ou autres. Mais ils auraient pu très bien apporter leurs contributions à un projet existant. Après c'est peut être le seul cas dans systemd…
Pour l'histoire du monolithique je reprenais un argument, en outre il me dérange pas, c'est plus l'aspect "tout les oeufs dans le même panier" qui me dérange

Bon j'arrive après le débat, mais bon…
Après faut aussi voir que certains "antis" sont contre l'implémentation qui est systemd mais pas forcement contre l'idée de systemd. La simplicité, dépendances, …(mettre ici tous les arguments des "pros") sont des très bonnes idées par contre la façon de faire; monolithique, NIH, (mettre ici tout les arguments des "antis") sont pour la plupart des points noirs du projet.

Effectivement si tu ouvres et fermes ta connexion à chaque requêtes ça va être significativement plus long. Mais sur pas mal de "services" (SSH, session http longue, xmpp)… c'est négligeable.
Après je pense que ça peut poser effectivement plus des problèmes d'interopérabilités. En plus de tes exemples je citerais l'exemple des smartcards. Il y en a très peu qui gèrent les clés de 4096 bits.

Depuis -> De plus
a remporter -> a remporté
dur le reveil…

$$$…
Pour moi depuis le début c'est une question d'argent.
Quand on voit le bordel que c'est déjà avec certaine extensions(.io notamment), j'imagine pas dans quelques années… Depuis quand on voit que c'est Amazon qui a remporter le .book, quelle légitimité il a comparé à un autre pour avoir le .book?

Et c'est bien connu, il est impossible d'envoyer des informations locales vers des serveurs distants

Oui, sauf que c'est de pire en pire, de plus en plus de site ne fonctionne plus sans javascript.

LD_LIBRARY_PATH c'est bien si ton programme n'appel pas de programme en dehors de ton package, autrement l'env sera propagé.
Le mieux que j'ai trouve c'est de faire un wrapper qui appel le linker dynamique de ton package

Par exemple:

/myroot/lib/ld-2.17.so --library-path /myroot/lib:/myroot/usr/lib /myroot/bin/myprogram
Reste le problème des autres variables d'env qu'il faut définir pour les bibliothèque que tu utilises dans ton package

Si je ne dis pas de bêtise, ton patron n'aura pas les mêmes charges sur ton augmentation que sur tes TRs. Voila pourquoi les patrons les distribuent à la pelle au lieu d'augmenter. En plus si tu es en SSII c'est directement compris comme faisant parti de ton salaire au rabais.

Effectivement, j'avais plus l'image du poteau que tu te prends dans la tronche dans la rue en regardant ton smartphone

C'est exactement le genre de réponse que j'attendais. C'est ce qu'on te "vend" (entre guillemet). Sur le papier ça parait parfait. Sauf que si comme moi (et mon entreprise) tu cherches à l'utiliser tu vas vite tomber sur le poteau rose.
En effet les schedulers ne savent pas prioriser les buffered writes (autant dire pratiquement tout les programmes que l'on peut être amener à utiliser). Alors si tu essayes de rendre prioritaire un service qui fait quelques petites écritures, face à un service qui fait des grosses manipulations de fichiers cela marchera très mal pour les petites écritures. Tu trimeras pour essayer de résoudre le "problème" jusqu'à tomber au fin fond d'un man disant(en cherchant pas mal):
What works
==========
- Currently only sync IO queues are support. All the buffered writes are still system wide and not per group. Hence we will not see service differentiation between buffered writes between groups.

Quelques patchs ont été proposé mais, il me semble pas que c'est d'actualité (et c'est bien dommage)

Je ne cherche pas à critiquer la solution, qui je trouve est une très bonne idée. Mais pour moi ce petit détail n'est pas suffisamment mis en avant; d'où cette perche tendue. Et c'est pour moi une des raisons qui peut empêcher l'industrialisation de celle-ci. Je vois mal expliquer à l'entreprise X que sont service est lent car l'entreprise Y fait des gros dd dans son conteneur(dans le cas de la mutualisation sous forme de conteneur).

C'est bien beau tout ça, pour des services utilisés de temps en temps, mais pour des services consommateurs en ressources, surtout si c'est pas la même entité qui utilise la même machine physique, ça doit pas être jojo. Je sais on va me sortir qu'il y a le IO scheduler, mais je vous laisse le loisir de tester "l'isolation"…

Effectivement, mais l'intégration avec OwnCloud n'est pas top, car OwnCloud et ce plugin(blind-coder) n'ont pas le même façon de gérer les groupes dans les vCards, donc il y a pas de groupes visibles dans RoundCube

VPN: Il y a aussi SocialVPN
Partage: Avec ton VPN tu peux surement utiliser D-LAN pour faire du P2P en dessus

Pas sur que tout le monde apprécie cmake ou les MAKEFILEs handmade

Ici: http://cgit.freedesktop.org/systemd/systemd/tree/src/tty-ask-password-agent/tty-ask-password-agent.c#n443

Donc si get_ctty_devnr retourne un code d'erreur négatif et que tu retourne l'opposé de cette valeur, tu ne peux pas différencier une erreur d'un FD.

D'ailleurs c'est tellement pas un bug que cela a été corrigé hier. https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18136.html

https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18134.html

NextInpact !

mais qu'en automobile tout passe dans un "bus" et qu'il faut ensuite que le programme intercepte les messages et les traite correctement.

Tu parles en automobile ou chez Toyota?

tout passe dans un "bus"

Des bus. Tu ne mélanges pas les messages de ton autoradio à ceux de ton ABS

en attendant que l'[ICANN] valide une TLD d'une seule lettre

En attendant que l'[ICANN] et les registrars s'en mettent plein les poches avec un truc sans grand intérêt, non? Outre quelques cas, à part faire le bonheur des registrars, je ne vois pas l'intérêt. On a déjà le skatage des domaines de certaines îles pour avoir une URL courte (.io) sans qu'il y ai de relation avec la choucroute.
Maintenant on a les caractères spéciaux généralisés sur la plupart des TLDs même ceux qui en ont pas besoin.
Donc au lieu d'acheter trucmuch.com, trucmuch.fr et cie on devra acheter:
trûcmuch.com, trucmûch.com, trûcmûch.com, trûcmuch.fr, trucmûch.fr, trûcmûch.fr, trucmuch.paris, trûcmuch.paris, trucmûch.paris, trûcmûch.paris et cie, si on veut être sûre de pas se faire squatter ou hameçonner.

C'est pas parce que google va avoir son TLD qu'il va abandonner ou ne plus faire d'enregistrement de domaine sur les TLD "classiques". En quoi cela pose problème de faire x.google.y au lieu de x.google?

Il aurait fallu tous les pendre; haut et court bien entendu.

Il faut aussi ajouter que le std::move est lié au Rvalue-reference. Cela permet de "convertir" une Lvalue-reference (pour le compilateur) en Rvalue-reference

Un autre exemple pourrait être (en se basant sur le tien), une fonction qui fait la moyenne

double mean(const std::vector<double> &func) {
    /// blabla
    return 0;
}

Ça c'est bien mais essaye de faire ça

mean(func());

Tu auras le droit à un beau message d'erreur du compilateur (l'argument n'est pas un Lvalue-reference)
Quelle était la solution?
-Soit tu mettais le résultat de func dans une variable (une copie si il n'y a pas de RVO)
-Soit tu ajoutais la fonction suivante

double mean(std::vector<double> func) {
    /// blabla
    return 0;
}

Par contre la tu fais une copie.

La solution avec les Rvalue-references est d'ajouter la fonction:

double mean(const std::vector<double> &&func) {
/// blabla
return 0;
}

Tu peux maintenant utiliser:

mean(func());

std::enable_if sert surtout pour faire de la meta-programmation. Après si tu ne développes pas de composants génériques dans tes programmes, effectivement je vois pourquoi tu n'en vois pas l'interêt.
Si tu veux un exemple réel pour voir l'intérêt de la chose(ou l'équivalent boost), regarde par exemple Firebreath (voir JSObject qui est une bibliothèque permettant d'exposer par l'intermédiaire d'un plugin NPAPI tout ce qu'il te chante.
En utilisant (c'est assez acrobatique des fois) cette fonctionnalité, il est capable de convertir des types, qu'il ne connaît pas forcement, en objet javascript que tu pourras utiliser dans ta page par exemple. Exemple: si ta fonction retourne un type itérable il pourra par exemple le représenter sous forme de liste coté javascript.
Effectivement c'est assez complexe, mais c'est le moindre mal quand tu veux faire quelque chose de générique, de la à dire que c'est de la masturbation…