Jérôme Flesch a écrit 345 commentaires

Yep désolé, le serveur s'est pris les pieds dans le tapis. C'est réparé.

Une autre façon de voir ça, c'est que Zsh a fait une grosse erreur en ne choisissant pas la GPLv3.

À vue d'œil:

• Plus de facilité pour faire de l'orienté-objet ;
• Pas mal d'outils supplémentaires pour éviter de faire des boulettes (RIAA, smart_ptr<>, etc) ;
• Pas mal d'outils supplémentaires pour pouvoir faire des boulettes (bizarreries sur certains trucs genre unique_ptr<>, etc) ;
• Quelques outils pour faire moins de code et/ou plus optimisé (exceptions, etc) ;
• Quelques outils pour faire plus de code (templates de templates de templates, etc).

(PS: J'ai 10 ans de C derrière moi, mais clairement pas autant en C++)

Snowflake

(…)

Pauvre chou

(…)

la violence verbale n'est plus acceptée

Sérieusement ?

Aller, c'est pas vendredi, mais un troll bien gras comme ça, je peux pas résister ^^

Je suis le seul qui voit pas le problème avec la pub Gillette ? (je mets un lien vers l'original pour que chacun puisse se faire sa propre idée :P). Perso, je vois juste une pub qui dit "on peut sûrement faire mieux, alors faisons mieux". De façon générale, ça me semble plutôt une bonne approche dans la vie.

(Operation 'troll' is a go. I repeat, operation 'troll' is a go")

À mon avis, pas forcément si inutile.

Par exemple, imaginons une société de plus de 100 employés dont le PDG serait raciste. C'est très facile pour lui d'aller voir le programmeur du site web et lui mettre la pression pour avoir ce qu'il veut (-> un seul employé). Par exemple, le formulaire pourrait bazarder automatiquement tout ceux qui ne répondent pas qu'ils sont blancs. Qui irait vérifier ?

Avec la loi française, il faudrait qu'il passe à la consigne à tout les RH qui font les entretiens (-> souvent plusieurs personnes), donc plus de risque qu'il y ait une fuite. On peut rajouter à ça le risque qu'il y ait un mot de travers ou une bavure lors de l'entretien en face-à-face. Bref, nettement plus risqué.

Par courrier papier, c'est un peu la même chose: Il y a souvent juste une ou deux personnes qui trient les CVs.

Là je parle de racisme affiché/ouvert, mais il y a aussi un racisme plus "subtil": le préjugé. Le RH reçoit le formulaire de candidature ou le CV, voit une ethnicité autre que blanche ou un nom typé autre que franco-français --> De par son propre passé (son éducation par exemple), son jugement se retrouve tout de suite biaisé, consciemment ou non. C'est malheureusement naturel comme biais. Du coup, le candidat n'aura peut-être même pas l'opportunité de contre-balancer ces préjugés par un simple face-à-face. Or, basé sur mon expérience personnelle, quand les gens "existent" au lieu d'être un simple nom écrit sur une feuille, notre perception d'eux change immédiatement.

Ceci dit, les préjugés peuvent s'étendre aux CV anonymes. À mon avis, ça pourrait justifier de les rendre obligatoires et systématiques.

PS: Et ce n'est parce-que les chinois font n'importe-quoi n'importe-comment que nous devrions faire pareil :P

En France, c'est totalement interdit: https://www.cnil.fr/fr/cnil-direct/question/352 . Mais effectivement, c'est légal aux États-Unis à partir du moment où ils arrivent à justifier la question par une utilisation légale: https://work.chron.com/ask-race-job-applications-31050.html . Par exemple, ils peuvent la justifier en disant que c'est juste pour vérifier qu'ils ne discriminent pas.

Personnellement, je trouve ça quand même très douteux. C'est trop facile à justifier et de quand même s'en servir pour discriminer. Même en offrant la possibilité de ne pas répondre, ça reste trop simple: Par exemple, « Il a pas voulu répondre ? On va supposer qu'il n'est pas blanc ».
D'un autre coté, je suppose que ce genre de question peut aussi permettre de sélectionner son employeur. Étant moi-même blanc mais n'ayant pas envie de bosser avec des racistes, je me ferais un plaisir de répondre "ne souhaites pas répondre".

Quelques bonnes nouvelles:

Les critiques concernant les problèmes de compatibilité dans GTK+ 3 ont été entendues par les développeurs de GTK+: « GTK+ 4.0 ne sera pas GTK+ 4 ».

Pour le support des scanners, pour avoir un truc plus propre et multiplate-forme, je travaille actuellement sur une bibliothèque: Libinsane. Je ne suis plus très loin de sortir la version 1.0 (fin du mois j'espère).

Un peu dans la même idée, j'ai deux machines:

• Dédié chez OVH
• Olinuxino A20 chez moi

Mes documents perso:

• Tout mes documents sont synchronisés par Syncthing sur toutes mes machines perso, avec une copie sur mon dédié.
• Toutes les nuits, le dédié fait une sauvegarde dans un .tar.gz de tout mes documents. Il .tar.gz aussi mes mails (ceux-là ne sont pas synchronisés).
• Quelques heures plus tard, un script sur le Olinuxino vient récupérer tout ça par rsync. Il garde aussi les .tar.gz de la nuit d'avant.

Les services hébergés sur mon dédié (site web perso, openpaper.work, etc):

• Là, je peux me permettre 1 semaine de perte sans que ce soit trop grave. C'est surtout les installations et configurations que je veux sauvegarder plus que les données elles-même. La plupart des donnés sont soit sur Git soit je m'en fiche un peu (flux RSS, etc).
• Chaque service tourne dans son propre conteneur LXC (--> plusieurs Apache, 2 MariaDB, etc).
• Une fois par semaine, un à un, un script les arrête, en fait un .tar.gz, et les relance.
• Quelques heures plus tard, un script sur le Olinuxino vient récupérer tout ça par rsync. Il garde aussi une copie des .tar.gz de la semaine précédente.

À l'occasion, il faudra que je regarde pour utiliser duplicity pour faire des sauvegardes incrémentales.

Il y a sûrement moyen de faire plus efficace. Par exemple je pourrais éviter la coupure temporaire des conteneurs LXC. Mais pour l'instant c'est la solution la plus simple que j'ai trouvée. Avec cette approche, je n'ai pas à me soucier si un service tourne et pourrais corrompre la sauvegarde, ni à faire de méthode de sauvegarde spécifique à chaque service (cf MariaDB).

Bien vu !

Comme je travaille en QWERTY, je n'y avais pas fait attention. Mais ça peut peut-être se rattraper. Par exemple, le firmware du clavier et du trackpad est open-source, ce qui peut sûrement permettre de rajouter des combinaisons Fn- pour mapper '<' et '>'.

Les deux ont des configurations identiques.

Ceci dit, il y a quand même divers points à prendre en compte :

• Le Pinebook semble avoir quelques coût cachés. Le Teres a aussi des frais de port non-négligeables et le prix affiché est HT. Dans mon cas par exemple, le prix de base du portable + pièces supplémentaires : 277€ ; frais de port : 23€ (UPS) ; TVA : 60€ ; Total: 360€
• Le Pinebook est vendu assemblé. Le Teres est vendu en kit.
• Le Pinebook n'est pas openhardware. Pour le Teres, les schémas et PCBs sont libres (Apache 2.0). Par contre, les composants individuellement restent des boites noires (documentées mais fermées).
• Armbian ne supporte que le noyau 3.10 pour le Pinebook. Armbian supporte le noyau 4.18 pour le Teres.
• Le support du Pinebook a commencé à être ajouté au kernel mainline à partir du 4.19. Le support du Teres a commencé à être ajouté au kernel mainline à partir de 4.17. (ça laisse penser qu'il sera complètement supporté un peu avant)
• Le Pinebook est vendu depuis Hong-kong. Le Teres est vendu depuis la Bulgarie.
• Pour avoir du support concernant le Pine64, c'est sur leur site de support (on notera que les tickets ne sont pas accessibles au public). Pour avoir du support concernant le Teres, c'est par mail, sur IRC ou sur leur forum.
• Il y a une file d'attente pour le Pinebook. Le Teres, malgré ce qui est mentionné sur leur site, m'a été envoyé le lendemain de ma commande.

Non, aucune. Le composant AllWinner A64 est le cœur de ce portable. De ce que j'en ai compris, il est limité à 3Go. Olimex a regardé pour monter à 3Go, mais il ne semble pas simple de trouver les bons composants.

Attention toutefois. En me relisant, je réalise que j'ai omis de mentionner deux choses:

• Les pilotes Allwinner sont propriétaires, d'oú le fait que la distribution founie par Olimex est coincée en Ubuntu 16.04 avec un kernel 3.10. L'effort pour le support du kernel 4.x implique le passage à des pilotes libres.
• Le clavier est QWERTY. Il est toujours possible de le passer en AZERTY avec avec des autocollants achetés sur Amazon, mais c'est clairement moins classe.

J'y avais pensé. Mais je pensais attendre que le support Armbian et kernel 4.x avance encore un peu plus. Parce-que niveau logiciel libre, ça ne fait pas encore rêver pour le moment :/

Personnellement il me faudrait juste le contrôle de la luminosité de l'écran pour le rendre utilisable avec Armbian. Le support de l'indicateur de batterie serait un bon plus. Je songe de plus en plus à regarder si je ne pourrais pas le faire moi, mais pour le moment je suis un peu confus par rapport à quel variante du code kernel utiliser comme base (Armbian ? Sunxi ? Torvalds ? ..). Il va falloir que j'aille discuter sur les forums Armbian pour mettre ça au clair. (et manque de temps, tout ça … :/)

J'en ai acheté un Teres il y a quelques mois. À première vue, pour un développeur/geek, ce portable a peu d'intérêt: Petit processeur, peu de RAM, architecture un peu exotique et relativement chère pour cette configuration. Du coup, ma justification pour cet achat était "parce-que j'en ai envie".

C'est du DIY, avec des pièces de rechange clairement disponibles. Donc je me suis fait plaisir en mélangeant pièces noires (intérieur) et pièces blanches (extérieur) et en repeignant les pièces blanches en bleu. Comme dirait Bob Ross, il n'y pas d'erreur, juste d'heureuses coïncidences … J'ai aussi peint la plupart des touches en noires. (je peux poster des photos s'il y a des curieux :-)

Le montage:
Globalement pas de problème. Le manuel est clair. Si vous savez assembler un PC fixe, vous savez assembler ce portable. Le seul truc qui m'a posé problème: le câble d'antenne Wifi/Bluetooth fait pile poil la longueur nécessaire. Donc en gros bourrin, au premier montage, je l'ai cassé --> portée du Wifi: 1 mètre. Après une 2ième commande et un démontage/remontage, tout est en ordre.
Encore une fois, c'est du DIY. J'en ai donc profité pour ne pas mettre la webcam ni les enceintes.

Niveau logiciel:
Il est fourni avec Ubuntu 16.04 et un vieux kernel 3.10-préhistoire et des pilotes Allwinner tout-moisis-mais-qui-fonctionnent. Le passage en Ubuntu 18.04 est possible mais cause quelques bugs concernant les indicateurs de batteries et le décodage vidéo. Personnellement j'ai finalement préféré rester en 16.04 et utiliser un schroot contenant une debian testing à coté.
La bonne nouvelle, c'est qu'il y a un travail qui est en cours pour moderniser et libérer tout ça. Le résultat est déjà prometteur (meilleures perfs de la eMMC interne notamment).

Niveau matériel:
- 11,5 pouces ;
- ARM 4 coeurs, 2GB de ram, 16GB de mémoire interne ;
- J'ai rajouté une carte SD de 128Go ;
- Avec la distribution officielle: Mémoire interne: 20Mo/s. Carte SD: 20Mo/s. USB: 30 à 40Mo/s ;
- Avec Armbian: Mémoire interne: 40Mo/s. Carte SD: 20Mo/s ;
- La batterie tient sans problème plusieurs heures. Elle tient plus de 10h au repos ;
- La dalle est du 1366x768 (qualité largement suffisante à mes yeux) ;
- Très léger: < 1kg.

Au final je suis entrain de prendre l'habitude de développer dessus. L'idée est que si mes développements fonctionnent correctement sur cette machine, ils fonctionneront partout. Je suppose aussi que travailler dessus mettra plus en évidence les bouts de code qui ont besoin d'optimisations.

Au final, je trouve que son autonomie et sa légèreté le rendent très agréable à utiliser. Par contre, c'est sûr que je ne ferais pas tourner une VM Windows dessus.

Le problème, c'est qu'Olimex, c'est des électroniciens. Ils ne s'y connaissent pas en moulage plastique. Ils ont donc choisi d'utiliser un châssis déjà existant.

Je crois me souvenir qu'ils avaient étudié la possibilité de faire du spécifique, mais que ça augmenterait considérablement le cout.

Ça fait aussi pas loin d'un an que mon téléphone (Moto G 3ieme generation) tourne sous LineageOS, sans aucune application propriétaire Google. Mon téléphone n'en est que plus agréable à utiliser :-)

Proposition: Framagit (instance GitLab de Framasoft)

Et si tes données sont liées à une partie non libre de gitlab ?

Game over. C'est toujours le risque avec le propriétaire. Le secret, c'est de ne pas se rendre dépendant des parties non-libres :-)

Vraiment ? Tu sais déjà ce que ça donnerait ? Tu peux nous éclairer ?

Facile. Exactement ce qui s'est passé avec Windows, LDAP/Active-Directory, Office, Internet Explorer, etc: "Extinguish" ; Ajouts d'incompatibilité avec les autres fournisseurs, complexification, développement de fonctionnalités totalement spécifiques à Microsoft, méthodes commerciales anti-compétitives, et j'en passe.

il y a une quinzaine d'année je n'aurais jamais cru que Microsoft ouvrirait des morceaux entiers de .Net

Oui, on avait de la chance à cette époque. Steve Ballmer était trop bête pour voir que la stratégie EEE s'applique très bien aussi aux projets open-source. Ça demande juste beaucoup plus de temps.

Je suis peut-être parano, mais pour une société comme Microsoft, il m'a toujours semblé que l'argent était la finalité. Et le meilleur moyen de faire un maximum d'argent en investissant le moins possible, c'est de rendre ses clients dépendants. À noter que ce raisonnement s'applique à toutes les entreprises. C'est juste que beaucoup n'ont simplement pas l'opportunité de le faire.

Ah bien vu.

Ceci dit, il s'agit de code propriétaire ==> le problème d'enfermement du client reste exactement le même (cf Windows, Office, etc).

Si ils se font prendre à regarder les dépôts privés, c'est leur arrêt de mort

Ah c'est sûr. Facebook démontre d'ailleurs très bien l'importance à donner à la confidentialité des données utilisateurs. Le dernier scandale a bien l'air de les avoir ruinés et d'avoir fait perdre toute valeur à l'entreprise /s (graphique à regarder sur 5 ans pour bien se faire une idée des non-dégâts).

Les gens disaient la même chose de Facebook: "D'accord Facebook collecte mes préférences, informations personnelles s'en sert et les revend, et après ?". Après, Cambridge Analytica s'est servi des informations pour essayer (réussir?) de manipuler les élections américaines.

Est-ce qu'il faut vraiment attendre le prochain scandale ?

L'information c'est le pouvoir, et le pouvoir corrompt. Donnez trop d'information à une entreprise, c'est l'abus de pouvoir assuré.

qu'il me semble que les contributions se concentrent essentiellement sur faire marcher les outils open-source (k8s, etc) avec les outils fermés de Microsoft (Azure, etc). Ce qui rend possiblement dépendant des outils fermés, et ce qui correspond très bien à la partie "Embrace" et "Extend".

Concernant Gitlab, la différence avec Azure, c'est que tu peux héberger une instance Gitlab open-source sur ton réseau. Tu ne pourras pas héberger une infrastructure Azure sur ton réseau.
Parce-que Gitlab est au moins en parti open-source, si tu t'auto-héberges, tu pourras toujours récupérer toutes tes données. Pour Azure, je ne sais pas ce qu'il en est à l'heure actuelle, mais je peux déjà dire ce qu'il en sera si Azure arrivait à prendre plus de 90% du marché cloud.
Autrement dit, avec un auto-hébergement GitLab, tu sais que tu pourras toujours être maître de tes données. On est donc clairement plus dans un objectif de coopération avec le client que dans un objectif de le capturer.

Questions que je me pose:
Pour Kubernetes, ne s'agit-il pas juste d'ajouter et maintenir le support des containers Windows ainsi que de supporter Kubernetes par dessus Azure ? Pour Go, ne s'agit-il pas juste de le supporter dans Azure ?

Si oui, qu'est-ce qui indique que Microsoft ne suit pas juste sa stratégie habituelle de EEE ?
Pour l'instant, tel que je vois ça, il ne s'agit pas forcément de réelle coopération. Il est possible qu'ils tentent maintenant d'appliquer simplement le EEE aussi aux projets opensource.

Dans mon cas spécifiquement, c'est juste un problème de réputation de chaque entreprise:

• GitHub, bien que fournissant un service fermé, a toujours fait les choses correctement (excellente UI, toutes les données peuvent être exportées par Git ou par APIs, etc). GitHub ayant pour seul revenu sa forge, je pense qu'ils savaient qu'ils étaient obligés de fournir un service impeccable si ils voulaient garder leur position.
• De son coté, Microsoft est un spécialiste du EEE et est connu pour ses pratiques anti-concurrentielles. Microsoft ne s'est visiblement jamais senti obligé d’exceller, mais juste d'enfermer ses clients dans ses solutions.