pulkomandy a écrit 2290 commentaires

C'était dans ma TODO list depuis longtemps.

Le problème était que j'avais un fichier forké à partir d'une version de vim de 1998 avec plein de modifications pas très bien documentées, et c'était compliqué de reporter les changements sur la version actuelle du fichier qui a beaucoup évolué. Maintenant que c'est découpé dans un fichier séparé, ce sera plus simple.

Il y avait (et je pense qu'il y a toujours) des bugs dans certains cas, surtout sur le code C++ (je viens de modifier les patterns pour accepter les "::" dans les types et dans les noms de fonctions, par exemple). Et il n'y a pas seulement des ratages sur la surbrillance des types, mais aussi (surtout) ça cause des régressions sur d'autres choses. Même si pour moi, avoir la coloration des types est plus importante que les autres trucs qui sont cassés, il est probable que tout le monde ne sera pas d'accord.

Je ne pense pas que ce sera accepté par vim en l'état, et il faudra que j'essaie de corriger au moins les plus gros problèmes. Je vais installer cette nouvelle version sur mes différentes machines perso et pro et la tester pendant quelques jours pour voir ou ça en est, avant de proposer l'intégration dans vim.

C'est un truc de cryptomonnaies décentralisées-mais-en-fait-non qui s'est fait voler des millions de dollars en crytocoins. Et qui essaie de négocier avec les pirates pour les récupérer.

Rien de très intéressant, donc.

Oui du côté de Qt il n'y a plus d'acivité sur WebKit.

Il faut donc plutôt regarder du côté de GTK avec Epiphany/Gnome Browser? C'est vrai que les autres navigateurs (Midori, Kazehakaze, …) n'ont pas l'air très actifs.

La version GTK de WebKit est maintenue par Igalia qui l'utilise dans différents projets pour des applications embarquées. Donc pour l'instant du côté du moteur et de son intégration avec Linux il n'y a pas trop de soucis à se faire. Et WebKit est un projet beaucoup plus ouvert à la collaboration entre différentes entités et à la portabilité sur différentes plateformes. Du côté de Blink/Chromium, par exemple, il n'y a pas de support des systèmes BSD; alors que chez WebKit c'est le cas et ils sont plutôt réceptifs à l'idée d'intégrer même la version pour Haiku (si on avait le temps de leur envoyer nos patchs…). WebKit est aussi porté sur d'autres systèmes plus exotiques comme MorphOS.

son absence totale de concurrence sérieuse sur le créneau des navigateurs pas basés sur Chrome

WebKit ne compte pas, alors? C'est pourtant un moteur qui fonctionne plutôt bien.

C'est un peu plus spécifique et ce n'est pas un organisme public, muis il exste déjà le groupe européen d'intérêt pour les risques liés aux tableurs (European spreadsheet risks intrest group, EUSPRIG).

Leurs rapports se trouvent ici: http://www.eusprig.org/horror-stories.htm

Nous avions déposé la marque Haiku mais seulement dans la catégorie "systèmes d'exploitation". Et en plus, la marque déposée a expiré en 2018 car l'association Haiku inc a oublié de la renouveler.

C'est vrai, mais il y a de nouveaux projets de systèmes "alternatifs", en particulier on entend pas mal parler de SerenityOS et Redox OS

Au début de Liberapay il y avait vraiment une notion de porte-monnaie dans le site, et on pouvait le remplir puis étaler les dons et les répartir comme on voulait. On pouvait même re-donner l'argent qu'on avait reçu, sans aucun frais. Mais ils se sont fait jeter par l'entreprise qui traitait les paiements (Mangopay) et ils ont migré sur Stripe et Paypal qui ne permettent pas ce genre de choses.

Mais la présentation des choses dans Liberapay est resté comme avant alors que ça ne correspond plus du tout à ce qu'il se passe vraiment. Donc maintenant, en vrai, Liberapay c'est plutôt pour donner une fois par an, et avoir un rappel ou un renouvellement automatique des dons. Et découvrir quels projets ou développeurs acceptent des dons.

Je trouve que c'est dommage de persister à présenter l'ancien mode de fonctionnement qui n'existe plus. Ça embrouille tout le monde.

Ça dépend aussi ce qu'on entend par régulièrement.

Du point de vue d'une association, par exemple, la comptabilité se fait sur l'année, donc le truc optimal c'est de faire un don par an. D'un côté le budget est facile à prévoir, de l'autre ça fait moins de transactions et donc moins de frais (surtout si ça passe par Paypal ou ce genre de services).

Par contre si c'est un don directement à un développeur, c'est probable qu'il fasse son budget mois par mois pour payer son loyer, ses factures, etc. Et dans ce cas les dons à l'année ne sont peut être pas assez fréquents (mais ça dépend sûrement des gens, y'en a qui ont peut être des sous de côté pour attendre les dons de l'année suivante).

En général c'est important surtout si le don est "gros" par rapport au budget du destinataire. C'est différents si c'est 10€ dans le budget d'une grosse association qui emploie un développeur à plein temps (budget de quelques dizaine de milliers d'euros par an), ou si c'est 100€ dans le budget d'un petit projet qui ne sait pas s'il va pouvoir payer son hébergement web jusqu'à la fin de l'année. Dans le premier cas il y a pas vraiment de questions à se poser, dans le deuxième, ça risque de mettre des gens en difficulté s'ils ne s'y attendaient pas. Mais il suffit d'être clair sur le fait qu'il s'agit d'un don ponctuel, je pense?

En fait c'est marrant mais même si on a très peu d'argent pour nous (pour du financement de salaire, je veux dire), on en a pas mal pour du communautaire (on explique ça en fin de l'article).

Ça m'intrigue un peu ça. En effet l'article dit que ce n'est pas possible d'utiliser ces dons pour payer un contributeur, mais n'explique pas pourquoi.

Qu'est-ce qui pose problème? On le fait régulièrement (enfin, pas aussi souvent qu'on voudrait) chez Haiku et ça fonctionne plutôt bien, et il me semble que c'est le cas aussi pour ReactOS.

En fait elle était déjà en cours de modération avant la publication du lien.

J'essaierai la prochaine fois de l'envoyer en modération un peu plus en avance pour qu'elle puisse être relue plus tranquillement, et publiée dès l'annonce officielle :)

Bonjour, les commentaires racistes ne sont en effet pas les bienvenus sur le forum et les canaux de discussion de Haiku. Conformément aux règles de modération indiquées sur cette page: https://www.haiku-os.org/community/organization/policies/ l'équipe de modération peut prendre toutes les décisions qui semblent appropriées.

Le projet s'appelle lossless-cut et pas lowless-cut.

C'est pour essayer de faire oublier que c'est un téléphone fabriqué en chine, par une entreprise chinoise avec un cpu chinois?

https://www.dailydot.com/debug/freedom-phone-security-issues/?amp&__twitter_impression=true

L'utilisation est assez différente. Les wikis et les pages web classiques sont faits pour durer et être relativement faciles à retrouver. Twitter est plutôt là pour des informations en direct qui ne sont utiles que momentanément.

C'est un peu comme comparer un livre et un journal quotidien. Bien sûr qu'il y en a un qui va pouvoir prendre le temps d'organiser les informations et d'approfondir un sujet, alors que l'autre n'a pas le temps de le faire. Mais l'autre va pouvoir donner des informations de façon assez rapide après l'occurence d'un évènement.

Ça me semble un peu compliqué à mettre en place dans un véhicule en mouvement et qui ne circule pas sur un terrain parfaitement plat. Concrètement ça risque de surtout mesurer le bon réglage des amortisseurs?

Mais il y a des solutions plus simples: il me semble que les bus sont déjà équipés de "vidéoprotection"? On ne pourrait pas utiliser ces images pour évaluer le remplissage?

Donc, je me demande : plutôt que de stigmatiser et de courir après 20% d'antivax avec une seringue, pourquoi ne pas offrir des vaccins à des personnes d'autres pays qui ne demandent que cela, cela ne serait-il pas plus efficace ?

Apparemment après les annonces d'hier soir, il y a une bonne partie des gens qui se sont dit qu'ils feraient bien de prendre rendez-vous pour se faire vacciner. C'était donc plutôt du "oui oui je verrai ça plus tard" que vraiment antivax. Il restera sûrement quelques irréductibles antivax à la fin, mais on y est pas encore.

Cela dit, ce serait effectivement pas mal de s'assurer que les choses avancent hors de nos frontières aussi…

On rapelle que le mainteneur de Tenacity étant victime d'une campagne de harcèlement et de menaces à l'arme blanche, il avait peut être d'autres préoccupations que faire des commits.

De plus, pour être en contact avec un autre développeur de Tenacity, je sais qu'il y avait aussi du travail moins visible en cours: définir la gouvernance du projet, choisir un nom, décider comment gérer un nom de domaine, mettre en place un code de conduite, …

Toutes les choses importantes à faire avant de se lancer dans le code la tête baissée, donc. Histoire d'éviter des problèmes plus tard.

Les dommages éventuels sur le cerveau aussi, c'est lié à la façon d'utiliser le téléphone: il ne faut pas le coller près de la tête. Par exemple en évitant les longues discussions, ou en utilisant un micro-casque déporté (pour les appareils disposant d'une prise jack, parce que sinon, c'est du bluetooth et ce sont les mêmes fréquences, quoique à puisance bien plus faible).

A priori la quantité d'énergie électromagnétique reçue décroit avec le carré de la distance, donc quelques centimètres peuvent tout changer?

Si on veut parler de bénéfice/risque, il faudrait même compter le nombre de gens sauvés par l'utilisation d'un téléphone portable. Si ça se trouve, ça compense complètement le risque.

Mais ils faut déduire ceux qui sont morts dans un accident de trottinette parce qu'ils avaient le nez dans leur smartphone en traversant la rue. Je pense que le vrai danger avec les téléphones est à chercher plutôt de ce côté là?

Le problème de la license GPL vis à vis des entreprises ne se situe pas au niveau du copyleft.

Par exemple chez Apple, il y a pas mal de trucs sous GPLv2 qui sont utilisés. Mais pas de GPLv3. A priori le problème serait plutòt autour des restrictions sur les brevets logiciels.

Quand à la séparation entreprises vs particuliers, dans mon travail salarié je contribue par exemple à Wireshark (GPL) et j'ai des collègues qui participent à Linux (GPL). Chez moi sur mon temps libre, je contribue à Haiku (MIT et pas vraiment de contributions de la part d'entreprises). Donc, je suis pas vraiment convaincu par ton analyse.

