Je n'ai pas pratiqué TT-RSS, donc je ne sais pas si c'est équivalent.
Mais j'utilise FreshRSS, qui n'est pas parfais mais me semble relativement complet et fonctionne. C'est aussi du php, ça fonctionne bien en auto-hébergement, c'est assez bien intégré à Yunohost, …
M'intéressant un peu aux librairies/outils de GUI utilisable en Rust, je l'avais vu passer mais pas encore pris le temps de regarder plus en détails.
J'avais déjà des doutes sur le fait qu'il serait adapté à mon usage. Je vise plutôt l'édition de données, la création de contenu, que l'affichage de données.
Est-ce qu'une (grande) partie des problèmes dans le publique ne serait pas du justement au fait qu'on y applique les logiques du privé : la recherche de la rentabilité, réduction des coûts, etc ?
Du coup, je ne voie pas comment privatiser encore plus améliorerais les choses.
Le privé n'est pas forcément mieux, mais au moins on n’est pas face à un monopole donc on a le choix.
Qui à le choix ? Quel choix ?
Par exemple les délégations de service publique pour l'eau, en tant que consommateur tu n'as pas le choix. Et c'est souvent du privé, même s'il y un un retour en arrière dans beaucoup de collectivité, car finalement le privé c'est pas si bien : plus cher et pas meilleur service.
Pour le reste force est de constater que bien souvent le public fait pire.
Désolé mais je ne fais pas le même constat.
Qu'est ce que le public fais "pire" ? pire pour qui ?
Par contre je crois que "le public" fait de moins en moins bien.
Note : enfin le public étatique, il me semble que le public des collectivités locales par exemple fonctionne plutôt bien mieux, en tous cas d'après des échos que j'ai autour de moi, il semble un avoir par endroit un vrai regain de "public".
Et je pense que c'est parce que un nombre important de la classe dirigeante fait en sorte de casser le service public justement pour ouvrir la voie à la privatisation. Il me semble d'ailleurs, que c'est souvent les mêmes qui prennent des décisions qui dégrade le service public et qui ensuite dise qu'il ne fonctionne pas bien et qu'il faut privatiser.
Et je pense que la SNCF est clairement dans ce cas.
De ce que je perçois, la SNCF est aujourd'hui une structure géré comme une boite privé, du coup je ne considère pas que c'est un bonne exemple pour expliquer que le public ne fonctionne pas.
Dsl j'ai du mal a comprendre ce que tu veux dire, donc je ne suis pas certain d'avoir bien compris.
Je suis plutôt d'accords que l'argent public est loin d'être utiliser au mieux. Et je dirais (en simplifiant) que c'est en grande partie la cause de politiques de libéralisation.
Quand tu dit "le privé fait bien mieux", tu pense à quoi ? Le privé fait mieux quoi ? Pour qui ?
Parce que dans ma vision, si le public n'est pas exempt de défaut, le privé n'est pas la panacée.
Après concernant la vision de société vers laquelle on souhaite se diriger, de mon coté j'ai plus envie d'un monde ou l'on remet plus de public, en améliorant le public que plus de privé.
Le coté individualiste du privé, me semble incompatible avec les contraintes au-quelle l'humanité doit faire face, tel que les ressources fini de notre magnifique planète terre face à la croissance continue de l'humanité.
Et pour ça avant, il faut voir pourquoi on exonère de cotisations, de taxes, qu'on laisse des niches fiscales partout : car ils sont trop élevés par rapport à nos partenaires et concurrents.
En quoi le fait que les cotisations et taxes soit plus élevés en France que dans d'autres pays veux dire qu'ils sont trop élevés chez nous ?
L'argent récolté par les institutions publiques ne s'évapore pas, il sert à financer tout un tas de choses (éducation, santé, transport, armé, …).
Donc potentiellement c'est des dépenses en moins dans certain domaine par rapport à la vie dans d'autres pays.
En plus ça crée des emplois, donc des cotisations, donc des moyens pour l'état.
Bien sur on pourrait discuter de la pertinence de la répartition de ce budget. Mais en quoi transférer ce budget dans les mains des individus serais préférable ?
Pour moi, les niches fiscales ça sert juste à favoriser certain domaines ou structures (pour en profiter il faut savoir qu'elles existent et savoir les utiliser) au détriment d'autres. Et ce indépendamment du fait de trouver ça positif ou négatif.
C'est justement ce dont je voulais parler dans mon deuxième point, le temps de compilation n'est qu'une partie du temps d'itération.
Et donc dans ce cas, le mieux est encore de pouvoir itérer sans recompiler et sans relancer. Par exemple en changeant l'état de variable au runtime. Bien sur ce n'est pas toujours possible, mais ça permet de bien diminuer l'impact du temps de compilation.
Contexte: Je n'ai pas lu l'article en question, par contre je suis programmeur C++ expérimenté et je me forme actuellement à Rust. Mon expérience Rust se concentre pour l'instant sur des projets assez petit.
De mon point de vue l’inconvénient des temps de compilation en Rust est largement compensé par un nombre d'itération beaucoup moins important.
L'étape qui est longue c'est la génération de code, par contre le checker qui est indépendant et qui s'occupe de détecter et signaler les erreurs de programmation (enfin la validité du code écrit) est utilisable indépendamment et est rapide.
Du coup quand tu passes à l'étape compilation (ou il faut attendre) la qualité du code est bien meilleur, et il reste beaucoup moins de bug qui nécessiteront d'itérer.
En prenant en compte que le temps d'itération n'est pas uniquement lié au temps de compilation, mais aussi au temps pour retrouver l'état du programme adapté pour tester (du temps pour charger des ressources, pour faire une suite de manipulation, etc …
De ce que j'ai lu, tu peux déjà oublié le badge bleu comme "valeur de certification". Elon Musk l'a déjà fait changer en : il suffis de payer pour l'avoir.
A éventuellement confirmer si tu veux en être certain, je ne suis pas utilisateur de Twitter, donc je ne suis pas aller chercher plus loin.
Ooops, j'ai raté ma citation, un modérateur peux corriger ?
Il faut arrêter la citation a partir de "Pour moi c'est le monde de l'interprété qui est cruel."
Oui j'avais compris l'humour mais j'avais envie d'en profiter ^
En effet, les langages interprété sont souvent présenté comme plus facile, plus simple d'accès. Hors je trouve que dans les faits c'est vraiment pas forcement le cas.
La simplicité de façade se traduit souvent par des inconvénients (notamment ceux que je citais précédemment.
Alors autant C/C++ avait quand même des subtilités qui pouvais compliquer leur utilisations par des néophyte ou programmeur occasionnel.
Autant Rust, avec son aspect explicite et tous les outils qui viennent avec rend les choses vraiment plus accessible. Les outils en deviennent de bon guide pour l'apprentissage.
Je n'ai pas encore tout lu, mais cette article / partage m'intéresse.
Je suis programmeur C++ expérimenté et programmeur Rust en apprentissage, ça pourrais m'intéresser si j'ai besoin de faire interagir Rust avec du Python.
Pas que j'aime le Python ou que j'ai envie d'en faire, mais s'il y avait besoin d'intérragir avec du code existant et/ou fait par quelqu'un d'autres.
En effet, vous quittez alors le monde merveilleux (et lâche) de l'interprété, pour le terrible et cruel (et implacable) monde du C, où tout doit être connu (si possible à l'avance).
Pour moi c'est le monde de l'interprété qui est cruel.
Le compilateur (et outils de check associé) permette de détecter tellement d'erreurs de programmation et autre bugs alors qu'ils ne sont détecté qu'à l'exécution dans le cas de langage interprété.
Et c'est encore plus flagrant en Rust, j'ai tellement plus confiance en mon programme une fois qu'il compile (sa qualité, son nombres réduit de bugs).
C'est plus reposant pour l'esprit, et ça permet de plus ce concentrer sur les problématique à résoudre, et moins sur la technique pour les résoudre.
peut-être que tant qu'a être grillé ils teste la justice.
Et/ou une "vengeance" en faisant perdre du temps et de l'argent (en frais de procédures) à des journaux qui n'ont pas forcement beaucoup de moyen.
En tous cas j'espère que les attaqués pourront bien se défendre et demander au minimum le remboursement des frais d'avocat.
Peut-être que c'est lié aux personnes "disponible" pour travailler sur ce sujet et/ou au fait que le langage soit déjà directement utilisable dans le projet.
Mais en tous cas ça m'a aussi fait tiquer. J'aurais trouvé ça plus judicieux si Rust avait été utilisé pour la ré-implémentation de ses protocoles.
Vu que se sont des composants de base de l'application, la sécurité la légèreté et la fiabilité poussé par Rust m'aurais semblé intéressant.
Mais je ne connais pas toute les raisons de ce choix.
Bonsoir, merci pour le partage public de ce webinaire, il pourrait m'intéresser (par curiosité).
Par contre je n'ai pas de compte eventbrite, et si je peux j'aimerais éviter de m'en créer un. Est-ce qu'il y aurait un autre moyen d'avoir le lien pour assister ?
Si je souhaite pouvoir échanger avec des personnes par un système messagerie qui s’appuie sur Internet, je ne vois pas pourquoi je devrais lier mon profil avec mon numéro de téléphone, qui lui est pertinent pour le réseau GSM pas Internet.
Les personnes de Signal à fait ce choix, ils ont le droit. Par contre en ce qui me concerne j'estime que c'est un choix qui pose des problématiques, donc je ne pourrais pas conseiller Signal comme application de messagerie.
Je ne parlerais pas de rapport, mais pour moi le fait que Signal n'autorise pas la fédération fait qu'il n'est pas une réponse idéale aux messageries propriétaire et centralisé, malgré le fait qu'il soit libre.
Je ne connaissais pas la possibilité d'utiliser des cartes SIM anonyme/de VOIP, merci de "l'idée", même si je n'en aurais sans doute pas l'usage.
J'ai une certaine culture informatique, mais je ne connaissais pas, donc en workaround pourquoi pas, mais ça ne me parait pas un contre-argument "pertinent" pour invalider la critique.
Et quel coût cela a ? Je ne pense pas que ça soit gratuit.
Qu'est-ce qui empêche de faire une instance concurrent et adapter le code pour être multi-serveurs?
De ce que j'ai compris, c'est plus ou moins ce que les membres de sessions on fait avec Session : https://getsession.org
Enfin en mieux coté décentralisation, puisse qu'il n'y a plus un serveur, mais en gros un réseaux de nœuds.
En plus, avantage par rapport à Signal (et d'autre), pas besoin d'associer son compte à un numéro de téléphone.
Coté utilisation, je n'ai pas encore testé, donc je ne peux pas donner mon avis.
Il y a un peu plus d'un an j'avais aussi tenté d'essayer Jami, mais là j'ai été très déçu, plein de choses ne fonctionnais pas bien et sans informations, donc difficile de remonter des bugs pertinents. Et chose rédhibitoire pour moi, lors de l'utilisation d'un même compte sur plusieurs appareils, les conversations n'étaient pas synchronisées, chaque appareil avait seulement les messages envoyés lorsqu'il était connecté.
Mais, ça a évolué, peut-être que c'est beaucoup mieux aujourd'hui.
Mais pour que ces alternatives puissent exister, il faut qu'elle puisse se faire connaître. Donc on peut regretter que des médias comme The Verge ne présente pas un panel plus large de possibilités.
Et pour ceux qui seraient intéressés pour avoir un comparatif de messagerie sécurisé, le site https://www.securemessagingapps.com me semble intéressant et sérieux.
Attention :
1. c'est seulement la partie noyaux qui est libre (DRM/Modesetting/etc) pas les parties userspace (implémentation des api OpenGL/Vulkan/OpenCL/CUDA/etc).
2. c'est seulement pour les GPU a partir de la génération Turing, les plus anciennes n'y ont pas le droit.
Donc c'est un pas en avant, mais AMD garde de l'avance sur pas mal de point à mon avis (même si c'est pas parfait non plus)
Mais en pratique, quasiment personne ne fait ça, sauf des gens qui bossent en solo.
Tu est certain ? Est-ce qu'un développement qu'avoir un dépôt de référence implique de considéré le développement comme centralisé ?
Et s'il n'y a pas un, mais plusieurs dépôt de référence (exemple le noyaux Linux) ?
Et je retombe sur des temps très similaire au fread ou read. Plutôt un tout petit peut plus lent sur les petits fichiers, et un peu plus rapide sur les gros fichiers.
./test 1M 2M 4M 8M 16M 32M
File 1M
C++ istreambuf_iterator : .......... 3445 us
C++ stream::rdbuf : .......... 432 us (7.97)
C++ ifstream_read : .......... 137 us (25.15)
libc fread : .......... 137 us (25.15)
POSIX read : .......... 134 us (25.71)
File 2M
C++ istreambuf_iterator : .......... 7076 us
C++ stream::rdbuf : .......... 1319 us (5.36)
C++ ifstream_read : .......... 265 us (26.70)
libc fread : .......... 270 us (26.21)
POSIX read : .......... 262 us (27.01)
File 4M
C++ istreambuf_iterator : .......... 13638 us
C++ stream::rdbuf : .......... 2429 us (5.61)
C++ ifstream_read : .......... 596 us (22.88)
libc fread : .......... 601 us (22.69)
POSIX read : .......... 583 us (23.39)
File 8M
C++ istreambuf_iterator : .......... 27491 us
C++ stream::rdbuf : .......... 5478 us (5.02)
C++ ifstream_read : .......... 1984 us (13.86)
libc fread : .......... 1983 us (13.86)
POSIX read : .......... 1986 us (13.84)
File 16M
C++ istreambuf_iterator : .......... 54919 us
C++ stream::rdbuf : .......... 10920 us (5.03)
C++ ifstream_read : .......... 4773 us (11.51)
libc fread : .......... 4789 us (11.47)
POSIX read : .......... 4805 us (11.43)
File 32M
C++ istreambuf_iterator : .......... 109104 us
C++ stream::rdbuf : .......... 36073 us (3.02)
C++ ifstream_read : .......... 9698 us (11.25)
libc fread : .......... 9748 us (11.19)
POSIX read : .......... 9660 us (11.29)
D'ailleurs, le test ne compare pas les performances des stream C++ et des read(posix) et fread(libc). Mais compare plusieurs méthodes pour charger entièrement un fichier dans une string.
Dans d'autres cas (très gros fichiers) la méthodes qui consiste à charger entièrement le fichier en mémoire ne serait pas utilisable.
[^] # Re: TT-RSS
Posté par xoddark . En réponse au journal Le développement de TinyTinyRSS semble menacé par les blocages du Roskomnadzor (Russie). Évalué à 3.
Je n'ai pas pratiqué TT-RSS, donc je ne sais pas si c'est équivalent.
Mais j'utilise FreshRSS, qui n'est pas parfais mais me semble relativement complet et fonctionne. C'est aussi du php, ça fonctionne bien en auto-hébergement, c'est assez bien intégré à Yunohost, …
# Sous Fedora
Posté par xoddark . En réponse au lien PSA: upgrade your LUKS key derivation function. Évalué à 1.
Merci pour le partage.
Mes systèmes installé en Fedora 37 sont en argon2id, par contre celui installé a partir d'une version plus ancienne était seulement en argon2i.
# Vidéo d'explication du droit
Posté par xoddark . En réponse au lien Interdiction de manifestation : des préfectures organisaient l’incontestabilité de leurs arrêtés. Évalué à 3.
La chaîne Vous Avez Le Droit vient de sortir une vidéo dont le sujet du droit autour des manifestations :
https://www.youtube.com/watch?v=vXCw8s83en4
[^] # Re: Ce n'est pas du natif
Posté par xoddark . En réponse à la dépêche Slint 1.0 : une boîte à outils graphiques natifs pour poste client et embarqué. Évalué à 1.
Merci pour les précisions.
M'intéressant un peu aux librairies/outils de GUI utilisable en Rust, je l'avais vu passer mais pas encore pris le temps de regarder plus en détails.
J'avais déjà des doutes sur le fait qu'il serait adapté à mon usage. Je vise plutôt l'édition de données, la création de contenu, que l'affichage de données.
# Brève en français qui en parle
Posté par xoddark . En réponse au lien How Rust went from a side project to the world’s most-loved programming language. Évalué à 3.
https://www.nextinpact.com/lebrief/71022/la-saga-rust
[^] # Re: Exactement
Posté par xoddark . En réponse au journal Une idée pour financé les retraites . Évalué à 10.
Est-ce qu'une (grande) partie des problèmes dans le publique ne serait pas du justement au fait qu'on y applique les logiques du privé : la recherche de la rentabilité, réduction des coûts, etc ?
Du coup, je ne voie pas comment privatiser encore plus améliorerais les choses.
Qui à le choix ? Quel choix ?
Par exemple les délégations de service publique pour l'eau, en tant que consommateur tu n'as pas le choix. Et c'est souvent du privé, même s'il y un un retour en arrière dans beaucoup de collectivité, car finalement le privé c'est pas si bien : plus cher et pas meilleur service.
Désolé mais je ne fais pas le même constat.
Qu'est ce que le public fais "pire" ? pire pour qui ?
Par contre je crois que "le public" fait de moins en moins bien.
Note : enfin le public étatique, il me semble que le public des collectivités locales par exemple fonctionne plutôt bien mieux, en tous cas d'après des échos que j'ai autour de moi, il semble un avoir par endroit un vrai regain de "public".
Et je pense que c'est parce que un nombre important de la classe dirigeante fait en sorte de casser le service public justement pour ouvrir la voie à la privatisation. Il me semble d'ailleurs, que c'est souvent les mêmes qui prennent des décisions qui dégrade le service public et qui ensuite dise qu'il ne fonctionne pas bien et qu'il faut privatiser.
Et je pense que la SNCF est clairement dans ce cas.
De ce que je perçois, la SNCF est aujourd'hui une structure géré comme une boite privé, du coup je ne considère pas que c'est un bonne exemple pour expliquer que le public ne fonctionne pas.
[^] # Re: Exactement
Posté par xoddark . En réponse au journal Une idée pour financé les retraites . Évalué à 10.
Dsl j'ai du mal a comprendre ce que tu veux dire, donc je ne suis pas certain d'avoir bien compris.
Je suis plutôt d'accords que l'argent public est loin d'être utiliser au mieux. Et je dirais (en simplifiant) que c'est en grande partie la cause de politiques de libéralisation.
Quand tu dit "le privé fait bien mieux", tu pense à quoi ? Le privé fait mieux quoi ? Pour qui ?
Parce que dans ma vision, si le public n'est pas exempt de défaut, le privé n'est pas la panacée.
Après concernant la vision de société vers laquelle on souhaite se diriger, de mon coté j'ai plus envie d'un monde ou l'on remet plus de public, en améliorant le public que plus de privé.
Le coté individualiste du privé, me semble incompatible avec les contraintes au-quelle l'humanité doit faire face, tel que les ressources fini de notre magnifique planète terre face à la croissance continue de l'humanité.
[^] # Re: Exactement
Posté par xoddark . En réponse au journal Une idée pour financé les retraites . Évalué à 7.
L'argent récolté par les institutions publiques ne s'évapore pas, il sert à financer tout un tas de choses (éducation, santé, transport, armé, …).
Donc potentiellement c'est des dépenses en moins dans certain domaine par rapport à la vie dans d'autres pays.
En plus ça crée des emplois, donc des cotisations, donc des moyens pour l'état.
Bien sur on pourrait discuter de la pertinence de la répartition de ce budget. Mais en quoi transférer ce budget dans les mains des individus serais préférable ?
Pour moi, les niches fiscales ça sert juste à favoriser certain domaines ou structures (pour en profiter il faut savoir qu'elles existent et savoir les utiliser) au détriment d'autres. Et ce indépendamment du fait de trouver ça positif ou négatif.
[^] # Re: Monde de merde. (Georges Abitbol)
Posté par xoddark . En réponse au journal J’m’ai fait eue !. Évalué à 5.
Ba c'est un .fr donc il y a forcément un contrôle sous la juridiction française.
En faisant une requête whois on peut compléter les informations :
le domaine semble être géré par la société : SAS Ligne Web Services - LWS
Ensuite l'adresse ip devrait permettre de connaître le lieu d'hébergement assez facilement.
[^] # Re: Le go n'est pas lent
Posté par xoddark . En réponse au lien Is coding in Rust as bad as in C++?. Évalué à 2.
C'est justement ce dont je voulais parler dans mon deuxième point, le temps de compilation n'est qu'une partie du temps d'itération.
Et donc dans ce cas, le mieux est encore de pouvoir itérer sans recompiler et sans relancer. Par exemple en changeant l'état de variable au runtime. Bien sur ce n'est pas toujours possible, mais ça permet de bien diminuer l'impact du temps de compilation.
[^] # Re: Le go n'est pas lent
Posté par xoddark . En réponse au lien Is coding in Rust as bad as in C++?. Évalué à 9. Dernière modification le 09 janvier 2023 à 11:27.
Contexte: Je n'ai pas lu l'article en question, par contre je suis programmeur C++ expérimenté et je me forme actuellement à Rust. Mon expérience Rust se concentre pour l'instant sur des projets assez petit.
De mon point de vue l’inconvénient des temps de compilation en Rust est largement compensé par un nombre d'itération beaucoup moins important.
L'étape qui est longue c'est la génération de code, par contre le checker qui est indépendant et qui s'occupe de détecter et signaler les erreurs de programmation (enfin la validité du code écrit) est utilisable indépendamment et est rapide.
Du coup quand tu passes à l'étape compilation (ou il faut attendre) la qualité du code est bien meilleur, et il reste beaucoup moins de bug qui nécessiteront d'itérer.
En prenant en compte que le temps d'itération n'est pas uniquement lié au temps de compilation, mais aussi au temps pour retrouver l'état du programme adapté pour tester (du temps pour charger des ressources, pour faire une suite de manipulation, etc …
[^] # Re: Source d'information certifiée
Posté par xoddark . En réponse au lien Effondrement ou faillite de Twitter ?. Évalué à 3.
Ok, je n’avais pas suivi cette partie-là.
En tout cas, ça ne donne pas trop confiance.
[^] # Re: Source d'information certifiée
Posté par xoddark . En réponse au lien Effondrement ou faillite de Twitter ?. Évalué à 3.
De ce que j'ai lu, tu peux déjà oublié le badge bleu comme "valeur de certification". Elon Musk l'a déjà fait changer en : il suffis de payer pour l'avoir.
A éventuellement confirmer si tu veux en être certain, je ne suis pas utilisateur de Twitter, donc je ne suis pas aller chercher plus loin.
[^] # Re: Merci
Posté par xoddark . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 1.
Ooops, j'ai raté ma citation, un modérateur peux corriger ?
Il faut arrêter la citation a partir de "Pour moi c'est le monde de l'interprété qui est cruel."
[^] # Re: Merci
Posté par xoddark . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 2.
Oui j'avais compris l'humour mais j'avais envie d'en profiter ^
En effet, les langages interprété sont souvent présenté comme plus facile, plus simple d'accès. Hors je trouve que dans les faits c'est vraiment pas forcement le cas.
La simplicité de façade se traduit souvent par des inconvénients (notamment ceux que je citais précédemment.
Alors autant C/C++ avait quand même des subtilités qui pouvais compliquer leur utilisations par des néophyte ou programmeur occasionnel.
Autant Rust, avec son aspect explicite et tous les outils qui viennent avec rend les choses vraiment plus accessible. Les outils en deviennent de bon guide pour l'apprentissage.
# Merci
Posté par xoddark . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 3. Dernière modification le 07 novembre 2022 à 23:30.
Je n'ai pas encore tout lu, mais cette article / partage m'intéresse.
Je suis programmeur C++ expérimenté et programmeur Rust en apprentissage, ça pourrais m'intéresser si j'ai besoin de faire interagir Rust avec du Python.
Pas que j'aime le Python ou que j'ai envie d'en faire, mais s'il y avait besoin d'intérragir avec du code existant et/ou fait par quelqu'un d'autres.
Pour moi c'est le monde de l'interprété qui est cruel.
Le compilateur (et outils de check associé) permette de détecter tellement d'erreurs de programmation et autre bugs alors qu'ils ne sont détecté qu'à l'exécution dans le cas de langage interprété.
Et c'est encore plus flagrant en Rust, j'ai tellement plus confiance en mon programme une fois qu'il compile (sa qualité, son nombres réduit de bugs).
C'est plus reposant pour l'esprit, et ça permet de plus ce concentrer sur les problématique à résoudre, et moins sur la technique pour les résoudre.
[^] # Re: Campagne de pub gratuite
Posté par xoddark . En réponse au lien Next Inpact attaqué en justice par Avisa Partners suite à un article sur le papier de Fakir.. Évalué à 1.
peut-être que tant qu'a être grillé ils teste la justice.
Et/ou une "vengeance" en faisant perdre du temps et de l'argent (en frais de procédures) à des journaux qui n'ont pas forcement beaucoup de moyen.
En tous cas j'espère que les attaqués pourront bien se défendre et demander au minimum le remboursement des frais d'avocat.
[^] # Re: Pour des raisons de sécurité
Posté par xoddark . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 5.
Peut-être que c'est lié aux personnes "disponible" pour travailler sur ce sujet et/ou au fait que le langage soit déjà directement utilisable dans le projet.
Mais en tous cas ça m'a aussi fait tiquer. J'aurais trouvé ça plus judicieux si Rust avait été utilisé pour la ré-implémentation de ses protocoles.
Vu que se sont des composants de base de l'application, la sécurité la légèreté et la fiabilité poussé par Rust m'aurais semblé intéressant.
Mais je ne connais pas toute les raisons de ce choix.
[^] # Re: Pourquoi ce webinaire ?
Posté par xoddark . En réponse au lien Webinaire de présentation de Thunderbird 102. Évalué à 4.
Bonsoir, merci pour le partage public de ce webinaire, il pourrait m'intéresser (par curiosité).
Par contre je n'ai pas de compte eventbrite, et si je peux j'aimerais éviter de m'en créer un. Est-ce qu'il y aurait un autre moyen d'avoir le lien pour assister ?
Merci
[^] # Re: Signal
Posté par xoddark . En réponse au lien The Verge suggère 5 applis de messagerie chiffrée, aucune n'est libre. Évalué à 4.
Si je souhaite pouvoir échanger avec des personnes par un système messagerie qui s’appuie sur Internet, je ne vois pas pourquoi je devrais lier mon profil avec mon numéro de téléphone, qui lui est pertinent pour le réseau GSM pas Internet.
Les personnes de Signal à fait ce choix, ils ont le droit. Par contre en ce qui me concerne j'estime que c'est un choix qui pose des problématiques, donc je ne pourrais pas conseiller Signal comme application de messagerie.
Je ne parlerais pas de rapport, mais pour moi le fait que Signal n'autorise pas la fédération fait qu'il n'est pas une réponse idéale aux messageries propriétaire et centralisé, malgré le fait qu'il soit libre.
Je ne connaissais pas la possibilité d'utiliser des cartes SIM anonyme/de VOIP, merci de "l'idée", même si je n'en aurais sans doute pas l'usage.
J'ai une certaine culture informatique, mais je ne connaissais pas, donc en workaround pourquoi pas, mais ça ne me parait pas un contre-argument "pertinent" pour invalider la critique.
Et quel coût cela a ? Je ne pense pas que ça soit gratuit.
[^] # Re: Signal
Posté par xoddark . En réponse au lien The Verge suggère 5 applis de messagerie chiffrée, aucune n'est libre. Évalué à 5.
En plus, avantage par rapport à Signal (et d'autre), pas besoin d'associer son compte à un numéro de téléphone.
Coté utilisation, je n'ai pas encore testé, donc je ne peux pas donner mon avis.
Il y a un peu plus d'un an j'avais aussi tenté d'essayer Jami, mais là j'ai été très déçu, plein de choses ne fonctionnais pas bien et sans informations, donc difficile de remonter des bugs pertinents. Et chose rédhibitoire pour moi, lors de l'utilisation d'un même compte sur plusieurs appareils, les conversations n'étaient pas synchronisées, chaque appareil avait seulement les messages envoyés lorsqu'il était connecté.
Mais, ça a évolué, peut-être que c'est beaucoup mieux aujourd'hui.
Mais pour que ces alternatives puissent exister, il faut qu'elle puisse se faire connaître. Donc on peut regretter que des médias comme The Verge ne présente pas un panel plus large de possibilités.
Et pour ceux qui seraient intéressés pour avoir un comparatif de messagerie sécurisé, le site https://www.securemessagingapps.com me semble intéressant et sérieux.
# Partie Kernel only
Posté par xoddark . En réponse au lien NVIDIA publie désormais ses pilotes graphiques pour Linux sous licence libre. Évalué à 10.
Attention :
1. c'est seulement la partie noyaux qui est libre (DRM/Modesetting/etc) pas les parties userspace (implémentation des api OpenGL/Vulkan/OpenCL/CUDA/etc).
2. c'est seulement pour les GPU a partir de la génération Turing, les plus anciennes n'y ont pas le droit.
Donc c'est un pas en avant, mais AMD garde de l'avance sur pas mal de point à mon avis (même si c'est pas parfait non plus)
[^] # Re: Enfumage
Posté par xoddark . En réponse au journal GitHub supprime les issues et pull requests de comptes russes suspendus ... puis les restaure. Évalué à 1.
Et s'il n'y a pas un, mais plusieurs dépôt de référence (exemple le noyaux Linux) ?
[^] # Re: Le résultat ne m'a pas étonné du tout
Posté par xoddark . En réponse au lien ifstream vs posix (le résultat va vous étonner). Évalué à 2.
Effectivement,
j'ai fait un test rapide en utilisant un std::ifstream::read() tell que présenté dans la page cppréférence : https://en.cppreference.com/w/cpp/io/basic_istream/read
Et je retombe sur des temps très similaire au fread ou read. Plutôt un tout petit peut plus lent sur les petits fichiers, et un peu plus rapide sur les gros fichiers.
[^] # Re: Le résultat ne m'a pas étonné du tout
Posté par xoddark . En réponse au lien ifstream vs posix (le résultat va vous étonner). Évalué à 3.
D'ailleurs, le test ne compare pas les performances des stream C++ et des read(posix) et fread(libc). Mais compare plusieurs méthodes pour charger entièrement un fichier dans une string.
Dans d'autres cas (très gros fichiers) la méthodes qui consiste à charger entièrement le fichier en mémoire ne serait pas utilisable.