X345 a écrit 580 commentaires

Non.

C'est exactement le cas que je décris. La partie client bittorent de Deluge est écrite en C++, c'est la libtorrent-rasterbar. C'est certes une bonne solution mais ça oblige à écrire des bindings .so/Python ou C,C++/Python. Dans le cas de la libtorrent, ce n'est vraiment pas un problème : écrire une un client bittorent est beaucoup plus long et difficile que d'écrire un binding python pour une bibliothèque déjà existante.

Cependant, quand on code tout soi-même, on apprécie de tout faire dans le même langage et ne pas avoir un process de compilation trop compliqué.

l'API ressemble à du PHP.

Tu sais que ce n'est pas vraiment convaincant ça ?

Merci, tu ensoleilles mon vendredi :-)

Bon déjà shared_ptr<> c'est certes bien mais ça n'est sûrement pas un ramasse miettes complet (c'est un peut comme si tu comparais un moteur de voiture avec une voiture complète). Il faut toujours se préoccuper de problèmes comme la rule of three, se demander si on veut passer les objets par copie ou par référence. Il faut aussi gérer les .hpp et .cpp, se casser la tête parce qu'on doit faire des forward déclaration de classes si on a des dépendances circulaires. L'héritage en C++ n'est pas aussi simple qu'en Java : il faut se préoccupper de déclarer ses méthodes virtual (et ses destructeurs hein pour éviter les fuites) , regarder comment on caste les shared_ptr<> si on en utilise. Sans compter les cas où les exceptions se marient moyennement bien avec la gestion manuelle de la mémoire. Je pourrais continuer comme ça pendant des heures.

Bref, coder en C++, c'est dur. Bien plus dur que coder en Java. On devrait coder en C++ uniquement quand on a besoin du gain de performance apporté.

Tu dis que ne pas gérer la mémoire à la main, c'est masquer les problèmes. Certes, mais c'est bien le sens de ce qu'on fait en informatique depuis 30 ans, non ? Le C masque l'assembleur et le fait que mon processeur à des registres et qu'il faut aller chercher des trucs de la mémoire pour les mettre dans des registres. Même chose pour les systèmes d'exploitations qui masquent le matériel et offre des API unifiées.

Et honnêtement une application en C++ a mille fois plus de chances de fuire qu'une application codée en Java. Certes l'application Java utilisera certainement plus de mémoire à la base, mais le ramasse-miette limite franchement les erreurs de programmation.

Concernant les bibliothèques Java utilisant de manière excessivement les annotations, tu n'es pas obligé de les utiliser.

C'est du vécu, la lenteur de Python peut devenir problématique. Même mettre à jour un TreeView GTK+ (contenant environ une centaine d'items) à partir de données provenant d'un backend C peut devenir
lent. Peut-être que les bindings GTK+ pour Python sont mal codés, je ne sais pas ce que ça aurait donné en Qt mais je suspecte tout de même Python.

Dans l'exemple que je donnais dans mon journal, il ne serait pas envisageable d'écrire la partie client bittorent en Python, ce serait trop lent. Alors que si on opte pour Java, il est possible de tout écrire en Java sans se casser la tête.

Il me semble qu'il avait été rapporté ici le cas du clavier virtuel d'Ubuntu qui était ridiculement lent et consommait énormément de mémoire au rapport de sa fonction.

De manière générale, dans une application graphique, la latence (c'est à dire le temps de réaction de l'interface à une action utilisateur) est importante. Une différence que quelques dizaines de millisecondes est perceptible (ça en rend pas l'interface non fonctionnelle mais laisse l'impression que le logiciel est lent). Alors même si on ne fait pas de calcul intensif, la lenteur de Python est problématique. Et c'est sans compter le packaging et le fait qu'il soit typé dynamiquement.

Oui, à l'école on m'a appris qu'il ne fallait ni utiliser des return multiples, ni des break et autres continue mais plutôt utiliser un booléen qu'on vérifie dans la condition de terminaison de la boucle.
J'ai arrêté de respecter cette règle après avoir vu des tonnes de break dans du code libre. Et en plus, subjectivement, je trouve que ça rend le code vraiment plus lisible d'utiliser des break.