La raison pour laquelle mes projets personels sont sous license MIT est que j'ai envie que mon code puise être utilisé par le plus de monde possible sans imposer de restrictions. Je ne vois pas l'intérêt des contraintes de la GPL dans mon cas. Par contre je vois bien l'intérêt pour une entreprise qui publie du code, de s'assurer que les concurrents qui utilisent et modifient ce code doivent aussi jouer le jeu et partager leurs changements. Donc une license copyleft me semble tout à fait pertinente dans ce cas.

Il y a des outils d'analyse statique. Quelques uns en vrac (pas tous libres): clang-tidy, cppcheck, clint, coverity, codesonar, pvs studio, …

L'idée est d'analyser le code lors de la compilation et de détecter ce genre de problèmes.

On peut aussi activer certaines protection à l'exécution dans les compilateurs modernes: ubsan (détecte le code exploitant des comportements laissés indéfinis par les spécification du C ou du C++), asan (détecte les accès à de la mémoire non allouée ou déjà libérée). Ça a un coût en terme de performances. S'il y a ce genre de besoins il est peut-être pertinent de regarder si un autre langage offrant plus de garanties ne serait pas un meilleur choix

Ce qui pose apparament problème parce que c'est incompaeible avec la license d'Audacity (GPL) qui dit qu'on ne peut pas restreindre le droit d'utilisation du programme.

