pulkomandy a écrit 1928 commentaires

J'utilisais StarOffice quand j'étais au collège, puis OpenOffice au Lycée (pas de suite Microsoft installée dans les 2 cas, ça coûtait bien trop cher). En IUT et en école d'ingénieurs, les deux suites (Microsoft et OpenOffice) étaient installées. On est 5 ans plus tard et le marché n'est pas franchement partagé.

La gendarmerie nationale ne peut pas faire de pub parce que c'est un service public. Tu dirais quoi s'ils faisaient de la pub pour Microsoft financée avec tes impôts? Pourquoi ce serait différent avec de la pub pour Canonical ou pour la Document Fundation?

C'est sur que FreeDOS est le système parfait pour les gamers!

Je suis content de voir le matériel libre, l'accessibilité et l'ouverture aux "personnes sous-représentées" dans la liste des priorités de la FSF. C'est beaucoup mieux que la liste précédente. Bravo à la FSF qui arrive enfin à sortir un peu le nez du code source!

Euh… comme Grumpy?

Et entre différentes implémentations de Unix (à part celle de Microsoft dans Windows), ça marche bien?

Pour compléter: actuellement, les moteurs d'exécution (que ce soit Javascript ou Java) sont configurés pour être performant sur du code écrit "à la main" (ou par javac avec peu de transformations). Il est donc pertinent, quand on génère du code, de générer quelque chose qui ressemble à du code écrit à la main, et qu'ils savent très bien optimiser. Alors que plus on s'éloigne de ça, plus on se retrouve avec des cas ou l'optimiseur n'arrive pas à comprendre ce qu'on a voulu faire.

Cela arrive aussi quelquefois avec les compilateurs C. Il y a des cas connus où une fonction memcpy optimisée à la main (pour faire des alignements mémoire, copier des gros bouts d'un coup, etc), finissait par être moins rapide que du code "naïf" optimisé par le compilateur C.

Enfin, je précise qu'il existe des optimiseurs de bytecode java. Je pense par exemple à ProGuard: https://www.guardsquare.com/en/proguard , dont la FAQ donne quelques idées de ce qui n'est normalement pas fait par javac, et laissé au soin du runtime. En plus, ProGuard a la bonne idée d'être sous licence GPL ce qui permet de jeter un œuil dedans.

Car une dépense est une dépense, le fait de déléguer à une mutuelle des frais ne va pas réduire la facture globale que devront payer l'ensemble des Français pour se soigner.

C'est plutôt le contraire en fait: en France, l'assurance maladie "coûte" à peu près 15% du PIB. Aux USA, ou c'est géré par le privé, c'est plutôt autour de 18% (de mémoire).

Ce qui semble assez logique: moi, ça m'embête que mes cotisations de mutuelle servent à payer le marketing de la mutuelle en question, plutôt qu'à rembourser des gens. Sans même parler de la partie "bénéfice".

J'ai installé CyanogenMod récemment sur un Samsung Galaxy S (pas tout récent), et ça s'est plutôt bien passé. Il y a un outil sous Linux pour remplacer le bootloader sans l'aide du constructeur. Je n'ai aucun message d'avertissement au démarrage. Et j'ai un bootloader avec un menu de secours qui me permet de faire pas mal de choses pour tenter une récupération, si jamais l'OS tombe en panne (accessible avec une conbinaison de boutons au démarrage).

Et de toutes façons, ce téléphone n'est plus sous garantie depuis un moment. J'ai donc un téléphone plutôt correct (pas pour lancer les derniers jeux à la mode, mais pour naviguer sur internet ou écouter de la musique) et avec une version d'Android plutôt propre, pas mal configurable, et surtout, suffisamment à jour pour pouvoir y installer des applications récentes (je suis passé d'Android 2.3 fourni par Samsung avec plein d'applications SFR dedans, à un Android 4.4).

Je pense que se renseigner sur un téléphone d'occasion pas cher et qui peut être mis à jour de cette façon, est une option intéressante si on a pas besoin de gigaoctets de mémoire et de tout plein de gigahertz (peut être un peu plus récent que le mien, tout de même). Et bien sûr si on accepte que ce ne soit pas 100% libre (le noyau Linux l'est probablement, mais il y a des firmware binaires pour le Wifi, le GPU, et le modem téléphonie).

Ensuite, j'ai installé F-Droid et également le Play Store (mais pas les autres applications de Google, ce qui limite un peu le traçage), j'utilise le premier en priorité mais on n'y trouve pas encore des applications pour tout faire. Là, à chacun de faire son compromis comme il veut.

