pulkomandy a écrit 1710 commentaires

… mais on est en numérique.

Pour un signal analogique sur 24 bits, il faut de l'électronique propre pour ne pas avoir d'interférences sur le signal. Composants de qualité, une carte conçue pour pas avoir d'interférences, en particulier des signaux USB qui sont juste à côté, etc.

Effectivement, en numérique on peut utiliser un analyseur logique (pas un oscilloscope), et là on peut monter en fréquence sans trop de problèmes.

Avec juste l'accéléromètre, oui. Mais en utilisant d'autres capteurs présents dans le téléphone, c'est possible:
https://www.google.com/atap/project-tango/

https://github.com/cjb/GitTorrent

Pour transporter du git via bittorrent et la blockchain bitcoin. Mais ça n'a pas encore l'air complètement décentralisé pour le moment (on peut récupérer un commit si on connaît son hash en p2p, mais on a besoin d'un serveur git central pour savoir le hash correspondant au head d'un dépot, si j'ai bien suivi).

Je trouve que c'est plus "querelle de clochers" que "guerre de religion", toutes proportions gardées?

Une autre question, que penses-tu de la 3ème clause de la license BSD:

"3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."

Est-ce que ce n'est pas un peu la même chose que de protéger une marque?

en ce qui concerne le dépot d'une marque, elle permet de se protéger de gens qui n'utilisent même pas le code source. Imaginons que Microsoft publie un système qui s'appelle "GNU/Windows". Et qui ne contient pas un octet de code du projet GNU. Avec juste une license, on ne peut rien faire. Avec une marque déposée, on peut faire quelque chose.

il existe par exemple la "AGNULA Trademark License": https://fsfe.org/campaigns/agnula/license.en.html
De la même façon que la GPL (ou n'importe quelle license) repose sur le copyright pour contrôler quels droits on donne sur le code, cette license repose sur le droit des marques. Elle autorise l'utilisation de la marque sous certaines conditions.

Ce qui est important là dedans, ce sont les conditions qui sont posées. Le fait de déposer la marque permet de poser des conditions, c'est tout. Et oui, c'est la même chose avec les brevets: on peut poser un brevet puis mettre une license dessus qui autorise tout le monde à l'utiliser. Est-ce que ce n'est pas mieux que d'attendre que quelqu'un d'autre pose le brevet et empêche tout le monde d'utiliser l'invention?

Le libre n'autorise pas "par défaut". Par exemple, la license MIT (et toute la famille des licenses BSD) commence comme ça:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

Surprise, il faut d'abord respecter les conditions. Et ensuite, tu as le droit de faire tout ça. Alors, est-ce que le libre est pourri par le droit du copyright? Est-ce que ça serait mieux s'il n'y avait que du code en domaine public, partout, et que le copyright n'existait pas du tout? Peut-être. Mais ce n'est pas le cas, et donc on a trouvé des moyens d'utiliser le copyright pour faire quand même du libre. Est-ce qu'on ne peut pas faire pareil avec le droit des marques et avec les brevets?

Je maintiens: c'est aussi comme ça que fonctionnent n'importe quelle license libre. Elles disent:

1) Vous n'avez le droit de rien faire (puisqu'elles reposent sur le copyright)
2) Pour obtenir des droits supplémentaires bien précis, vous devez respecter les conditions données (diffuser les modifications, etc).

Même si on prend une license avec aucune contrainte, comme la WTFPL ou la license CC0, ça marche comme ça. On dit "C'est moi l'auteur, donc c'est moi qui choisit ce qu'on peut faire avec mon code. Et je choisis que tout le monde puisse faire ce qu'il veut."

ça marche pareil quand on dépose une marque:

1) Vous n'avez pas le droit d'utiliser la marque (puisqu'elle est déposée)
2) Sous les conditions suivantes, vous pouvez quand même l'utiliser

