pulkomandy a écrit 2290 commentaires

Je ne pense pas que tu puisses changer la taille donnée par le firmware de la carte. ça, c'est interne au firmware et normalement pas modifiable.

Le mieux que tu puisses obtenir, c'est de créer une partition de 8Go ou un peu moins, et de faire attention de ne jamais utiliser le reste de l'espace "disponible".

Pour vim, j'ai installé youcompleteme, qui communique avec un serveur faisant tourner clang sur les buffers ouverts. On a la complétion, les prototypes des fonctions, et plein d'autres trucs que je découvre petit à petit.

Seul inconvénient: cela mange quelques Go de RAM quand on a des projets un peu complexes, car l'AST (la représentation interne de clang) de chaque fichier est stockée en RAM (cela comprend le fichier + tous les includes).

Presto (le moteur d'Opera) est toujours développé. Il fait toujours fonctionner Opera Mini sur les téléphones. Simplement il n'est plus utilisé pour leur navigateur "desktop", qui n'est pas celui sur lequel ils font des bénéfices, de toutes façons.

Le modèle d'Opera est qu'ils gagnent des sous avec le moteur Presto qu'ils utilisent pour l'embarquer dans plein de trucs (plusieurs consoles de chez Nintendo par exemple). Le navigateur desktop c'est juste une vitrine pour faire savoir qu'ils existent et que les gens reconnaissent leur marque.

Je m'interroge un peu plus sur des gens comme Vivaldi Technologies, qui développent un navigateur basé sur Blink et le distribuent gratuitement. Je me demande comment ils comptent faire pour continuer à payer leurs 35 employés?

Et le très complet ProjeQtOr, mais là, on est plus vraiment dans les outils pour les développeurs…

Moins connus mais pas forcément moins utiles:

• m4, un langage de macros pour remplacer des choses dans un fichier texte. Peut être utilisé pour pré-traiter du code source, quand le préprocesseur C montre ses limites, mais aussi pour plein d'autres choses.
• graphviz, pour faire des graphes.
• gperf, un outil pour générer une table de hachage sans collisions à partir de chaînes de caractères.

Et pour aller avec CMake, il me paraît intéressant de mentionner CTest (un moteur pour faire des tests unitaires) et CPack (pour générer facilement des pauqets deb, rpm, et même des installeurs pour Windows). Tous les deux sont utilisables avec ou sans CMake, mais sont assez bien intégrés dans ce dernier.

La fonction annuler/refaire d'un éditeur de texte est-elle utile pour produire du code? Je me sers beaucoup de git comme une extension (ou généralisation) de cette fonctionnalité (persistance sur le disque, gestion de plusieurs fichiers, etc).
Pour moi c'est un outil indispensable pour produire du code.

Il y en a plein d'autres qui sont libres, par exemple:
* Open Watcom
* SDCC (pour l'embarqué, PIC, z80, …)

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.

Je ne sais plus comment je l'ai découvert, probablement en listant :help syntax dans 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!

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).

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.

Oups, j'ai confondu les chiffres…

Pour la production il y a ceci dans la FAQ:

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…

Peut être que tout le monde commence à comprendre que tu avais raison depuis le début, hein?

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/

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.

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.

Grâce à toi je viens de découvrir http://www.oswash.org .

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