J'ai du mal à croire qu'il y aie des gens (même riches ou richissimes) qui gardent tout leur argent sous leur matelas. Du coup, dès que c'est dans une banque sur un compte d'épargne, ce n'est pas sorti de l'économie.
Cela dit il repose aussi sur d'autres trucs plus récents (DHCP, …) et les RFC ont été plusieurs fois mises à jour depuis.
(et puis, on pouvait déjà booter sur le réseau à l'époque du Xerox Alto en 1973. Par contre ça n'était probablement pas tout à fait le même protocole).
Le déclin du LL sur le navigateur ça n'a pas l'air d'être trop le cas pour le moment. Que je sache, Chrome (qui est de loin le navigateur le plus utilisé maintenant) est un logiciel libre. Et ne vient pas me dire que "oui mais c'est Google, c'est pas pareil" (le bon et le mauvais chasseur?).
Il y a des gens qui se trompent de combat. Pour les navigateurs, le combat sur le LL est déjà gagné, et c'est bien. Mais on a un peu oublié le combat sur le respect de la vie privée des utilisateurs et de leurs données, qui finalement, ne vient pas forcément automatiquement avec le logiciel libre. Moi, c'est plus là-dessus que j'attends Mozilla, maintenant.
Early production runs are likely to be done in batches of ~25 wafers. This would yield around 100-200K good chips per batch. We expect to produce packaged chips for less than $10 each.
Donc, une première production de 100 à 200 000 unités à 10$ pièce? On est effectivement pas vraiment dans un volume "faible".
git repose exactement sur la même "supposition". Selon leurs propres mots: il y a plus de chance que les développeurs du projet soient tués par des loups une nuit, dans des évènements indépendants, que de tomber par hasard sur une collision SHA-1.
La supposition que les collisions sont suffisament rares pour ignorer le problème permet à git (et je suppose aussi à SVN) d'être rapide. Dans le cas de git, il me semble qu'ils vérifient qu'il n'y a pas de collision, et donc lors d'un commit, tu auras un message d'erreur avant de casser ton dépôt. C'est déjà ça…
vim peut convertir le contenu d'un fichier en code HTML préservant la coloration syntaxique. C'est la commande :TOhtml. Ensuite tu peux ouvrir le résultat comme un fichier HTML (dans un navigateur web ou directement dans LO?) et copier le résultat dans ton document.
Je rajoute un lien vers le projet LowRISC, qui est un des projets pour fondre des puces utilisant le jeu d'instructions RISC-V (64 bit): http://www.lowrisc.org/faq/
Leur but est d'avoir un system on chip pour environ 10$ pièce, gravé en 22nm, et qui tournerait à 1 ou 1.5GHz, pour y faire fonctionner un système Linux.
Ils prévoient de lancer une campagne de financement cette année pour pouvoir investir dans la réalisation des circuits. En attendant, cela s'expérimente sur des FPGA, ce qui leur permet déjà de travailler aux compilateurs, portage de Linux vers leur système, etc.
En Europe, il n'y a que GSM et UMTS. Aux USA, tu as des opérateurs en CDMA, par exemple. Et ça c'est pour les trucs déjà déployés et mis en production. A chaque nouvelle génération de standard (3G, 4G, …), plusieurs projets sont mis en concurrence.
Je ne crois pas que l'implémentation matérielle des puces Atheros soit ouverte?
En ce qui concerne les specs pour l'UMTS, cela m'a l'air d'être disponible par ici: http://www.3gpp.org/specifications (un lien vers un serveur FTP avec tous les documents, un peu en vrac il est vrai).
Par contre, il y a, d'une part des brevets, et d'autre part, une partie confidentielle qui concerne le chiffrement des données: http://www.3gpp.org/specifications/60-confidentiality-algorithms . ça semble normal qu'ils ne veulent pas filer leurs clés de chiffrement à n'importe qui :o)
OpenCores est une bibliothèque de composants matériels libres. On y trouve la description en langage VHDL (le code source, quoi) de ces composants, que l'on peut assembler pour fabriquer un appareil électronique.
Ce n'est qu'une partie du travail, ensuite il faut synthétiser tout ça et le mettre dans du matériel. Dans un premier temps, on simule logiciellement (en général, pas assez performant pour faire du temps réel). Dans un deuxième temps, on peut mettre ça sur un (ou plusieurs) FPGA (une puce électronique reconfigurable qui permet d'avoir des performances "correctes" pour faire des essais en temps réel - là ça consomme beaucoup). Enfin, on peut faire fondre un ASIC, c'est à dire une "vraie" puce figée avec le design final. Là, on peut avoir les performances d'un ARM ou d'un Atom, mais ça coûte des millions d'euros à produire (en grande quantité) et il faut être vraiment sûr de pas avoir laissé traîner des bugs dans le matériel.
En ce qui concerne OpenRISC, c'est un projet pour concevoir un cœur de processeur libre et sans licence. Il n'y a pas de raison qu'il soit moins bon qu'un autre (ARM ou Atom), mais il faut voir à l'usage, et cela peut dépendre des implémentations. De la même façon que le jeu d'instruction x86 est implémenté de différentes façons par Intel ou AMD, ou même dans différents produits chez le même fabricant; OpenRISC aura aussi plusieurs implémentations, tournées soit vers les performances brutes, soit plus vers l'économie d'énergie.
PS: note que si tu conçois ce genre de système, il me semble que les législations obligent à permettre le traçage des utilisateurs par les chtars.
Je dirais que ça, c'est seulement si tu relies ce genre de système (ou de façon générale, des gens) à Internet (et encore…). N'importe qui a le droit de monter son propre réseau, avec ou sans fils.
Il me semble qu'il faut une licence pour devenir radio amateur et avoir le droit d'utiliser les fréquences ouvertes. Et la dite licence peut être retirée si tu fais n'importe quoi (un peu sur le principe d'un permis de conduire, en gros).
Le wi-fi est une "bande libre", ce qui signifie que n'importe qui a le droit d'émettre en respectant certaines conditions, notamment de puissance maximale (100mW maxi). C'est différent des réseaux téléphoniques mobiles, où les opérateurs doivent acheter des fréquences.
Je ne vois rien là dedans qui empêche de développer sa propre carte Wi-Fi. Par contre, la loi est différente dans d'autre pays (ou continents), et aussi, je ne sais pas si on peut vendre un système Wi-Fi qui serait capable d'émettre à d'autres fréquences. En France on a du Wifi autour de 2.4 et de 5GHz, mais il ne faudrait pas que quelqu'un se retrouve à émettre à 3 ou 4GHz. Si j'ai bien suivi, c'est la raison pour laquelle on a des firmware binaires pour pas mal de cartes Wi-Fi. Ce firmware se charge de limiter les bandes de fréquences qui peuvent être utilisées, et il devrait être choisi en fonction de la région (au sens de l'allocation des fréqeunces radio) où on se trouve.
En tout cas je ne vois rien là dedans qui pourrait interndire un mesh wifi réalisé avec une application sur smartphone. Est-ce que les problèmes de ce genre d'applications sont légaux, ou simplement dans le contrat qui te lie avec ton opérateur téléphonique si tu commences à relayer les données d'autres personnes?
Quand c'est compliqué, le mieux à faire c'est de découper le problème en morceaux plus petits.
Pour le logiciel, on pourrait par exemple prendre Replicant, qui est un OS construit à partir des morceaux libres d'Android.
Pour le matériel, avoir les schémas de la carte électronique serait déjà un début. C'est loin d'être suffisant, mais c'est toujours ça de pris. ça permet aussi aux gens de s'intéresser à comment ça marche et d'avoir quelques infos.
Pour le "téléphone", on pourrait prendre pour commencer une clé USB 3G, si possible une qui a pas besoin de firmware, ou mieux, dont le firmware est libre (parce que je ne crois pas qu'on puisse trouver un truc vraiment sans firmware: il serait simplement codé en dur dans la clé, ce qui est finalement pire qu'un firmware à charger par le pilote de périphérique).
Pour l'écran, aucun problème on peut acheter ça pour pas trop cher, éventuellement avec un pavé tactile déjà équipé.
Il reste le problème d'avoir un système sur puce libre. Et ça, c'est plus compliqué actuellement. On pourrait commencer à assembler des morceaux de VHDL venant de différents endroits (OpenRISC? OpenCores?) et commencer à tester sur un FPGA (lui même pas libre) avec des outils de compilation pas libres. De ce côté là il y a encore énormément de travail pour arriver à un truc vraiment libre. Mais pareil, on peut faire les choses une à la fois: d'abord la toolchain de traitement du VHDL, ensuite le FPGA ciblé, etc. Cela demandera sans doute plusieurs années mais je ne pense pas que ça soit impossible.
Sachant que bricoler le hash d'un commit git n'est pas forcément difficile (même sans cacher des fichiers dedans), car on peut aussi bricoler les métadonnées: message de commit, date et heure, etc.
Cela est déjà mis en pratique par exemple ici (bien regarder les commit hashs affichés dans l'historique - juste en changeant la date des commits de +/- 30 minutes):
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).
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).
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?
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.
[^] # Re: Cotisations != employé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un four à pain c'est considéré comme un employé ?. Évalué à 2.
J'ai du mal à croire qu'il y aie des gens (même riches ou richissimes) qui gardent tout leur argent sous leur matelas. Du coup, dès que c'est dans une banque sur un compte d'épargne, ce n'est pas sorti de l'économie.
[^] # Re: vim
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Copier/coller avec coloration syntaxique dans LO Impress. Évalué à 2.
Je ne sais plus comment je l'ai découvert, probablement en listant
:help syntaxdans vim?Pour emacs, tu peux utiliser ça pour libérer quelques doigts. Mais ça ne donne pas de bon points à emacs pour autant: ça marche aussi avec vim!
[^] # Re: Netboot
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Libérer un Mac/Intel. Évalué à 3. Dernière modification le 02 mars 2017 à 13:05.
PxE repose assez largement sur TFTP, dont la RFC date de 1981. PxE lui même est documenté dans une RFC datant de 1984. Source: https://fr.wikipedia.org/wiki/Preboot_Execution_Environment
Cela dit il repose aussi sur d'autres trucs plus récents (DHCP, …) et les RFC ont été plusieurs fois mises à jour depuis.
(et puis, on pouvait déjà booter sur le réseau à l'époque du Xerox Alto en 1973. Par contre ça n'était probablement pas tout à fait le même protocole).
[^] # Re: et si ça n'a rien à voir avec les licences ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mozilla nous dit que le closed-source est plus bankable. Évalué à -4.
Le déclin du LL sur le navigateur ça n'a pas l'air d'être trop le cas pour le moment. Que je sache, Chrome (qui est de loin le navigateur le plus utilisé maintenant) est un logiciel libre. Et ne vient pas me dire que "oui mais c'est Google, c'est pas pareil" (le bon et le mauvais chasseur?).
Il y a des gens qui se trompent de combat. Pour les navigateurs, le combat sur le LL est déjà gagné, et c'est bien. Mais on a un peu oublié le combat sur le respect de la vie privée des utilisateurs et de leurs données, qui finalement, ne vient pas forcément automatiquement avec le logiciel libre. Moi, c'est plus là-dessus que j'attends Mozilla, maintenant.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
Oups, j'ai confondu les chiffres…
Pour la production il y a ceci dans la FAQ:
Donc, une première production de 100 à 200 000 unités à 10$ pièce? On est effectivement pas vraiment dans un volume "faible".
[^] # Re: Et paf le Subversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et paf, le SHA-1 !. Évalué à 7.
git repose exactement sur la même "supposition". Selon leurs propres mots: il y a plus de chance que les développeurs du projet soient tués par des loups une nuit, dans des évènements indépendants, que de tomber par hasard sur une collision SHA-1.
La supposition que les collisions sont suffisament rares pour ignorer le problème permet à git (et je suppose aussi à SVN) d'être rapide. Dans le cas de git, il me semble qu'ils vérifient qu'il n'y a pas de collision, et donc lors d'un commit, tu auras un message d'erreur avant de casser ton dépôt. C'est déjà ça…
[^] # Re: et si ça n'a rien à voir avec les licences ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mozilla nous dit que le closed-source est plus bankable. Évalué à 6.
Peut être que tout le monde commence à comprendre que tu avais raison depuis le début, hein?
# vim
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Copier/coller avec coloration syntaxique dans LO Impress. Évalué à 4.
vim peut convertir le contenu d'un fichier en code HTML préservant la coloration syntaxique. C'est la commande :TOhtml. Ensuite tu peux ouvrir le résultat comme un fichier HTML (dans un navigateur web ou directement dans LO?) et copier le résultat dans ton document.
Dans le même esprit il y a Pyygmentize en python: http://pygments.org/docs/cmdline/
[^] # Re: Système de fichiers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les tutoriaux du mois de février 2017. Évalué à 2.
Sous Haiku, j'utilise BFS, bien sûr.
Pour les autres systèmes, XFS ou JFS, selon l'humeur du moment. Je n'ai toujours pas réussi à les départager.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
Je rajoute un lien vers le projet LowRISC, qui est un des projets pour fondre des puces utilisant le jeu d'instructions RISC-V (64 bit): http://www.lowrisc.org/faq/
Leur but est d'avoir un system on chip pour environ 10$ pièce, gravé en 22nm, et qui tournerait à 1 ou 1.5GHz, pour y faire fonctionner un système Linux.
Ils prévoient de lancer une campagne de financement cette année pour pouvoir investir dans la réalisation des circuits. En attendant, cela s'expérimente sur des FPGA, ce qui leur permet déjà de travailler aux compilateurs, portage de Linux vers leur système, etc.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
En Europe, il n'y a que GSM et UMTS. Aux USA, tu as des opérateurs en CDMA, par exemple. Et ça c'est pour les trucs déjà déployés et mis en production. A chaque nouvelle génération de standard (3G, 4G, …), plusieurs projets sont mis en concurrence.
Je ne crois pas que l'implémentation matérielle des puces Atheros soit ouverte?
En ce qui concerne les specs pour l'UMTS, cela m'a l'air d'être disponible par ici: http://www.3gpp.org/specifications (un lien vers un serveur FTP avec tous les documents, un peu en vrac il est vrai).
Par contre, il y a, d'une part des brevets, et d'autre part, une partie confidentielle qui concerne le chiffrement des données: http://www.3gpp.org/specifications/60-confidentiality-algorithms . ça semble normal qu'ils ne veulent pas filer leurs clés de chiffrement à n'importe qui :o)
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 3.
OpenCores est une bibliothèque de composants matériels libres. On y trouve la description en langage VHDL (le code source, quoi) de ces composants, que l'on peut assembler pour fabriquer un appareil électronique.
Ce n'est qu'une partie du travail, ensuite il faut synthétiser tout ça et le mettre dans du matériel. Dans un premier temps, on simule logiciellement (en général, pas assez performant pour faire du temps réel). Dans un deuxième temps, on peut mettre ça sur un (ou plusieurs) FPGA (une puce électronique reconfigurable qui permet d'avoir des performances "correctes" pour faire des essais en temps réel - là ça consomme beaucoup). Enfin, on peut faire fondre un ASIC, c'est à dire une "vraie" puce figée avec le design final. Là, on peut avoir les performances d'un ARM ou d'un Atom, mais ça coûte des millions d'euros à produire (en grande quantité) et il faut être vraiment sûr de pas avoir laissé traîner des bugs dans le matériel.
En ce qui concerne OpenRISC, c'est un projet pour concevoir un cœur de processeur libre et sans licence. Il n'y a pas de raison qu'il soit moins bon qu'un autre (ARM ou Atom), mais il faut voir à l'usage, et cela peut dépendre des implémentations. De la même façon que le jeu d'instruction x86 est implémenté de différentes façons par Intel ou AMD, ou même dans différents produits chez le même fabricant; OpenRISC aura aussi plusieurs implémentations, tournées soit vers les performances brutes, soit plus vers l'économie d'énergie.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
Je dirais que ça, c'est seulement si tu relies ce genre de système (ou de façon générale, des gens) à Internet (et encore…). N'importe qui a le droit de monter son propre réseau, avec ou sans fils.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
Il me semble qu'il faut une licence pour devenir radio amateur et avoir le droit d'utiliser les fréquences ouvertes. Et la dite licence peut être retirée si tu fais n'importe quoi (un peu sur le principe d'un permis de conduire, en gros).
Le wi-fi est une "bande libre", ce qui signifie que n'importe qui a le droit d'émettre en respectant certaines conditions, notamment de puissance maximale (100mW maxi). C'est différent des réseaux téléphoniques mobiles, où les opérateurs doivent acheter des fréquences.
Je ne vois rien là dedans qui empêche de développer sa propre carte Wi-Fi. Par contre, la loi est différente dans d'autre pays (ou continents), et aussi, je ne sais pas si on peut vendre un système Wi-Fi qui serait capable d'émettre à d'autres fréquences. En France on a du Wifi autour de 2.4 et de 5GHz, mais il ne faudrait pas que quelqu'un se retrouve à émettre à 3 ou 4GHz. Si j'ai bien suivi, c'est la raison pour laquelle on a des firmware binaires pour pas mal de cartes Wi-Fi. Ce firmware se charge de limiter les bandes de fréquences qui peuvent être utilisées, et il devrait être choisi en fonction de la région (au sens de l'allocation des fréqeunces radio) où on se trouve.
En tout cas je ne vois rien là dedans qui pourrait interndire un mesh wifi réalisé avec une application sur smartphone. Est-ce que les problèmes de ce genre d'applications sont légaux, ou simplement dans le contrat qui te lie avec ton opérateur téléphonique si tu commences à relayer les données d'autres personnes?
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 4.
Quand c'est compliqué, le mieux à faire c'est de découper le problème en morceaux plus petits.
Pour le logiciel, on pourrait par exemple prendre Replicant, qui est un OS construit à partir des morceaux libres d'Android.
Pour le matériel, avoir les schémas de la carte électronique serait déjà un début. C'est loin d'être suffisant, mais c'est toujours ça de pris. ça permet aussi aux gens de s'intéresser à comment ça marche et d'avoir quelques infos.
Pour le "téléphone", on pourrait prendre pour commencer une clé USB 3G, si possible une qui a pas besoin de firmware, ou mieux, dont le firmware est libre (parce que je ne crois pas qu'on puisse trouver un truc vraiment sans firmware: il serait simplement codé en dur dans la clé, ce qui est finalement pire qu'un firmware à charger par le pilote de périphérique).
Pour l'écran, aucun problème on peut acheter ça pour pas trop cher, éventuellement avec un pavé tactile déjà équipé.
Il reste le problème d'avoir un système sur puce libre. Et ça, c'est plus compliqué actuellement. On pourrait commencer à assembler des morceaux de VHDL venant de différents endroits (OpenRISC? OpenCores?) et commencer à tester sur un FPGA (lui même pas libre) avec des outils de compilation pas libres. De ce côté là il y a encore énormément de travail pour arriver à un truc vraiment libre. Mais pareil, on peut faire les choses une à la fois: d'abord la toolchain de traitement du VHDL, ensuite le FPGA ciblé, etc. Cela demandera sans doute plusieurs années mais je ne pense pas que ça soit impossible.
[^] # Re: pas de marché au contraire.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 9.
Grâce à toi je viens de découvrir http://www.oswash.org .
[^] # Re: Et paf le Subversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et paf, le SHA-1 !. Évalué à 4.
Sachant que bricoler le hash d'un commit git n'est pas forcément difficile (même sans cacher des fichiers dedans), car on peut aussi bricoler les métadonnées: message de commit, date et heure, etc.
Cela est déjà mis en pratique par exemple ici (bien regarder les commit hashs affichés dans l'historique - juste en changeant la date des commits de +/- 30 minutes):
https://github.com/vog/beautify_git_hash/commits/master
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les mobiles libres ont du plomb dans l’aile et les systèmes d’exploitation ne vont pas mieux. Évalué à 5.
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).
[^] # Re: Est-ce réellement un problème ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et paf, le SHA-1 !. Évalué à 3.
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?
[^] # Re: Ne pas raconter n'importe quoi non plus...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à -3.
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".
[^] # Re: smartphone et OS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les mobiles libres ont du plomb dans l’aile et les systèmes d’exploitation ne vont pas mieux. Évalué à 2.
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).
[^] # Re: Est-ce réellement un problème ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et paf, le SHA-1 !. Évalué à 6.
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).
[^] # Re: smartphone et OS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les mobiles libres ont du plomb dans l’aile et les systèmes d’exploitation ne vont pas mieux. Évalué à 2.
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?
[^] # Re: OS libre et feature phone
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les mobiles libres ont du plomb dans l’aile et les systèmes d’exploitation ne vont pas mieux. Évalué à 3.
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.
# Multitalk
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche PAMPI — Présentations avec Markdown, Pandoc, Impress. Évalué à 5.
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.