pulkomandy a écrit 2290 commentaires

En plus, dans le cas du Neo900, il s'agit de faire rentrer une nouvelle carte dans une mécanique existante. Au début on se dit: "cool, du travail en moins, pas besoin de refaire la mécanique". Mais en fait, ça veut dire:
- Les ports d'entrées sortie et les connecteurs internes (pour l'écran, le clavier, etc) doivent être exactement au même endroit que sur la carte existante, et doivent être compatibles (possiblement plus chers que de choisir un connecteur récent)
- Il y a de fortes contraintes de place disponible dans le téléphone (il fait même pas 2cm d'épaisseur, auxquels il faut enlever l'écran, le clavier, le boîtier, et la batterie qui sont tous superposés sur ce modèle)
- Si Nokia a fait de la place pour certains trucs (genre, placé la carte SIM plutôt d'un côté ou y'avait moins de bazar sur leur carte), alors la nouvelle carte doit prendre ces contraintes en compte.
- On ne pourra produire la carte que pour des gens qui ont déjà le téléphone, et qui souhaitent remplacer la dite carte. Donc forcément, marché plus réduit que pour un téléphone neuf.

Résultat, la conception d'une telle carte coûte cher, mais sa fabrication aussi. On voit bien ce que ça a donné: ils ont essayé d'empiler des composants les uns sur les autres pour gagner un peu de place et ça n'a pas bien marché.

Donc au final, le prix ne me semble pas complètement délirant. Il aurait peut-être mieux valu faire un téléphone à partir de zéro, mais là par contre on a des coûts fixes pour lancer la production de la mécanique (coque, etc) et il faut faire une vraiment grosse production pour que ça marche.

A mon avis, on ne pourra pas arriver à quelque chose de sérieux si le libre est le seul argument de vente: le marché est encore trop petit pour ça. Commençons déjà par libérer ce qui peut facilement l'être (schémas, procédé d'assemblage), et on verra si ça prend et si dans un deuxième temps on peut s'attaquer aux puces électroniques placées dessus. C'est la démarche de Olimex avec le TERES-I, par exemple: https://www.olimex.com/Products/DIY%20Laptop/KITS/TERES-A64-BLACK/open-source-hardware

