pulkomandy a écrit 2019 commentaires

cryptopan!

Sous Windows, on branche la clé, elle est montée toute seule et les fichiers sont accessibles en écriture.

Sous Linux:
- On monte la clé, les UID ne sont pas bon
- On note l'UID dans un coin
- On démonte la clé
- On ouvre un terminal, on fait man mount pour retrouver l'option qui va bien
- On remonte la clé avec les bons paramètres cette fois ci.

Je me vois mal expliquer ça à mes parents qui s'en sortent très bien avec la façon dont ça fonctionne sous Windows.

Alors ouais, c'est "toujours possible". Mais moi je préfère un truc qui "juste marche". D'ailleurs je vois plutôt les utilisateurs de Linux garder leurs clé USB et autres supports amovibles formatté en FAT, y'a ptêtre bien une raison.

Alors voilà le genre de questions que Stallman se pose:

https://stallman.org/archives/2006-mar-jun.html#05 June 2006 (Dutch paedophiles form political party)

I am skeptical of the claim that voluntarily pedophilia harms children. The arguments that it causes harm seem to be based on cases which aren't voluntary, which are then stretched by parents who are horrified by the idea that their little baby is maturing.

https://stallman.org/archives/2012-jul-oct.html#15_September_2012_(Censorship_of_child_pornography)

Rick Falkvinge joins me in demanding an end to the censorship of "child pornography", and points out that if in the US you observe the rape of a child, making a video or photo to use as evidence would subject you to a greater penalty than the rapist.

à un moment il va falloir s'en poser, des questions. C'est quelqu'un qui soutient ouvertement la pornographie infantile. Alors très bien, il pense ce qu'il veut, mais c'est pas la meilleure personne à mettre à la tête de la FSF.

exFAT est un système de fichier pour les supports amovibles. Mettre de l'EXT2 sur une clé USB, c'est chiant, parce que tu vas arriver sur une autre machine, les user IDs des utilisateurs ne vont pas correspondre et du coup tu n'auras pas les droits pour accéder aux fichiers.

D'autre part, il est prévu pour qu'on puisse débrancher la clé n'importe quand (au milieu d'une écriture) et que ça ne mette pas trop le bazar dans le système de fichiers.

Et enfin, comme indiqué dans la réponse au-dessus, il est reconnu par Windows.

Alors oui, on a déjà un système de fichier qui répond pas trop mal à ces trois critères, c'est UDF. Mais personne ne sait qu'il existe!

BFS existe toujours et fonctionne très bien sur Haiku. Par contre ça manque toujours d'application exploitant vraiment ces fonctions. On passe beaucoup par le gestionnaire de fichier pour faire certains trucs, mais ça suppose d'utiliser la même interface pour gérer les mails, la musique, les photos, etc, et c'est pas super pratique.

Il y a aussi un tas de problèmes d'interopérabilité, quand on copie un fichier vers une clé usb en FAT, les attributs qui permettent d'indexer les fichiers ne sont pas préservés par exemple, et plus embêtant, on risque de perdre ces atttributs si on essaie de faire un "cp" en ligne de commande, par exemple, parce que par défaut ça ne copie que le contenu.

Il y a aussi le problème que la plupart des formats de fichiers (mp3 avec les tags id3, jpeg avec exif, …) ont développé des solutions pour stocker les attributs plutôt dans le fichier, et du coup, il faut synchroniser ces deux modes de fonctionnement (et la correspondance n'est pas toujours directe).

Donc techniquement, on sait faire, mais pour l'expérience utilisateur, c'est pas encore ça.

Pas tant que ça sur les premières versions de Windows 95 et avec une installation propre. C'est devenu moins bon à ce sujet à force d'ajouter plein de services dans les versions suivantes et jusqu'à l'arrivée de Windows 2000 et XP qui a pas mal remis les choses au propre.

Je t'auréis bien montré quelques outils pqs spéciqlement pour développeurs, mais ce soir j'ai pas envie de fouiller parmi les plus de 2700 projets déjà publiés par microsoft sur github. Il en faudra combien pour convaincre les gens que Microsoft fait du logiciel libre?

On peut citer le cas de EGCS, le fork de GCC qui a tellement bien marché que… maintenant c'est lui qui s'appelle GCC, et le GCC original a été jeté à la poubelle.

Pourtant ce fork avait été créé un peu dans le même esprit: une constatation que l'organisation humaine de gcc empêchait certains développements et expérimentations.

C'est souvent difficile au moment de la création d'un fork de savoir si la mayonnaise va prendre ou pas. C'est toujours un pari risqué et souvent un aveu d'échec d'autres méthodes (a priori ce serait mieux d'arriver à travailler ensemble, mais ça ne marche pas toujours).

Le problème en fait n'est pas de faire un fork (c'est un droit donné par la licence du logiciel, sans avoir à donner de justification bonne ou mauvaise). Le problème c'est la façon de communiquer sur la création du nouveau projet. On peut faire ça de façon respectueuse en explicant calmement, ou bien attaquer le projet original en essayant de leur voler des contributeurs.

