pulkomandy a écrit 1957 commentaires

ça m'énerve un peu qu'on puisse dire que tout le "milieu du dev en génral" est comme ça. Il y a des projets qui fonctionnent différemment, et c'est dommage de les oublier et de dire "c'est comme ça et on peut pas y faire grand chose".

Il y a plein de projets de logiciels libres:
- où on est pas obligés de boire de la bière
- pas en anglais (il y en a pas mal qui sont en japonais par exemple (exemple au hasard: http://www.geocities.co.jp/Berkeley/2093/driller.html), ou en russe (je l'ai plus sous la main, mais c'était un émulateur de la puce son du zx spectrum), ou en chinois, ou de l'open hardware en tchèque (http://www.8bit.8u.cz/Files/Faudraj/))
- plus accueillant que l'équipe du noyau Linux

Alors certes, c'est pas forcément les plus visibles ou les plus connus (surtout ceux qui ne sont pas en anglais), mais il y a des gens qui font des efforts dans ce sens, et dire que le milieu du dev en général fonctionne forcément comme l'équipe qui dirige le développement du noyau Linux, ça manque un peu de respect pour tous ceux qui font des efforts pour que ça change. Et ça m'énerve, apparemment.

C'est pas forcément choquant, mais c'est au moins déplacé. On se dit que ça va, que c'est pour rigoler, mais quand tout un projet est plein de blagues douteuses de ce genre (que ça soit dans le code, sur des listes de diffusions ou n'importe où), ça ne crée pas une ambiance très accueillante.

En ce moment c'est le Google Code-In, pour les projets qui participent, ça veut dire, canaux IRC pleins de participants au concours, entre 13 et 18 ans. Et on a du virer des gens de notre canal IRC pour comportement déplacé (pas des contributeurs au projet, heureusement).

Enfin, s'il y a au moins une personne qui se sent choquée ou insultée, c'est insultant ou choquant. Ce n'est pas à l'auteur de la plaisanterie d'en décider, tout ce qu'il peut faire, c'est s'excuser ou admettre qu'il n'en a rien à faire que les gens soient choqués par ses blagues, ou bien que c'est volontairement provocateur.

Le milieu du dev en général, il t'emmerde de ma part.

Hereusement que tous les projets ne sont pas comme ça, parce que sinon je ferais beaucoup moins de logiciel libre.

Comme souvent, il y a plein de choses qui se mélangent, et dans ce cas, les deux camps ont intérêt à entretenir la confusion, ce qui n'arrange rien.

Sur les OGM: le principe est de modifier le patrimoine génétique d'une espèce (par exemple, une variété de maïs) en y ajoutant des gènes venus d'une autre espèce (par exemple, une bactérie). Il y a quelques risques éventuels de déclencher des mutations non prévues, car les méthodes pour bricoler les gènes sont parfois un peu bourrin (on bombarde le noyau de la cellule avec des microbilles de métal enveloppées d'ADN, on garde les cellules survivantes et on espère que le gène injecté se soit mix au bon endroit sans rien casser d'important). On fait des progrès avec les "ciseaux génétiques" CRISPR, qui permettent de mieux maîtriser ça.

On a des boîtes du genre Monsanto qui utilise ça pour fabriquer des plantes résistantes à un herbicide (vendu avec), auquel très peu d'autres plantes peuvent survivre, par exemple. Du coup, on peut utiliser l'herbicide en question sur les champs et tuer tout sauf les plants OGM qu'on veur récolter.

Il y a des gens qui ont peur que les plantes OGM, qui sont donc plus résistantes, envahissent la nature. Le risque est une diminution de la biodiversité (tous les agriculteurs sèment le même maïs acheté chez Monsanto). Pour éviter ça, les plants OGM sont sensé être stériles pour éviter une contamination.

Les plans stériles empêchent les agriculteurs de conserver les graines d'une récolte pour re-semer l'année suivante. Du coup, ils doivent acheter de nouvelles graines à Monsanto tous les ans, ils sont donc dépendants de l'entreprise et de ce qu'on veut bien leur vendre.

Enfin, il se pose la question de la brevetabilité du vivant. Monsanto a déposé des brevets sur certains gènes, ce qui interdit donc la culture de plants contenant ce gène sans autorisation de leur part. ça rejoint un peu la problématique des brevets logiciels: est-ce qu'on peut poser un brevet sur un gène/sur un algorithme?

Alors, il y a des choses contre lesquelles on peut ne pas être d'accord dans ce que fait Monsanto, mais à mon avis, attaquer sur les OGM, c'est se tromper de cible. Le problème est surtout, d'une part sur les brevets, et d'autre part sur la préservation de la biodiversité et des espèces naturelles endogènes. Ce qui n'empêche pas de faire des cultures d'OGM, je pense. En attendant, aussi bien Monsanto que Greenpeace s'arrangent bien que les plans d'OGM soient stériles…

Je trouve très surprenant en général que y = f(x) puisse modifier x, et les compilos récents n'ont aucun mal à optimiser v = sort(v) correctement. Ceci dit, j'ai peut-être tendance à tenter de retrouver en C++ des concepts qui viennent des langages de plus haut niveau.

Là il faudrait faire de la programmation fonctionnelle, effectivement C++ n'est pas le meilleur choix pour ça.

elle va supporter l'écriture vi |= action::sort | action::unique;

On peut voter quelque part pour le support du Brainfuck dans C++19?

Je suppose qu'ils ont voulu faire un truc qui ressemble aux "pipes" en shell unix?

Publier du code sous licence MIT (et l'assumer) n'empêche pas de souhaiter que les autres en fassent autant. Même s'ils ont le droit de ne pas le faire.

Tant que ça en reste là et qu'on ne tombe pas dans le "c'est des gros méchants voleurs de code", tout va bien, non?

Unicomp vend ça (ainsi que plusieurs autres dispositions). Ce sont des évolutions de l'authentique claver Model M de chez IBM.

C'était surtout un accident, au début :) Quelqu'un s'est dit: "hé, mais on peut faire un langage Turing complet avec ça!". Et ensuite y'a eu des gens pour s'en servir…

Merci. C'est ça, le bien commun.

Tu as lu la licence GPL? Parce que ça ressemble quand même pas mal à ce que tu viens de décrire. Je dis ça je dis rien :)

Euh… toutes les licences sont là pour te dire ce que tu as le droit de faire. Tout ce qu'elles n'autorisent pas explicitement, c'est interdit (sauf si la loi l'autorise, mais dans ce cas, une licence qui essaie de l'interdire n'est pas valide).

