Il est important de dénoncer les solutions qui se prétendent "libres" mais ne le sont pas, mais il est tout aussi important de ne pas se planter quand on fait une telle accusation, sinon c'est contre-productif.
Personnellement, j'aurais préféré que le code comporte des commentaires, ce serait plus intéressant à lire, et motiverait peut-être d'autres personnes pour contribuer… Mais bon je salue l'effort.
Pour les languages, dans MS-DOS, on utilisait des Codepage (pour l'affichage des polices) et des Country Codes (pour la langue). C'était des nombres, tirés apparemment de l'indicatif international de téléphonie: http://manmrk.net/tutorials/DOS/help/country.htm .
Ça aurait été intéressant, mais dans cette réalité ce n'est pas possible. Le pays qui possède ce genre de constellation (GPS, Starlink, Glonaass etc) a un atout stratégique énorme sur ses voisins.
Dans ce genre de situation (atout stratégique, péril non évident et non immédiat), les dirigeants font quasiment toujours la même chose: tout d'abord chacun pour soi (et essayer de rafler la mise du 1er arrivé), et une fois la domination établie on regarde et on demande aux autres de ne pas faire la même "bêtise".
Au sein d'un même pays on a le gouvernement et le parlement pour réguler un peu ce phénomène. Au niveau mondial, rien de tel.
Il ne manque plus qu'à publier des nouvelles versions des SDKs et des clients du Password Manager pour que ces derniers redeviennent correctement libre (le commentaire dit bien que les clients du password manager sont déjà indépendants du secret manager).
Le problème est apparu il y a 3 semaines seulement, y a-t-il eu ne serait-ce qu'une version publiée du SDK et/ou de des clients qui auraient pu ne pas être libres ?
Je pense que bien peu de gens utilisent l'interface web proposée par le serveur. C'est pas pratique, tout simplement, à part pour quelques tâche de maintenance.
Tout le monde utilise le plugin pour navigateur, et/ou l'application pour téléphone.
La question n'était pas tant de savoir le pourquoi mais plutôt d'acter que cela impliquait des renoncements fonctionnels non acceptables pour certains.
Tout à fait, mais je voulais quand même nuancer le tableau noir dressé ici.Et en général on choisit un modèle bien géré avant de se lancer dans cette voie.
Pris mot à mot, cette phrase n'est pas si rassurante que ça.
Tant mieux :) Il faut être lucide si on veut s'aventurer sur un OS encore jeune. Ensuite, à chacun de placer ses propres priorités.
En général le matériel marche plutôt bien, l'exception c'est vraiment l'appareil photo, où même sur Android il est difficile de le faire fonctionner correctement sans la ROM d'origine.
C'est un plat de spaghetti entre les firmwares mystérieux en 50 morceaux, une initialisation du matériel partagée entre l'appli constructeur, les firmwares et l'OS, et de petites variations (critiques) entre chaque modèle vendu. Tout ça n'est bien sûr documenté nulle part.
permettre la modification et la redistribution d'un soft dans son intégralité avec la possibilité de l'adapter pour qu'il soit fonctionnel quelque soit le cas de figure
Il y a sûrement plusieurs façons de lire la liberté 1 (liberté d'étudier un programme et de le modifier pour ses besoins), mais le fait d'avoir un SDK non libre n'est pas forcément un frein. Tout dépend de ce qu'on nomme le "programme" en question…
Après je reste un peu surpris par ce mini "scandale". Le côté serveur de Bitwarden n'a jamais été libre, on ne peut pas l'auto-héberger. C'est pourtant un composant central de l'offre Bitwarden. Alors le fait que le SDK ne soit pas libre, je trouve ça assez secondaire en fait.
certaines entreprises qui vendent du support libre office, n'y contribue pas
Je ne vois pas le problème. Ces entreprises contribuent à diffuser libreoffice dans les milieux professionnels, et participent donc à son adoption à plus grande échelle.
Par contre, logiquement, elles devraient avoir un support moins efficace que les entreprises qui contribuent au code et connaissent mieux les rouage internes du logiciel. Si ce n'est pas le cas, alors il y a un problème chez ces dernières, pas chez Linagora.
J'utilise depuis un an imapsync pour faire un backup de mon GMail vers mon serveur IMAP local, et ça marche très bien.
Il y a des options pour limiter la quantité de données téléchargée par imapsync, et donc même si la synchro initiale se fait sur plusieurs jours ça devrait bien se passer.
Aucun problème avec le login, j'ai juste créé un mot de passe dédié pour l'accès depuis imapsync.
C'est rassurant de savoir que si un jour Gmail pose des conditions inacceptables pour moi, je peux tout simplement utiliser mon backup IMAP directement, ou encore le reverser sur un autre provider de mail de mon choix.
Halium/libhybris est un projet né d'un choix pragmatique: à l'époque, la possibilité d'avoir une gestion décente du matériel avec un noyau "mainline" était quasi inexistante.
La dépendance à Google n'est pas vraiment le problème ici: la couche Android est minimale, et ne sert qu'à dialoguer avec les pilotes. On peut garder un vieil Android, le risque pour les données ou l'appareil est quand même très restreint.
Le gros souci, c'est plutôt le noyau, qui est lié aux pilotes non maintenus par le constructeur: on est condamné à utiliser un vieux noyau, qui ne bougera quasiment plus.
Et pour qualcomm, le mainline ne résoud pas grand chose: si demain ils décident d'abandonner le protocole QRTR pour le modem 4G/5G et passent à un truc non documenté et obscur, ofono et ModemManager mettront un certain temps avant de trouver une solution, si jamais elle existe.
Le tableau n'est pas si sombre que ça: de façon générale, les téléphones avec SoC qualcomm arrivent assez bien à tourner avec un noyau récent. En m'appuyant sur les efforts faits par la communauté postmarketos, j'ai pu faire tourner "assez facilement" le Xiaomi Note 5 et le Xiaomi Mi A1 avec un noyau plutôt récent (6.9.1), et avec quasi toutes les fonctionnalités (le capteur photo reste un point noir).
Ofono et ModemManager ont maintenant une bonne gestion du protocole utilisé par Qualcomm, et Mesa n'est pas trop en retard sur les GPU Adreno.
Donc c'est loin d'être idéal, mais c'est largement mieux que la situation d'il y a 10 ans !
Déjà, bravo pour ton travail sur Droidian, l'intégration dans le Gnome Control Center est un gros plus pour l'utilisation au quotidien.
Est-ce qu'il y a des interactions entre Mobian et Droidian ? Une mise en commun de certaines parties ?
De ce que je comprends la principale différence est que Mobian est axé sur le support "mainline", là où Droidian s'appuie explicitement sur libhybris. Mais vu de loin, passé cette couche de support hardware, le gros du boulot semble commun aux deux… Est-ce le cas ?
Pour LuneOS (dont je fais partie), on fait un peu des deux, avec une transition (récente) vers le mainline; toute la partie UI/Middleware est commune.
Ce n'est pas parce que ton login/password Github a fuité que ta clé de génération TOTP a fuité aussi…
Et si ton browser est compromis, je ne suis pas sûr que ça change grand chose.
L'objectif de Doctolib est peut-être simplement de se faire des sous en revendant cette base de données de discussions, dans laquelle il n'y a aucun texte généré par IA.
J'ai l'impression que cela devient assez rare, et donc pourrait être revendu à bon prix…
Et pour confidentialité des échanges, bah, tant pis hein !
En effet, le système ressemble beaucoup au système "Swish", qui a complètement conquis la population suédoise. Là-bas payer avec de la monnaie est devenu l'exception, et le verbe "swisher" est entré dans le vocabulaire du quotidien.
Et avant même Swish, il est aussi possible de régler ses factures facilement, avec un numéro de virement. Un jour, peut-être, en France…
Et l'IBAN existe encore là-bas, bien entendu, ça n'a pas le même usage.
Cette faille permet une exécution de code dans le contexte du plugin "foomatic" de cups, et donc dans le contexte de cupsd.
Sur mon Archlinux, c'est donc en tant que root. C'est peut-être "lp" chez toi.
Le gros problème pour moi ce sont les constructeurs qui ne proposent plus de mises à jour de l'OS et surtout de patches de sécurité au delà de plusieurs années
Normalement, cela aurait dû être en grande partie réglé avec l'introduction du projet Treble dans Android: une séparation claire entre la partie OS « générique », qui peut être mise à jour par Google, et la partie « constructeur » qui est souvent rapidement laissée à l'abandon par ce dernier.
Mais cette belle idée est mise à mal par le comportement des constructeurs:
- ils veulent proposer leur surcouche de la partie générique, et donc on dépend à nouveau d'eux pour la mise à jour
- la séparation générique/constructeur est parfois mal faite
- on ne peut pas facilement changer la partie générique pour revenir sur un Android « standard » (bootloader bloqué, et souvent impossible à re-bloquer lorsqu'on a mis un OS plus à jour…)
On voit bien que l'argument de la sécurité, utilisé aujourd'hui pour enfermer l'utilisateur dans un Android bourré de pubs et/ou de services du constructeur, est complètement dévoyé.
[^] # Re: slint
Posté par Christophe . En réponse au journal TapTempo en Slint. Évalué à 10.
Et on appellerait ça une licence ?…
Il est important de dénoncer les solutions qui se prétendent "libres" mais ne le sont pas, mais il est tout aussi important de ne pas se planter quand on fait une telle accusation, sinon c'est contre-productif.
[^] # Re: points intéressants : le multi-plateformes
Posté par Christophe . En réponse au lien Après 3-4 ans d'interruption Le développement de POV-Ray reprend. Évalué à 4.
C'est amusant, je viens de lire le message qui est à l'origine de POV-Ray, et dans les conditions de création du projet il y avait:
If you decide to do this, I would like to place a few rules on the
packages (or at least those developed from DKB):
Je ne sais pas à quel moment le 3ème point est passé à la trappe…
[^] # Re: Nostalgie…
Posté par Christophe . En réponse au lien MSDOS-0. Évalué à 3.
Personnellement, j'aurais préféré que le code comporte des commentaires, ce serait plus intéressant à lire, et motiverait peut-être d'autres personnes pour contribuer… Mais bon je salue l'effort.
Pour les languages, dans MS-DOS, on utilisait des Codepage (pour l'affichage des polices) et des Country Codes (pour la langue). C'était des nombres, tirés apparemment de l'indicatif international de téléphonie: http://manmrk.net/tutorials/DOS/help/country.htm .
[^] # Re: autre dimension?
Posté par Christophe . En réponse au lien Pollution du spectre électro-magnétique par l’industrie numérique. Évalué à 3.
Ça aurait été intéressant, mais dans cette réalité ce n'est pas possible. Le pays qui possède ce genre de constellation (GPS, Starlink, Glonaass etc) a un atout stratégique énorme sur ses voisins.
Dans ce genre de situation (atout stratégique, péril non évident et non immédiat), les dirigeants font quasiment toujours la même chose: tout d'abord chacun pour soi (et essayer de rafler la mise du 1er arrivé), et une fois la domination établie on regarde et on demande aux autres de ne pas faire la même "bêtise".
Au sein d'un même pays on a le gouvernement et le parlement pour réguler un peu ce phénomène. Au niveau mondial, rien de tel.
[^] # Re: D'autres liens
Posté par Christophe . En réponse au journal La fin de la 2G : quelles solutions pour une communication stable et flexible ?. Évalué à 3.
Je te laisse deviner ce qui va se passer :)
[^] # Re: Les clients peuvent à nouveau être libres
Posté par Christophe . En réponse au lien bitwarden sdk - relicensed to GPLv3. Évalué à 3.
Le problème est apparu il y a 3 semaines seulement, y a-t-il eu ne serait-ce qu'une version publiée du SDK et/ou de des clients qui auraient pu ne pas être libres ?
[^] # Re: Compromission de l'appli web : un oubli?
Posté par Christophe . En réponse au lien Forensic analysis of bitwarden self-hosted server. Évalué à 2.
Je pense que bien peu de gens utilisent l'interface web proposée par le serveur. C'est pas pratique, tout simplement, à part pour quelques tâche de maintenance.
Tout le monde utilise le plugin pour navigateur, et/ou l'application pour téléphone.
Ceci dit la remarque reste valide j'imagine.
[^] # Re: que maintenant?
Posté par Christophe . En réponse au lien Android 16 will include a Terminal and full Linux VM support with GPU acceleration. Évalué à 2.
Tout à fait, mais je voulais quand même nuancer le tableau noir dressé ici.Et en général on choisit un modèle bien géré avant de se lancer dans cette voie.
Tant mieux :) Il faut être lucide si on veut s'aventurer sur un OS encore jeune. Ensuite, à chacun de placer ses propres priorités.
[^] # Re: que maintenant?
Posté par Christophe . En réponse au lien Android 16 will include a Terminal and full Linux VM support with GPU acceleration. Évalué à 4.
En général le matériel marche plutôt bien, l'exception c'est vraiment l'appareil photo, où même sur Android il est difficile de le faire fonctionner correctement sans la ROM d'origine.
C'est un plat de spaghetti entre les firmwares mystérieux en 50 morceaux, une initialisation du matériel partagée entre l'appli constructeur, les firmwares et l'OS, et de petites variations (critiques) entre chaque modèle vendu. Tout ça n'est bien sûr documenté nulle part.
[^] # Re: Un bug ?
Posté par Christophe . En réponse au lien bitwarden - Desktop version 2024.10.0 is no longer free software. Évalué à 3.
Il y a sûrement plusieurs façons de lire la liberté 1 (liberté d'étudier un programme et de le modifier pour ses besoins), mais le fait d'avoir un SDK non libre n'est pas forcément un frein. Tout dépend de ce qu'on nomme le "programme" en question…
Après je reste un peu surpris par ce mini "scandale". Le côté serveur de Bitwarden n'a jamais été libre, on ne peut pas l'auto-héberger. C'est pourtant un composant central de l'offre Bitwarden. Alors le fait que le SDK ne soit pas libre, je trouve ça assez secondaire en fait.
[^] # Re: Arf ça casse
Posté par Christophe . En réponse au lien Pour ceux qui s'intéressent au support de LibreOffice pour l'état français. Évalué à 4.
Je ne vois pas le problème. Ces entreprises contribuent à diffuser libreoffice dans les milieux professionnels, et participent donc à son adoption à plus grande échelle.
Par contre, logiquement, elles devraient avoir un support moins efficace que les entreprises qui contribuent au code et connaissent mieux les rouage internes du logiciel. Si ce n'est pas le cas, alors il y a un problème chez ces dernières, pas chez Linagora.
# Synchro hebdo sans problème
Posté par Christophe . En réponse au message imapsync, migration : google et quota quotidien dépassé?. Évalué à 2.
J'utilise depuis un an imapsync pour faire un backup de mon GMail vers mon serveur IMAP local, et ça marche très bien.
Il y a des options pour limiter la quantité de données téléchargée par imapsync, et donc même si la synchro initiale se fait sur plusieurs jours ça devrait bien se passer.
Aucun problème avec le login, j'ai juste créé un mot de passe dédié pour l'accès depuis imapsync.
C'est rassurant de savoir que si un jour Gmail pose des conditions inacceptables pour moi, je peux tout simplement utiliser mon backup IMAP directement, ou encore le reverser sur un autre provider de mail de mon choix.
[^] # Re: noyau figé
Posté par Christophe . En réponse au journal Droidian: un OS fonctionnel pour les téléphones Android. Évalué à 3. Dernière modification le 17 octobre 2024 à 16:41.
Halium/libhybris est un projet né d'un choix pragmatique: à l'époque, la possibilité d'avoir une gestion décente du matériel avec un noyau "mainline" était quasi inexistante.
La dépendance à Google n'est pas vraiment le problème ici: la couche Android est minimale, et ne sert qu'à dialoguer avec les pilotes. On peut garder un vieil Android, le risque pour les données ou l'appareil est quand même très restreint.
Le gros souci, c'est plutôt le noyau, qui est lié aux pilotes non maintenus par le constructeur: on est condamné à utiliser un vieux noyau, qui ne bougera quasiment plus.
Et pour qualcomm, le mainline ne résoud pas grand chose: si demain ils décident d'abandonner le protocole QRTR pour le modem 4G/5G et passent à un truc non documenté et obscur, ofono et ModemManager mettront un certain temps avant de trouver une solution, si jamais elle existe.
[^] # Re: Liens avec Mobian ?
Posté par Christophe . En réponse au journal Droidian: un OS fonctionnel pour les téléphones Android. Évalué à 2.
Le tableau n'est pas si sombre que ça: de façon générale, les téléphones avec SoC qualcomm arrivent assez bien à tourner avec un noyau récent. En m'appuyant sur les efforts faits par la communauté postmarketos, j'ai pu faire tourner "assez facilement" le Xiaomi Note 5 et le Xiaomi Mi A1 avec un noyau plutôt récent (6.9.1), et avec quasi toutes les fonctionnalités (le capteur photo reste un point noir).
Ofono et ModemManager ont maintenant une bonne gestion du protocole utilisé par Qualcomm, et Mesa n'est pas trop en retard sur les GPU Adreno.
Donc c'est loin d'être idéal, mais c'est largement mieux que la situation d'il y a 10 ans !
# Liens avec Mobian ?
Posté par Christophe . En réponse au journal Droidian: un OS fonctionnel pour les téléphones Android. Évalué à 3. Dernière modification le 17 octobre 2024 à 10:03.
Déjà, bravo pour ton travail sur Droidian, l'intégration dans le Gnome Control Center est un gros plus pour l'utilisation au quotidien.
Est-ce qu'il y a des interactions entre Mobian et Droidian ? Une mise en commun de certaines parties ?
De ce que je comprends la principale différence est que Mobian est axé sur le support "mainline", là où Droidian s'appuie explicitement sur libhybris. Mais vu de loin, passé cette couche de support hardware, le gros du boulot semble commun aux deux… Est-ce le cas ?
Pour LuneOS (dont je fais partie), on fait un peu des deux, avec une transition (récente) vers le mainline; toute la partie UI/Middleware est commune.
[^] # Re: TOTP
Posté par Christophe . En réponse au journal ultimatum de github pour passer au 2FA. Évalué à 6.
Ce n'est pas parce que ton login/password Github a fuité que ta clé de génération TOTP a fuité aussi…
Et si ton browser est compromis, je ne suis pas sûr que ça change grand chose.
[^] # Re: il est donc temps
Posté par Christophe . En réponse au lien Chrome prévient qu'uBlock Origin et d’autres extensions ne seront bientôt plus compatibles. Évalué à 3.
Alors, vu le traitement de JPEG-XL, je ne me ferais pas trop d'illusions.
Mais sait-on jamais, sur un malentendu…
[^] # Re: postmarketos
Posté par Christophe . En réponse au journal Danew DBook 110 : l'ordinateur des nouilles. Évalué à 3.
Quelqu'un a porté une vieille Debian Buster sur le Odroid Go Advance, qui a le même chipset RK3326.
Donc avec un peu de motivation, il peut peut-être installer une Debian !
[^] # Re: Toujours pareil
Posté par Christophe . En réponse au lien Doctolib déploie une IA pour capter et analyser les conversations patients-médecins ! . Évalué à 3.
Trop tard:
- LinuxFR.org a déjà été indexé par les générateurs LLM
- Quelques journaux ou réponses contiennent déjà du texte issue de LLM…
[^] # Re: Toujours pareil
Posté par Christophe . En réponse au lien Doctolib déploie une IA pour capter et analyser les conversations patients-médecins ! . Évalué à 8.
L'objectif de Doctolib est peut-être simplement de se faire des sous en revendant cette base de données de discussions, dans laquelle il n'y a aucun texte généré par IA.
J'ai l'impression que cela devient assez rare, et donc pourrait être revendu à bon prix…
Et pour confidentialité des échanges, bah, tant pis hein !
[^] # Re: je doute que ce soit la fin de l'IBAN
Posté par Christophe . En réponse au lien C’est la fin de l’IBAN : les banques françaises s’allient pour simplifier les virements avec Wero. Évalué à 6.
En effet, le système ressemble beaucoup au système "Swish", qui a complètement conquis la population suédoise. Là-bas payer avec de la monnaie est devenu l'exception, et le verbe "swisher" est entré dans le vocabulaire du quotidien.
Et avant même Swish, il est aussi possible de régler ses factures facilement, avec un numéro de virement. Un jour, peut-être, en France…
Et l'IBAN existe encore là-bas, bien entendu, ça n'a pas le même usage.
[^] # Re: Infos à vérifier
Posté par Christophe . En réponse au journal Faille d'exécution de code à distance dans cups. Évalué à 4.
Cette faille permet une exécution de code dans le contexte du plugin "foomatic" de cups, et donc dans le contexte de cupsd.
Sur mon Archlinux, c'est donc en tant que root. C'est peut-être "lp" chez toi.
[^] # Re: Obsolescence programmée
Posté par Christophe . En réponse au journal android : obsolescence et backup. Évalué à 6.
Normalement, cela aurait dû être en grande partie réglé avec l'introduction du projet Treble dans Android: une séparation claire entre la partie OS « générique », qui peut être mise à jour par Google, et la partie « constructeur » qui est souvent rapidement laissée à l'abandon par ce dernier.
Mais cette belle idée est mise à mal par le comportement des constructeurs:
- ils veulent proposer leur surcouche de la partie générique, et donc on dépend à nouveau d'eux pour la mise à jour
- la séparation générique/constructeur est parfois mal faite
- on ne peut pas facilement changer la partie générique pour revenir sur un Android « standard » (bootloader bloqué, et souvent impossible à re-bloquer lorsqu'on a mis un OS plus à jour…)
On voit bien que l'argument de la sécurité, utilisé aujourd'hui pour enfermer l'utilisateur dans un Android bourré de pubs et/ou de services du constructeur, est complètement dévoyé.
[^] # Re: Java !
Posté par Christophe . En réponse au lien De l'intérêt majeur de choisir un langage memory safe pour tout nouveau code d'un projet existant. Évalué à 10.
Forcément, une fois que tu as alloué toute la mémoire à la VM, il n'y a plus la place pour une fuite !
[^] # Re: désactivé par défaut
Posté par Christophe . En réponse au journal Faille d'exécution de code à distance dans cups. Évalué à 5.
Il était actif par défaut sur ma Debian bookworm toute neuve…