J'ai le sentiment que ce n'est pas forcément faisable, ni souhaitable, de commenter la totalité de son code. Par commenter la totalité de son code j'entends associer un commentaire type "javadoc" à chaque fonction/méthode que l'on code. D'autant que dans certains cas la valeur ajoutée est vraiment très faible. Quelle est l'utilité réelle de commentaires comme les suivants :

/** Computes the threshold based on the red component
  * on the pixel with the highest red component in
  * the picture
  *
  * @param maxRedValue
  *     The red component of the pixel with the highest red component
  * @return the computed threshold
  */
double computeThreshold(int maxRedValue) {
   ...
}

/**
  * Get the user ID
  *
  * @return the user ID
  */
int getID() {
   ...
}

Mieux vaut dépenser son temps à bien penser l'architecture de son application/refactoriser si nécessaire plutôt que de le perdre à écrire ce genre de commentaires. Un document expliquant l'architecture de l'application/la manière dont elle a été conçue et pensée sera bien plus utile à quelqu'un voulant la modifier que ce type de commentaires.

La situation est évidemment différent quand il s'agit d'API publiques. Dans ce cas, évidemment tout doit être précisément documenté sinon elles sont inutilisables et donc inutiles.

Il faut bien garder à l'esprit qu'écrire des bons commentaires pour son code, c'est pas juste une bonne pratique, ça prend beaucoup, beaucoup de temps. D'autant plus qu'il faut maintenir les commentaires avec le code sinon ils font plus de mal que de bien. Je crois donc qu'on peut se passer de commentaires dans les classes utilisées en interne.

J'ai eu l'occasion de mettre les mains dans le code d'Hadoop et apparemment, c'est l'approche qu'ils ont choisi. Les classes utilisés en interne ne sont pas commentées (si ce n'est de petits commentaires pour indiquer des choses pas évidentes au premier coup d'œil). Les API publiques sont par contre parfaitement documentées.

Est-ce que tu prévois d'ajouter le support de MultiDeskOS dans ton logiciel dans un futur proche ?
Non, parce que c'est l'OS que j'utilise et c'est vrai que cette fonctionnalité manque aussi sous cet OS.

Non, désolé mais je ne trouve pas l'article très bon (je dirais même qu'il est carrément mauvais et que c'est de la masturbation intellectuelle).

L'auteur a rédigé un article plus de 10 paragraphes (autrement dit, très long) pour nous expliquer qu'on peut coder une backdoor en 10 lignes de bash, inutile d'épiloguer là-dessus. Je veux dire, c'est complètement trivial, n'importe quel étudiant en deuxième année d'informatique sait faire ça en Bash, Perl, C ou que sait je. Hein, il s'agit juste d'établir une connection TCP/IP et de piper ça dans le shell. Je me propose de battre l'auteur : je peux réaliser la même chose en une ligne (une ligne, t'as vu comme je suis un grand hacker) de socat.

Il présente ça comme une attaque ou une technique d'exploitation avancée alors qu'il a juste codé une backdoor complètement triviale. Et par pitié, qu'on vienne pas me dire que la technique d'inverser la connexion (la machine exploitée est cliente) est originale. Éventuellement, la remarque que les NIDS est intéressante, il y aurait du progrès à faire dans ce domaine car il ne parait pas impossible de détecter ce genre de connexion suspecte. Par exemple, on pourrait imaginer des règles détectant qu'une connexion contient des envoi de commande shells et des réponses ensuite (ce qui permettrait de discriminer par rapport au cas de l'adminsys faisant une recherche google).

Chez online, y'a également des petites dédibox (gamme "perso") à 11.95€/mois TTC pour 500Go et 17,93€/mois TTC pour 1To [1]. Au niveau processeur, c'est un petit via à 1,6Ghz avec 2Go de RAM. Je fais des backups là dessus en utilisant duplicity et via ssh, ça me suffit et c'est relativement peut contraignant.

[1] Online - Gamme perso