Une licence qui interdit des trucs, c'est donc redondant et inutile.

Pour ceux qui pensent qu'un clavier normal n'a pas assez de touches:

http://www.pckeyboard.com/page/product/UB40B5A

On peut ausi ajouter des pédales vendues par Kinesis, que l'on peut utiliser pour control et alt, ce qui améliore grandement l'ergonomie pour les utilisateurs d'emacs.

Justement, après, ça tombe dans le domaine public et on peut l'utiliser. C'est le (petit) avantage des brevets.

Ici on a des adhérents qui n'ont pas d'accès internet, et d'autres qui ne souhaitent pas nous donner leur adresse mail.

Il existe des logiciels non libres qui implémentent des formats standard, et sont tout à fait interopérables.

Donc, un "logiciel privateur" ça ne veut rien dire, et en tout cas ce n'est pas la même chose qu'un logiciel non libre.

Si tu parles de brevets logiciels, d'abord en Europe ça n'existe pas, et d'autre part, un logiciel libre pourrait très bien implémenter une méthode brevetée, s'il signe un accord qui va bien avec le propriétaire du brevet.

Et inversement, on peut utiliser OpenSSL (un logiciel libre) pour chiffrer un flux de communication ou un format de fichier et donc empêcher les gens d'implémenter un autre logiciel pour traiter les données.

Il manque l'ancêtre des claviers à accords: le clavier Baudot, utilisé avec le code du même nom: https://fr.wikipedia.org/wiki/Code_Baudot

Source: https://fr.wikipedia.org/wiki/Dose_%C3%A9quivalente_en_banane