Je garde l'exemple du projet Haiku, les restrictions sont définies ici:
http://haiku-inc.org/trademark-usage-requirements.html
http://haiku-inc.org/trademark-allowed-usage.html

Encore une fois, elles me semblent tout à fait raisonables, et elles sont indépendantes de l'utilisation du code source.

Le fonctionnement des licenses libres est le même. Tu donnes l'exemple de l'auteur qui meurt, de la fondation qui change d'avis: la même chose peut se produire avec la license du code, et avec les mêmes conséquences. L'auteur peut décider de ne plus diffuser son code sous license GPL, mais sous une license propriétaire. C'est pour éviter ce genre de problèmes que la FSF demande à avoir le copyright sur tous les changements dans les projets GNU.

Si ça ne te satisfait pas, la seule alternative, ça serait de mettre les choses dans le domaine public (aussi bien pour les noms/logos/marques que pour le code). Mais selon ton point de vue, une license comme la GPL ou la MIT est beaucoup trop restrictive et complètement inacceptable?

Bonjour,

Je contribue depuis quelques années au projet Haiku (www.haiku-os.org). C'est un projet qui a fait le choix d'une license (très) libre (la license MIT), mais aussi de déposer la marque "Haiku".

Le but n'est pas d'empêcher les gens de modifier le logiciel, bien au contraire. On fournit tous les outils pour compiler le système avec ou sans la marque (toutes les apparitions du nom et du logo de Haiku peuvent être enlevées avec une simple option du script de configuration).

ça permet à tout le monde de faire ce qu'il veut avec le code du projet: distribuée des versions plus ou moins modifiées, récupérer des morceaux du code pour en faire complètement autre chose, etc. Par contre, le nom "Haiku" nous appartient, et c'est normal que les projets qui font des modifications aient des noms différents, simplement pour que tout le monde s'y retrouve. Je ne pense pas que ça soit une très grosse contrainte. Et dans tous les cas, n'importe qui peut demander la permission d'utiliser le nom, qui en général ne pose pas de problèmes. C'est par exemple le cas de la distribution "discover Haiku" (http://www.discoverhaiku.com/), vendue par une entreprise indépendante du projet Haiku. Tous les bénéfices de la vente de "Discover Haiku" (sous la forme d'une clé USB) n'iront pas forcément au projet Haiku. ça ne pose pas de problèmes du moment qu'ils ont demandé la permission, mais si quelqu'un le faisait sans demander et dans le but de ramasser des sous en se faisant passer pour le projet Haiku, ça serait quand même pas terrible.

Donc, on a une protection en déposant la marque, et ensuite, on a des exceptions qui donnent à des gens le droit de l'utiliser. C'est exactement le même principe de fonctionnement que la license GPL, qui utilise le droit du copyright pour d'abord dire ce qu'on n'a pas le droit de faire, et ensuite donner des droits bien précis aux gens qui sont prêts à respecter les règles. Moi ça me semble tout à fait raisonable?

Il y a eu plein d'autres projet rejetés pour le GSoC cette année, y compris certains plus petits et qui participaient aussi depuis longtemps. Une des raisons est qu'il y a beaucoup de bonnes candidatures et pas de place pour tout le monde. Du coup, certains projets ne sont acceptés qu'un an sur deux, par exemple.

Je ne pense pas qu'il y aie derrière une volonté stratégique de la part de Google.

Le site du fork en question: http://kolibrios.org/fr/
Il me semble que la communauté de KolibriOS est un peu plus impliquée dans le libre, avec une participation régulière au Google Summer of Code et au moins quelques uns des développeurs assez présents sur les canaux IRC de Freenode. Je n'y ai jamais vu de développeur de MenuetOS.

Je n'ai pas tous les détails, alors, je vous laisse vous faire un avis.

Haiku, inc: entre 25000 et 35000 dollars par an.

J'utilise maintenant Rainloop, qui est simple et efficace: http://www.rainloop.net/

Il y a un outil (libre) pour t'aider à faire le tri: http://joblint.org/

Dans d'autres pays d'Europe il y a moins de SSII mais beaucoup de dévelopeurs en freelance. La raison c'est, je pense, que c'est quand même un peu plus compliqué/plus cher/moins confortable en France de monter sa boîte tout seul.

Et puis c'est pas forcément mal, une SSII: c'est pour le client un moyen d'avoir une solution sur mesure, plutôt qu'un logiciel générique. Est-ce que le problème ne serait pas ailleurs?

La plupart de ces appareils électroniques chinois n'ont pas passé les tests pour les normes CE, FCC, et autres. C'est encore un coût en moins pour les entreprises qui conçoivent et fabriquent ces appareils.

ça ne les empêche pas forcément de fonctionner, on trouve du bon, mais aussi du très mauvais (composants électroniques factices, par exemple, ou chargeurs de téléphones portables avec une conception électronique dangereuse).

Le BASIC du Thomson TO8 a des instructions "turtle" pour utiliser une tortue comme en Logo. Je ne sais pas si c'est le cas d'autres versions du BASIC Microsoft, mais en tout cas, la tortue en BASIC, ça existe!

Le site passera en mode "lecture seule", puis dans un deuxième temps en mode "archive", proposant de télécharger une archive de chaque projet pour en extraire les données et les remettre en ligne ailleurs.

Ils ont également fourni des outils pour faciliter la migration sur d'autres plateformes (sans avoir besoin d'être administrateur du projet du côté google code).

