C'est tout à fait faisable avec BountySource, mais leur équipe marketing a choisi plutôt d'importer directement les tickets des bugtrackers de différent projets sans aucun filtrage, et sans implication directe des gens qui travaillent sur les projets en question.
Il y a même des cas ou un ticket est fermé et le développeur qui a fait le travail n'est pas au courant qu'il y avait une prime et ne la réclame pas.
Je pense qu'on peut reprocher à BountySource d'avoir voulu grossir trop vite. Car, effectivement, une campagne de récolte de dons un peu mieux ciblée, ça fonctionne souvent beaucoup mieux et ça permet de communiquer plus facilement (c'est quelque chose d'"actif", on présente un plan d'attaque, on dit quel(s) développeur(s) va faire le job, on a à peu près une idée du budget nécessaire).
Mais du coup on se rapproche plus des trucs de crowdfunding à la Kickstarter.
Alors, je suis développeur de logiciels libres sur mon temps libre, et développeurs d'autres trucs sur mon temps salarié.
Le salaire d'un développeur c'est mettons 2000€/mois net (pour prendre un chiffre rond) pour 20 jours travaillés, soit 100€ par jour environ.
Avec 20€ tu pourrais donc financer même pas 2h de travail pour 1 personne (et là c'est sans compter aucune charge, etc). On est donc loin du compte, même pour un bug "simple", sur un projet comme LibreOffice il faut du temps pour trouver ou est le problème, vérifier que la solution fonctionne bien, etc. Et ensuite il faut envouer le code, qu'il soit relu et validé par un autre développeur. Probablement il faut ajouter un test automatisé aussi.
De plus, je trouve pas que c'est un très bon modèle d'être payé à la tâche comme ça. Ça encourage à faire le travail vite et mal pour pouvoir passer au paiement suivant le plus vite possible. Laissant aux autres contributeurs le soin de nettoyer derrière. Ça n'encourage pas la collaboration, puisqu'il faudrait ensuite partager les gains (ou demander de l'aide à quelqu'un et puis ne rien lui donner en contrepartie).
Donc au final, ce n'est pas une source de revenu suffisante, ni même suffisamment stable pour permettre à un développeur de se libérer du temps pour travailler sur un bug (en gros il faudrait que ça permette aux gens d'en vivre ou disons au moins que ça paie mieux que les autres possibilités, sinon, ça ne sert pas à grand chose). Et en plus ça met une ambiance pourrie dans les projets.
Et enfin, ça donne plus de pouvoir de décision aux gens qui ont des sous à donner.
Finalement dans Haiku, on a mis en place un système de vote sur notre bugtracker (chaque utilisateur peut donner un +1/-1 sur les bugs). Et on utilise ça (entre autres) pour prioriser les prochaines choses à faire. Pour le financement, on récolte des dons et on espère un jour en avoir assez pour pouvoir payer un de nos devs à plein temps de façon durable.
Ce câble de douze paires de fibre optique, offrant une vitesse de transfert de 30 térabits/seconde
Quelques centaines de paires ça ferait donc presque un petabit par seconde de données. L'internet moderne est pas très économe, mais quand même, il faut pas exagérer. Et on peut multiplexer le traffic dedans de façon logicielle (pas comme au temps du téléphone ou du télégraphe analogique ou il fallait une paire de fils de cuivre par communication).
On pourrait penser que c'est une bonne idée d'avoir plusieurs paires de fibres pour faire de la redondance, mais en cas d'incident (câble pris dans un chalut de pêche, séisme, …) y'a des chances que tout le cable soit cassé d'un coup. Donc il vaut mieux poser plusieurs câbles avec des points de départ et d'arrivée différents.
Enfin, ces cables ne sont pas simplement des très longues fibres optiques: il y a à intervalles régulier (tous les 100km environ) des répéteurs qui remettent le signal en forme. Et qui prennent de la place et ont besoin d'une alimentation électrique. On ne peut donc pas si facilement que ça augmenter le nombre de fibres.
et voir que cette exception a été écrite à l'origine pour un outil utilisant CUDA pour bruteforcer des clés Wifi.
Il est malheureux que ça ait été repris tel quel, là ou une clause plus générique aurait pu être rédigée. Mais ça semble être plus par facilité (de réutiliser un texte existant) que par malveillance ou volonté de limiter les choses au maximum. C'est aussi probablement plus facile à faire accepter aux développeurs: plus la clause est générique, plus la différence avec la GPL est importante, plus il est probable que quelqu'un trouve que ça va trop loin?
A priori (source: https://github.com/LeelaChessZero/lc0/issues/184 ) ils ont repris un template d'exception GPL qui existait déjà. Mais la source (chez Gentoo) semble ne plus exister. Et j'ai pas le courage d'aller creuser dans webarchive pour voir à quoi cela s'appliquait au départ.
Pour l'instant il n'y a pas de pilotes avec accélération matérielle pour OpenGL dans Haiku. C'est le moteur llvmpipe de Mesa qui est utilisé. Ça viendra un jour mais il y a d'autres priorités.
Du coup, pas de recommendations particulières pour choisir du matériel de ce côté là. Prévoir plutôt un bon CPU et quelques Go de RAM, que Medo mettra à profit pour mettre en cache le rendu vidéo et permettre de naviguer rapidement dedans.
La version 64bit de Haiku est fortement recommandée.
J'ai cru comprendre dans l'article que l'approche est du type "J'utilise Plan9 pour les trucs qu'il peut faire, pour le reste, je lance une machine virtuelle OpenBSD", ce que je peux assez bien comprendre. Je ferai probablement la même chose chez moi quand Haiku pourra lancer des machines virtuelles avec accélération matérielle.
Les phrases précédentes et suivantes dans l'article du monde précisent - si jamais celle citée ici ne prend pas assez de pincettes - qu'il s'agit d'un risque purement théorique qui n'a jamais été constaté.
C'est donc plutôt rassurant: les hypothèses les plus improbables de possibles effets secondaires ont été envisagées et prises en compte avant de décider de produire des millions de doses de vaccin, et pour celle-ci la conclusion est que ça semble assez improbable, la prise de risque est donc acceptable.
Les soucis mentionnés dans l'article de recherche (dans ta citation, j'ai pas lu l'article en entier), ça semble plutôt correspondre à des réactions allergiques, soit à l'arn lui-même, soit à son "emballage" dans le vaccin. Réactions qui seraient donc à court ou moyen terme après l'injection, puisque ces deux trucs ne restent pas dans l'organisme et sont détruits assez rapidement.
Autant pour un médicament qui serait pris régulièrement pendant une longue durée j'imagine facilement qu'il peut y avoir des effets à long terme, autant pour un vaccin (une ou deux injectiosn de quelques millilitres, donc), j'ai du mal à voir ce qui pourrait se passer? Quel genre de bombe à retardement ce serait pour que les effets n'apparaissent que plus d'un an après l'injection?
Nombre de personnes vaccinnées en Allemagne: 118533. Au Royaume-Uni: presque 1 million. En Italie: 72000 (j'ai pioché quelques pays au hasard).
On voit aussi d'autres pays ou il n'y a pas de données et il semblerait que la vaccination n'aie pas commencé? Suisse, Belgique, Espagne par exemple.
Donc, oui, on est pas dans les premiers, et non, avoir un ou deux mois de retard sur l'Allemagne ne va rien changer pour la découverte d'effets secondaires à long ou moyen terme. Par contre ça risque de changer des choses sur le nombre de morts.
On peut surveiller ça et en reparler dans une semaine ou deux pour voir comment ça évolue.
L'explication semble être un truc du genre:
- Mirai utilise uclibc
- Maintenant, tous les antivirus voient un bout de uclibc et se disent "oh mon dieu mais c'est Mirai!"
Les "empreintes" utilisées par les antivirus ne ciblent pas toujours un morceau du code qui est effectivement propre au virus. Quand il s'agit d'un bout de code opensource qui est utilisé un peu partout, ben, ils détectent certes le virus, mais aussi plein d'autres trucs qui n'ont rien à voir.
C'est un problème assez courant et la conclusion est que on ne peut pas compter sur les fournisseurs d'antivirus pour ce genre de choses (ce qui est dommage, parce que, comment dire, ça devrait être leur métier).
A force d'avoir des faux positifs tout le temps, on finit par désactiver l'antivirus, et le jour ou y'a un vrai rootkit, on est pas protégé.
En fat, de nos jour, l'initialisation du matériel se fait plutôt par le bootloader que par l'OS lui même.
Si tu utilises EFI tu démarres avec ta pile (et le reste de la mémoire) déjà initialisée, tu as même de quoi afficher des choses à l'écran, utiliser des périphériques USB, …
Je sais pas si je dois être vex, de pas voir Haiku dans cette liste parce qu'il a été oublié, oucontent qu'il n'y soit pas parce qu'il est considéré stable et fonctionnel :)
Idée récupérée des premières versions de Mac OS, d'ailleurs. Ça permettait de défragmenter la mémoire, bien utile sur ces systèmes ou il n'y a pas de MMU.
Et effectivement ça se fait beaucoup mieux dans un langage qui utilise peu ou pas du tout de pointeurs (Pascal à l'époque, mais Java peut convenir aussi) que avec du code C ou on est jamais sûr de qui pointe sur quoi (et on laisse donc les développeurs d'applis se débrouiller tout seuls pour locker et délocker à la main des morceaux de la mémoire).
En tout cas je ne vois pas ce qui empêcherait d'écrire un garbage collector en Java. Il faudra forcément un bout de code bas niveau pour intéragir avec le matériel (dire au MMU d'allouer de la mémoire physique, par exemple), mais toute la gestion de quelle mémoire est allouée à qui peut tout à fait se faire en Java, pourquoi pas?
Au passage il faut rappeler que Java peut aussi être un langage compilé. Et que la machine virtuelle Java n'est jamais qu'un CPU virtuel assez simple et qui peut servir à tout autre chose que faire du Java. On peut le programmer en assembleur java bytecode si on veut.
Principalement le switch de contexte entre les threads (au moins en C, ou il n'y a pas de coroutines inclues dans le langage).
Plein de choses dans la libgcc, mais ça compte pas, ça fait partie du compilateur (multiplications, divisions, etc pour différents types).
Les opérations atomiques ou de synchronisation de mémoire cache (souvent une seule ligne d'assembleur via un inline en C), encore que, gcc fournit des "builtins" qui évitent d'écrire ça directement.
Je crois que Linux a aussi ses propres trucs pour des raisons de performances (opérations sur des bitfields, par exemple? ça fait un moment que j'ai pas mis le nez dedans)
Probablement un petit morceau de bootloader, encore que, avec EFI ou openfirmware, on a déjà un environnement assez confortable au démarrage pour que ça ne soit pas nécessaire.
Ça c'est si on fait du C. Mais si on fait un langage qui ne permet pas de faire tout ce que fait le C (volatiles, trucs moches avec des pointeurs pour l'accès direct à la mémoire, par exemple), on sera probablement obligé de mettre un peu plus d'assembleur pour faire les trucs en question.
Quand on me demande ce à quoi je pensais quand j'ai écrit un bout de code il y a plus de 1 ou 2 mois, c'est difficile pour moi de me souvenir dans quel contexte c'était. Mais cela dépend des gens, de l'organisation des projets, etc. De toutes façons cette métrique n'est pas forcément pertinente: j'espère bien qu'aucun projet n'est complètement réecrit tous les 6 mois ou même tous les 2 ans! C'est assez normal d'avoir du code stable qui n'a pas besoin de bouger, non?
C'est indépendant du turnover, ça mesure surtout le fait que les gens oublient les détails sur ce qu'ils ont fait (même s'ils sont toujours là pour essayer de répondre aux questions).
Je suppose qu'il est possible sans trop complexifier le truc de faire une analyse par tranches: % du code qui a moins de 6 mois, moins de 2 ans, etc. Ça ferait encore un joli graphe à rajouter :)
Pour mesurer la perte de connaissance liée au turnover il faudrait mettre en relation les "knowledge carriers" (nombre de lignes de code qu'une personne est la dernière à avoir modifiées) avec la date du dernier commit par la personne en question?
Swift utilise du reference counting (comme Rust et comme les shared_ptr en C++).
De toutes façons quel que soit le langage, pour faire un OS y'aura forcément un bout d'assembleur à écrire à la main quelque part. C'est juste un plus ou moins gros bout en fonction du langage choisi.
Et y'a Fuchsia chez Google qui est en production sur certains de leurs produits (pas pour remplacer Android, mais sur certains de leurs gadgets connectés il me semble).
Sans compter le prédecesseur "lk", qui est un micronoyau (sans OS autour) utilisé à plusieurs endroits pour le même genre de choses.
[^] # Re: Sociétés de consultance autours de LibreOffice (Collabora et d'autres)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 3.
C'est tout à fait faisable avec BountySource, mais leur équipe marketing a choisi plutôt d'importer directement les tickets des bugtrackers de différent projets sans aucun filtrage, et sans implication directe des gens qui travaillent sur les projets en question.
Il y a même des cas ou un ticket est fermé et le développeur qui a fait le travail n'est pas au courant qu'il y avait une prime et ne la réclame pas.
Je pense qu'on peut reprocher à BountySource d'avoir voulu grossir trop vite. Car, effectivement, une campagne de récolte de dons un peu mieux ciblée, ça fonctionne souvent beaucoup mieux et ça permet de communiquer plus facilement (c'est quelque chose d'"actif", on présente un plan d'attaque, on dit quel(s) développeur(s) va faire le job, on a à peu près une idée du budget nécessaire).
Mais du coup on se rapproche plus des trucs de crowdfunding à la Kickstarter.
# Mon point de vue de développeur
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Programmes de bug bounty dans les projets libres en général et Libreoffice en particulier. Évalué à 10.
Bonjour,
Alors, je suis développeur de logiciels libres sur mon temps libre, et développeurs d'autres trucs sur mon temps salarié.
Le salaire d'un développeur c'est mettons 2000€/mois net (pour prendre un chiffre rond) pour 20 jours travaillés, soit 100€ par jour environ.
Avec 20€ tu pourrais donc financer même pas 2h de travail pour 1 personne (et là c'est sans compter aucune charge, etc). On est donc loin du compte, même pour un bug "simple", sur un projet comme LibreOffice il faut du temps pour trouver ou est le problème, vérifier que la solution fonctionne bien, etc. Et ensuite il faut envouer le code, qu'il soit relu et validé par un autre développeur. Probablement il faut ajouter un test automatisé aussi.
De plus, je trouve pas que c'est un très bon modèle d'être payé à la tâche comme ça. Ça encourage à faire le travail vite et mal pour pouvoir passer au paiement suivant le plus vite possible. Laissant aux autres contributeurs le soin de nettoyer derrière. Ça n'encourage pas la collaboration, puisqu'il faudrait ensuite partager les gains (ou demander de l'aide à quelqu'un et puis ne rien lui donner en contrepartie).
Donc au final, ce n'est pas une source de revenu suffisante, ni même suffisamment stable pour permettre à un développeur de se libérer du temps pour travailler sur un bug (en gros il faudrait que ça permette aux gens d'en vivre ou disons au moins que ça paie mieux que les autres possibilités, sinon, ça ne sert pas à grand chose). Et en plus ça met une ambiance pourrie dans les projets.
Et enfin, ça donne plus de pouvoir de décision aux gens qui ont des sous à donner.
Finalement dans Haiku, on a mis en place un système de vote sur notre bugtracker (chaque utilisateur peut donner un +1/-1 sur les bugs). Et on utilise ça (entre autres) pour prioriser les prochaines choses à faire. Pour le financement, on récolte des dons et on espère un jour en avoir assez pour pouvoir payer un de nos devs à plein temps de façon durable.
[^] # Re: nombre de paires dans un câble
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Câbles sous-marins transatlantiques. Évalué à 10.
Quelques centaines de paires ça ferait donc presque un petabit par seconde de données. L'internet moderne est pas très économe, mais quand même, il faut pas exagérer. Et on peut multiplexer le traffic dedans de façon logicielle (pas comme au temps du téléphone ou du télégraphe analogique ou il fallait une paire de fils de cuivre par communication).
On pourrait penser que c'est une bonne idée d'avoir plusieurs paires de fibres pour faire de la redondance, mais en cas d'incident (câble pris dans un chalut de pêche, séisme, …) y'a des chances que tout le cable soit cassé d'un coup. Donc il vaut mieux poser plusieurs câbles avec des points de départ et d'arrivée différents.
Enfin, ces cables ne sont pas simplement des très longues fibres optiques: il y a à intervalles régulier (tous les 100km environ) des répéteurs qui remettent le signal en forme. Et qui prennent de la place et ont besoin d'une alimentation électrique. On ne peut donc pas si facilement que ça augmenter le nombre de fibres.
# Pour ceux qui en veulent encore plus…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien The etymology of command line tools. Évalué à 10.
https://wiki.debian.org/WhyTheName
[^] # Re: Le TrackPoint, cet incompris
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le trackpoint sur les thinkpad…. Évalué à 5. Dernière modification le 20 janvier 2021 à 23:07.
Il y a des claviers (mécaniques) avec trackpoint aussi chez Unicomp qui a repris la fabrication de claviers basés sur le "model M" d'IBM.
(ils ont aussi des claviers avec 24 touches de fonction, si jamais vous manquez de raccourcis clavier)
[^] # Re: pourquoi s'acharner...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fin des résultats directs sans Javascript sur Google. Évalué à 10.
Je ne vois aucun Javascript dans la version "lite" de DuckDuckGo. Et les liens sont directs.
Il existe un mode lite chez Qwant aussi mais y'a du javascript dedans donc ça a l'air moins intéressant.
# La puce 5G
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Données relatives aux personnes vaccinées contre la Covid-19. Évalué à 8.
Je suis déçu, je m'attendais à trouver les données de géolocalisation de la puce 5G injectée avec le vaccin :(
# Étiquettes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Conception d'une nouvelle police de caractères musicale libre pour MuseScore. Évalué à 3. Dernière modification le 16 janvier 2021 à 12:04.
Message à la modération: j'ai trouvé les étiquettes "music" et "musicale" qui devraient probablement être fusionnées avec "musique"?
("musicale" étant utilisé par un seul sujet sur le forum qui voulait probablement utiliser "retranscription musicale")
[^] # Re: Question : "éthique" des libristes qui n'aiment pas l'open source
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ceres, le moteur d'échecs basé sur Leela Chess Zero, flashé à pleine vitesse. Évalué à 3.
En fait on peut retrouver le commit en question: https://gitweb.gentoo.org/repo/gentoo.git/commit/licenses/GPL-3+-with-cuda-exception?id=9a838b52fc386496ffa471c07193711ede32a119
et voir que cette exception a été écrite à l'origine pour un outil utilisant CUDA pour bruteforcer des clés Wifi.
Il est malheureux que ça ait été repris tel quel, là ou une clause plus générique aurait pu être rédigée. Mais ça semble être plus par facilité (de réutiliser un texte existant) que par malveillance ou volonté de limiter les choses au maximum. C'est aussi probablement plus facile à faire accepter aux développeurs: plus la clause est générique, plus la différence avec la GPL est importante, plus il est probable que quelqu'un trouve que ça va trop loin?
[^] # Re: Question : "éthique" des libristes qui n'aiment pas l'open source
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ceres, le moteur d'échecs basé sur Leela Chess Zero, flashé à pleine vitesse. Évalué à 3.
A priori (source: https://github.com/LeelaChessZero/lc0/issues/184 ) ils ont repris un template d'exception GPL qui existait déjà. Mais la source (chez Gentoo) semble ne plus exister. Et j'ai pas le courage d'aller creuser dans webarchive pour voir à quoi cela s'appliquait au départ.
[^] # Re: L'arroseur arrosé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le groupe eurosceptique leave.eu quitte le Royaume-Uni pour pouvoir conserver son nom de domaine. Évalué à 3.
En fait c'est plutôt cohérent. Maintenant que le Royaume-Uni est sorti de l'Europe, il reste 27 autres pays dont il faut s'occuper… :o)
[^] # Re: Impressionnant !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Medo, un éditeur de vidéos pour Haiku. Évalué à 4.
Pour l'instant il n'y a pas de pilotes avec accélération matérielle pour OpenGL dans Haiku. C'est le moteur llvmpipe de Mesa qui est utilisé. Ça viendra un jour mais il y a d'autres priorités.
Du coup, pas de recommendations particulières pour choisir du matériel de ce côté là. Prévoir plutôt un bon CPU et quelques Go de RAM, que Medo mettra à profit pour mettre en cache le rendu vidéo et permettre de naviguer rapidement dedans.
La version 64bit de Haiku est fortement recommandée.
[^] # Re: overview
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Plan9, l’OS installé parce qu’OpenBSD était trop mainstream. Évalué à 6.
J'ai cru comprendre dans l'article que l'approche est du type "J'utilise Plan9 pour les trucs qu'il peut faire, pour le reste, je lance une machine virtuelle OpenBSD", ce que je peux assez bien comprendre. Je ferai probablement la même chose chez moi quand Haiku pourra lancer des machines virtuelles avec accélération matérielle.
[^] # Re: La vaccination massive est indispensable
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Du désastre du début de la vaccination contre la covid-19 en France . Évalué à 6.
Les phrases précédentes et suivantes dans l'article du monde précisent - si jamais celle citée ici ne prend pas assez de pincettes - qu'il s'agit d'un risque purement théorique qui n'a jamais été constaté.
C'est donc plutôt rassurant: les hypothèses les plus improbables de possibles effets secondaires ont été envisagées et prises en compte avant de décider de produire des millions de doses de vaccin, et pour celle-ci la conclusion est que ça semble assez improbable, la prise de risque est donc acceptable.
Les soucis mentionnés dans l'article de recherche (dans ta citation, j'ai pas lu l'article en entier), ça semble plutôt correspondre à des réactions allergiques, soit à l'arn lui-même, soit à son "emballage" dans le vaccin. Réactions qui seraient donc à court ou moyen terme après l'injection, puisque ces deux trucs ne restent pas dans l'organisme et sont détruits assez rapidement.
[^] # Re: La vaccination massive est indispensable
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Du désastre du début de la vaccination contre la covid-19 en France . Évalué à 6.
Autant pour un médicament qui serait pris régulièrement pendant une longue durée j'imagine facilement qu'il peut y avoir des effets à long terme, autant pour un vaccin (une ou deux injectiosn de quelques millilitres, donc), j'ai du mal à voir ce qui pourrait se passer? Quel genre de bombe à retardement ce serait pour que les effets n'apparaissent que plus d'un an après l'injection?
# Les chiffres
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Du désastre du début de la vaccination contre la covid-19 en France . Évalué à 5.
Comme ça discute pas mal dans le vide dans les commentaires au-dessus, peut être que c'est utile de jeter un oeuil à cette page: https://ourworldindata.org/covid-vaccinations
Nombre de personnes vaccinées en France: 322.
Nombre de personnes vaccinnées en Allemagne: 118533. Au Royaume-Uni: presque 1 million. En Italie: 72000 (j'ai pioché quelques pays au hasard).
On voit aussi d'autres pays ou il n'y a pas de données et il semblerait que la vaccination n'aie pas commencé? Suisse, Belgique, Espagne par exemple.
Donc, oui, on est pas dans les premiers, et non, avoir un ou deux mois de retard sur l'Allemagne ne va rien changer pour la découverte d'effets secondaires à long ou moyen terme. Par contre ça risque de changer des choses sur le nombre de morts.
On peut surveiller ça et en reparler dans une semaine ou deux pour voir comment ça évolue.
[^] # Re: Vitesse de développement par rapport au C/C++
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Sortie de Redox OS 0.6.0. Évalué à 2.
En C++, en plus de Haiku, il y a au moins SkyOS, Syllable et AtheOS (tous les 3 abandonnés aujour'hui), et surtout Fuchsia chez Google.
[^] # Re: Faux positif à 99.9999999999999% (à l'erreur d'arrondi prés)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Virus Mirai dans Ventoy. Évalué à 6.
L'explication semble être un truc du genre:
- Mirai utilise uclibc
- Maintenant, tous les antivirus voient un bout de uclibc et se disent "oh mon dieu mais c'est Mirai!"
Les "empreintes" utilisées par les antivirus ne ciblent pas toujours un morceau du code qui est effectivement propre au virus. Quand il s'agit d'un bout de code opensource qui est utilisé un peu partout, ben, ils détectent certes le virus, mais aussi plein d'autres trucs qui n'ont rien à voir.
C'est un problème assez courant et la conclusion est que on ne peut pas compter sur les fournisseurs d'antivirus pour ce genre de choses (ce qui est dommage, parce que, comment dire, ça devrait être leur métier).
A force d'avoir des faux positifs tout le temps, on finit par désactiver l'antivirus, et le jour ou y'a un vrai rootkit, on est pas protégé.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
En fat, de nos jour, l'initialisation du matériel se fait plutôt par le bootloader que par l'OS lui même.
Si tu utilises EFI tu démarres avec ta pile (et le reste de la mémoire) déjà initialisée, tu as même de quoi afficher des choses à l'écran, utiliser des périphériques USB, …
[^] # Re: RedoxOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Linux ne m'intéresse plus. Évalué à 10.
Je sais pas si je dois être vex, de pas voir Haiku dans cette liste parce qu'il a été oublié, oucontent qu'il n'y soit pas parce qu'il est considéré stable et fonctionnel :)
[^] # Re: Pas de pilotes...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
Idée récupérée des premières versions de Mac OS, d'ailleurs. Ça permettait de défragmenter la mémoire, bien utile sur ces systèmes ou il n'y a pas de MMU.
Et effectivement ça se fait beaucoup mieux dans un langage qui utilise peu ou pas du tout de pointeurs (Pascal à l'époque, mais Java peut convenir aussi) que avec du code C ou on est jamais sûr de qui pointe sur quoi (et on laisse donc les développeurs d'applis se débrouiller tout seuls pour locker et délocker à la main des morceaux de la mémoire).
En tout cas je ne vois pas ce qui empêcherait d'écrire un garbage collector en Java. Il faudra forcément un bout de code bas niveau pour intéragir avec le matériel (dire au MMU d'allouer de la mémoire physique, par exemple), mais toute la gestion de quelle mémoire est allouée à qui peut tout à fait se faire en Java, pourquoi pas?
Au passage il faut rappeler que Java peut aussi être un langage compilé. Et que la machine virtuelle Java n'est jamais qu'un CPU virtuel assez simple et qui peut servir à tout autre chose que faire du Java. On peut le programmer en assembleur java bytecode si on veut.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 10.
Principalement le switch de contexte entre les threads (au moins en C, ou il n'y a pas de coroutines inclues dans le langage).
Plein de choses dans la libgcc, mais ça compte pas, ça fait partie du compilateur (multiplications, divisions, etc pour différents types).
Les opérations atomiques ou de synchronisation de mémoire cache (souvent une seule ligne d'assembleur via un inline en C), encore que, gcc fournit des "builtins" qui évitent d'écrire ça directement.
Je crois que Linux a aussi ses propres trucs pour des raisons de performances (opérations sur des bitfields, par exemple? ça fait un moment que j'ai pas mis le nez dedans)
Probablement un petit morceau de bootloader, encore que, avec EFI ou openfirmware, on a déjà un environnement assez confortable au démarrage pour que ça ne soit pas nécessaire.
Ça c'est si on fait du C. Mais si on fait un langage qui ne permet pas de faire tout ce que fait le C (volatiles, trucs moches avec des pointeurs pour l'accès direct à la mémoire, par exemple), on sera probablement obligé de mettre un peu plus d'assembleur pour faire les trucs en question.
[^] # Re: Mais qu'est-ce que c'est-il donc ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Repostat, générer des statistiques sur un dépôt Git. Évalué à 2.
Quand on me demande ce à quoi je pensais quand j'ai écrit un bout de code il y a plus de 1 ou 2 mois, c'est difficile pour moi de me souvenir dans quel contexte c'était. Mais cela dépend des gens, de l'organisation des projets, etc. De toutes façons cette métrique n'est pas forcément pertinente: j'espère bien qu'aucun projet n'est complètement réecrit tous les 6 mois ou même tous les 2 ans! C'est assez normal d'avoir du code stable qui n'a pas besoin de bouger, non?
C'est indépendant du turnover, ça mesure surtout le fait que les gens oublient les détails sur ce qu'ils ont fait (même s'ils sont toujours là pour essayer de répondre aux questions).
Je suppose qu'il est possible sans trop complexifier le truc de faire une analyse par tranches: % du code qui a moins de 6 mois, moins de 2 ans, etc. Ça ferait encore un joli graphe à rajouter :)
Pour mesurer la perte de connaissance liée au turnover il faudrait mettre en relation les "knowledge carriers" (nombre de lignes de code qu'une personne est la dernière à avoir modifiées) avec la date du dernier commit par la personne en question?
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 7.
Swift utilise du reference counting (comme Rust et comme les shared_ptr en C++).
De toutes façons quel que soit le langage, pour faire un OS y'aura forcément un bout d'assembleur à écrire à la main quelque part. C'est juste un plus ou moins gros bout en fonction du langage choisi.
[^] # Re: micro-noyau
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 7. Dernière modification le 08 décembre 2020 à 13:33.
Et y'a Fuchsia chez Google qui est en production sur certains de leurs produits (pas pour remplacer Android, mais sur certains de leurs gadgets connectés il me semble).
Sans compter le prédecesseur "lk", qui est un micronoyau (sans OS autour) utilisé à plusieurs endroits pour le même genre de choses.