pulkomandy a écrit 1703 commentaires

C'est triste, parce que les gens sont prêts à payer 12 dollars pour ça, et pourtant Ubuntu n'a pas réussi à trouver de business model qui fonctionne pour Linux sur le Desktop. Trop occupés à réécrire un serveur graphique, un environnement de bureau, tout ça, sans doute?

Parce que bon, pour avoir cotoyé des utilisateurs néophytes d'Ubuntu, le "à force de faire des mises à jour qui ne suppriment jamais les anciens noyaux, mon disque dur est plein et maintenant j'arrive plus à ouvrir une session graphique", c'est un classique du PC en panne. Et pendant ce temps on continue à se moquer de Windows…

Donc oui, les gens sont prêts à payer pour un truc qui juste marche. C'est dommage que Ubuntu ne le propose pas directement, non?

Les infrarouges sont bien ressentis par la peau, même pas besoins des yeux pour ça.

C'est pour faire comme GNU/Linux!

Nous avons notre propre thread "event loop" qui centralise les accès à dbus. On s'arrange pour ne pas faire de traitements trop longs dedans, seulement distribuer les évènements vers d'autres threads.

Il s'agit d'un thread Java qui appelle via JNI les fonctions de la libdbus native, ce qui fait qu'on a peu de code natif à maintenir.

Utiliser GDBus nous aurait contraint à une boucle d'évènement native basée sur la GLib, et du coup à faire beaucoup plus de choses en C ou C++ (langages que j'apprécie beaucoup, mais là on parle d'un projet en Java). Avec JNIDbus, un projet Java peut utiliser DBus sans avoir besoin d'ajouter aucun code natif et de façon plutôt confortable (puisque les messages sont automatiquement convertis en objets Java). Je ne suis pas certain qu'on serait arrivé à la même chose avec une boucle d'évènement native, je pense que chaque application aurait nécessité d'intervenir dessus et du coup on ne pourrait pas vraiment dire que c'est une API Java s'il faut écrire du JNI pour s'en servir.

C'est effectivement une API bas niveau, ce qui serait pénible pour l'utiliser directement dans une application, mais qui est plutôt intéressant pour construire une API Java au-dessus en prenant en compte les besoins de nos applications. C'est souvent difficile de prendre une API haut niveau d'un langage pour l'exposer directement dans un autre.

Pour la liste officielle des bindings, je m'en occuperai à mon retour de vacances la semaine prochaine.

En tant que mec qui maintient des projets libres (sur Github ou pas), j'ai autre chose à faire que de surveiller mes mails pour voir si y'aurait pas un patch à relire qui aurait atterri sur une mailing list. D'autant plus si l'auteur dudit patch n'a pas l'intention de prendre en compte les commentaires faits par les relecteurs.

On a des patchs qui ont plus de 5 ans et qui sont encore en train de murir doucement sur notre outil de suivi. C'est hors de question de gérer ça avec une mailing list.

Il faut se rendre compte que la facilité de cette appruche pour toi qui contribue occasionellement à un projet, c'est du boulot en plus pour les mainteneurs du projet en question (soit pour suivre les patchs à la main, soit pour mettre en place et maintenir un outil de suivi).

Visiblement github a visé juste, pour des projets petits ou moyens, leur approche fonctionne très bien. Et pour les gros, ben ils peuvent se permettre de maintenir leurs propres outils.

Il reste bien sûr le gros souci que tout se retrouve centralisé sur le même site, le jour ou github va fermer, ça va être rigolo!

Le résultat, c'est des compilateurs propriétaire, périmés, buggé,

Bah bien sûr une entreprise qui vend des processeurs elle a tout intérêt à te filer un compilateur qui marche pas avec, comme ça tu ne peux pas utiliser leur matériel correctement et tu finis par acheter celui du concurrent. C'est pas du tout suicidaire comme approche.

S'ils avaient eu envie de faire ça, ils auraient juste pas du tout utilisé GCC et développé leur machin en interne. Et du coup, entre un machin développé en interne qui marche à moitié et un truc basé sur LLVM qui fonctionne bien, en effet y'a des chances qu'ils prennent LLVM.

Mais ceux qui avaient choisi GCC et de jouer le jeu du logiciel libre, ils y voient peut être un intérêt supplémentaire (au hasard, que la communauté fasse "gratuitement" une partie du travail pour eux)? Et du coup, ils vont peut être bien continuer dans la même voie?

Faut arrêter de croire que toutes les entreprises sont forcément des gros méchants qui ne veulent que du code propriétaire et fermé.

Pareil pour le MIT, des mecs brillants, y en a des tonnes, il y aura certainement un type qui le remplacera

Et ça serait encore mieux si c'était pas un mec ou un type de sexe masculin, tiens, pour une fois?

Moi, en tant que contributeur de logiciels libres, je préfère ne pas être représenté du tout que d'être représenté par Stallman et la FSF, avec qui je ne suis pas d'accord sur beaucoup de points. Si ça nous apporte un peu de diversité de points de vue, c'est plutôt une bonne nouvelle.

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 :)