16ar

J’hallucine qu’il manque un Hello World en Go (golang pour les moteurs de recherche) package main func main() { println("Hello World") }

J’ai développé dans pas mal de langages (java, android, C#, python, bash, …) avant de rester sur le C++ pendant un moment. Principalement pour le fait que c’était LE langage pour créer des jeux vidéos (c’était avant Unity) et aussi il était cross platform (avec beaucoup de travail pour le rendre cross-platform) et il avait des performances (très) bonnes. J’ai adoré apprendre plein de choses avec ce langage, mais le gros probème, cette amélioration de perf, ça venait avec une complexité de fou. Déjà, gérer sa mémoire avec ses pointeurs, tout de suite tu rajoutes une charge mentale sur ton design. Et même en réfléchissant bien, il suffisait que tu oubliais un cas moisi, et hop tu te retrouvais avec de la mémoire non libérée, même avec des std::shared_ptr, un double delete sur une zone mémoire. Parce que, que tu le veuilles ou non, tu arriveras à un moment sur un programme pas écrit par toi, trop gros pour comprendre exactement où les choses sont allouées/désallouées, si c’est sur le même thread ou non, etc. Et là, tu commences à perdre des cheveux. Oui, tu peux être optimisé, mais ça vient à un tel coût en développement et en maintenance pour bien le faire qu’après, tu abandonnes, perd la motivation, et fait de la merde, quand ce n’est pas ton boss direct qui te dit qu’on n’a pas le temps pour faire ça. Depuis, j’ai découvert le Go, et ça a de bonne performances mais ça te facilite énormément de choses sur la gestion mémoire (il y a un bon garbage collector) et le multi threading (il possède des concepts natifs permettant de faire de la programmation concurrente beaucoup plus facilement que beaucoup de langages). Go est souvent utilisé pour remplacer des composants plus gourmands dans des startups qui grossissent. La startup a commencé à avoir des millions d’utilisateurs, et leur (micro)service en PHP, Java, Python, Ruby ne tient plus la charge ou coûte trop cher en serveur cloud, et du coup ils passent au Go pour rendre ça plus gérable. Mais ce qui est encore plus important que les performances sur le Go, c’est que les créateurs du langage l’ont rendu puissant côté machine, mais ont essayé de le garder simple côté humain. Ils promeuvent beaucoup la lisibilité ou la maintenabilité d’un programme. Du coup, par défaut, le compilateur Go va t’optimiser un max de trucs, pour pas que tu aies à le faire (c’est aussi le cas de compilateurs comme GCC et CLANG en passant, ça optimise à fond). Mais aussi, ils te fournissent un max d’outils pour profiler en live ton application sans impacter trop les perfs (je crois que pprof doit bouffer 1% de perf quand il est en profiling actif). Du coup, la mantra, c’est Fait le marcher (compile + run ok), fait le bien (refactor, redesign), rend le rapide (optimise) Et franchement, ça marche bien. Tu fais un code minimal qui marche, tu le redesignes pour qu’il soit lisible/compréhensible (par qqn d’autres, ou toi plus tard :p) et après, tu mesures/benchmark/profile et tu optimises là où les outils te disent qu’il y a un gain possible à prendre. Je ne compte plus le nombre de fois où j’ai commencé à optimiser un endroit en étant persuadé que c’était là le problème, et en fait, pas du tout, avec les optim compilateurs, le goulot d’étranglement était ailleurs. Avec Go, j’optimise que quand j’en ai besoin et que si ça ne se fait pas avec un coût trop gros sur la maintenance. Mais clairement, si je pouvais remplacer par Go + du graphisme natif (opengl ou autre) toutes ces applis électrons qui bouffent 300 Mo min de ram + CPU juste pour afficher un chat, ça ferait plaisir à mon laptop avec ses 8Go de ram.

Toutes les cryptomonnaies ne fonctionnent pas sur la même technologie blockchain sous-jacente. Du coup, oui, toute ne demande pas de miner avec carte graphique ou mineur ASIC dédié. G1, je connais pas, mais en regardant, ça se base sur la blockchain duniter et ça génère des token/coin régulièrement sans minage. Maintenant, économiquement parlant, je ne sais pas ce que ça vaut, si ça peut tenir une utilisation massive et que ça ne va pas dévaluer le coin directement.

Perso, j’attends beaucoup de PostmarketOS. OS mobile de 10Mo… OK. Et surtout, tu peux refaire du développement d’app Linux qui fonctionnent sur un linux classique. Pas avec 25 surcouches d’API trop liée à une boîte. Je suis pour apprendre de ces API et les porter sur du linux de base. Il y avait déjà des tentatives sur Gnome et KDE (pour KDE PIM, etc), mais au final, très peu utilisé. Il faudrait quelque chose de propre et universel. La XDG n’a pas des ébauches d’API dans ce genre ?

TL;DR : https://github.com/dolanor/dsuite J’avais YunoHost pendant un moment sur mon serveur, dans un conteneur LXC. La mise à jour était difficile, elle ne fonctionnait pas. J’ai découvert Docker à cette période également, et après quelques années j’ai remplacé des services de YunoHost par plusieurs containers. J’en ai fait un docker-compose et ça permet d’avoir: - LDAP pour centraliser les comptes, mot de passe : un compte + un mot de passe peux te donner accès à plusieurs services - serveur email : pour ne plus avoir tout sur gmail - calendrier synchronisable sur mobile, liste de contact, fichiers synchro à la dropbox/google drive (nextcloud) - un registre privé docker pour publier ses propres images - un système d’intégration continue - un système d’hébergement de source à la github

Je viens de voir les tarifs de mega, et c’est fou. Google cloud storage, 20To : 414$ AWS S3, 20To: 480$ GoogleOne (drive), 20To: 199$ Mega.nz, 16To: 30$ Maintenant, est-ce que Mega est fiable, aucune idée. Vu le prix, j’ai presque peur. Mais bon, sait-on jamais. En mode nouveau venu et nouvelle techno, il y a Storj qui chiffre tes données, puis les envoie sur des machines en peer2peer qui servent de datacenter décentralisé (je suis hébergeur par ce biais, et je suis rémunéré via crypto monnai (STORJ)). Et tu peux utiliser un protocole style S3 pour envoyer/récupérer le bordel. https://documentation.tardigrade.io/pricing

Ma patience envers les GAFAM est enfin épuisée, et j’étais en train de me lamenter de ce qui restait en mobile + free avec un collègue, et notamment de la disparition d’ubuntu touch et de la double expérience mobile + desktop juste en pluggant un dock/écran. Mais entre temps, je suis tombé sur :  https://tuxphones.com/ et https://postmarketos.org/ Du coup, ça m’a redonné foi. Je pense que je vais retenter l’aventure (j’avais tenté Qtopia à l’époque, pas que des bons souvenirs :p)

Hello à tous ! Ça fait un bail que je n'ai plus traîné par ici, mais c'est bien là que j'ai eu mes débuts sur linux… En tout cas, je me suis senti retourner en 2004 : j'ai acquis un nouveau PC (Dell XPS 13 9350). Autant les anciennes version avait encore le support de l'équipe de Dell Sputnik pour avoir ubuntu dessus, autant ils sont en retard sur ce modèle et il utilise du matos dernière génération. Du coup, j'ai du me recompiler un kernel à la main, chopper des firmware sur le git de linux-firmware, sinon, pas de wifi… Et comme y'a pas de port ethernet sur ces ultra portables, c'était un peu pas fun de faire du tethering usb avec mon mobile. Du coup, j'en ai profité pour essayer de pousser plus loin ma config et faire enfin ma config de rêve. Mais fallait se baser sur gentoo pour ça : https://wiki.gentoo.org/wiki/Sakaki's_EFI_Install_Guide. Pas encore fini, la partie qui bloque c'est de booter directement le kernel depuis l'EFI, histoire de pouvoir avoir un kernel signé sur une microSD, et le reste du disque dur sur LVM chiffré par LUKS. (même boot et swap). Du coup, si des gens ont des expériences à booter sur de l'EFI avec un kernel avec un EFIStub, je suis preneur. Autrement, je me suis foutu à fond sur Go/golang et je m'éclate. Je découvre des projets intéressants tous les jours et c'est difficile de se concentrer. Je regarde pas mal http://camlistore.orget https://github.com/ipfs/go-ipfs . Sinon je m'amuse avec un petit cluster de rapsberry pi grâce à http://blog.hypriot.compour balancer des container dockers à travers le "swarm". C'est vraiment sympa. Et docker a rendu mon serveur plus propre, tout tourne dessus sauf un vieux container LXC faisant tourner mon YunoHost. Du coup, plus de librairies de tests installées à l'arrache dans /usr/local, ou autre. Tout ce que je teste va dans un docker. Et un fois que c'est fini, c'est facile de nettoyer, même si on avait tout oublié depuis. C'est quoi vos projets/idées en ce moment ?

Pareil pour moi. Je vais bien me tenter un razor-qt, lxde et xfce avec ça. À moi les low riders !

Sinon, y'a http://www.thedarkmod.com/ :) (Et c'est en standalone maintenant, plus besoin de doom3. Ils ont fait un boulot de fou) En tout cas, grâce à Steam, pas mal de bons jeux débarque sous nux, et j'en suis très content