C'est comme pour leurs résultats sur la météo, les résultats de foot, les cours de la bourse ou encore leur comparateur de billets d'avion.

Et la calculatrice, et le calculateur de quantité de fromage par personne pour faire une raclette, et plein d'autres trucs. Qui ne posent en général pas de problème, mais là aussi, ça dépend des sources.

Par exemple:
https://www.google.fr/search?q=quantité+de+fromage+pour+une+raclette

Voilà un joli tableau avec les quantités en fonction du nombre de personnes. Mais, on se rend compte qu'il est proposé par un vendeur de fromage. Du coup, on peut se demander s'il n'aurait pas tendance à surestimer les quantités? Est-ce qu'il ne vaudrait pas mieux trouver une réponse chez un diététicien?

Le problème c'est que la présentation qui est faite n'est pas du tout celle d'un résultat de recherche! Cet encadré apparaît en très gros caractères, et avant même les annonces publicitaires.

Qu'il apparaisse dans les résultats de la recherche, ça me semble normal. Mais qu'il apparaisse dans un encadré comme ça, du genre "définition officielle", c'est un peu génant, surtout dans ce cas parce que ça met en avant un site qui est probablement orienté politiquement, et pas un site neutre qui donne des définitions.

Donc oui, moi, je préfèrerais que les "définitions" proviennent de sites "fiables" validés par le moteur de recherche (ce qui n'empêche pas du tout d'y inclure des sites nouveaux, s'ils arrivent à se faire remarquer par le moteur de recherche en question). Sinon, je préfère me passer de ce genre de fonctionnalité et avoir des résultats de recherche normaux, et faire le tri moi-même.

Je n'ai jamais vraiment creusé comment ça marche sous Linux (c'est pas mon OS préféré :)). Mais de mémoire, juste pour la partie driver, on va se retrouver avec une interface midi qui apparaît "quelque part" dans /dev, il va falloir écrire une règle udev pour avoir le droit de s'en servir, et ensuite expliquer patiemment à chaque logiciel où elle se trouve et à quoi il faut la brancher. Est-ce qu'on a quelque chose de mieux que "ls /dev" pour découvrir les interfaces MIDI sous Linux maintenant?

D'abord une précision technique: ce n'est justement pas du RS232. Le RS232 définit précisément tous les points d'un "port série" qui sont différents du MIDI: les connecteurs, les niveaux électriques, etc, mais pas le protocole de "tramage" utilisé (comment on traduit "framing" en français?). En revanche, on utilise en MIDI, et la plupart du temps en RS232, des signaux de type "UART", qui eux ont un format similaire dans les deux cas (et pour le MIDI, ça fait partie de la norme).

En tout cas voilà comment ça se passe pour Haiku:
- Il y a effectivement un driver générique pour les interfaces USB<->MIDI, ce qui n'est pas bien compliqué donc il est probable que Linux aie sensiblement la même chose.
- Il y a une API standard dans Haiku pour énumérer les interfaces MIDI (USB ou pas), que les applications peuvent utiliser pour découvrir le matériel mais aussi le logiciel (un synthétiseur logiciel peut exposer un port "MIDI" virtuel via lequel il recevra des commandes MIDI, donc)
- Il ne reste plus qu'à connecter tout ça ensemble (entrée MIDI<-USB vers synthétiseur logiciel, par exemple): c'est la partie "plug"
- Ensuite, on presse les touches du clavier MIDI qui envoie les "note on" et "note off" qui vont bien, et le synthétiseur s'active: c'est la partie "play".

Jusque là tout va bien. Après, quand on rentre dans les messages SysEx et autres trucs compliqués, oui, ça devient moins facile, mais on y arrive tout pareil (on "branche" tout ensemble et les messages arrivent ou il faut et quand il faut).

Il y a quelques applications "amusantes". Je pense au "super long MIDI cable" qui est un proxy MIDI vers Ethernet pour relier à grande distance plusieurs machines. Et on peut y brancher n'importe quoi en entrée comme en sortie, tant que ça arrive à se parler en MIDI (que ça soit des Note On/Off, des SysEx ou n'importe quoi d'autre, d'ailleurs).

Sans nier l'excellent travail d'Ubuntu là-dessus, Mandrake et SuSE avaient largement préparé le terrain pour ça.

Et Corel Linux était là avant!

