Yakulu a écrit 143 commentaires

L'ARM fait donc 35% de plus pour 67% de prix en plus, sachant qu'on a 2x moins de RAM (donc si on a besoin de RAM, hic encore plus cher).

Oui et comme tu le dis, le Via Nano U2250, qui consomme 8W, est tout sauf un foudre de guerre. CPUBenchmark publie un grand test de processeurs x86, ça permet de le situer par rapport à d'autres. La différence vient surtout du nombre de cœurs, mais ici pour une consommation semblable (10W pour le D2700). En somme, le processeur ARM employé chez Online ne semble pas très efficace mais peut tenir la comparaison face à des serveurs dotés d'Atom (du moins lorsque ceux-ci n'ont qu'un seul cœur).

Restent que les autres défauts relevés rendent l'offre, pour moi, moyennement attractive.

À vrai dire, cela ne me surprendrait pas tant que ça. Je pense qu'il faut aussi se méfier de ces bench sur des VPS, car selon les technologies sous-jacentes, il est possible qu'il y ait une sur-allocation de CPU - burst au delà des ressources garanties - si l'ensemble du serveur hôte n'est pas trop sollicité. Je crains que la seule comparaison valable serait face à un dédié Atom dans la même gamme de prix.

Il y a deux choses que je trouve intéressantes dans l'offre d'Online :

1. La possibilité d'ajouter de l'espace ou des disques SSD à la volée.
2. L'usage de Docker et d'images générées par la communauté. L'installation en un clic d'applications trop gourmandes ou complexes à mettre en œuvre pour du mutualisé pourrait être un cas d'usage (sans nécessité d'administrer la machine, si l'image est bien faire et reconstruite chaque jour par Online).

En revanche :

• Il s'agit d'un serveur physique, sans redondance des données (contrairement à la plupart des offres VPS). Mais à 12€/mois, on peut faire un RAID1 logiciel.
• Comme dit plus haut, le disque n'est pas en local mais accédé en réseau.
• C'est de l'ARM, donc un peu plus risqué : un support moins pérenne du SoC en question, des applications moins testées sur cette architecture (donc anomalies, optimisations en retrait ?)…

Ca consomme moins qu'Intel à performance identique? A quel prix? (identique ou pas?)

Bon alors on va me reprocher avec raison la méthodologie, l'aspect micro-bench etc… mais j'ai vu passé quelques comparatifs ARM/x86 chez Phoronix. Par exemple dans le cas du Tegra K1 1 & 2. Le K1 semble compétitif face à des Atom (ici âgés mais dont les performances semblent avoir peu augmenté au fil des années, sauf à ajouter des cœurs et à davantage consommer) ou des APU AMD d'entrée de gamme pour une consommation plus faible.

Le K1 n'est cela dit sans doute pas dans la même gamme que les processeurs utilisés par Free dans son offre. En revanche, pour cette puce-là, il y a un UnixBench qui a été fait pendant la phase bêta.

J'ai déjà utilisé du FreeBSD/ZFS sans ECC, mais sur des machines non critiques et après avoir testé la RAM.
C'est un gros débat dont tu trouveras des pages de discussions sur les forums de FreeNAS, PCBSD etc

Pour deux points de vue un peu détaillés et assez récents :

• Please Use ZFS With ECC Memory
• Why I Chose Non-ECC RAM for my FreeNAS

Ce que j'en ai retenu des mois plus tard : ne pas prendre de l'ECC est un risque, que l'on court ou non (et qui peut se solder par des corruptions de données plus ou moins importantes), risque minimisé en s'assurant que sa RAM non-ECC se comporte bien aux tests de type memtest.

J'ai plusieurs serveurs MiniDLNA qui tournent sur mes machines et tout fonctionne à merveille, quasiment sans aucune configuration (minidlna.conf de base, juste adapté aux dossiers qui m'intéressent), que ce soit sous Arch ou Debian (stable comme testing).

Déjà, qu'as tu dans les journaux de minidlna (normalement /var/log/minidlna.log )?
J'ai eu à faire à deux petites erreurs sur une Debian Stable :

1. Pas d'accès en exécution et lecture aux dossiers contenant les médias pour l'utilisateur minidlna. Cela ne semble pas être ton cas puisque en local tu as bien accès à ta bibliothèque.
2. L'erreur Inotify max_user_watches [8192] is low or close to the number of used watches [45] and I do not have permission to increase this limit. . Dans ce cas, j'ai du adapter le max_users_watches avec sysctl fs.inotify.max_user_watches=16384 temporairement ou en modifiant sysctl.conf pour rendre le changement moins temporaire.

Pour le pare-feu, ufw status te renvoie bien quelque chose comme inactive ?

En espérant que ça puisse t'aider.

Oui tu peux en effet utiliser hstore ou JSON sur PostgreSQL. L'intérêt de Couch est surtout à chercher du côté de sa réplication des données et de sa gestion des pièces jointes. Pour les performances, voir le commentaire ci-dessous, pour la validation sur mesure d'un modèle, c'est possible dans la base et cela se fait par le biais une fonction javascript.