il faudrait que le dimanche soit payé double parce que c'est vrai que le dimanche c'est spécial

C'est bien là tout l’enjeu des débats actuels. Si le travail le dimanche se généralise, ce jour cessera progressivement d'être un jour spécial et la rémunération majorée sera remise en cause. Je vois bien les tenants du travail le dimanche revenir vers nous dans 5 ans, une fois que cette pratique ce sera généralisée, pour remettre en cause la majoration salariale.

Il parait que certaines personnes sont "volontaires" pour travailler le dimanche. Ah bon ? Moi je crois que ce que les gens veulent, c'est surtout la majoration salariale, mais ne rêvons pas, elle va disparaître.

C'est ce que dit Gérard Filoche sur Slate.

Cette dernière solution que tu proposes me parait plus raisonnable (i.e. y'a plus de chances qu'elle fonctionne de manière à peut près fiable). Drdb sera adapté pour faire un "RAID1 réseau" entre tes deux clés USB sur deux rapsberry différents.

En plus drdb sera surement beaucoup plus léger que Ceph.

Je peux confirmer, j'ai essayé quasiment la même chose : lancer l'outil de management (je voulais juste démarrer une machine virtuelle) de virtualbox sur un machine ayant une connexion avec un upload de 5Mbit/s (donc qui devrait quand même être suffisant pour juste faire du bureau à distance). J'ai jamais réussi à avoir un affichage complet de la fenêtre (je crois avoir attendu au moins deux minutes…).

Et puis j'ai découvert php-virtualbox… (Oui, je sors du sujet mais ça pourra peut-être t'être utile).

On estime qu'un expert C nécessite un bon paquets d'années d'expérience pour y parvenir à ce stade. Le C++ est bien plus vaste et avec bien plus de possibilités. Cela rend le langage riche et puissant mais très tortueux (surtout que sa conception est étrange) et rallonge la durée d'apprentissage.

Bon, on est déjà descendu d'un cran (une vie entière -> durée d'apprentissage allongée). Je ne vais pas te contredire sur le fait que C++ est vaste et compliqué.

Honnêtement, a-t-on vraiment besoin de maîtriser un langage de fond en comble ? Ce qui compte c'est de le connaître suffisamment bien pour l'utiliser pour développer (ce qui nécessite tout de même de le maîtriser hein) et c'est totalement faisable pour du C++ (et oui, en quelques années, on peut largement devenir un bon, voir un très bon programmeur C++, à moins d'avoir le cerveau en ciment).

HDFS n'est pas un système de fichiers à usage général (general purpose filesystem en anglais) ce qui signifie qu'il n'est pas prévu pour servir de système de fichier de tous les jours (et surtout pas pour une base SQL) où on installe un OS, stocke ses documents etc. Il a été conçu uniquement pour fournir un bon débit en lecture/écriture à des applications lisant des fichiers très volumineux en mode batch (au hasard des applications MapReduce).