En fait une tablette ça remplace la télé. ça ne sert pas à aller sur internet!

Si tu veux du MIDI en plug and play, tu peux tenter l'aventure avec Haiku (www.haiku-os.org) à la place de Linux, il fait ça très bien. Par contre ça manque encore un peu d'applications, malhereusement. Mais on a Sequitur (un séquenceur MIDI) et plusieurs synthétiseurs (SynC Modular - non libre - par exemple).

C'est un peu compliqué le fonctionnement chez Google, qui est une grosse entreprise avec pas mal de monde dedans. Il y a des équipes qui ont bien compris comment marche le libre et qui font ce qu'elles peuvent pour contribuer. C'est le cas pour les gens qui font Android.

Il y a d'autres équipes qui sont plus dans une approche fermée des choses. C'est le cas pour les "Google Apps", qui sont indépendantes de Android.

Donc, déjà si tu enlèves les Google Apps, tu obtiens un système libre (partiellement, j'y reviens) et sans traceurs de la part de Google. Tu peux installer un app store alternatif (f-droid qui ne contient que des logiciels libres, par exemple, mais il y a d'autres possibilités avec différents degrés de qualité des logiciels et de quantité d'espions dedans). Pour cela, on peut regarder du côté de AOSP (Android Open Source Project) et des divers forks, dont CyanogenMod était le plus connu, mais il y en a d'autres.

Maintenant, il y a un autre problème, c'est d'avoir le noyau Linux a mettre en-dessous de ton Android. Contrairement à l'architecture des PC, qui est bien standardisée maintenant (avec un BIOS ou un UEFI, un bus PCI pour découvrir les périphériques, etc), sur les tablettes et en général tous les machins avec un CPU ARM, il n'y a rien de tel. Le noyau est donc, pour le moment, adapté spécifiquement à chaque matériel. Les constructeurs de matériel et les gens qui portent le noyau jouent plus ou moins le jeu du logiciel libre, et c'est là que se joue vraiment les choses (pas tellement chez Google, en fait). Donc, il faut se renseigner sur le matériel utilisé et sur la possibilité d'avoir un noyau Linux dont on dispose des sources (ça devrait être obligatoire, mais il faut avoir envie de faire un procès au vendeur de la tablette pour qu'il te fournisse les sources, bon courage).

Et donc, si tu as envie d'être extrêmiste et de n'avoir que du logiciel libre, il te faut aller voir du côté de Replicant. C'est une version d'Android avec exclusivement du logiciel libre: pas de blobs binaires, noyau entièrement sous GPL, etc. Ils supportent un choix de matériel assez restreint, et souvent pas toutes les fonctionnalités (accélération 3D, wifi, …) par manque de drivers ou de firmware libre. Il peut être intéressant de voir quels modèles ils supportent (a priori ce sont les fabriquants les plus coopératif), mais de prendre un Android avec quelques blobs binaires pour avoir quelque chose d'utilisable, faute de mieux.

Enfin, si tout cela ne te convient pas, il vaut mieux regarder du côté des tablettes sur une base de processeur Intel, sur lesquelles il sera plus facile d'installer un Linux plus traditionnel. Et il paraît que Gnome 3 fait de gros efforts pour être plus ergonomique sur un écran tactile, de nos jours.

Il te faut un frogpad pour taper avec une main tout en tenant la tablette dans l'autre: http://www.frogpad.com

Quand tu génères du JavaScript, derrière il y a plusieurs implémentations de l'interpréteur (au moins une par navigateur - WebKit en a plusieurs et passe de l'une à l'autre à la volée pour chaque fonction, selon plusieurs critères). Elles sont parfois très différentes. Du coup, le principe est plutôt de laisser le runtime faire l'optimisation.

On a un peu la même philosophie quand on génère du bytecode Java: le bytecode standard est pas du tout optimal, en fait il est plutôt éloigné de ce que les machines virtuelles font vraiement. Mais, chaque machine virtuelle vient avec une "surcouche" qui s'occupe de faire l'optimisation qui va bien.

Cela a un inconvénient: il faut faire cette phase d'optimisation au runtime alors qu'elle aurait pu être faite une fois pour toute à la compilation. Mais ça a un gros avantage: ton code "objet" (bytecode java ou code js généré) sera optimisé pour la machine virtuelle qui l'exécute, même si elle n'existe pas encore lorsque tu écris le code.

Du coup, il n'est pas nécessaire et parfois même contre-productif de "pré-optimiser" le code js. Tu ne sais pas quelle machine virtuelle va l'interpréter, de toutes façons.

Parfois il vaut mieux une bibliothèque Python bien optimisée, plutôt qu'un code C écrit à la main. Un exemple qui me revient: https://www.tablix.org/~avian/blog/archives/2016/04/measuring_interrupt_response_times/
(et dans lequel, finalement, il vaut mieux un driver dans le noyau, mais c'est une autre histoire).

gcc arrive très bien à conserver les commentaires C (et même, ajouter les lignes du fichier C en commentaire) dans les fichiers assembleur qu'il génère. D'ailleurs, c'est indispensable qu'il sache faire ça car c'est aussi utilisé pour générer les informations de debug, qui permettent à un debugger de savoir quelle ligne du fichier C est en train de s'exécuter.

Encore plus fort: quand on génère du C, on peut ajouter des directives #line et #file, et du coup, annoter que le fichier est généré à partir d'un autre. Et cela sera aussi intégré et le debugger pourra afficher où on est dans le fichier source qui a servi à la génération.

Si Grumpy (et les autres transpileurs ) ne sait pas faire ça, alors comment on fait pour debugger? Obligé de regarder le code généré qui n'a pas de commentaires, et retrouver l'équivalent dans le fichier Python à la main? ça me semble être la moindre des choses, quand même?

Tiens, je pense à un truc: les Grands Anciens de l'Informatique ont inventé ASN.1 et PER, qui permettent de décrire le contenu du message. Il existe des outils qui peuvent non seulement générer les fichiers binaires, mais aussi le code (C, Python, …) pour encoder et décoder un message depuis/vers une structure ou un objet du langage.

Dans ton exemple, tu rentre "0123" mais le résultat est sur un seul octet. Comment fait-on pour encoder 123 (décimal) sur 2 octets ou 4 octets?

Si j'ai bien compris, le but c'est:

1) Faire tourner l'application existante en la convertissant en Go
2) Commencer à réécrire certains morceaux en Go pour migrer petit à petit
3) à la fin, tout le code est réécrit en Go.

