Il "suffit" de faire valider le hack. Je doute que la fiabilité du hack soit plus faible que l'utilisation de vieilles disquettes 5"1/4. De toutes façon on est déjà dans une situation de type "hack", avec du matériel qui est probablement en fin de vie depuis des années, et peu claquer ou mal-fonctionner d'un jour à l'autre.
C'est amusant, en regardant la vidéo d'origine de ABC7, on sent que bien peu des intervenants dans la vidéo ont connu cette époque…
La journaliste parle bien de disquette 5"1/4, mais montre en permanence une disquette 3"1/2
Un intervenant affirme qu'à son inauguration en 1998, le système était l'état de l'art… On en doute quand même. Les disques durs existaient depuis longtemps, et la disquette 5"1/4 appartenait déjà au passé depuis une décennie.
Clou du spectacle, lorsqu'une petite fille montre la disquette 3"1/2 de la journaliste à sa maman et lui demande ce que c'est, la maman lui explique "C'est un disque dur (hard disk) !"
Leur système semble donc bien fragile en effet. Pourtant, je serais surpris qu'il ne soit pas possible de brancher un petit disque dur sur le bousin pour quelques centaines de dollars…
Je me demande, en voyant cela, à quel point les envois de données vers les RTB sont réduits (ou non) par l'usage d'un bloqueur de pub style uBlock Origin. Est-ce que ça change sensiblement la donne ? Est-ce que ça arrive trop tard ou passe à côté ?
Pour moi, en tant qu'usager lambda d'internet, c'est un des rares leviers que je vois pour contrer cette effusion de données personnelles…
Pas forcément, il dit qu'il n'a toujours pas reçu l'autorisation. À mon avis le département juridique ne veut pas se mouiller, il n'aura jamais de réponse.
Ça reste du code dupliqué et non trivial (on n'est pas sur 3-4 lignes, là).
Demander de refaire complètement l'architecture de la libsystemd
Euh, on parle de séparer un .so en deux, ou même de juste construire (et rendre dispo) un .a statique intermédiaire. Ça demande de sélectionner quel code va dans la lib de base, c'est tout.
Les dev systemd font des choses bien plus impactantes à chaque version; le dlopen par exemple n'est pas forcément plus simple à faire.
Une macro dans un .h permettrait aussi de résoudre le problème. Ce n'est pas non plus ce qu'a choisi systemd, qui préfère donner une implémentation de référence dans la doc. Ceci dit c'est peut-être quelque chose à proposer dans une MR.
Le patch est long, car OpenSSH a décidé de faire une option de build
En voyant le patch en question, je trouve cette affirmation assez fausse. Le patch est long, car coder proprement une fonction d'envoi de signal prend plus que "quelques lignes de code".
Et c'est bien la raison pour laquelle le ticket GitHub demande, à l'origine, de découper la bibliothèque "libsystemd" pour fournir des éléments plus unitaires, n'ayant réellement aucune dépendance superflue. Demande qui a été refusée d'un revers de la main, disant en gros "le dlopen résoud le problème, et on n'ira pas plus loin"… Personnellement, ça me semble très léger, et dans le cas de xz je suis persuadé qu'une variante aurait pu quand même s'activer malgré ce dlopen.
Au final, on se retrouve donc avec une belle duplication de code. Je n'ai pas compris ce refus peu (pas ?) argumenté du découpage de libsystemd.
dès qu'on va vers un constructeurs tierce, ya plus grand monde..
En ce qui concerne webOS-ports, un des problèmes c'est qu'il n'y a pas grand monde quelque soit le constructeur. C'est une équipe réduite, on est loin des dizaines de contributeurs réguliers à postmarketos.
Donc il faut faire des choix: privilégier les noyaux "mainline" par exemple. Et les plateformes les plus ouvertes sont celles où la maintenance et le debug sont les plus simples, tout bêtement.
PostmarketOS a le vent en poupe en ce moment, et tant mieux pour eux. Toutes ces communautés se connaissent, et s'aident les une les autres, ce qui permet d'avancer plus efficacement. D'ailleurs pour les noyaux mainline on va sûrement utiliser certaines de leurs briques, qui semblent intéressantes :)
Il n'y a pas de veille à faire: LineageOS continue à maintenir les patchs de sécurité pour ma version (18.1). Et les bulletins de sécurité Android, c'est tous les débuts de mois. Donc il suffit de faire un update + build une fois par mois pour être à jour.
Le site de LineageOS explique très bien comment faire ce genre de manipulation. Ça prend un peu de temps quand on ne connaît pas, mais c'est loin d'être inaccessible si on est motivé et attentif.
Quand je dis 20min, c'est 1min pour lancer le script et 19min d'attente de rebuild, c'est tout.
Mais tout cela est impossible à faire si on n'est pas maître sur son propre téléphone. Personnellement j'aimerais pouvoir reverrouiller le bootloader (en cas de vol, comme pour les Pixel), mais bizarrement pour cette fonctionnalité toute bête de sécurité il n'y a plus personne.
L'argument des applis "chiantes", c'est qu'un téléphone rooté est dans un état de sécurité inconnu. Mais les apps malicieuses s'installent via le Google Store, et exploitent les failles humaines (et parfois les CVE non corrigés): rien à voir avec l'aspect rooté ou non.
Je préférerais que mon appli bancaire vérifie la date du dernier patch de sécurité Android, ce serait déjà moins idiot. A la place, je lui fait croire que le téléphone n'est pas rooté et elle est contente: super, on a vachement avancé.
J'ai rooté le mien pour… la sécurité. Ben oui, mon "vieux" téléphone de 2018 n'a plus de mise à jour de sécurité depuis 2021 (cf le cimetière ici ), donc il a bien fallu trouver une solution autre que racheter un téléphone.
Donc voilà, je passe à du LineageOS, certes non officiel, mais au moins avec des mises à jour de sécurité. Et lorsque le mainteneur de la ROM est passé à autre chose, j'ai juste compilé ça chez moi, ça me prend 20min par mois.
Mais les apps bancaires se sentiraient plus en sécurité avec une ROM officielle vieille de 3 ans, manifestement. Allez comprendre.
Bah surtout qu'à la troisième ligne de l'article on a déjà un contournement: Install Magisk and Play Integrity Fix to ensure RCS messaging works on rooted Android phones, despite Google's restrictions
Donc voilà, même astuce que pour faire marcher les apps de banque, l'identité numérique, et les autres adorateurs de la pseudo-sécurité.
Apparemment le code semble être prêt depuis plusieurs mois, est-ce qu'il y a une raison pour ne pas encore l'accepter ? Peut-être des tests à poursuivre ?
Alors, oui, il n'est pas bien difficile d'exécuter une appli desktop sur ces OS. Mais pour l'utilisabilité, c'est tout autre chose, car un doigt fera toujours la même taille:
il faut un clavier virtuel, qui prend 1/4 de l'écran environ
les boutons doivent être plus gros pour être utilisables; de manière générale, tout ce qui implique un clic précis devient quasi inutilisable
le point précédent implique une quantité réduite de widgets à l'écran: fini les grandes barres d'outils ou les fenêtres "dockées" dans la fenêtre principale
les menus textuels deviennent aussi une horreur à utiliser
etc
En gros, les exemples d'applis desktop qui restent utilisables sur un écran de smartphone sont rares, très rares. Mais ce n'est pas une fatalité: les apps GNOME qui étaient peu utilisables en 2020, semblent être bien plus flexibles aujourd'hui.
Simplement ça demande pas mal de boulot de design en amont, et la plupart des apps desktop ne visent pas une telle flexibilité.
Le problème ce n'est pas l'intégrité du projet, mais l'intégration à l'OS. Aucun de ces projets n'utilise que Qt.
UT utilise une surcouche de QML pour quasiment tous les widgets, permettant une intégration avec certains de leurs concepts: couche réseau, "Lens", comptes en ligne, thèmes…
Plasma mobile: pareil (Kirigami)
SailfishOS: pareil (Silica)
LuneOS: la surcouche est beaucoup plus light (principalement le thème), mais le gros de la communication avec les services systèmes se fait via des appels maison de type DBus, pas avec Qt…
Pour exécuter une app UT (par exemple) sur LuneOS, il faudrait ramener tout la pile logicielle sur laquelle leur code QML s'appuie. Et globalement, ça veut dire ramener toutes les spécificités de l'autre OS sur LuneOS.
Certains ont essayé de faire des ponts mais ont rapidement abandonné devant l'effort à fournir. De plus il faudrait que les apps soient écrites avec un tel SDK, pas directement avec celui de l'OS…
Personnellement j'ai fait quelques essais pour réimplémenter l'API QML de UbuntuTouch sur LuneOS, afin d'importer directement des apps UT. Mais cela marche mal voire pas du tout: la plupart des apps sont en fait des exécutables qui embarquent le QML, et qui sont souvent liées à des libs que LuneOS n'a pas…
Bref, à suivre, car la situation actuelle ressemble effectivement à un gros gâchis de ressources.
Il y a des applis, mais c'est encore un gros point noir. La majorité de la communauté historique de webOS est maintenant passée à autre chose au fil des années, ce qui est très compréhensible.
On a quelques apps venant de webOS-OSE, mais elles sont prévues pour un format TV et donc pas toujours adaptées à un format plus petit.
Pour l'instant, la grosse majorité des applis peuvent être récupérées via l'«App Museum», qu'on peut parcourir en ligne: https://appcatalog.webosarchive.org/showMuseum.php . Mais ce sont quasiment toutes des apps datant de l'époque de webOS.
Ceci dit ce problème n'est pas spécifique à LuneOS: les apps pour smartphone GNU/Linux sont rares, et à part Ubuntu Touch et SailfishOS les autres ont le même souci (Plasma Mobile, Phosh, PostmarketOS…). Pour certaines on peut lancer des applis desktop, mais ça reste peu pratique.
Waydroid, qu'on tente de proposer sur LuneOS, pourrait contourner le problème en permettant de lancer des apps Android. Mais reste un «hack», et on continue de réfléchir à la question pour proposer mieux.
Le projet n'est pas abandonné, mais il avance à un rythme assez lent. L'équipe est très réduite, et on fait juste ça pour le plaisir dans notre temps libre. Personnellement ça me permet de jouer avec beaucoup de technos (systemd, qt, lxc, wayland, et j'en passe…) assez variée, sur un projet plutôt sympa.
Le fait de s'appuyer sur des projets existants (webOS-OSE, Yocto…) nous permet maintenant de rester à jour plus facilement, mais ne nous a pas laissé de temps pour les nouveautés visibles, comme le côté applicatif. Ce dernier reste un gros point noir à résoudre.
Papoter sur Internet est utile, c'est un échange d'idées. Et papoter n'est pas directement lié à la crise climatique comme le sont les moteurs à explosion.
Il y a d'autres façons de se faire plaisir qu'en brûlant du kérosène.
La décroissance, c'est vivre mieux, partager plus, avec un recentrage sur la solidarité entre générations.
Non, ça c'est une implémentation de la décroissance. On ne sait pas vraiment si elle est faisable, ni laquelle sera mise en œuvre, voire imposée par dame Nature.
La décroissance, c'est surtout utiliser globalement moins de ressources. Je suis beaucoup moins optimiste que toi sur la façon dont ça va se passer.
non pas parce qu'ils sont HS en eux-mêmes mais parce qu'ils questionnent certaines personnes.
ce ne sont pas les quelques personnes émoustillées par ton lien qui vont faire pencher la balance de la note du lien…
Ces dernières souhaiteraient que linuxfr.org soit déconnecté du monde réel
Ou alors, les personnes visitant linuxfr souhaitent apprendre des choses en rapport avec Linux et le libre
Ensuite, chacun est libre ou non de lire ce qui apparaît sur les pages de linuxfr.org
Et chacun est libre de noter la pertinence perçue du contenu, ça va dans les deux sens bien sûr.
si la modération est d'accord, qu'il y a de place pour tout le monde
Bien sûr, quasi aucun contenu HS n'a jamais été supprimé
Ce n'est pas tant que ça "dérange", "fait sortir de la bulle", "fissure la zone de confort", ou je ne sais quel autre choc de société, c'est juste que la plupart de ces sujets HS ne sont pas jugés pertinents ici, et encore moins en insistant encore et encore.
La tolérance est présente et tu peux continuer à poster ces liens, mais il ne faut pas non plus sur-interpréter un HS qui est noté "inutile".
[^] # Re: Autre génération
Posté par Christophe . En réponse au lien 3 disquettes font tourner le métro de cette ville depuis 26 ans, l’inquiétude monte [USA]. Évalué à 3.
Il "suffit" de faire valider le hack. Je doute que la fiabilité du hack soit plus faible que l'utilisation de vieilles disquettes 5"1/4. De toutes façon on est déjà dans une situation de type "hack", avec du matériel qui est probablement en fin de vie depuis des années, et peu claquer ou mal-fonctionner d'un jour à l'autre.
# Autre génération
Posté par Christophe . En réponse au lien 3 disquettes font tourner le métro de cette ville depuis 26 ans, l’inquiétude monte [USA]. Évalué à 6. Dernière modification le 09 avril 2024 à 17:14.
C'est amusant, en regardant la vidéo d'origine de ABC7, on sent que bien peu des intervenants dans la vidéo ont connu cette époque…
Leur système semble donc bien fragile en effet. Pourtant, je serais surpris qu'il ne soit pas possible de brancher un petit disque dur sur le bousin pour quelques centaines de dollars…
# Efficacité des bloqueurs de pub ?
Posté par Christophe . En réponse à la dépêche Les enchères en temps réel, un danger pour la vie privée mais aussi pour la sécurité européenne. Évalué à 7.
Je me demande, en voyant cela, à quel point les envois de données vers les RTB sont réduits (ou non) par l'usage d'un bloqueur de pub style uBlock Origin. Est-ce que ça change sensiblement la donne ? Est-ce que ça arrive trop tard ou passe à côté ?
Pour moi, en tant qu'usager lambda d'internet, c'est un des rares leviers que je vois pour contrer cette effusion de données personnelles…
[^] # Re: open source
Posté par Christophe . En réponse au lien Sur quel projet le plus inutile avez-vous travaillé ?. Évalué à 5. Dernière modification le 07 avril 2024 à 11:19.
Pas forcément, il dit qu'il n'a toujours pas reçu l'autorisation. À mon avis le département juridique ne veut pas se mouiller, il n'aura jamais de réponse.
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par Christophe . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 4.
Ça reste du code dupliqué et non trivial (on n'est pas sur 3-4 lignes, là).
Euh, on parle de séparer un .so en deux, ou même de juste construire (et rendre dispo) un .a statique intermédiaire. Ça demande de sélectionner quel code va dans la lib de base, c'est tout.
Les dev systemd font des choses bien plus impactantes à chaque version; le dlopen par exemple n'est pas forcément plus simple à faire.
Pour rappel, un commentaire sur GitHub avance une liste des logiciels où cela permettrait de réduire les dépendances. 150 duplications de code, tout va bien…
Une macro dans un .h permettrait aussi de résoudre le problème. Ce n'est pas non plus ce qu'a choisi systemd, qui préfère donner une implémentation de référence dans la doc. Ceci dit c'est peut-être quelque chose à proposer dans une MR.
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par Christophe . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 4.
En voyant le patch en question, je trouve cette affirmation assez fausse. Le patch est long, car coder proprement une fonction d'envoi de signal prend plus que "quelques lignes de code".
Et c'est bien la raison pour laquelle le ticket GitHub demande, à l'origine, de découper la bibliothèque "libsystemd" pour fournir des éléments plus unitaires, n'ayant réellement aucune dépendance superflue. Demande qui a été refusée d'un revers de la main, disant en gros "le dlopen résoud le problème, et on n'ira pas plus loin"… Personnellement, ça me semble très léger, et dans le cas de xz je suis persuadé qu'une variante aurait pu quand même s'activer malgré ce dlopen.
Au final, on se retrouve donc avec une belle duplication de code. Je n'ai pas compris ce refus peu (pas ?) argumenté du découpage de libsystemd.
[^] # Re: Abondonner au profit de Libre-Office
Posté par Christophe . En réponse au lien OpenOffice 4.1.15 est là (la version 4.2 toujours en attente) [correction de bugs divers]. Évalué à 6.
Non.
Oui.
my 2 cents
[^] # Re: Dépôt GitLab
Posté par Christophe . En réponse au journal Jouons un peu avec linuxfr et CSS3. Évalué à 6.
Un petit screenshot du résultat serait sympa à avoir dans le README, j'ai un peu la flemme de l'appliquer juste pour voir à quoi ça ressemble…
[^] # Re: malheureusement
Posté par Christophe . En réponse à la dépêche Sortie de LuneOS « Eiskaffee ». Évalué à 2.
En ce qui concerne webOS-ports, un des problèmes c'est qu'il n'y a pas grand monde quelque soit le constructeur. C'est une équipe réduite, on est loin des dizaines de contributeurs réguliers à postmarketos.
Donc il faut faire des choix: privilégier les noyaux "mainline" par exemple. Et les plateformes les plus ouvertes sont celles où la maintenance et le debug sont les plus simples, tout bêtement.
PostmarketOS a le vent en poupe en ce moment, et tant mieux pour eux. Toutes ces communautés se connaissent, et s'aident les une les autres, ce qui permet d'avancer plus efficacement. D'ailleurs pour les noyaux mainline on va sûrement utiliser certaines de leurs briques, qui semblent intéressantes :)
[^] # Re: Précisions
Posté par Christophe . En réponse au lien Linux n’a jamais été aussi populaire, le système d’exploitation libre bat un record. Évalué à 5.
Le support sera étendu de 5 ans.
[^] # Re: Et puis root est-ce encore nécessaire aujourd'hui ?
Posté par Christophe . En réponse au lien Google Messages is blocking RCS texts on rooted Android phones (via OSnews) - Android Police. Évalué à 10.
Il n'y a pas de veille à faire: LineageOS continue à maintenir les patchs de sécurité pour ma version (18.1). Et les bulletins de sécurité Android, c'est tous les débuts de mois. Donc il suffit de faire un update + build une fois par mois pour être à jour.
Le site de LineageOS explique très bien comment faire ce genre de manipulation. Ça prend un peu de temps quand on ne connaît pas, mais c'est loin d'être inaccessible si on est motivé et attentif.
Quand je dis 20min, c'est 1min pour lancer le script et 19min d'attente de rebuild, c'est tout.
Mais tout cela est impossible à faire si on n'est pas maître sur son propre téléphone. Personnellement j'aimerais pouvoir reverrouiller le bootloader (en cas de vol, comme pour les Pixel), mais bizarrement pour cette fonctionnalité toute bête de sécurité il n'y a plus personne.
L'argument des applis "chiantes", c'est qu'un téléphone rooté est dans un état de sécurité inconnu. Mais les apps malicieuses s'installent via le Google Store, et exploitent les failles humaines (et parfois les CVE non corrigés): rien à voir avec l'aspect rooté ou non.
Je préférerais que mon appli bancaire vérifie la date du dernier patch de sécurité Android, ce serait déjà moins idiot. A la place, je lui fait croire que le téléphone n'est pas rooté et elle est contente: super, on a vachement avancé.
[^] # Re: Et puis root est-ce encore nécessaire aujourd'hui ?
Posté par Christophe . En réponse au lien Google Messages is blocking RCS texts on rooted Android phones (via OSnews) - Android Police. Évalué à 8.
J'ai rooté le mien pour… la sécurité. Ben oui, mon "vieux" téléphone de 2018 n'a plus de mise à jour de sécurité depuis 2021 (cf le cimetière ici ), donc il a bien fallu trouver une solution autre que racheter un téléphone.
Donc voilà, je passe à du LineageOS, certes non officiel, mais au moins avec des mises à jour de sécurité. Et lorsque le mainteneur de la ROM est passé à autre chose, j'ai juste compilé ça chez moi, ça me prend 20min par mois.
Mais les apps bancaires se sentiraient plus en sécurité avec une ROM officielle vieille de 3 ans, manifestement. Allez comprendre.
[^] # Re: Et l'impact sera...
Posté par Christophe . En réponse au lien Google Messages is blocking RCS texts on rooted Android phones (via OSnews) - Android Police. Évalué à 4.
Bah surtout qu'à la troisième ligne de l'article on a déjà un contournement: Install Magisk and Play Integrity Fix to ensure RCS messaging works on rooted Android phones, despite Google's restrictions
Donc voilà, même astuce que pour faire marcher les apps de banque, l'identité numérique, et les autres adorateurs de la pseudo-sécurité.
# Migration Rails 7
Posté par Christophe . En réponse au journal LinuxFr.org : première quinzaine de février 2024. Évalué à 2.
Apparemment le code semble être prêt depuis plusieurs mois, est-ce qu'il y a une raison pour ne pas encore l'accepter ? Peut-être des tests à poursuivre ?
[^] # Re: Il y a des applis ?
Posté par Christophe . En réponse à la dépêche Sortie de LuneOS « Eiskaffee ». Évalué à 10.
Alors, oui, il n'est pas bien difficile d'exécuter une appli desktop sur ces OS. Mais pour l'utilisabilité, c'est tout autre chose, car un doigt fera toujours la même taille:
En gros, les exemples d'applis desktop qui restent utilisables sur un écran de smartphone sont rares, très rares. Mais ce n'est pas une fatalité: les apps GNOME qui étaient peu utilisables en 2020, semblent être bien plus flexibles aujourd'hui.
Simplement ça demande pas mal de boulot de design en amont, et la plupart des apps desktop ne visent pas une telle flexibilité.
[^] # Re: Il y a des applis ?
Posté par Christophe . En réponse à la dépêche Sortie de LuneOS « Eiskaffee ». Évalué à 8.
Le problème ce n'est pas l'intégrité du projet, mais l'intégration à l'OS. Aucun de ces projets n'utilise que Qt.
Pour exécuter une app UT (par exemple) sur LuneOS, il faudrait ramener tout la pile logicielle sur laquelle leur code QML s'appuie. Et globalement, ça veut dire ramener toutes les spécificités de l'autre OS sur LuneOS.
Certains ont essayé de faire des ponts mais ont rapidement abandonné devant l'effort à fournir. De plus il faudrait que les apps soient écrites avec un tel SDK, pas directement avec celui de l'OS…
Personnellement j'ai fait quelques essais pour réimplémenter l'API QML de UbuntuTouch sur LuneOS, afin d'importer directement des apps UT. Mais cela marche mal voire pas du tout: la plupart des apps sont en fait des exécutables qui embarquent le QML, et qui sont souvent liées à des libs que LuneOS n'a pas…
Bref, à suivre, car la situation actuelle ressemble effectivement à un gros gâchis de ressources.
[^] # Re: Il y a des applis ?
Posté par Christophe . En réponse à la dépêche Sortie de LuneOS « Eiskaffee ». Évalué à 10.
Il y a des applis, mais c'est encore un gros point noir. La majorité de la communauté historique de webOS est maintenant passée à autre chose au fil des années, ce qui est très compréhensible.
On a quelques apps venant de webOS-OSE, mais elles sont prévues pour un format TV et donc pas toujours adaptées à un format plus petit.
Pour l'instant, la grosse majorité des applis peuvent être récupérées via l'«App Museum», qu'on peut parcourir en ligne: https://appcatalog.webosarchive.org/showMuseum.php . Mais ce sont quasiment toutes des apps datant de l'époque de webOS.
Ceci dit ce problème n'est pas spécifique à LuneOS: les apps pour smartphone GNU/Linux sont rares, et à part Ubuntu Touch et SailfishOS les autres ont le même souci (Plasma Mobile, Phosh, PostmarketOS…). Pour certaines on peut lancer des applis desktop, mais ça reste peu pratique.
Waydroid, qu'on tente de proposer sur LuneOS, pourrait contourner le problème en permettant de lancer des apps Android. Mais reste un «hack», et on continue de réfléchir à la question pour proposer mieux.
[^] # Re: développement
Posté par Christophe . En réponse à la dépêche Sortie de LuneOS « Eiskaffee ». Évalué à 10.
Le projet n'est pas abandonné, mais il avance à un rythme assez lent. L'équipe est très réduite, et on fait juste ça pour le plaisir dans notre temps libre. Personnellement ça me permet de jouer avec beaucoup de technos (systemd, qt, lxc, wayland, et j'en passe…) assez variée, sur un projet plutôt sympa.
Le fait de s'appuyer sur des projets existants (webOS-OSE, Yocto…) nous permet maintenant de rester à jour plus facilement, mais ne nous a pas laissé de temps pour les nouveautés visibles, comme le côté applicatif. Ce dernier reste un gros point noir à résoudre.
[^] # Re: Complément.
Posté par Christophe . En réponse au lien Fuite Viamedis et Almerys se joindre à la plainte. Évalué à 3.
Et… comment sait-on si on a été victime ?
[^] # Re: C'est une publicité ?
Posté par Christophe . En réponse au lien Transformez Thunderbird en champion collaboratif. Évalué à 2. Dernière modification le 25 janvier 2024 à 15:24.
En partant de la doc, on tombe sur leur repo git:
https://forge.bluemind.net/stash/repos?visibility=public
Edit: malgré tout, il semble y avoir des soucis technique pour accéder concrètement au code
[^] # Re: Évolution de l'aviation: bon sens
Posté par Christophe . En réponse au journal L'aviation a-t-elle un avenir ?. Évalué à 5.
Papoter sur Internet est utile, c'est un échange d'idées. Et papoter n'est pas directement lié à la crise climatique comme le sont les moteurs à explosion.
Il y a d'autres façons de se faire plaisir qu'en brûlant du kérosène.
[^] # Re: Évolution de l'aviation: bon sens
Posté par Christophe . En réponse au journal L'aviation a-t-elle un avenir ?. Évalué à 10.
Sauf que l'aviation du dimanche, ça ne sert… à rien.
Alors ça pollue moins qu'un A321, mais le rapport utilité/pollution reste en faveur de celui qui a une utilité.
Payer la TICE ne change pas grand chose, une fois que le CO2 est dans l'atmosphère c'est trop tard.
[^] # Re: bonne nouvelle
Posté par Christophe . En réponse au lien France: recul de la natalité de 6,8% sur les 11 premiers mois de 2023 par rapport à un an auparavant. Évalué à 5.
Non, ça c'est une implémentation de la décroissance. On ne sait pas vraiment si elle est faisable, ni laquelle sera mise en œuvre, voire imposée par dame Nature.
La décroissance, c'est surtout utiliser globalement moins de ressources. Je suis beaucoup moins optimiste que toi sur la façon dont ça va se passer.
[^] # Re: Petite question sérieuse et sincère
Posté par Christophe . En réponse au lien Histoire de l'art : comment les femmes en ont été gommées. Évalué à 10.
Au risque de te décevoir:
bof, pas vraiment
ce ne sont pas les quelques personnes émoustillées par ton lien qui vont faire pencher la balance de la note du lien…
Ou alors, les personnes visitant linuxfr souhaitent apprendre des choses en rapport avec Linux et le libre
Et chacun est libre de noter la pertinence perçue du contenu, ça va dans les deux sens bien sûr.
Bien sûr, quasi aucun contenu HS n'a jamais été supprimé
Ce n'est pas tant que ça "dérange", "fait sortir de la bulle", "fissure la zone de confort", ou je ne sais quel autre choc de société, c'est juste que la plupart de ces sujets HS ne sont pas jugés pertinents ici, et encore moins en insistant encore et encore.
La tolérance est présente et tu peux continuer à poster ces liens, mais il ne faut pas non plus sur-interpréter un HS qui est noté "inutile".
[^] # Re: Qui utilise au quotidien ?
Posté par Christophe . En réponse au lien EFL 1.27 et Enlightenment 0.26.0 sont sortis. Évalué à 2. Dernière modification le 26 décembre 2023 à 16:49.
Ça fait trois avenirs ;)
Edit: j'ai posté trop vite…