Ben oui, s'il y a une ligne de code avec cette licence dans le projet, il faut appliquer la licence. Par contre tu peux peut-être négocier un prix à la ligne de code avec le vendeur.
La licence est donc incompatible avec la GPL, et en plus, si le code a été touché par une douzaine d'intermédiaires, et qu'ils choisissent tous d'avoir une version commerciale, a priori il faut donc leur acheter une licence à chacun (à moins qu'ils se refacturent les choses entre eux?)
C'est là la vraie différence, en fait: quand j'écris du code et que je le publie (en général sous licence MIT dans mon cas), ça n'est certainement pas pour "lutter contre le copyright" (ou contre quoi que ce soit).
C'est parce que j'utilise tout un tas de logiciels libres (ou juste gratuits, parfois) et que je trouve que la moindre des choses, c'est de donner un truc en retour.
Je ne pense pas que le logiciel libre pourra gagner en se mettant en conflit avec le copyright (sur lequel les licences copyleft posent leurs fondements légaux, de toutes façons). Il pourra peut-être en montrant que ça marche mieux et que ça fait gagner du temps à tout le monde de partager du code.
dans le second tome de son Rapport sur l’exposition de 1839. Industrie française, il publie Des lacunes de la typographie, où il propose plusieurs signes typographiques émotionnels supplémentaires.
C'est un peu l'ancêtre des emojis unicode, en fait. Il est disponible dans les caractères spéciaux de Linuxfr.
ça fait assez longtemps que Sony publie les sources de leur noyau adapté pour AOSP (la version libre d'Android) et rend facile le déblocage du bootloader sur leurs téléphones (et même certaines smartwatches).
C'est plutôt bien de leur part et l'une des raisons pour lesquelles j'ai acheté un téléphone de chez eux.
D'après la news, on aura pas beaucoup mieux pour Jolla: uniquement les sources du noyau. De ce que j'ai compris, Sailfish X sera une "ROM" vendue 50 euros.
Par contre, cela veut dire qu'on peut avoir un noyau Linux standard avec les pilotes qui vont bien dedans, et probablement essayer de faire un debootstrap (ou l'équivalent dans votre distro préférée) puis développer une interface utilisateur libre par dessus. Là, c'est aux libristes de prendre les choses en main pour la suite!
Y'a un peu un gros message au dessus du graphique qui dit ceci:
This report contains preview data that has NOT been reviewed by Quality Assurance.
D'autre part, ils n'affichent pas les nombres absolus, seulement des pourcentages. Il se pourrait bien que Linux et Mac ne bougent pas beaucoup, mais que Windows baisse d'un coup (ce serait quand même intéressant de comprendre pourquoi).
Quand tu as une API stable, tu peux au moins essayer de l'utiliser, et de faire ton driver crade comme tu veux de ton côté avec. Si ça marche pas, tu peux alors faire l'effort de faire des changements dans le noyau. Mais ça rend tout de suite clair dans quoi tu te lances: il va falloir récupérer les sources du noyau, le recompiler, faire les changements, puis maintenir ce fork.
ça ne rend pas le code automatiquement de meilleure qualité hein. Mais par contre, ça force les gens à se dire "ouhlà, j'ai franchi la ligne rouge". À mon avis, ça rend juste les choses assez pénibles à faire pour que le dev se pose deux minutes et se demande s'il a pas moyen d'arriver à faire ce qu'il veut avec l'API qu'on lui a donné. Pas parce que c'est plus propre, mais parce que ça l'embête de devoir recompiler le noyau et pas juste son bout de driver.
Dans le fonctionnement actuel, c'est un peu "voilà les sources du noyau, débrouille-toi avec ça". Et c'est considéré normal que chaque pilote écrit aie besoin de réécrire la moitié du noyau (j'ai arrêté de compter combien de fois ils ont changé la stratéglie d'allocation mémoire pour les pilotes graphiques, par exemple).
En ce qui concerne l'unicité du matériel, ARM a fait pas mal de progrès pour tout ce qui est de base. Tu as une MMU standard, ainsi qu'un timer système pour faire tourner un scheduler. Déjà c'est pas mal. Autour de ça, il commence aussi à y avoir des standards de fait sur certains autres points. Par exemple, sur n'importe quelle plateforme ARM tu as toutes les chances de trouver une UART compatible 16C550 (la même qui pilote les ports série sur PC). Après pour les trucs plus avancés, cartes graphiques, etc, oui, c'est pas standard. Sur PC non plus, mais le BIOS dépanne en fournissant au moins un mode texte et du VESA pour pouvoir afficher des pixels sans accélération. Mais c'est pas vraiment là qu'est le gros du travail, en fait.
C'est vrai que c'est plus diversifié que sur l'architecture PC/x86, mais quand même, ça ne me semble pas insurmontable si les choses sont faites un minimum proprement.
L'architecture ARM est un gros merdier alors qu'il domine sur les tablettes et téléphones. Son avantage de son faible coût et de sa faible consommation pour une puissance raisonnable l'ont rendu incontournable. Mais faute de BIOS ou équivalent disponible (l'UEFI arrive petit à petit mais c'est long et pas généralisé sur l'ARM64) rend toutes ces puces légèrement incompatibles avec le voisin avec peu de possibilités simples pour avoir un système unique qui s'adapte à la machine.
Si les PCs avaient connus la même situation, cela aurait été difficile. Imagine s'il fallait une image Linux spéciale pour les HP, Dell, Acer ou autres, voire entre HP avec un Intel i386 et AMD compatible i686. Je doute que Linux en serait là aujourd'hui. Car cela aurait complexifié la venue de contributeurs et d'utilisateurs et les développeurs perdraient du temps à gérer cette situation plutôt que d'ajouter des fonctionnalités intéressantes.
D'autant plus que le problème des téléphones est exacerbé par le fait que les fondeurs de puces type Qualcomm, Broadcom font du mauvais travail. Linux gère leur téléphone mais ce travail est fait à l'arrache faute de temps et de budget. Ce qui fait que le noyau Linux officiel ne peut bénéficier de ces travaux et peut difficilement fonctionner sur ces puces.
Moui… Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.
Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).
La différence avec les PC, c'est la présence du bus PCI qui permet d'énumérer le matériel, et auparavant de l'ISA plug-n-play. Sur ARM, il n'y a pour l'instant (en général - on trouve des machines avec un bus PCI) pas d'équivalent pour ça. Du coup, la solution c'est le device tree, qui décrit le matériel et qui normalement permet d'utiliser le même noyau partout.
L'autre souci, c'est que pour Linux, tous les drivers devraient être intégrés dans le git de Linus Torvalds pour être maintenus. Mais ce n'est pas une approche réaliste pour plein de cas. Du coup, chaque fabricant préfère vivre avec son propre fork du noyau, ce qui coûte moins cher à court et moyen terme (et il y a peu de fabricants qui maintiennent leurs puces sur le long terme - c'est plus simple de les remplacer par des versions plus récentes).
Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.
Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.
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.
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).
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).
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à?
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.
[^] # Re: le texte de la licence ne varie pas
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La fausse bonne idée de la licence "libre mais pas pour les méchants". Évalué à 3.
Ben oui, s'il y a une ligne de code avec cette licence dans le projet, il faut appliquer la licence. Par contre tu peux peut-être négocier un prix à la ligne de code avec le vendeur.
La licence est donc incompatible avec la GPL, et en plus, si le code a été touché par une douzaine d'intermédiaires, et qu'ils choisissent tous d'avoir une version commerciale, a priori il faut donc leur acheter une licence à chacun (à moins qu'ils se refacturent les choses entre eux?)
Bref, ça devient très vite très compliqué.
[^] # Re: C'est pourtant simple
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La fausse bonne idée de la licence "libre mais pas pour les méchants". Évalué à 5.
C'est là la vraie différence, en fait: quand j'écris du code et que je le publie (en général sous licence MIT dans mon cas), ça n'est certainement pas pour "lutter contre le copyright" (ou contre quoi que ce soit).
C'est parce que j'utilise tout un tas de logiciels libres (ou juste gratuits, parfois) et que je trouve que la moindre des choses, c'est de donner un truc en retour.
Je ne pense pas que le logiciel libre pourra gagner en se mettant en conflit avec le copyright (sur lequel les licences copyleft posent leurs fondements légaux, de toutes façons). Il pourra peut-être en montrant que ça marche mieux et que ça fait gagner du temps à tout le monde de partager du code.
[^] # Re: Singulier, pluriel, faut savoir !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 8.
C'est du singuriel. Si on enlève le genre de la grammaire, y'a pas de raison de distinguer le nombre non plus.
[^] # Re: Le·a Tour·e Eiffeil·e
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 7.
Tu peux essayer d'ajouter un point d'ironie, mais ça ruine un peu l'effet.
https://fr.wikipedia.org/wiki/Point_d'ironie
C'est un peu l'ancêtre des emojis unicode, en fait. Il est disponible dans les caractères spéciaux de Linuxfr.
# C+=
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 10.
Bonus spécial pour celleui qui réussit à écrire une implémentation en C+=, le fork féministe (et parodique -enfin j'espère) de C++:
https://github.com/TheFeministSoftwareFoundation/C-plus-Equality
[^] # Re: Sony met le paquet sur Jolla
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 2.
ça fait assez longtemps que Sony publie les sources de leur noyau adapté pour AOSP (la version libre d'Android) et rend facile le déblocage du bootloader sur leurs téléphones (et même certaines smartwatches).
C'est plutôt bien de leur part et l'une des raisons pour lesquelles j'ai acheté un téléphone de chez eux.
D'après la news, on aura pas beaucoup mieux pour Jolla: uniquement les sources du noyau. De ce que j'ai compris, Sailfish X sera une "ROM" vendue 50 euros.
Par contre, cela veut dire qu'on peut avoir un noyau Linux standard avec les pilotes qui vont bien dedans, et probablement essayer de faire un debootstrap (ou l'équivalent dans votre distro préférée) puis développer une interface utilisateur libre par dessus. Là, c'est aux libristes de prendre les choses en main pour la suite!
[^] # Re: Nagios
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 6,9 % de Linux sur le bureau et autres chiffres surprenants de NetMarketShare. Évalué à 7.
Y'a un peu un gros message au dessus du graphique qui dit ceci:
D'autre part, ils n'affichent pas les nombres absolus, seulement des pourcentages. Il se pourrait bien que Linux et Mac ne bougent pas beaucoup, mais que Windows baisse d'un coup (ce serait quand même intéressant de comprendre pourquoi).
[^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 4.
Quand tu as une API stable, tu peux au moins essayer de l'utiliser, et de faire ton driver crade comme tu veux de ton côté avec. Si ça marche pas, tu peux alors faire l'effort de faire des changements dans le noyau. Mais ça rend tout de suite clair dans quoi tu te lances: il va falloir récupérer les sources du noyau, le recompiler, faire les changements, puis maintenir ce fork.
ça ne rend pas le code automatiquement de meilleure qualité hein. Mais par contre, ça force les gens à se dire "ouhlà, j'ai franchi la ligne rouge". À mon avis, ça rend juste les choses assez pénibles à faire pour que le dev se pose deux minutes et se demande s'il a pas moyen d'arriver à faire ce qu'il veut avec l'API qu'on lui a donné. Pas parce que c'est plus propre, mais parce que ça l'embête de devoir recompiler le noyau et pas juste son bout de driver.
Dans le fonctionnement actuel, c'est un peu "voilà les sources du noyau, débrouille-toi avec ça". Et c'est considéré normal que chaque pilote écrit aie besoin de réécrire la moitié du noyau (j'ai arrêté de compter combien de fois ils ont changé la stratéglie d'allocation mémoire pour les pilotes graphiques, par exemple).
En ce qui concerne l'unicité du matériel, ARM a fait pas mal de progrès pour tout ce qui est de base. Tu as une MMU standard, ainsi qu'un timer système pour faire tourner un scheduler. Déjà c'est pas mal. Autour de ça, il commence aussi à y avoir des standards de fait sur certains autres points. Par exemple, sur n'importe quelle plateforme ARM tu as toutes les chances de trouver une UART compatible 16C550 (la même qui pilote les ports série sur PC). Après pour les trucs plus avancés, cartes graphiques, etc, oui, c'est pas standard. Sur PC non plus, mais le BIOS dépanne en fournissant au moins un mode texte et du VESA pour pouvoir afficher des pixels sans accélération. Mais c'est pas vraiment là qu'est le gros du travail, en fait.
C'est vrai que c'est plus diversifié que sur l'architecture PC/x86, mais quand même, ça ne me semble pas insurmontable si les choses sont faites un minimum proprement.
[^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 3.
Moui… Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.
Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).
La différence avec les PC, c'est la présence du bus PCI qui permet d'énumérer le matériel, et auparavant de l'ISA plug-n-play. Sur ARM, il n'y a pour l'instant (en général - on trouve des machines avec un bus PCI) pas d'équivalent pour ça. Du coup, la solution c'est le device tree, qui décrit le matériel et qui normalement permet d'utiliser le même noyau partout.
L'autre souci, c'est que pour Linux, tous les drivers devraient être intégrés dans le git de Linus Torvalds pour être maintenus. Mais ce n'est pas une approche réaliste pour plein de cas. Du coup, chaque fabricant préfère vivre avec son propre fork du noyau, ce qui coûte moins cher à court et moyen terme (et il y a peu de fabricants qui maintiennent leurs puces sur le long terme - c'est plus simple de les remplacer par des versions plus récentes).
Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.
Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.
[^] # Re: suggestions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
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.
[^] # Re: Du mieux mais...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 2.
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.
[^] # Re: Question conception smartphone
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 5.
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.
[^] # Re: Question conception smartphone
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 4.
ç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).
[^] # Re: Question conception smartphone
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 4.
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).
[^] # Re: Du mieux mais...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 3.
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).
[^] # Re: Rapport performance / prix décevant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 5.
J'aime beaucoup le "crow funding" (littéralement, "financement par les corbeaux"). Je sais pas si c'était fait exprès, mais je garde!
[^] # Re: AH ah ah ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Java 9 est dehors. Évalué à 5.
ça ne crée pas les dossiers parents s'ils n'existent pas.
[^] # Re: Du mieux mais...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 3.
C'est donc moins libre qu'Android, en fait. Bon à savoir…
[^] # Re: Rapport performance / prix décevant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 3.
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".
# Latin-1 :'(
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Java 9 est dehors. Évalué à 3.
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.
[^] # Re: Computer in computer
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Dongle 4G sous environnement libre. Évalué à 2.
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.
[^] # Re: Computer in computer
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Dongle 4G sous environnement libre. Évalué à 5.
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à?
[^] # Re: Il sers à quoi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'EFF quitte le W3C. Évalué à 2.
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
[^] # Re: Computer in computer
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Dongle 4G sous environnement libre. Évalué à 2.
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".
[^] # Re: Computer in computer
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Dongle 4G sous environnement libre. Évalué à 4.
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.