Ah oui, screen c'est indispensable pour moi. Vraiment trop bien pour lancer des processus long et malgré tout avoir la main sur le bousin.

Pas mal. Essaye euromillion aussi, t'amélioreras ton potentiel de chance ! Pour ma part, je bosse encore sur une redhat, mais attention, la version 6, on approche des kernel 3.x !! Ouhhhhhhh ! Ah oui, on fait du calcul distribué sur une grille. Ces nouvelles machines fonctionnaient moins rapidement que nos anciennes (sachant que les anciennes étaient bien chargé en CPU/users). Les admins (on n'a pas les droits root) qui ont installé les nouvelle machines avaient installé cpufreq… Résultat, en le désactivant, 40% de perf en plus. Vous faites du calcule en grille sur un modèle SOA? ou c'est juste qu'ils avaient merdé la configuration du gouverneur? Dans le premier cas, les petites opérations type SOA ne déclenchent pas assez de charge cpu pour que le gouverneur (ondemand, mais surtout conservative) ne détecte le besoin de monter la fréquence, du coup les temps de traitement sont mauvais. Maintenant, s'ils ont mis powersave, là il n'y a pas de mystère. En fait, on est en train de développer la grille depuis 0, donc ça ne tourne pas 24/24. Et donc c'est que quand on lançait nos tests qu'on mesurait les perfs. Mais le pourcentage de machine à 100% sur la journée est faible, du coup c'est peut-être la raison que le governor ne gérait pas bien. Mais bon, à terme ça va être une grille de calcul, et surtout nos serveurs sont censé représenter ce à quoi on doit s'attendre niveau perf en prod. La moindre ms compte pour savoir si on continue le projet ou si le gain n'est pas assez suffisant pour dépenser plus dans le projet. Pas mal. Essaye euromillion aussi, t'amélioreras ton potentiel de chance ! Pour ma part, je bosse encore sur une redhat, mais attention, la version 6, on approche des kernel 3.x !! Ouhhhhhhh ! Ah oui, on fait du calcul distribué sur une grille. Ces nouvelles machines fonctionnaient moins rapidement que nos anciennes (sachant que les anciennes étaient bien chargé en CPU/users). Les admins (on n'a pas les droits root) qui ont installé les nouvelle machines avaient installé cpufreq… Résultat, en le désactivant, 40% de perf en plus. Vous faites du calcule en grille sur un modèle SOA? ou c'est juste qu'ils avaient merdé la configuration du gouverneur? Dans le premier cas, les petites opérations type SOA ne déclenchent pas assez de charge cpu pour que le gouverneur (ondemand, mais surtout conservative) ne détecte le besoin de monter la fréquence, du coup les temps de traitement sont mauvais. Maintenant, s'ils ont mis powersave, là il n'y a pas de mystère. Wait, ça m'intéresse vos histoires ! Au labo, on a tous nos noeuds sous scientific linux (donc un dérivé de RH bien vieillot), comment on vire toutes les merdes d'économie d'énergie que je suis un gros pollueur qui s'en fout ? Je ne pourrais pas t'en dire plus, les joies de l'informatique moderne font qu'on a accès à rien, tout est sous-traité par des gens à Singapour. (Même si les machines sont en IdF…). Donc à vrai dire, je ne sais pas ce qu'ils ont fait. Sûrement viré le module cpufreq au démarrage, ou mieux configuré le governor pour les perfs ? ha ? en virant cpufreq on a du gain ? on est aussi sous redhat et j'ai pas l'impression de soucis (dans un sens, il est toujours au max cpu avec ce que je fais ^^' ) pour le bepo, un pote m'en a parlé, ca me tenterai bien, mais m'en faudrai au taf et a la maison... galere :/ Comme dit, j'ai commencé light, avec 1 seul typematrix à la maison, pour m'entraîner un peu. À vrai dire, tu peux même commencer le bépo sans typematrix, après tout, c'est juste un layout. Mais le typematrix est tellement bien pensé que tu te tords moins les doigts que sur un clavier classique. Ça devient un tel luxe que tu en veux un deuxième. Au début, donc, j'ai commencé avec typematrix/bépo à la maison, et clavier normal/azerty au boulot. Au bout de 2 semaines, je suis passé a normal/bépo au boulot. Et au bout de 2 semaines, j'en avais marre du clavier normal, même en bépo. Se tapper des mauvaises conceptions de placements de touches à cause de raisons mécanique datant de 1850, ça va 2 minutes. (tous les claviers ont la ligne azerty décalée avec la ligne qsdfg, tout ça pour que les barres métalliques actionnant les marteaux de machines à écrire ne se frottent pas l'une l'autre… ). Du coup je me suis acheté mon 2ème typematrix

