pulkomandy a écrit 2019 commentaires

Le probleme c'est que je ne suis pas sur que cela soit faisable vu que vous utilisez des concepts differents.

On arrive bien à importer du SVN et même du CVS ou du RCS (le système de gestion de versions standardisé par POSIX) dans git. Par contre, le "dans les deux sens" est moins facile, je pense. Je n'ai heureusement pas eu besoin de ce genre de choses pour l'instant, seulement de migrer des projets existants de SVN ou RCS vers git.

On est bien d'accord, merci pour ces précisions.

Au final, on a quand même un OS avec AOSP et plusieurs distributions dont LineageOS qui viennent y ajouter des applications. Et au final on a quand même un système libre avec des applications (qu'il faut maintenir et faire évoluer, certes).

Pour moi c'est donc déjà largement mieux que Jolla/Sailfish, pour le moment. Même si c'est encore loin d'être parfait.

On oublie aussi le micro et les enceintes, qui sont petits, donc très sensibles au bruit et ne restituent pas facilement le son correctement. C'est beaucoup de boulot d'intégration aussi.

Les micros: en général il y en a deux, un près de la bouche et un autre pour le bruit d'ambiance. Ensuite on fait la différence entre les sons reçus par ces deux micros pour annuler le bruit d'ambiance et transmettre uniquement la voix sur le réseau téléphonique.

C'est juste un petit exemple de tous les trucs auxquels il faut penser pour faire un bon téléphone.

ça dépend ce qu'on entend par "mieux". Les gens qui fabriquent le Raspberry Pi par exemple, ils ont de l'expérience pour router une carte électronique. ça fait pas la moitié d'un smartphone (écran, batterie, boîtier, appareil photo, …). Et surtout, ils ne font pas de puces électroniques de leur propre conception, donc ils ne feraient pas mieux d'un point de vue open hardware que d'autres (au mieux, ils pourraient publier les schémas de leur carte électronique). C'est l'approche que tente Purism, sachant qu'ils ont déjà plus d'expérience que Raspberry ou d'autres (ils ont fait et vendus plusieurs modèles de PC portables complets).

Mais même comme ça, se lancer dans ce genre de projet a un coût non négligeable. Et ça c'est sans parler du développement logiciel - mais de ce côté là il semble que GNOME et KDE soient tous les deux motivés pour se lancer?

Quant à transformer un smartphone en serveur, il n'est pas difficile d'installer Debian par-dessus une base Android pour faire ce genre de chose (en passant par debootstrap). ça manque de distributions pré-conçues pour cet usage, mais ça, on a pas besoin d'une entreprise qui se lance dedans pour le faire.

En tout cas, la solution du Pi pour faire un ordinateur moins cher (en gros: on enlève le boîtier, on fait un truc 10 fois moins puissant) se transpose facilement au monde du téléphone. Sans même parler des certifications pour pouvoir faire du sans fil (et je pense que cela explique pourquoi le Pi a mis du temps avant d'intégrer wifi et bluetooth), et à fortiori pour se connecter au réseau GSM (il faudrait pas que ça fasse tomber les antennes relais en panne, ni que ça fasse frire le cerveau de la personne qui téléphone).

On leur a demandé, ils ont fait ça: https://learn.adafruit.com/arduin-o-phone-arduino-powered-diy-cellphone/overview

Je te laisse décider si c'est au niveau ou pas.

(et adafruit sont plutôt bons pour ce qu'ils font, mais leur but ce n'est pas de faire des téléphones grand public).

Tout à fait. C'est un peu confusionnant chez Google mais il y a AOSP (Android Open Source Project) qui est le système avec quelques applications de base. Puis, il y a la version "officielle" de Google qui ajoute les applications Google, etc, et qui idéalement, ne devrait être considérée que comme une surcouche constructeur parmi d'autres. Sauf que du coup, il y a peu de contributions aux applications de base d'AOSP (je ne sais pas si c'est parce que les gens qui essaient de contribuer se font jeter ou juste parce que personne en dehors de Google ne contribue) et elles sont souvent remplacées, soit par celles de Google, soit par autre chose (par exemple LineageOS a sa propre application appareil photo si ma mémoire est bonne).

J'aime beaucoup le "crow funding" (littéralement, "financement par les corbeaux"). Je sais pas si c'était fait exprès, mais je garde!

ça ne crée pas les dossiers parents s'ils n'existent pas.

C'est donc moins libre qu'Android, en fait. Bon à savoir…

Pour un Feature Phone, il faudrait toujours faire tourner Linux dessus, assembler le matériel (probablement en produisant moins de machines que la plupart des autres fabricants au début), etc. En fait, au final, vu que l'OS est déjà prêt pour lancer des applications, faire un téléphone capable de le faire, ça coûte pas forcément plus cher.

Conclusion: à mon avis, un feature phone préparé et produit de la même façon ne coûterait pas forcément beaucoup moins cher. Après on pourrait partir dans une autre direction pour avoir un matériel beaucoup moins puissant, pas de 4G, etc. Peut-être en laissant tomber Linux et en se dirigeant vers Rockbox, par exemple. Mais j'ai du mal avec le concept d'un téléphone libre où on ne pourrait pas installer une application dessus. ça va être compliqué de vendre ça aux gens: "oui alors, sur ce téléphone ci, qui est libre, tu dois tout recompiler si tu veux ajouter une nouvelle fonctionalité. Sur l'iPhone tout-verrouillé-propriétaire à côté, tu vas juste sur l'app store et en 3 clics tu as l'application installée".

C'est triste de voir des strings en Latin-1 plutôt qu'en UTF-8 qui aurait fait ganger à peu près autant de place.

Pour le logging, apparament le but est d'avoir un support pour les logs directement dans le coeur de Java, afin d'éviter que tous les autres modules (ou presque) dépendent de java.util.logging.

Là si j'ai bien compris on a une configuration de ce genre:

USB <-> Contrôleur ethernet <-> Routeur 3G

Du coup, il y a quand même un contrôleur ethernet au milieu ce qui fait que le routeur 3G, lui, ne devrait pas trop avoir accès à grand chose. Après il faudrait étudier le matériel pour voir comment c'est réalisé et à quel points ces trucs sont intégrés.

Un ASIC ne fait pas d'un périphérique un ordinateur. Rappel: Application-Specific Integrated Circuit, qui veut juste dire "circuit intégré spécifique à l'application". Ne contient pas forcément un processeur ou quoi que ce soit d'"intelligent" ou de capable d'exécuter du code. C'est juste un moyen de mettre plein de logique simple dans une seule puce.

En général quand on fait un ASIC, c'est plutôt pour des trucs qui ont besoin de haute performance et qu'on peut pas facilement faire avec du code. Donc c'est rare de trouver un processeur dedans. Sauf si y'en a aussi besoin pour d'autres raisons et qu'il restait de la place pour le mettre là?

Ils travaillent dessus, en effet:

https://interstices.info/jcms/c_34530/le-tatouage-de-son
http://www.carnot-lsi.com/notre-offre/protocoles-et-systemes-de-communication/offres/tatouage-de-contenu-audio-numerique

J'ai fait une comparaison entre deux choses:
- Un périphérique "intelligent" comme celui-ci, mais avec peu ou pas de driver sur la machine, et d'autre part,
- Un périphérique "bête" pour lequel une grosse partie du travail va être faite par le driver

Dans les deux cas, tu as à peu près les mêmes risques d'une prise de contrôle par un botnet: soit juste le périphérique, soit si la faille est dans un driver, toute ta machine (surtout qu'on a toujours pas d'OS avec un micronoyau qui permettrait d'avoir au moins une protection logicielle entre les drivers).

