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.
Chez Haiku ça nous arrange bien que Redox existe. Quand des gens sont tenté d'essayer d'ajouter du Rust dans Haiku on peut les rediriger vers un projet qui leur convient mieux :o)
Sinon, dans les langages morderes qui marchent bien, il y a Swift et Go à ne pas oublier, quand même. Et dans les moins modernes il y a aussi plein de trucs (Object Pascal, Ada, …) mais ça n'intéresse jamais personne.
Une fonction que j'utilise pas mal est de lancer un "make" ou équivalent dans un terminal vim. Ce qui permet à vim de parser la sortie du make et de me surligner les erreurs dans les fichiers ouverts.
Sinon ça me sert ponctuellement pour lancer une ou deux commandes (souvent un git grep pour retrouver un bout de code par exemple). Probablement parce que y'a plein de choses que je pourais faire directement avec des commandes vim, mais que j'ai jamais appris car j'ai l'habitude d'avoir un terminal.
Enfin, c'est utile parce que la gestion des splits, onglets, et compagnie de vim s'applique aux terminaux. Certes, on pourrait aussi faire ça avec tmux, mais quand on a l'habitude des raccourcis claviers de vim, ça fait une chose de moins à mémoriser.
J'ai travaillé pour MicroEJ il y a quelques années et globalement l'équipe était composée de gens qui savent ce qu'ils font en terme de performances et optimisation.
Leur SDK répond a des besoins bien spécifiques, par exemple la nécessité d'avoir sur le même cpu du code temps réel (écrit en C) et une interface graphique (écrite en Java, sans contraintes temps réel, et relativement bien isolée malgré l'absence de protection mémoire matérielle).
L'utilisation d'une machine virtuelle java a bien sûr un coût, mais elle permet aussi de faire mieux que le C sur certains points, par exemple c'est possible de défragmenter la mémoire, d'allouer dynamiquement la stack de chaque thread par tout petits morceaux (512 octets) qui ne sont utilisés que très ponctuellement, …
Le tout peut fonctionner avec seulement quelques dizaines de Ko de RAM pour une application complète (code C temps réel + interphace graphique)
Ça ferait une quinzaine de jours pour 256 octets, donc (en supposant que c'est linéaire)? C'est pas si long que ça, l'attaque ne se fait pas forcément en temps réel, mais peut être utilisée sur des données préalablement interceptées. Au bout de 15 jours je pense que certaines informations seront toujours valables et intéressantes.
Il n'y a pas vraiment une personne qui connaît tous les jeux derrière cette page. C'est généré à partir d'un projet Github (https://github.com/opengaming/osgameclones/) et c'est en ligne depuis quelques années. Et plein de gens (joueurs, développeurs de jeux, archivistes en herbe des internets, …) contribuent pour ajouter des jeux à la liste. Ça aurait pu trouver sa place sur wikidata ou quelque chose dans le même genre, peut être.
Les définitions de ce qui est "open source" et de ce qui est, ou pas, un "clone" sont en effet prises avec un sens assez large (mais je void qu'il y a maintenant des tags pour indiquer "remake", "clone", ou "similar").
Est-ce que XWiki pourrait remplacer Confluence, et sinon, qu'est-ce qui lui manque? Ça a l'air assez similaire mais j'ai peu utilisé Confluence et pas du tout XWiki pour l'instant.
Impossible de glisser les items dans la liste comme il est demandé: sur mon téléphone, la page scrolle en même temps…
Je regarderai demain depuis un ordinateur
On peut arrêter de parler de censure pour n'importe quoi? Facebook n'est pas un service public. Ils peuvent très bien décider ce qu'ils font apparaître sur leur site web ou pas.
Qu'ils fassent leur modération et leur sélection n'importe comment (de façon opaque et arbitraire), soit. Mais ce n'est pas de la censure.
Il y a la bitbox avec un CPU ARM à environ 130MHz (ça change en fonction du mode vidéo choisi) et des capacités graphiques quelque part entre l'Atari VCS 2600 et la MegaCD (beaucoup de choses étant faites en logiciel dans la bitbox, elle peut donc se programmer de plein de façons différentes selon les besoins).
Le matériel est relativement simple (il n'y a pas grand chose sur la carte à part le CPU et les connecteurs audio/video/usb) mais pas évident à assembler soi même si on a pas l'habitude de manipuler un fer à souder (composants montés en surface et de petite taille).
Le projet semble ne plus trop évoluer ces derniers temps. Peut être que je me remettrai un jour à programmer des choses pour la bitbox.
Oui, je n'ai pas précisé mais ce message était dans un esprit de "il faut connaîtreses ennemis". C'est pas parce que c'est pas libre qu'il n'y a que des mauvaises idées dedans, et, à défaut de pouvoir réutiliser le code, on peut au moins récupérer les idées.
Enfin bref, je ne comprend pas que ça ne soit pas une fonctionnalité par défaut de n'importe quel navigateur et qu'il soit nécessaire de jongler avec des outils comme youtube-dl ou des extensions.
Le navigateur web Vivaldi a un menu clic droit->enregistrer la vidéo (comme pour les images dans les autres navigateurs). Pourquoi faire simple quand on peut faire compliqué?
Difficile de voir ce à quoi la lettre fait références pour ces 3 vidéos, il est question d'un "exhibit A" mais je ne vois pas de lien ou de pièce jointe.
[^] # 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.
[^] # 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.
Chez Haiku ça nous arrange bien que Redox existe. Quand des gens sont tenté d'essayer d'ajouter du Rust dans Haiku on peut les rediriger vers un projet qui leur convient mieux :o)
Sinon, dans les langages morderes qui marchent bien, il y a Swift et Go à ne pas oublier, quand même. Et dans les moins modernes il y a aussi plein de trucs (Object Pascal, Ada, …) mais ça n'intéresse jamais personne.
[^] # 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é à 3.
Si je me souviens bien c'est inspiré de cet article: https://www.feststelltaste.de/identifying-lost-knowledge-in-the-linux-kernel-source-code/ et ce doit donc être le nombre de lignes de code qui n'ont pas été modifiées depuis plus de 6 mois
[^] # Re: Terminal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Transformer vim en IDE avec LSP et DAP. Évalué à 3.
Une fonction que j'utilise pas mal est de lancer un "make" ou équivalent dans un terminal vim. Ce qui permet à vim de parser la sortie du make et de me surligner les erreurs dans les fichiers ouverts.
Sinon ça me sert ponctuellement pour lancer une ou deux commandes (souvent un git grep pour retrouver un bout de code par exemple). Probablement parce que y'a plein de choses que je pourais faire directement avec des commandes vim, mais que j'ai jamais appris car j'ai l'habitude d'avoir un terminal.
Enfin, c'est utile parce que la gestion des splits, onglets, et compagnie de vim s'applique aux terminaux. Certes, on pourrait aussi faire ça avec tmux, mais quand on a l'habitude des raccourcis claviers de vim, ça fait une chose de moins à mémoriser.
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal COBOL : c'est dans les vieilles marmites.... Évalué à 7.
J'ai travaillé pour MicroEJ il y a quelques années et globalement l'équipe était composée de gens qui savent ce qu'ils font en terme de performances et optimisation.
Leur SDK répond a des besoins bien spécifiques, par exemple la nécessité d'avoir sur le même cpu du code temps réel (écrit en C) et une interface graphique (écrite en Java, sans contraintes temps réel, et relativement bien isolée malgré l'absence de protection mémoire matérielle).
L'utilisation d'une machine virtuelle java a bien sûr un coût, mais elle permet aussi de faire mieux que le C sur certains points, par exemple c'est possible de défragmenter la mémoire, d'allouer dynamiquement la stack de chaque thread par tout petits morceaux (512 octets) qui ne sont utilisés que très ponctuellement, …
Le tout peut fonctionner avec seulement quelques dizaines de Ko de RAM pour une application complète (code C temps réel + interphace graphique)
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal COBOL : c'est dans les vieilles marmites.... Évalué à 5.
Depuis quand c'est un langage de programmation qui doit encadrer les stagiaires? C'est pas plutôt le rôle du maître de stage?
[^] # Re: Efficacité limitée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Nouvelle faille découverte sur les CPU Intel via l'implémentation RAPL . Évalué à 3.
Ça ferait une quinzaine de jours pour 256 octets, donc (en supposant que c'est linéaire)? C'est pas si long que ça, l'attaque ne se fait pas forcément en temps réel, mais peut être utilisée sur des données préalablement interceptées. Au bout de 15 jours je pense que certaines informations seront toujours valables et intéressantes.
[^] # Re: bien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Liste des clones de jeux connus. Évalué à 5.
Il n'y a pas vraiment une personne qui connaît tous les jeux derrière cette page. C'est généré à partir d'un projet Github (https://github.com/opengaming/osgameclones/) et c'est en ligne depuis quelques années. Et plein de gens (joueurs, développeurs de jeux, archivistes en herbe des internets, …) contribuent pour ajouter des jeux à la liste. Ça aurait pu trouver sa place sur wikidata ou quelque chose dans le même genre, peut être.
Les définitions de ce qui est "open source" et de ce qui est, ou pas, un "clone" sont en effet prises avec un sens assez large (mais je void qu'il y a maintenant des tags pour indiquer "remake", "clone", ou "similar").
[^] # Re: Précisions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 2.
Est-ce que XWiki pourrait remplacer Confluence, et sinon, qu'est-ce qui lui manque? Ça a l'air assez similaire mais j'ai peu utilisé Confluence et pas du tout XWiki pour l'instant.
# Glisser déposer sur téléphone
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Votez pour les choix graphiques de la prochaine version stable de Debian, Bullseye jusqu'au 09/11/20. Évalué à 2.
Impossible de glisser les items dans la liste comme il est demandé: sur mon téléphone, la page scrolle en même temps…
Je regarderai demain depuis un ordinateur
# Payback
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien vieux (2008) mais amusant : « Ma vraie histoire de Grand Theft Auto ». Évalué à 4.
Ça me rapelle qu'il existe un clone de GTA pour Amiga: Payback. Mais ça ne tourne pas sur un Amiga en configuration de base.
# Censure?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Nouveau cas de censure de Facebook: le journal en ligne Rapport de forces en est totalement évincé. Évalué à 8.
On peut arrêter de parler de censure pour n'importe quoi? Facebook n'est pas un service public. Ils peuvent très bien décider ce qu'ils font apparaître sur leur site web ou pas.
Qu'ils fassent leur modération et leur sélection n'importe comment (de façon opaque et arbitraire), soit. Mais ce n'est pas de la censure.
[^] # Re: Combien de bits?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Construisez et programmez votre console de jeux open source. Évalué à 5.
Il y a la bitbox avec un CPU ARM à environ 130MHz (ça change en fonction du mode vidéo choisi) et des capacités graphiques quelque part entre l'Atari VCS 2600 et la MegaCD (beaucoup de choses étant faites en logiciel dans la bitbox, elle peut donc se programmer de plein de façons différentes selon les besoins).
Le matériel est relativement simple (il n'y a pas grand chose sur la carte à part le CPU et les connecteurs audio/video/usb) mais pas évident à assembler soi même si on a pas l'habitude de manipuler un fer à souder (composants montés en surface et de petite taille).
Le projet semble ne plus trop évoluer ces derniers temps. Peut être que je me remettrai un jour à programmer des choses pour la bitbox.
[^] # Re: Alternatives ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 4. Dernière modification le 25 octobre 2020 à 23:17.
Oui, je n'ai pas précisé mais ce message était dans un esprit de "il faut connaîtreses ennemis". C'est pas parce que c'est pas libre qu'il n'y a que des mauvaises idées dedans, et, à défaut de pouvoir réutiliser le code, on peut au moins récupérer les idées.
Enfin bref, je ne comprend pas que ça ne soit pas une fonctionnalité par défaut de n'importe quel navigateur et qu'il soit nécessaire de jongler avec des outils comme youtube-dl ou des extensions.
[^] # Re: Alternatives ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 2.
Le navigateur web Vivaldi a un menu clic droit->enregistrer la vidéo (comme pour les images dans les autres navigateurs). Pourquoi faire simple quand on peut faire compliqué?
[^] # Re: N'ont-ils pas donné à la RIAA tout ce qu'il faut?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 4.
A priori, les tests unitaires utilisent des vidéos de test de ce type: https://www.youtube.com/watch?v=BaW_jenozKc et de même pour les exemples dans la documentation.
Difficile de voir ce à quoi la lettre fait références pour ces 3 vidéos, il est question d'un "exhibit A" mais je ne vois pas de lien ou de pièce jointe.
[^] # Re: Ras le bol de ces noms de langage de merde!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ras le bol de ces moteurs de merde!. Évalué à 4.
D'un autre côté… faire des trucs impossible à retrouver via un moteur de rechercqe, ça oblige les gens à savoir utiliser les URLs et les bookmarks :o)