Si vous en voulez plus: https://wiki.debian.org/WhyTheName

Personnellement je n'ai pas trop envie d'avoir un score global de réputation, je suis là pour discuter tranquille.

Par contre, je trouve bien de voir que certains de mes messages se retrouvent en négatif et je me pose la question de savoir qui j'ai dérangé avec une intervention inappropriée. Et ça devient plus agressif envers les gens qui dépassent vraiment les bornes en postant vraiment beaucoup de commentaires inutiles.

Du coup, je trouve que le système actuel marche plutôt bien, il n'est pas trop intrusif, on peut toujours voir facilement les commentaires négatifs (je le fais souvent quand je vois une réponse qui a l'air intéressante ou que le sujet m'intéresse).

On est dans une logique de modération (au sens premier du terme) plus que de récompense et de réputation. Ce système tend à calmer les choses et éviter les trolls qui durent sur des centaines de messages.

ça n'a surtout rien à voir avec IRC, il faut avoir utilisé un client dans un terminal.

J'utilise souvent IRC sans disposer de ce raccourci.

Et surtout c'est un vrai standard ouvert, avec les spécifications disponibles chez l'ECMA sans payer et sans avoir besoin d'être membre de l'Open Invention Network: https://www.ecma-international.org/publications/standards/Ecma-167.htm

Alors, oui, mais pas pour ça.

Yaffs est un système de fichier prévu pour les cas ou on a accès directement à la mémoire NAND flash, qui a besoin:
- De "wear leveling": s'assurer de ne pas écrire trop souvent aux mêmes endroits dans la mémoire car elle finit par s'user
- De gestion des "bad blocks": stockage de bits supplémentaires permettant de vérifier l'intégrité de chaque secteur et de corriger les erreurs de quelques bits qui se produisent régulièrement sur ce type de mémoire.

Si tu utilises une clé USB, elle a déjà un contrôleur qui s'occupe de tous ces détails en interne, donc YAFFS ne sert à rien. En plus, il a besoin d'accéder aux données "OOB" de la flash: des bits "en plus" dans chaque bloc qui sont prévus pour stocker des métadonnées sur la flash elle-même, et qui ne sont pas accessibles sur une clé USB. Donc il ne sera même pas utilisable.

ça marche tant que l'équipe "core dev" reste petite. Si elle finit par grossir, on peut très bien retrouver le même problème à l'intérieur de l'équipe.

Mais on a effectivement aussi ce genre de chose chez Haiku: quand on fait un vote, seuls les membres de cette équipe peuvent voter, mais ça n'empêche pas les autres de donner leur avis, et même peut-être ça les pousse à faire du lobbying auprès des gens qui peuvent voter.

Je n'ai pas de solution parfaite, on fait avec :)

Chez Haiku, on a eu aussi le problème ou on fait tout un tas de discussions, on choisit une option, et à la fin il se trouve que les gens qui ont poussé cette option ne sont pas développeurs et/ou n'ont pas envie de s'occuper de la réalisation.

Donc on a aussi laissé tomber le formalisme là dessus: c'est le développeur qui écrit le code qui prend les décisions (sur l'architecture et les outils utilisés, en tout cas), en consultant la communauté seulement pour les points sur lesquels il ne sait pas prendre de décision tout seul.

Le cas le plus remarquable remonte à quelques années, quand on a décidé de remplacer SVN. Après des heures de débats acharnés, la plupart des gens ont voté pour Mercurial. Mais étant donné le cahier des charges, la personne responsable du développement a tout de même mis en place Git qui permettait de faire tout ce dont on avait besoin.

L'intelligence collective ne permet pas de prendre des décisions. On peut l'interroger sur des points précis et récolter des tas d'informations, mais il faut quand même quelqu'un qui finit par trancher les décisions.

C'est marrant comment sparc est oublié partout alors que ça fait 30 ans que le jeu d'instruction est ouvert! Mais du coup ça fait 3 :)

Du coup, c'est à chaque application de se débrouiller pour faire la mise à l'échelle, et ça ne fonctionne que si l'application a toutes ses fenêtres avec le même DPI (donc pas si on répartit une ou plusieurs fenêtres sur 2 écrans, par exemple).

Mais effectivement je pense qu'on ne fera pas beaucoup mieux. Et puis il faudrait déjà qu'on aie des drivers de cartes graphiques qui savent afficher des choses sur plusieurs écrans :)

Bon, en France, le droit d'accès aux données existait déjà avant le RGPD, du coup, rien ne change?

Alors, dans l'idée c'est ça, mais la mise en pratique est plus compliquée.

On pourrait en effet choisir de changer le rapport entre "points" et pixels, mais il y a des cas ou l'application a vraiment besoin de manipuler des pixels directement, du coup ça mettrait le bazar.

Si on reprend la doc de BeOS à ce sujet:

A single coordinate unit is 1/72 of an inch, roughly equal to a typographical point. However, all screens are considered to have a resolution of 72 pixels per inch (regardless of the actual dimension), so coordinate units actually count screen pixels. In other words, one unit is the distance between the centers of adjacent pixels on-screen.