Dans les deux cas, la solution est la même: du code libre (celui embarqué sur le périphérique ou celui du driver) qui permettra d'auditer la sécurité et de corriger les problèmes.

Le fait d'avoir cette intelligence dans le périphérique protège au moins un peu plus les données qui sont sur ta machine. Et de ce point de vue de la sécurité, je ne pense pas que ça aie d'inconvénients. Après, il y a d'autres problèmes (de gaspillage de ressources pour construire un matériel plus compliqué, par exemple).

Les choses "simples" techniquement ne sont pas toujours les plus simples à utiliser ou même à comprendre. Quelle solution on aurait pour copier une photo entre deux appareils en local? DLNA? Bonjour/Avahi? Pas forcément des trucs simples car un appareil peut rejoindre ou quitter le réseau à tout moment. Et on ne veut pas d'un serveur central. ça devient vite plutôt compliqué de faire le truc qui "juste marche".

C'est peut-être pas plus mal que ça soit du logiciel.

Quand on fait des choses complexes, il y a forcément des problèmes de sécurité. Et il est beaucoup plus facile de mettre à jour le logiciel, que de corriger le matériel.

De plus, cela permet de segmenter les choses. Le router dans ce cas est quand même bien isolé de ta machine principale. Même si son OS est troué, si tu utilises des protocoles chiffrés, et sécurisés, et bien il ne pourra pas faire grand chose pour accéder à tes données. Il pourra par contre miner des bitcoins où toute autre activité plus ou moins légale confiée à un botnet.

En fait, je pense que je préfère ça, plutôt qu'un driver (venant du même fabriquant) à installer directement dans le noyau de mon système d'exploitation, et qui aurait du coup accès à toute les ressources de la machine (mémoire, CPU, …).

Cela n'empêche pas, dans les deux cas, que ce logiciel devrait être libre. Mais c'est un problème indépendant.

Il faut disputer l'équipe pour ne pas être claire sur son workflow.

Dans certains cas, il est possible d'utiliser git pull --rebase (et d'ailleurs d'activer l'option autorebase dans le .git pour ne pas avoir à le faire à la main tout le temps). Dans d'autres cas, il y a juste trop d'activité et un historique trop compliqué pour que ça soit possible (le noyau Linux, WebKit, ou de très gros projets très actifs dans ce genre).

Et comme git est conçu d'abord pour le noyau Linux, forcément les réglages par défaut sont surtout appropriés pour ce cas là.