En tant que trésorier d'une association, le problème avec les virements, c'est qu'on a souvent du mal à savoir de qui ça vient et pourquoi. Et du coup, c'est compliqué de tenir la comptabilité.
Tandis qu'un encaissement de chèque ou un prélèvement, on peut s'arranger pour qu'il y aie une trace de notre côté.

Si ma mémoire est bonne, c'est principalement à cause du potassium que les bananes sont radioactives.

On doit pas parler du même genre de devices. LWIP s'utilise avec des microcontrôleurs qui ont en général quelques Ko de RAM, et le code s'exécute directement depuis la flash (qui est souvent plus grande que la RAM). Je pense par exemple aux STM32 chez ST, et certains PIC32 chez Microchip. De gros microcontrôleurs capables de faire de l'IP, mais pas assez gros pour faire confortablement fonctionner Linux.

Alors oui, bien sûr quand on a du matériel assez puissant pour mettre Linux, il vaut mieux le faire. Mais c'est loin d'être le cas partout. Et ça ne règle pas le problème qu'il faut faire le suivi des mises à jour de sécurité et publier régulièrement des corrections du firmware, ce qui est trop rarement fait, Linux ou pas.

Je ne suis pas sur que LWIP soit "très peu utilisé". C'est l'une des rares solutions pour l'embarqué quand on a pas la place de mettre un Linux, et on la croise quand même assez souvent. Et elle est sous licence BSD, ce qui fait qu'il y a plein de gens qui l'utilisent sans diffuser les sources et sans communiquer dessus. Difficile donc d'évaluer si elle est répandue ou non.

Je maintiens la question: si ta plateforme n'exécute QUE du code en flash, tu fais comment pour injecter du code dans la flash à partir de paquets IP? Faire planter le device, oui, sans problème, mais injecter du code dans la flash, j'ai du mal à y croire. Tu auras beau faire tous les buffers overflows que tu veux et écraser toute la RAM, la flash ne va pas bouger? C'est pas une question de compétence là, je vois juste pas comment on peut injecter du code en flash juste à partir de paquets IP.

LWIP date de 2002, elle a donc plus de 10 ans :)

Pourquoi elle serait forcément de moins bonne qualité que celle de Linux?

Quel que soit le logiciel utilisé, ne l'utilisez pas sans l'avoir fait tester par des vrais méchants du pen test. On a vu ce qu'il s'est passé avec OpenSSL, par exemple.

"Oui mais c'est Linux, tout le monde utilise ça, donc c'est forcément fiable"? J)y crois moyennement. Il y a régulièrement des mises à jour de Linux et il est rare qu'elles soient déployées sur des devices IoT (quand on arrive à avoir un kernel à jour dès la conception du device, c'est déjà pas mal. dans certains cas les fournisseurs de system-on-chip fournissent une version du noyau; qui date de la mise sur le marché du chip…).

En plus de ça, même avec une pile IP pleine de trous on est loin d'avoir un botnet. Injecter du code dans un firmware où le code ne s'exécute que depuis la mémoire flash d'un microcontrôleur, ou il n'y a pas de shell et donc aucun moyen de prendre le contrôle directement de la machine, où il n'y a pas d'interface de syscall claire entre le noyau et le reste, où les adresses de toutes les fonctions changent à chaque recompilation du firmware, je te souhaite bon courage.

(par contre, ça sera peut être facile de faire planter et rebooter le device en question. même sans en prendre le contrôle pour faire un botnet ça peut déjà bien mettre le bazar).

moi aussi j'aime les pâtes!

Il y a aussi LWIP et uIP (micro IP), qui proposent même de l'IPv6. LWIP est plutôt fiable, il n'y a pas de raison que ça soit moins bien sécurisé que la stack IP de Linux.

Petite confusion sur les composant logiques "série 74", je pense?

On trouve dedans toute sorted de technologies:

7400: la "vraie" série 74
74LS00: low-power shotky
74HC00: CMOS

et ainsi de suite (74F, 74HCT, 74AVL, …). On a donc des portes logiques à fonctions équivalentes, mais utilisant des technologies différentes. Certaines sont toujours utiles pour des cas bien précis, même si de plus en plus de choses sont intégrées dans des circuits plus complexes de nos jours.