"Une unité de coordonnées vaut 1/72 de pouce, environ un point typographique. Cependant, on considère que tous les écrans ont une résolution de 72dpi (peu importe la taille réelle), donc l'unité de coordonnée est en fait un nombre de pixels. Autrement dit, une unité est la distance entre le centre de deux pixels adjacents sur l'écran"

Lorsque le support de l'impression est arrivé, c'est clairement la deuxième définition qui a été retenue. Sur papier, on a des unités de 1/300 ou 1/600 de pouce selon l'imprimante utilisée. Il faut donc faire la mise à l'échelle en utilisant des polices de caractères plus grandes, etc.

La solution retenue est donc:
- Laisser l'utilisateur choisir une taille de texte dans les préférences (fait)
- Ajuster la taille de tous les éléments en fonction (le texte lui-même, les icônes, l'espacement entre les éléments de l'interface, etc (en cours)
- Ajuster la taille de texte (et du reste par conséquent) par défaut en fonction de la résolution de l'écran (pas encore fait, et de trop nombreux écrans ne donnent pas des informations correctes)

Il y a quelques détails pénibles, par exemple les constantes B_V_SCROLL_BAR_WIDTH et B_H_SCROLL_BAR_HEIGHT qui donnent l'épaisseur des barres de défilement et qui sont fixées à 16 pixels, ce qui est trop petit sur un écran haute définition.

Et là ou ça devient le bazar, c'est quand il y a plusieurs écrans avec des résolutions différentes. Si une fenêtre est visible sur 2 écrans en même temps, on ne sait pas encore bien comment faire. L'approche ou on fait une mise à l'échelle entre les "points" et les pixels n'est pas forcément meilleure, par exemple sous Windows on se retrouve avec un rendu flou et très moche sur certaines applications. On aurait probablement le même genre de problème si une application essaie d'allouer un bitmap pour dessiner quelque chose hors de l'écran: comment savoir si ce bitmap va être ensuite affiché (un cas assez courant, ça permet d'éviter certains clignotements désagréables de l'interface), ou si c'est un traitement d'une image destinée à être enregistrée sur le disque dur, par exemple?

En fait le problème se pose, pas pour les composants eux-même, mais quand à la place d'un schéma on te donne ce genre de chose:

Du coup si tu es daltonien, impossible de savoir la valeur de la résistance que tu dois utiliser!

(bon, la page d'ou vient cette image en particulier contient aussi le schéma avec un formalisme plus classique et les valeurs numériques indiquées. Mais c'est pas forcément le cas partout).

Ok, alors il s'agit d'un démonstrateur pour un projet de matériel sécurisé (donc pas du tout hackable). Le code sera open source parce que ce n'est pas vraiment le but premier du projet. Les développement sur le matériel seront utilisés dans d'autres projets secret défense.

Un truc qui me surprend c'est qu'à un moment ça parle de travail sur un compilateur sécurisé pour… le langage C? On aurait pu trouver un meilleur choix comme langage de programmation, non?

Probablement parce que les versions plus récentes utilisent du code développé par d'autres entreprises, sur lequel ils ne peuvent pas aussi facilement changer la license, et aussi parce qu'il n'y a probablement pas un dépôt git avec les sources de tout Windows XP.

Déjà pour MS-DOS 6.22, la seule différence avec la version 6.20 est le remplacement de l'outil de compression de disques, drivespace remplace un autre outil pour lequel Microsoft n'avait qu'une license temporaire. C'est aussi la raison pour laquelle HyperTerminal n'est plus fourni avec Windows aujourd'hui.

Mais ils ont déjà libéré des choses plus récentes: le winfile.exe de Windows 3.11 qui apparament était toujours utilisé et maintenu par un développeur en interne, la calculatrice de windows 10, …

Ça arrive tout doucement et par petits morceaux.

En tant que développeur de Haiku, je ne suis pas au courant de ça non plus.

On a récupéré des bouts de code source de BeOS (le Tracker et la Deskbar) qui avaient été publié sous licence libre à la toute fin de Be. Mais jamais de financements.

Pour son commentaire sur le fait que Haiku serait une version "bootleg" de BeOS, il s'agit probablement d'une confusion avec Zeta, qui lui utilisait les sources de BeOS dans des conditions contractuelles peu claires (ça rappelle un peu ce qui s'est passé également avec RiscOS).

Alors, DR-DOS est devenu Caldera OpenDOS qui a été publié mais avec une license incompatible avec la plupart des autres licenses libres (d'après https://archive.org/details/opendos701)

Et FreeGEM/OpenGEM est également directement issu des sources du GEM original publiées également par Caldera.

Donc oui, DR-DOS et GEM ont été libérés bien avant le DOS de Microsoft et les projets sont toujours un peu vivants. Surtout pour GEM, car il y a aussi pas mal d'activité sur les machines compatibles Atari ST "modernes" avec des versions gérant les couleurs 32bit, etc. La version DOS de GEM reste assez simpliste en comparaison.

Sinon tu as l'approche d'Objective C: appeler une méthode d'un objet nil renvoie nil. Pas de plantage, il ne se passe juste rien.