ça démystifie pas mal les choses déjà, et si ça peut donner envie aux gens de regarder comment ça marche dedans, peut-être qu'on pourra cultiver une communauté de hackers du matériel, comme il y en a une pour le logiciel, qui poussera le libre et fera avancer les choses, aussi bien pour l'offre (des gens capables de faire ça), que pour la demande (pour avoir des appareils qu'on peut bidouiller).

Le CRC est utilisé pour vérifier l'intégrité de chaque fichier dans un zip, par exemple. Mais en effet il est rarement utilisé en dehors. Peut-être juste parce qu'il manque les outils pour le faire, mais aussi parce que finalement, ça coûte pas tellement plus cher de mettre un SHA256 qui donne quelques garanties supplémentaires. à moins de traiter vraiment beaucoup de gros fichiers?

Pour poser un brevet, il faut qu'il y aie une innovation. Donc, le fait qu'il y aie plein de brevets déposés en ce moment, c'est plutôt bon signe pour l'innovation. Indépendamment du débat "pour ou contre les brevets logiciels".

Si ça marche dans un chroot, ça fait déjà une grande partie du travail de faite. Ce qu'il va manquer:
- D'éventuels trucs faits en espace utilisateur pour faire marcher le matériel. Par exemple, le noyau Linux peut avoir besoin de udev pour charger des firmwares et autres blobs binaires. On doit pouvoir s'en sortir en bricolant un peu l'init du système.
- Faire marcher l'écran et les entrées (tactile etc), car apparemment les chroot se contentent de fournir ça via un accès distant. Faut voir comment on peut faire tourner un X ou un Wayland sur un noyau Android (avec des drivers un peu accélérés, pas du fbdev), ou bien porter les toolkits (Qt, GTK, …) pour utiliser le framework d'Android à base d'EGL si je me souviens bien. Là, je ne sais pas trop quelle est la meilleure approche et ce qui est déjà possible (de mémoire FirefoxOS est dans une approche de ce genre).

Pourquoi ça serait plus compliqué?

Normalement, une fonction de hachage, elle doit donner un résultat très différent même pour des changements mineurs du fichier original. La "distance" entre les clés n'est donc pas corrélée avec la distance entre les contenus source.

Pour une image ISO par exemple, on commence par ajouter les fichiers malveillants, puis on lance le machin pour trouver une collision, en lui disant tous les endroits où il peut faire des changements. Typiquement, les secteurs d'une image ISO font 2048 octets, et la fin du dernier secteur alloué à chaque fichier n'est pas utilisée (car le fichier n'a pas une taille multiple de 2048 octets, il y a donc un peu de place perdue). L'outil n'a plus qu'à trouver comment remplir ces espaces de façon à générer une collision.

Maintenant, je n'ai pas été vérifier: est-ce que cet outil génère à volonté des collisions avec un hash donné, ou bien est-ce qu'il peut "seulement" générer deux fichiers avec la même signature? (en ayant le contrôle des deux, et pas d'un seul)? Même dans ce deuxième cas, il y a plein d'endroits où ça pourrait être utilisé (comme indiqué dans le journal: on pourrait te faire signer numériquement un fichier PDF avec un contrat, mais avoir fabriqué un autre fichier PDF avec un texte différent, et "prouver" que c'est celui-là que tu as signé, puisqu'il a le même hash).

C'est super facile d'installer un Debian dans un chroot sous Android: https://wiki.debian.org/ChrootOnAndroid

Il y a des applications pour le faire (avec un appareil Android sur lequel tu as un accès root, c'est mieux). Cela fonctionne sans problème. Tu continues à utiliser ton noyau Android, mais avec un espace utilisateur Debian par dessus.

Dans l'autre sens, c'est plus compliqué: le noyau Android contient plein de changements qui ne sont pas forcément intégrés dans l'upstream de Linux. ça se fait tout doucement, mais ça prend du temps et Android continue d'avancer.

Je viens de voir cette solution intéressante: http://whiteboard.ping.se/Android/Debian
- Noyau Android
- Système Debian
- Système Android dans un chroot (optionnel, je suppose)

Le problème n'est pas vraiment là. Ce qu'on voudrait, c'est quelque chose de bien packagé et "propre", c'est à dire un truc avec toutes les sources et qu'on peut facilement recompiler. Pour ça, il faut prendre le noyau fourni par le fabriquant du téléphone et l'intégrer dans le système de build de ta distribution (j'ai pris Debian parce que je connaît un peu, mais a priori c'est pareil avec n'importe quelle autre). Ou alors, il faudrait que les changements soient intégrés dans le noyau Linux officiel.

Le projet Linux a fait le choix de ne pas garantir une interface stable entre le noyau et les pilotes de périphériques. Chaque version du noyau peut changer cette interface. Cela leur permet d'expérimenter et d'évoluer rapidement, mais la contrepartie est qu'ils doivent constamment tenir les drivers à jour. Et pour ça, la seule solution qui marche est que les dits drivers soient intégrés dans le code source du noyau. Mais pour y arriver, il faut que le code soit propre et accepté par les gens qui vont le maintenir. Du coup, de nombreux fabriquant qui font fonctionner Linux sur leurs puces se contentent de faire fonctionner une version, et de publier les sources, sans faire les efforts nécessaire pour intégrer leurs changements au noyau officiel. On peut les comprendre, ils ont surement mieux à faire.

Donc, si tu es prêt à jouer un peu avec des scripts shell à l'installation, et à avoir des blobs binaires pour la partie GSM et d'autres trucs, faire fonctionner un environnement GNU/Linux "classique" sur un noyau Android n'est pas un problème. Y'a plus qu'à trouver un environnement graphique qui marche bien avec un écran tactile, et il me semble que GNOME 3 travaille pas mal là dessus et qu'ils sont pas les seuls?

Les sources de Symbian avaient été publiées à l'époque, en plus (de 2009 à 2011). Quelqu'un sait ce que c'est devenu?

Sinon, il y aurait aussi des trucs à faire à partir de Rockbox en ajoutant la partie téléphonie.

J'utilise souvent Multitalk (https://github.com/JohannesBuchner/multitalk), qui pourra peut-être apporter quelques idées. En particulier, il permet de positionner les slides par glissé-déposé dans la présentation, leur position étant stockée dans un fichier à côté de celui avec le contenu des slides.

Il vaut mieux publier les choses en l'état, ça ne prend pas trop longtemps à faire (créer un compte chez sourceforge/framagit/github… et quelques git push). Tu pourras ensuite prendre tranquillement le temps de nettoyer petit à petit, ou bien attendre que quelqu'un d'autre s'y mette!

Je ne sais pas pour un jeu, mais on a un peu ce genre de problèmes quand il s'agit de faire des icônes ou d'autres éléments graphiques dans une application.

Haiku a des règles sur la façon de dessiner les icônes (https://www.haiku-os.org/development/icon-guidelines) et plusieurs personnes ont pu participer, tout en gardant la cohérence. ça dépend aussi des outils utilisés, et du fait que les artistes partagent non seulement le résultat de leur travail, mais aussi les "sources": fichiers vectoriels, palettes de couleurs, méthode utilisée pour réaliser tel ou tel effet, etc. Ce qui permet de prendre un icône et de le dériver pour en faire un autre, par exemple.

xkcd est sous licence CC BY-SA: https://xkcd.com/license.html . Mais en effet, je ne vois pas Randall Munroe dans la liste des contributeurs à la dépêche…

Qu'il faut quand même passer en arguments à la commande initiale pour complètement répondre à la question:

for i in $(seq 1 100) ; do printf "coin " ; done |xargs commande

ça serait pas simplement le réseau qui se déconnecte lorsque la machine se met en veille, par exemple?

Et puis comme elles sont écrites en DocBook, tu peux utiliser une feuille de style à jour pour les générer en HTML5 tout beau tout propre!

Plus sérieusement: http://tdg.docbook.org/tdg/5.1/docbook.html mis à jour il y a à peine 3 mois, et la première édition n'a que 7 ans :)

(il faut chercher "docbook 5" plutôt que juste docbook pour trouver plus facilement des informations à jour, je suppose?)

Si quelqu'un te pique ton téléphone, il a accès à tes SMS ainsi qu'à l'application de la banque et au site web, pour lequel tu as peut-être stocké le mot de passe quelque part dans le même téléphone.

L'authentification a multiple facteurs, ça marche bien, mais seulement si les différents facteurs sont effectivement bien séparés.

Avec une carte bancaire + un code PIN à 4 chiffres pour cette carte + un identifiant et mot de passe pour le site internet, on a 3 facteurs bien séparés.

Le gros problème reste l'authentification assez misérable de beaucoup de banques (genre code à 6 chiffre max…)

Avec un nombre limité d'essais (en général 3), cela me paraît plus sécurisé qu'un mot de passe très long avec tentatives illimitées. ;)

Je sais même pas si le nombre d'essais est limité. Chez ma banque c'est un code a exactement 6 chiffres (pas maximum 6), du coup il y a encore moins de possibilités. Et pour me protéger des keyloggers, je suis obligé de le taper à la souris sur un gros clavier virtuel affiché au milieu de l'écran. Comme ça, n'importe qui qui peut voir mon écran peut le récupérer. Et les chiffres changent de place à chaque fois pour m'empêcher de cliquer dessus rapidement.

Je trouve ce système complètement nul et pas du tout sécurisant.

Le boîtier lecteur de carte bancaire de la banque populaire est effectivement beaucoup mieux. En plus ça permet aux gens de faire un peu de cryptographie et de comprendre la différence entre authentification, signature, et chiffrement.

Et encore tu as de la chance, chez moi ce n'est pas 24 mais 72h. La raison est que leur site internet pour ajouter des bénéficiaires est insuffisamment sécurisée. Si quelqu'un se connecte à mon compte et ajoute le sien comme bénéficiaire dans le but de me piquer des sous, j'ai donc 72h pour réagir.

Mais sinon oui, je songe très sérieusement à changer de banque. Surtout que ce n'est pas la plus gênante de leurs limitations…

Un exemple pour les curieux: https://samy.pl/pwnat/

Et pour le brancher à git: http://staxmanade.com/2014/12/use-different-git-diff-tools-per-file-extension/

Sinon, en format léger, il y a vimwiki (https://github.com/vimwiki/vimwiki) avec de l'export en HTML. Comme son nom l'indique, il est plutôt bien intégré dans vim.

RTF est un format de présentation, pas de structure. Et en plus il est à peu près aussi pénible que LaTeX à écrire à la main (c'est plein de \ et de commandes bizarres).

Ce sont pour moi les deux gros avantages de DocBook:

• Enfin un vrai langage structuré pour écrire de la documentation. Tous les "concurrents", markdown et compagnie, sont en fait plus proches de HTML, très orientés formatage du texte. DocBook permet vraiment de gérer de grosses bases de documentation et de faire du vrai hypertexte (non seulement des liens, mais aussi de la recherche, des indexs, etc), et de vraiment séparer le rendu du contenu.
• Il utilise XML, avec tous les outils qui vont autour. En particulier, XSLT avec des stylesheets pour générer à peu près tout et n'importe quoi et qui sont facilement personnalisables.

Et aussi les deux gros défauts:
- DocBook fait trop de choses. Il y a plusieurs centaines de balises, ce qui peut le rendre assez compliqué à manipuler quand on part de rien (si on fait des changements dans des documents existants, je pense que ça se passe mieux)
- Il utilise XML, qui n'est pas la syntaxe la plus facile et confortable pour les humains. Et mettre en place la toolchain n'est pas toujours simple. DocBook vers HTML, ça va, mais DocBook vers PDF, il faut passer par LaTeX ou fop, qui sont tous les deux assez "usine à gaz". Mais l'idée de fop est pas mal (c'est un genre de concurrent à postscript, mais en XML).

Bref, avec les bons outils, ça marche bien une fois que c'est mis en place.

Et pour le "pas très connu": je crois que gtkdoc repose aussi sur docbook. En fait il est partout, mais il marche tellement bien que ça se voit pas!

Pour les utilisateurs: le système de paquets de Haiku permet d'installer, d'une part, des paquets systèmes dans /system, d'autre part, des paquets utilisateurs dans /home/config. Plusieurs variables d'environnement (PATH, chemin de recherche des includes du compilateur, etc) sont configurées pour tenir compte de l'existence de ces deux hiérarchies. Ce qui permet d'avoir une partie commune au système, et une propre à chaque utilisateur qui peut compléter où remplacer des choses.

Un exemple concret: un projet qui a été développé sur une version de Debian qui est maintenant la oldstable. Il a besoin d'une vieille version de perl et de GNU make, entre autres.

Il est beaucoup plus simple de dire aux nouveaux développeurs d'installer le système Linux de leur choix, puis de déployer la Debian oldstable à partir d'une image (ça pourrait être docket je suppose, mais en l'occurence c'est un truc avec un chroot et des scripts maison). Et ça marche tout seul, pas de maintenance à faire sur l'environnement.

On a clairement pas le temps de s'amuser à recompiler de vieilles versions de Perl, make, du compilateur croisé utilisé, etc. D'ailleurs, par exemple, il est impossible (enfin, compliqué, en faisant plein de patches, peut-être) de compiler un gcc 4.5 ou antérieur pour x86_64 avec un gcc récent. Et oui, on peut avoir besoin de ce genre de choses, par exemple si on maintient un produit avec un CPU 68hc11, qui n'est pas supporté par un gcc actuel et pour lequel on doit pouvoir avoir au mieux un gcc 3.4, de mémoire (les patches n'ont jamais été intégrés dans le gcc officiel).

Donc voilà, l'environnement de dev, il est comme ça, il changera pas, et il fait sa vie. ça coûte rien à maintenir tant que le noyau Linux ne change pas ses appels systèmes et qu'on trouve des CPU x86 compatibles avec les binaires qui sont dedans.

C'est l'approche de pkgsrc, développé d'abord chez NetBSD mail il existe des dépôts de binaires pour Solaris, par exemple.
Par contre, ça ne s'intègre pas (je crois) avec un éventuel dépôt pré-existant (celui de Debian ou de Fedora, par exemple). Tu risques donc d'avoir des paquets en double et installés au même endroit, ce qui risque de créer plein de problèmes.