En C++98 il y avait auto_ptr: https://en.cppreference.com/w/cpp/memory/auto_ptr

Mais sinon c'est tout à fait possible d'écrire ses propres "smart pointers" ou autres outils de gestion de la mémoire, car il n'y a pas besoin de modifier le compilateur pour ça.

Par exemple dans Haiku on a ceci:
https://git.haiku-os.org/haiku/tree/headers/private/shared/AutoDeleter.h#n151

Qui s'utilise comme cela:

    {
        char* dynAlloc = malloc(1234);
        MemoryDeleter deleter(dynAlloc);
    } // La mémoire est libérée avec free() dès qu'on sort de ce bloc

Ça s'utilise très bien avec gcc 2.95.3 (encore utilisé dans Haiku pour la compatibilité avec BeOS). Cette version de gcc est trop ancienne pour implémenter complètement C++98. Donc je pense que n'importe quel compilateur C++ des 25 dernières années ne devrait pas avoir trop de problèmes avec ce code. Ou au pire on peut en écrire une version qui ne nécessite pas de templates, si vraiment on veut utiliser un compilateur datant de la préhistoire :)

Il n'y a pas besoin de C++20 pour faire l'équivalent de "cleanup". Il me semble dailleurs avoir pris soin de préciser dans mon commentaire que C++98 était suffisant?

C'est donc gcc+clang+icc+open watcom+Microsoft Visual C++, au moins 5 compilateurs.