De plus, avec un hébergement décentralisé (git ou mercurial par exemple), on peut de toutes façons retrouver tout l'historique du repo à partir d'un checkout des sources, donc il y a peu de chance d'avoir des choses définitivement perdues.

Conclusion: ça se passe beaucoup mieux que lors de la fermeture de berlios ou d'opensvn.

Ils ne sont pas partis d'un cadavre, ils ont développé tout ça y'a 10 ans quand Sourceforge, c'était cool, et que gitlab, ça n'existait pas. Et maintenant ça tourne, alors pourquoi migrer?

L'exercice est intéressant en tout cas, même si le résultat n'est pas forcément utilisable. ça permet de voir dans quelle mesure les langages de programmation existants sont plus ou moins influencés par l'anglais, par les notations mathématiques, etc.

Si on regarde les conventions de codage et de nommage souvent utilisées, on va trouver des choses du genre:
- une fonction doit être nommée par un verbe
- une variable doit être nommée par un nom
- utilisation de la notation hongroise pour marquer le type ou le rôle d'un objet dans son nom

Pourquoi ne pas inclure ces conventions directement dans un langage de programmation? Et du coup, est-ce qu'on ne pourrait pas enlever les mots clés utilisés actuellement pour exprimer la même chose?

Là, on se rapproche peut-être du BASIC, ou a$ est une chaîne de caractères, a% est un entier, etc (et le suffixe suffit au compilateur pour connaître le type des variables).

En utilisant le Latin dans Perligata, on obtient un langage assez verbeux, mais qui a la particularité d'identifier le rôle des objets utilisés par leurs déclinaisons et autres suffixes, plutôt que par leur position dans la phrase. Après, on peut "optimiser" le langage de programmation obtenu et utiliser des suffixes symboliques et plus concis, en essayant de conserver cette idée que l'ordre des mots n'est pas important.

Donc, le passage par l'Esperanto ou une autre langue permet peut-être d'exprimer des concepts d'une façon différente de l'Anglais, et du coup, d'arriver à un langage de programmation qui fonctionne différement, et éventuellement qui sera plus facile à prendre en main, même si au final on y met quand même de la notation symbolique.

L'anglais est concis en programmation parce que beaucoup de développeurs ont l'habitude de réfléchir en anglais, et de nommer les choses dans cette langue. Du coup dans les autres langues on a que des traductions, pas toujours heureuses, des concepts anglais.