Pas mal. Essaye euromillion aussi, t'amélioreras ton potentiel de chance ! Pour ma part, je bosse encore sur une redhat, mais attention, la version 6, on approche des kernel 3.x !! Ouhhhhhhh ! Ah oui, on fait du calcul distribué sur une grille. Ces nouvelles machines fonctionnaient moins rapidement que nos anciennes (sachant que les anciennes étaient bien chargé en CPU/users). Les admins (on n'a pas les droits root) qui ont installé les nouvelle machines avaient installé cpufreq… Résultat, en le désactivant, 40% de perf en plus. Et sinon, je me suis foutu au bépo avec un typematrix 2030, et du coup j'en ai 1 au boulot, et 1 chez moi. C'est vraiment génial une fois qu'on dépasse une certaine vitesse de frappe (je dirais à partir de 20 mpm, donc environ 2/3 semaines). Et sinon je suis d'assez près le projet yunohost, ça me semble pas mal.

Tu as tout sur le SVN... Mais j'ai aussi cherché longtemps ... http://websvn.kde.org/trunk/KDE/kdebase/wo...ace/wallpapers/

J'ai envie de dire que la différence est assez grande ! Mais bon, pas aussi grande que la difference entre la 4.0 et la 4.1 (vu que la 4.0 etait bien instable quand meme)