Si et j'y verrais quelques avantages :

• tout est document, donc semble assez proche de la notion autour de laquelle s'articule pod;
• il est possible d'attacher des pièces jointes aux documents, ce qui reste assez efficace sauf pour des fichiers de centaines de Mo ou supérieurs;
• enfin, cela permettrait de profiter de la synchronisation maître à maître offerte par CouchDb, vers d'autres noeuds Couch mais aussi, pourquoi pas, PouchDb, TouchDb et autres cousins des documents ainsi que des pièces jointes.

En revanche, si CouchDb a un concept de révision employé à chaque nouvelle version de document, il ne faut pas l'utiliser pour l'historique, car les anciennes révisions n'apparaissent pas dans les réplicats ni ne sont conservées après compactage de la base.

Sinon il y a RSSBridge, logiciel libre qui fait Twitter, Youtube, Instagram, le Bon Coin etc. Installable chez soi, ou utilisable en ligne comme service.

Seront diffusées les diapositives et nous tenterons un enregistrement audio (mais nous ne sommes pas vraiment équipés pour). Le tout sera sur la page de l'ALDIL dès que rendu disponible.

Si je suis le dépôt archlinuxfr, je ne vois que i686 et x86_64 de supporté. Or tu as du installer une version ARM de Archlinux pour ta Raspberry. Il faudrait donc plutôt sur ton dépôt soit l'un de ceux-là (le fichier par défaut est /etc/pacman.d/mirrorlist).

Certains pensent à un canary, une manière d'informer ses utilisateurs que la NSA (ou autre) a imposé de compromettre le code, sans rentrer dans l'illégalité en l'exprimant directement. Mais le fait de promouvoir des solutions fermées sur le site met un peu en doute cette théorie…

Tu peux essayer avec os-release, par exemple un cat /etc/os-release.

Oui, et encore plus récemment, Github a annoncé Atom (partiellement libre, et si l'on en croit la FAQ ils ne sont pas prêts à ouvrir le coeur..).

Il y a également LightTable, un éditeur qui essaie d'apporter des concepts neufs et a été pleinement libéré.

Personnellement j'ai juste essayé Light Table mais il y a longtemps et vu les vidéos concernant Brackets et Atom. Pas d'avis à donner donc ;)

Je ne peux pas répondre pour l'auteur. En revanche il me semble que SàT est antérieur à MOVIM : il y a une 0.0.1 qui date de mai 2009 contre novembre 2010 pour le premier commit chez MOVIM. Au delà de cela, je pense que si les deux utilisent XMPP, les technologies sont assez différentes (Python, multiclients d'un côté, PHP et Web de l'autre) et les fonctionnalités développées et imaginées sans doute également.

Et pourtant, c'est bien soutenu par la fondation (1, 2).

Il y a également Qt-Apps.org qui contient une longue liste d'applications Qt. On y retrouve d'ailleurs la plupart de celles listées par Razor.

Au sujet de la performance : la réponse de Sencha (même chose en vidéo), que l'on sait fortement impliqué dans les technologies JavaScript/HTML, essaie d'argumenter le contraire.

En résumé, selon eux :

• la performance sur le Web n'est que partiellement liée à JavaScript. Il y a les tout un tas de rendus, les manipulations du DOM, les éléments qui profitent ou non de l'accélération GPU…
• environ la moitié des améliorations de performance JavaScript seraient dûes, ces dernières années, au matériel. L'autre à celle des moteurs JS.
• le pic de performance global ne serait pas atteint car il y a, pour chaque navigateur, des zones conséquentes qui peuvent être améliorées et l'ont été récemment (par exemple le rendu du canvas).
• les ramasseurs de miette ont fait de gros progrès ces dernières années, et employer des techniques comme le recyclage d'éléments du DOM aiderait fortement à augmenter la fluidité des applications mobile

À propos du pic de performance pour JavaScript seul, Are We Fast Yet, de Mozilla, qui est lui aussi un acteur très impliqué, semble montrer que sur l'année dernière, tant leur moteur que v8 de Google continuent de s'améliorer (de l'ordre de 30% en un an selon le test et le moteur, ce qui n'est pas négligeable).

Elle est basée sur Slackware

Je crois que les premières versions l'ont été mais ça fait un bye qu'elle est indépendante. Je n'ai en tout cas pas trouvé de trace de Slackware sur le site officiel. Wikipedia mentionne l'ancien lien entre Slack et Furgalware.