C'était le cas jusqu'à maintenant. Ils ont prévenus Lilypond que c'étaient les derniers à utiliser Guile 1.8 lors de la release précédente et avaient déjà conservé ce paquet pas maintenu rien que pour eux. Entretemps, le problème n'est toujours pas réglé.

Si la migration n'est vraiment pas possible, il aurait fallu que Lilypond (ou quelqu'un d'autre) forke Guile 1.8 et prenne en charge la maintenance. Personne chez Debian n'ayant envie de le faire.

J'avais lu un blog plus détaillé (les infos sont peut être dans le rapport complet du deuxième lien). Mais en gros, en dehors du record, on voit surtout un décalage de 7° qui apparaît "d'un coup", dont on ne se rend compte qu'en comparant à d'autres stations proches et en faisant quelques statistiques.

Il a fallu remonter aux relevés papier originaux pour voir que l'écriture change juste à ce moment là. Et la conclusion: la station n'était plus opérée par la même personne, et visiblement, le nouveau responsable ne savait pas utiliser un thermomètre à maxima correctement: il a lu la température en haut du marqueur, et pas en bas.

Ce genre d'erreur peut donc apparaître et disparaître avec le temps, en fonction du matériel, des gens (ou des machines) qui font les relevés, etc. La cohérence d'une série avec elle-même n'est donc pas complètement assurée et personne ne pense à prendre note de ces changements. Du coup les données sont difficiles à interpréter.

Personnellement, j'aurais plus confiance dans une machine (conçue correctement: plusieurs mesures indépendantes, un système qui les compares pour éliminer celles qui sont trop à côté de la plaque par rapport aux autres, et un système d'alerte pour quand la machine n'arrive plus à décider: problème matériel probable), que dans un humain. Mais j'aurais moins confiance dans une machine mal pensée et sans surveillance.

Donc, je ne vois pas de problème avec l'automatisation. Mais j'en vois avec le manque de contrôle. Ensuite, le contrôle peut lui-même être automatisé, et ça récurse!

Il y a des cas d'erreurs humaines dans des stations météo, aussi.

Ce que tu dit me semble justifié, mais complètement indépendant de l'automatisation.

Exemple:
http://www.notre-planete.info/actualites/actu_3465_temperature_plus_haute_Terre.php
http://journals.ametsoc.org/doi/abs/10.1175/BAMS-D-12-00093.1