En pratique, ça se manifeste de la manière suivante :
- Un fichier consomme au moins un bloc dans HDFS. La taille par défaut est de 64Mo (et HDFS n'est pas conçu pour faire descendre cette limite très bas), ce qui fait qu'un fichier de config de 2Ko va te bouffer 64Mo.
- Les temps d'accès sont élevés.
- Pour assurer la fiabilité, HDFS utilise de la triple réplication par défaut. Donc tu n'auras qu'un tiers de ton espace total disponible. C'est certes configurable mais enfin…
- Il n'est pas possible de monter un système de fichier HDFS (il existe certes un driver fuse mais c'est loin d'être idéal pour les raisons expliquées ci dessus)
- Il a été conçu pour fonctionner sur des serveurs moyen de gamme avec une certaine quantité de RAM.

Comme tu t'en doutes sûrement, la solution la plus fiable est celle que tu emploies actuellement : laisser la base de données sur le NAS. N'importe quelle solution à base de raspberry sera beaucoup beaucoup moins fiable et performante (les performances en lecture des cartes SD sont général pourries, elles sont beaucoup moins fiables qu'un HDD etc.), mais je suppose que tu fais un peu ça pour t'amuser :-)

Il existe des systèmes de fichiers distribués (qui permettent donc de mutualiser l'espace de stockage de plusieurs machines) : Ceph (surement un des plus à la mode), Lustre, GlusterFS, et je pense que c'est ce qu'il faut que tu utilises. J'aurais tendance à te recommander Ceph. Par contre, je ne sais pas si il fait du RAID 5 (je pense qu'il fait sa cuisine en interne pour la réplication de données). Je sais pas trop si Ceph va bien se comporter sur des raspberry, parce que là encore c'est plutôt prévu pour tourner sur des grosses machines.

drdb n'est pas adapté dans ton cas, ça te fera l'équivalent d'un RAID 1 en réseau et non pas d'un RAID 5. Si tu veux vraiment faire un RAID 5 distribué (et sur un réseau ça va avoir des performances vraiment pourries, déjà que ça impacte les performances en local) à titre expérimental, tu peux jouer avec nbd (network block device) qui va te permettre d'accéder à des block device (par exemple une partition sur les cartes SD) distants. Il te restera plus qu'à faire ton RAID 5 dessus. Par contre, tu ne pourras accéder au RAID 5 que depuis un seul raspberry (les autres seront de bêtes esclaves).

Bref, je te conseille Ceph. Et bon hack :-)

la simplicité et l'élégance du C […]

Vraiment ? Le C simple et élégant ? Honnêtement, si t'amuses à faire de la POO en C, ça va être sacrément moche (rien que la syntaxe pour les pointeurs de fonction, mmh, ravissant et pas du tout error-prone). Tu me diras qu'on peut aussi éviter la POO (bah oui, c'est bien connu la POO c'est qu'une mode/ça a été inventé par les SSII pour faire du fric), mais je suis pas sur que ça t'amène à du code vraiment plus élégant. De manière plus générale, un langage avec des pointeurs et des mallocs, c'est un langage de bas niveau, et c'est rarement ce qui permet d'exprimer les algorithmes de manière élégante. On y gagne en performance par contre.

Quand au troll sur le fait qu'il faut une vie entière pour apprendre le C++, je ne sais même pas quoi répondre. C'est complètement exagéré. Certes c'est un langage compliqué, y'a des pièges un peu partout, mais enfin, on est quand même plusieurs milliers sur cette planète à l'utiliser pour faire des logiciels, c'est donc que c'est faisable.

Bof, de nos jours, C++ a aussi fait ses preuves, est souple et connu de la majorité de développeurs. Bon après ce n'est pas vraiment un langage simple (malheureusement), il y a beaucoup (trop ?) de fonctionnalités et constructions syntaxiques (je pense aux classes/fonctions amies, héritage privé etc.), et il y a pas mal de pièges du fait du mélange de la programmation orientée objet et de la gestion manuelle de la mémoire.

Ahma, si tu veux faire de la POO extensivement, tu as besoin de C++. C n'est pas vraiment adapté pour faire de la POO.

Honnêtement, je vois pas trop l'intérêt de faire de la pseudo-programmation orientée objet avec des pointeurs de fonction dans les structures, mais peut-être que quelqu'un pourra m'éclairer dans la suite des commentaires. Ça me semble être un détournement de l'outil utilisé (le langage C) pour faire des choses beaucoup plus faciles à faire avec un langage plus adapté (le langage C++). Encore, je peux concevoir que ça avait un intérêt à une époque où les compilateurs C++ étaient moins optimisés/moins disponibles que les compilateurs C.

Tu as précisé dans les commentaires que tu allais également programmer un GUI dans cette applications. Si tu utilises un framework C++ (au hasard Qt), j'aurais tendance à te conseiller de programmer également avec un style C++, ça te rendra la vie beaucoup plus facile. Si tu utilises un framework C (GTK+ ?), tu peux éventuellement rester en C, même si ça devrait bien s'utiliser en C++ aussi.

Mouais, un des avantages de C/C++, c'est d'avoir de bonnes performances. Et bien que Go soit un langage compilé, pour l'instant la performance est plus ou moins au niveau de Java (même si il y a de bonnes chances que l'occupation mémoire soit meilleure) [1] [2]. Et tant qu'à avoir la performance de Java, j'ai envie de dire autant faire du Java qui est un langage beaucoup plus répandu (donc avec plus de bibliothèques disponibles). Oups, j'ai marché plongé dedans. Beh, j'en ai jusqu'au genou. Et on est pas du tout vendredi.

Cela étant dit, j'ai lu que Go était très bien pour faire des applications réseau. Il contient notamment tout ce qu'il faut en standard pour faire des applications asynchrones et propose des choses sympathiques pour gérer la concurrence, ce qui est très utile quand on fait du réseau [3].

Pour revenir plus sur le sujet de ton commentaire, ça me fait toujours tiquer quand on conseille un truc nouveau qui serait la panacée pour remplacer un truc vieux qui deviendrait par conséquent obsolète. Les nouveaux langages même s'ils apportent des améliorations très agréables n'ont pas toujours autant fait leurs preuves que les vieux machins qui sont utilisés depuis des dizaines d'années par des milliers de personnes. Ça fait qu'on peut très bien être le premier à déterrer un bug dans le compilateur/le framework qu'on utilise, qu'on a moins de documentation, etc. Personnellement, il n'y a rien qui m'horripile plus que de passer mon temps à chercher de la doc parce que la doc officielle n'est pas complète (des fois carrément lire le code source pour pallier le manque de doc), contourner des bugs ou découvrir que le compilateur ne sait pas optimiser une partie particulière de mon code.

Dans le cas de Go, il commence à être relativement éprouvé (tu ne seras pas le premier à l'utiliser pour faire une appli réseau) mais la jeunesse relative du langage se ressent dans le manque d'optimisations du compilateur.

[1] SO - Performance of Google Go
[2] Loop Recognition in C++/Java/Go/Scala
[3] Go Tour - Concurrency

Sur mon NAS (un QNAP TS-119+), j'utilise une Debian avec OpenMediaVault qui est une distribution pour les NAS. Comme la distribution OpenMediaVault utilise une base Debian, il est possible d'installer le paquet OpenMediaVault sur une Debian déjà installée. Attention cependant, le paquet n'est pas juste une interface web, il amène tout un tas de dépendances avec lui (postfix, apache, proftpd, samba etc.).

L'interface est écrite en extjs/PHP et est de très bonne qualité. Elle permet de configurer les interfaces réseau, les partages, les différents services (SSH, FTP, samba, rsync) ainsi que monter les disques durs.

Le paquet n'est pas disponible pour Debian armel, j'avais du le recompiler. Je suppose que comme l'application est écrite en PHP, tu devrais pouvoir la porter assez facilement sous buildroot.
En tous cas, c'est parfait pour un NAS, mais pas forcément très léger ni bien intégré à buildroot.

Ah, c'était un oubli. Désolé pour le ton agressif de mon message, je pensais que c'était volontaire, d'où mon "coup de gueule".

Autant je trouve que parler de distribution GNU/Linux, ça peut avoir un sens (et encore…) mais le noyau GNU/Linux, ça ne veut vraiment pas dire grand chose. Linux n'est justement pas issu du projet GNU, à la différence de l'userland qui l'accompagne généralement dans les distributions courantes.

Rajouter GNU devant Linux sans réfléchir, c'est pour faire plus libriste ?

Bref dans ce cas. Tu va galérer, il te faut de la communication entre tes instance, une approche « asynchrone » au lieu des threads.
Tu peux essayer de t'amuser avec asio. Mais je te souhaite bonne chance, si c'est un projet perso ça peux être fun. En entreprise, utilise Erlang ou Python, l'un le supporte directement dans le langage, l'autre a des librairies très puissantes pour le faire.

Sérieusement… Qu'est-ce qu'il ne faut pas lire. boost::asio juste bien pour s'"amuser" dans "un projet perso" et pas adapté à une utilisation en entreprise ? Pour information, asio est utilisé dans le logiciel gérant les clusters Blue Gene/Q d'IBM. C'est un sacré projet perso, tu ne trouves pas ? Il y a aussi des tout petits projets libres comme la libtorrent et la libbitcoin qui s'appuient sur asio. Enfin, je te laisse consulter la liste des projets utilisant asio et c'est sans compter les dizaines de personnes qui l'utilisent quotidiennement dans un contexte propriétaire et fermé sans en faire la publicité.

Quant à ce tu racontes sur le fait qu'on a pas besoin d'avoir un langage performant pour écrire des serveurs parce qu'on peut faire passer à l'échelle l'architecture, scaler horizontalement comme on dit, c'est tellement à la mode, c'est juste n'importe quoi. Whaou, on peut faire du DNS round robin pour répartir la charge sur plusieurs serveurs. Bravo, mais on t'avait pas attendu pour ça. Dans le domaine du web, il y a un facteur 20 entre les frameworks les plus rapides et les frameworks les plus lents sur des tâches simples [1]. Administrer une ferme de 5 serveurs est beaucoup plus confortable qu'administrer une ferme de 100 serveurs. Quand ton architecture pour faire tourner ta jolie application twisted commence à nécessiter un adminsys à temps complet pour la faire tourner, tu réfléchis à la réécrire dans un autre langage. Hacker news est plein d'histoires de personnes en réécrivant leurs applications serveurs dans un langage compilé pour gagner en performance.

Oui, une application bien écrite en boost::asio scalera horizontalement aussi bien qu'une application écrite avec netty ou twisted. Oui, ce sera surement plus long à écrire, plus difficile à debugguer qu'une application Java ou Python. Mais ce sera aussi plus rapide, et tu auras un bien meilleur ratio performance/watt. Il y a un facteur 10 en moyenne en temps entre du Python et du C++ sur des tâches calculatoires. Rien que le fait qu'il existe une bonne douzaine de projets visant à accélérer le code Python montre bien qu'il y a parfois un problème de performance avec ce langage (qui par ailleurs offre une excellente expressivité). Bien sur ce serait génial d'avoir un langage aussi expressif que Python offrant les performances du C++, mais ça n'existe pas encore aujourd'hui.

Attention, je ne suis pas en train de dire que C++ est la panacée et qu'il faut toujours privilégier la solution la plus performante. Clairement si c'est pour une application web qui évolue tous les mois, vaut sûrement mieux l'écrire en Python. Si c'est le service/api web avec lequel ta start up fait du blé, peut-être que Java est la meilleure solution. Si tu veux écrire un système de stockage distribué performant devant tourner sur cluster, peut-être qu'il faut utiliser du C++. Parfois la performance est importante et le ratio performance/watt ou performance/euros est important.

[1] TechEmpower - Web Framework Benchmarks

Je répondais à cette phrase :

En tout cas le processeur utilisé dans leurs machines gère les instructions de virtualisation à la sauce Intel apparemment donc c'est plutôt bon signe.

de Sclarckone.

Et j'ai mis kvm (au sens kernel virtual machine) pour éviter de confondre avec Kerboard Video Mouse. Mais c'est vrai qu'au final la discussion n'est pas très claire.

Attention, les instructions de virtualisation du VIA Nano U2250 ne sont pas gérées par kvm (ni quoi que ce soit d'autres de ce que je me souviens). Apparemment, le jeux d'instruction serait particulier/buggé et les développeurs de kvm ont jugé que ce n'était pas nécessaire de passer du temps à ajouter le support de cette architecture étant donné la faible puissance de ces processeurs et le fait que l'architecture est vieillissante.

Voir : http://forum.online.net/index.php?/topic/3153-vt-sur-dedibox-sc-via-nano-u2250/

ACM et USENIX c'est des petits trucs ?
Et honnêtement on s'en fout un peu de savoir si le deux colonnes c'est joli ou pas. Ce qui est importe, c'est ce qui est écrit dans le papier. Après on respecte les règles de la conf/du journal et basta. Ici comme y'en a pas, je vois pas le besoin qu'il y a d'aller finasser là dessus étant donné que l'auteur lui-même a indiqué que son papier était plutôt à l'état de brouillon.