Voir aussi du côté des processeurs AMD, qui sont en général plus généreux sur les instructions dont la virtualisation.
J'ai un netbook MSI U230 acheté autour de 300€ il y a environ trois ans dont le processeur Neo MV40 est peu efficace (comme les Atom simple coeur) mais qui offre la virtualisation. Je n'ai eu aucun soucis pour la carte graphique (ni aucun autre composant d'ailleurs) avec les pilotes libres, mais j'utilise peu la 3D.

En revanche, il pourrait être difficile de trouver une autonomie de 6h dans le budget avec ce type de processeur. (LDLC propose des netbooks à base de Celeron pour moins de 400€ rentrant dans les critères, sauf l'autonomie.)

Une liste est disponible sur le Go Wiki, dont des bindings GTK en développement actif.

Tout ce qui suit est mon avis, subjectif et pas forcément le meilleur. D'autant que je ne fais plus énormément de Python ces temps-ci.

si un jour vous passez à une version en ligne de l'outil (quelques affichages par exemple), quel outil utilisez-vous ?

Bottle.py est un excellent micro framework Web.

utilisez-vous les mêmes classes/méthodes de la couche métier de l'application pour votre application web ?

Oui, à mon avis l'interaction Web n'est pas vraiment liée au code objet/modèle de données.
(d'ailleurs selon la complexité de ton application, dans la catégorie léger, peewee est un sympathique ORM).

question documentation, plutôt PyDoc ou asciidoc (ou autre?)

Le standard, il me semble, est plutôt Sphinx.

même question pour les tests unitaires ?

Le module inclus est utilisable. Sinon, personnellement j'employais pytest, dont je préférais l'API.

En théorie, tous les modules cités sont compatibles Python 2 et 3.
Bon courage.

Vidéo intéressante qui me semble une assez bonne introduction sur le sujet.
J'en profite pour (re)mettre un coup de projecteur sur Retroshare.

Ce logiciel libre (C++/Qt) dispose de paquets pour la plupart de nos distributions, d'un port FreeBSD et de binaires Windows, OS X. Des clients NCurses, Web et Android sont en cours de développement. Une version nogui existe mais je crains qu'elle soit encore un peu limitée.

Il s'agit d'une plateforme de communication décentralisée où tout repose sur son réseau d'amis. Ceux-ci sont ajoutés via leurs clés GPG justement. Vous pouvez permettre le routage anonyme et la découverte d'amis d'amis, jusqu'à 7 niveaux. Un tableau distribué global peut être utilisé afin de retrouver plus facilement ses amis lors d'une nouvelle connexion. Retroshare est capable de traverser un réseau NATé via UPnP. Toutes les données échangées sont chiffrées en utilisant les clés GPG il me semble mais de bout en bout par le biais de tunnels OpenSSL. L'application repose sur un certain nombre de technologies pair à pair éprouvées, comme par exemple la DHT de Kademlia, le routage anonyme de Turtle F2F. Il existe un blog technique pour expliquer bien mieux que je ne puisse le faire tous ces aspects.

Le logiciel propose :

• l'ajout d'amis, la certification et la recommandation
• le classement des contacts dans un à plusieurs groupes
• la discussion instantanée à deux ou davantage
• la création de salons de discussion privés ou publics
• l'envoi de messages (type mail mais nécessitant un contact entre les expéditeurs et destinataires)
• le partage, la recherche de fichiers de tout type, et leur téléchargement multisources (via leur hash et des tunnels anonymes si vous n'êtes pas en contact direct avec la personne possédant le fichier) avec la capacité de reprendre un chargement partiellement effectué
• des canaux de diffusion privés ou publics, qui servent à publier, sans commentaires possibles (contenus anonymes ou signés)
• des forums de discussion (type newsgroup) publics ou privés, dont les messages peuvent être anonymes ou signés
• l'abonnement aux canaux et forums désirés et le suivi des nouveautés qui y ont été postées
• la création et la prise de charge de liens retroshare:// pour faciliter l'ajout de contacts, le téléchargement de fichiers…

Des plugins existent, dont l'un des plus populaires est celui autorisant la VoIP et permettant une discussion à deux.

Ce qui me parait intéressant dans le logiciel, que je connais encore mal car je ne le teste que depuis quelques jours, c'est sa relative facilité de prise en main. Il permet à certains d'envisager d'y amener des amis non technophiles, un bout de famille etc. Bien sûr, condition importante pour une adoption plus large, il est intégralement traduit en plusieurs langues dont celle de Molière.

L'outil n'est pas parfait, loin de là. Mais les développeurs ont l'air assez ouverts et preneurs de suggestions ou coups de main.

À ce sujet, hier, le même site d'informations a publié :

• l'avis de l'Hadopi
• leur analyse
• une interview de Jean-Baptiste Kempf, de Videolan

mais dans quelle mesure serait-il capable de prendre du javascript tout lent et de le convertir en asm.js et le tout à la volé

Comme répondu ailleurs, ce n'est pas possible en l'état.

En revanche, il est possible d'utiliser un langage intermédiaire comme LLJS. Des travaux sont en cours pour permettre une compilation vers asm.js.

Voir aussi ce billet assez complet sur asm.js où il est en partie question de LLJS. Je cite :

LLJS aims for a middle ground — like a C to asm.js’s assembly — that’s easier to write than raw asm.js but has more predictable performance than regular JS. But unlike C, it still has smooth interoperability with regular JS. That way you can write most of your app in dynamic, flexible JS, and focus on only writing the hottest parts of your code in LLJS.

a savoir universel, sandbox, oriente source et platform agnostic

Je ne suis pas un expert mais je pense que Lua aurait été un bon candidat, non ?