Je suis d'accord que ce serait mieux si github mettait les pages wiki et les bugs dans le repository (google code le faisait pour les pages wiki au moins).

C'est le cas (dans un repository séparé): https://help.github.com/articles/adding-and-editing-wiki-pages-locally/

Je trouve l'idée de Fossil d'intégrer le wiki et le suivi de bugs avec les sources intéressant pour faire un truc complètement décentralisé. Chacun travaille sur sa machine avec sa liste de bugs, son wiki qui est tenu à jour avec les sources, etc. Et on synchronise tout ça avec un push sur un serveur, par exemple.

Je précise que je n'ai pas (encore) joué avec et que je ne sais pas comment ça se comporte en pratique. La solution retenue chez moi pour le moment est un dépôt git avec des pages vimwiki dedans, mais l'inconvénient est que vim est quasiment indispensable pour naviguer dans le wiki ou générer un rendu html.

Cela à aussi un intérêt pour l'archivage. Par exemple sur le site du Computer History Museum on trouve le code source de Microsoft Word 1.1a, avec la licence "Microsoft Research": http://www.computerhistory.org/atchm/microsoft-research-license-agreement-msword-v-1-1a/

Après une relecture rapide, on a la liberté d'étudier modifier le logiciel. On a pas la liberté de le distribuer ni de l'utiliser à des fins commerciales. Et en plus, Microsoft obtient automatiquement les droits sur les éventuelles versions modifiées.

Par contre, ils acceptent de couvrir les dommages matériels causés par ce code dans la limite de 5 dollars.

Donc, pas grand intérêt pratique, mais ce code est archivé et dans une quarantaine d'année il sera dans le domaine public, et au moins avec cette licence il y a quelques chances qu'il reste quelques copies utilisables d'ici là. Mais c'est pas dit qu'on en fasse grand chose alors.

Il y a d'autres logiciels avec des licences similaires dans les archives du Computer History Museum. Je dirais que c'est pas terrible, mais c'est mieux que de laisser ce code source pourrir sur de vieilles disquettes. Et on peut toujours l'étudier pour comprendre les formats de fichiers utilisés et écrire un logiciel pour convertir des fichiers vers un format plus récent, par exemple.

Personnellement, j'avoue ne jamais avoir compris comment on pouvait concevoir des DRM efficaces pour empêcher la copie sans verouiller la totalité du système, du BIOS au moniteur. Si tu veux pomper ton film, tu captures le flux audio ou vidéo après le navigateur, non?

Tout à fait. Et maintenant que le W3C a dit "ok" pour le navigateur, la prochaine étape sera le système d'exploitation, puis ensuite le BIOS. Pour le matériel, c'est déjà fait avec HDCP pour le HDMI, le DVI et le DisplayPort, par exemple. Enfin, ils essaient en tout cas, car il existe du matériel permettant de contourner le HDCP.

L'EME, c'est donc la porte d'entrée qui permettra à un site web de vérifier si oui ou non, ton ordinateur est bien verrouillé comme il faut, avec son écran HDCP, son navigateur qui implémente les DRM, et son OS et son BIOS qui vérifient que tu n'interceptes pas les informations.

Après, je ne doute pas qu'il y aura rapidement un plug-in pour le navigateur qui répondra "oui oui c'est bon" sans rien vérifier. Mais, est-ce que la fondation Mozilla ou Google accepteront de le mettre dans leurs magasins d'extensions (où leur signature est maintenant obligatoire)?

Le W3C est l'organisme qui rédige et maintient les spécifications de HTML et CSS. Cela permet à tous les navigateurs de suivre ces recommandations et de participer à leur rédaction. Normalement, ça évite qu'un navigateur fasse plein d'extensions non-standard et permet que les sites internet marchent à peu près pareil partout.

D'où la question: est-ce qu'il vaut mieux des DRM standardisés, ou des DRM avec une implémentation et une spécification propriétaires qui ne marche qu'avec un seul navigateur? (bien sûr, la bonne réponse est qu'il vaut mieux pas de DRM du tout, mais le W3C a choisi de répondre "ça, on n'y peut rien").

Pourquoi du bricolage? C'est un périphérique tout à fait standard et pas très cher:

http://www.dx.com/p/fs1-1-usb-foot-switch-keyboard-mouse-control-foot-pedal-black-190cm-cable-198679#.Wb_ID3WslFQ

Il y a même une version pour les gens qui veulent utiliser leurs trois jambes:

http://www.dx.com/p/usb-triple-action-foot-switch-keyboard-control-foot-pedal-56508#.Wb_IFHWslFQ

Nom de Zeus!

2.22GW! C'est juste ce qu'il faut pour alimenter un convecteur temporel!

Coïncidence? Je ne pense pas…

On peut pas juste lancer un XMing et le connecter avec les applications WSL? Si le réseau passe ça devrait pas poser problème, non?

Ah et il est peut-être utile de le rappeler, c'est important d'avoir des pneus bien gonflés et une transmission lubrifiée correctement. ça fait largement plus de différence que le dénivelé, en fait.