pulkomandy a écrit 2037 commentaires

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.

Ok, alors j'ai commencé à faire du vélo en habitant Aussonne (1h de marche à pied pour rejoindre l'arrêt de tramway le plus proche, puis 45mn de tramway pour rejoindre le centre de Toulouse) et en allant travailler à Castelnau d'Estrétefonds (dans la direction opposée par rapport au dit tramway, qui du coup était inutile pour moi). Ensuite j'ai changé de mission et je me suis retrouvé à faire Aussonne-Ramonville. Regarde sur une carte et viens me dire que le problème c'est que les entreprises sont hors de la ville.

Faire 1h30 de vélo, c'est pas insurmontable. Et en 1h30, tu traverses largement Toulouse du nord au sud sans problème (trajet de 45mn en voiture compte tenu des bouchons en heure de pointe).

Des gens qui faisaient plusieurs heures de vélo ou de marche à pied pour aller travailler, y'en avait plein dans les années 50 ou 60 avant qu'on commence à mettre des voitures partout. Il va falloir arrêter d'attendre qu'une solution toute cuite et confortable tombe dans la bouche des gens, là.

Un langage qui "disparaît", c'est un http://cobolcowboys.com qui apparaît pour assurer la maintenance et se faire plein de sous.

Bonjour,

Le rendu pour un projet donne ceci: https://pulkomandy.github.io/xmpp-doap/samples/movim.xml (si y'a un webdesigner dans le coin qui veut améliorer un peu le style CSS, c'est avec plaisir).

Quand j'en ai eu marre de faire deux fois 1h30 de vélo et de transports en commun par jour pour aller travailler, j'ai déménagé moins loin de mon lieu de travail. Je traversais Toulouse du nord au sud.

Oui, il faut bousculer ses habitudes (y'a des gens qui pensent que 1h30 de transport c'est insurmontable?!)

Quand mon patron en a eu marre que des gens viennent en vélo et que ça pue la transpiration dans les bureaux, il a installé des douches.

C'est dans ce sens là que ça fonctionne. Si tu attends d'habiter à 10 minutes de ton travail avec une belle piste cyclable et des douches à l'arrivée, les choses ne vont pas avancer.

Et c'est la même chose pour "les politiques" mentionnés plus haut: s'ils sont réélus, c'est que des gens ont voté pour eux. Si des gens ont votés pour eux c'est parce que en majorité ils en ont rien à faire du réchauffement climatique. Ils savent que ça existe mais dans la tête de beaucoup de gens c'est pour les siècles à venir, sauf que non, c'est pour dans 10 ou 15 ans. Et beaucoup ne réalisent pas les efforts à faire (pour rappel, le compteur est à 10% d'émissions en moins chaque année pendant 10 ans, plus des efforts pour absorber du co2 pour que le bilan soit négatif à la fin. Ceci pour ne pas dépasser un réchauffement de 1.5 degrés. Sachant que en plus, ce serait mieux de le faire de façon équitable, c'est à dire que y'a certains pays qui ont plus d'efforts à faire que d'autres.

(je vous laisse, j'ai un voyage à Stocholm en train à préparer pendant que vous attendez la taxe sur le kérosène pour arrêter de prendre l'avion)

On a bien vu que c'était au moins largement inspiré de Pascal! Essaie pas de nous embrouiller en faisant croire que c'est pour remplacer C ou Go!

Pourquoi utiliser RSS quand il y a aussi un mirroir en Gopher?

Pourtant je vois ça dans la liste des fonctionalités:
"Can compile Javascript sources to executables with no external dependency."

Mais ça ne fait pas tout pour node.js, il faut aussi avoir des bindings vers les APIs natives pour tout un tas de trucs.