Il est donc intéressant de voir ce qu'il peut se passer si on essaie de travailler avec un autre langage. L'utilisation de déclinaisons en Latin, et de préfixes et suffixes en Esperanto, par exemple (voir les commentaires au dessus et en dessous) permettent une conception assez différente d'un langage de programmation. Les mots dans ces langues sont "fortement typés" (verbe, sujet, complément) et du coup Lingua::Romana::Perligata arrive à se passer complètement de notations symboliques (du genre = pour l'affectation). ça ne serait pas possible avec l'anglais comme base car il y aurait souvent des ambiguïtés (sujet/complément en particulier).

C'est donc intéressant juste pour voir ce qu'il en ressort, à condition que ça soit un peu plus que juste un rechercher/remplacer des mots clés du langage et des noms de fonctions des bibliothèques standard.

ça me fait penser à Lingua::Romana::Perligata, un module Perl qui permet de programmer en… Latin:
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html

Un exemple est donné sur cette page avec l'algorithme du cribble d'Erathostène:

     #! /usr/local/bin/perl -w
     use Lingua::Romana::Perligata;

     maximum inquementum tum biguttam egresso scribe.
     meo maximo vestibulo perlegamentum da.
     da duo tum maximum conscribementa meis listis.
     dum listis decapitamentum damentum nexto
         fac sic
            nextum tum novumversum scribe egresso.
            lista sic hoc recidementum nextum cis vannementa da listis.
         cis.

J'ai entendu parler de Purism (https://puri.sm/) avec un projet de laptop entièrement libre (pas de blob firmware, etc) et avec du matériel qui n'a pas l'air mal. C'est encore en précommande, et je ne sais pas ce que ça donnera au niveau de la qualité et de la solidité (mais ils ont pas l'air d'etre du genre à faire des compromis). A surveiller, en tout cas…

Ce n'est pas impossible d'avoir un GC dans un système temps réel (ou n'importe quel autre système de gestion dynamique des allocations mémoire). ça complique un peu les choses, il faut avoir un GC exécutable de façon planifiée et avec un temps 'exécution borné, mais dont on est sur qu'il peut libérer au moins autant de mémoire qu'il en a été allouée depuis sa dernière exécution.

ça a été fait par exemple ici avec du Java: http://www.ghs.com/news/20100302_IS2T_java_support.html

Le but du C est d'etre proche du matériel. Et toutes les architectures ne font pas la meme chose en cas d'overflow. ça peut faire un modulo, ou bien ça peut déclencher une exception matérielle. Dans le deuxième cas, tout le programme s'arrete (sauf si on intercepte le signal, etc). Donc: comportement indéfini pour tout le programe dans la norme C. Dans le cas contraire, soit certaines machines devraient intercepter le signal et faire le calcul du modulo, soit les autres devraient intercepter les overflows et lever une "exception" (ah mais ça n'existe pas en C ça).

Il y a pour cela plein de langages de plus haut niveau tout à fait appropriés et que le C n'essaie pas de remplacer. Avec des solutions différentes selon les cas: une machine virtuelle connue et maitrisée pour Java (avec un comportement bien défini), un système d'exception qui permet d'intercepter le problème en Ada, etc.

Sur les machines ou l'overflow d'un entier déclenche une erreur matérielle, Rust va devoir l'intercepter et reprendre l'exécution du programme. C n'a pas besoin de le faire. D'ou une simplification du runtime pour le C quelle que soit l'architecture cible.

En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.

Sinon, il y a Haiku qui est libre et qui fait les 2: une API stable et assez riche pour qu'on puisse developper des applications qui n'ont pas d'autres dependances que l'OS ; et aussi un gestionnaire de paquets qui permet d'avoir plusieurs versions d'une bibliotheque installees en fonction des besoins des applications. Et le tout avec un gestionnaire de paquets qui fait les mises a jour tout seul quand on le lui demande, en plus.