Sous BeOS et Haiku, ce genre d'infos sont stockées dans des xattrs au niveau du système de fichiers. ça évite de "pourrir" le fichier lui-même avec des tags bizarres.
Nouveau, c'est pour écrire un driver pour un GPU existant, pas pour refaire un GPU.
Il ne faut pas croire qu'un FPGA ou un DSP sont des trucs magiques pour avoir un système super rapide. D'abord, ça ne fait que du numérique, alors qu'une bonne partie du travail pour un modem GSM/GPRS/3G/4G est analogique (démodulation, traitement du signal, etc). Et même avec un FPGA, il va être compliqué de faire un truc qui mouline assez vite pour traiter toutes les données.
En plus de ça, on ne peut pas se mettre à faire du GSM comme ça, il faut passer toutes les homologations pour avoir le droit de se connecter au réseau (sinon, le modem est blacklisté et se fera jeter par les antennes relais).
Faire la rétro ingénierie d'une puce existante n'a pas d'intérêt, les specs des réseaux de téléphonie mobile sont connues et il "suffit" de les implémenter. Mais, c'est énormément de travail. Et, le temps que tu aies fini ton petit modem GSM, tout le monde est déjà passé à la 4G et tu as 3 générations de retard. Mais bon, il faut bien commencer quelque part.
Dès qu'on touche un peu au matériel, ça devient compliqué d'avoir quelque chose de purement communautaire. Il faut comprendre que pour ce genre de matériel, on travaille avec des équipements qui coûtent le prix d'une maison. Il faut pas attendre qu'un Richard Stallman du GSM se lance là dedans sur ses fonds propres. ça ne pourra se faire que si une entreprise le décide.
Une fois la solution libre publiée, il reste encore le problème de la produire. Est-ce qu'on peut faire confiance aux fondeurs d'ASICs pour ne pas trafiquer le design et y insérer un mouchard? Est-ce qu'on peut vraiement forker le design pour en faire une version améliorée, ou est-ce que les coûts sont trop élevés pour que ça soit raisonnable? Le libre ne réglera pas tous les problèmes du côté du matériel.
En fait c'est pour uniformiser avec les autres sytèmes à la pomme:
- iOS: pour les iBidules (iPhone, iPad)
- macOS: pour les macBidules (macBook, mac pro, etc.)
- watchOS: pour les montres (iWatch, ah zut ça commence par un i?)
Les nouveaux systèmes d'exploitation, iOS en version 10 et OS X qui serait à l'occasion renommé… MacOS ! Un nom dans lequel on peut voir, outre l'aspect "retour aux sources" (qui renoue avec la glorieuse époque de l'invention du premier système à interface graphique pilotée à la souris)
Même pas, le système des Macintosh à l'époque s'appellait… "system". Ce n'est qu'à partir de la version 7.6 qu'on a commencé à parler de MacOS, donc vers 1997. Pas l'époque la plus glorieuse pour Apple, qui a ce moment là essayait de vendre son OS à UMAX et Daystar Digital, tout en en essayant de ne pas avoir trop de BeOS sur leurs propres machines
D'ailleurs, il ne faut pas confondre la GPL de GNU avec celle d'Affero (souvent appelée AGPL pour éviter les confusions). Donc, c'est important de protéger le nom, qui peut sinon être repris avec une license complètement différente. Protéger le contenu de la license, par contre, ça n'a d'intérêt que pour limiter la prolifération des licences (du genre "je prend la GPL mais je rajoute une exception qui rend mon truc incompatible avec la GPL d'origine").
Après vérification, c'est 3 ans seulement (oups). C'est la section 3b de la licence (pour la GPL2, j'ai pas vérifié la GPL3):
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
Et il y a deux cas ou ce n'est pas nécessaire:
- Si on distribue directement les sources avec le logiciel,
- Ou, si on redistribue a titre non-commercial, dans ce cas on peut "faire suivre" l'offre de récupération du code que l'on a soi-même reçu.
Ça ne pose pas trop de problèmes quand on met un logiciel en téléchargement sur internet (il suffit dans ce cas de mettre un lien vers les sources juste à côté du lien vers le binaire). C'est plus pénible quand par exemple on veut vendre un CD d'installation d'une distribution Linux contenant du code sous GPL (et pas forcément les sources qui vont avec, faute de place).
Tout ça, sans parler du fait que la licence GPL est effectivement compliquée à lire, et surtout, contraignante aussi pour ceux qui décide de diffuser du code sous GPL (essayez un jour, pour voir). Il faut diffuser le code source (bon ok, ça ça va), mais aussi, il faut être prêt à donner le code source de n'importe quelle version précise du logiciel à toute personne qui le demande, et ce, jusqu'à 10 ans après la diffusion de la dite version.
Ce genre de restrictions, ça devient très vite compliqué à gérer, aussi bien quand on est un particulier et qu'on a juste envie de partager un bout de code, que quand on est une entreprise ou une association et qu'on veut se lancer dans le libre. Juste pour savoir ce qu'on a le droit de faire ou pas, il faut embaucher un juriste. Du coup, la solution la moins coûteuse, c'est de prendre une licence plus facile à lire. A moins d'être la FSF et d'avoir une armée de juriste rompus à ce genre d'exercice. Mais dans le monde du libre, c'est rare.
Un autre aspect, c'est que ça me paraît difficile de "vendre" du logiciel comme étant libre, mais d'expliquer qu'il y a des conditions d'utilisations aussi longues que le CLUF de Windows. Même si elles sont peut être moins restrictives, il faut les lire pour le savoir, et je ne pense pas que ça soit quelque chose qu'on peut demander à tous les utilisateurs. Comme le dit le journal: avez-vous lu votre licence?
Finalement, une licence courte et facile à lire, c'est une très bonne arme contre le FUD, non?
C'est une très bonne nouvelle que quelqu'un se penche enfin sur le travail collaboratif et le suivi de modifications avec KiCad. Même en l'utilisant tout seul pour quelques modestes projets open hardware, c'est quelque chose dont j'aurais bien besoin (mais pas assez pour avoir commencé à développer quelque chose).
je ne comprends même pas comment on peut imaginer que ça puisse marcher
ça coûte rien d'essayer!
Et en l'occurrence, il semble s'agir d'une association et non d'une entreprise. Je suppose à but non lucratif ou équivalent mais je ne connaît pas la loi suisse dans ce domaine.
Je ne vois pas pourquoi le fait d'utiliser un moteur existant empêcherait d'apporter quelque chose du point de vue technique (on peut toujours envoyer des patches ou les garder dans son fork), et surtout pour le respect des utilisateurs.
Pour avoir beaucoup contribué au portage de WebKit sur Haiku et au navigateur web associé (à plein temps pendant un peu plus d'un an), écrire un port de WebKit nécessite beaucoup de code natif (pour l'accès au réseau, pour le rendu graphique, etc) et on a quand même un contrôle assez fin sur plein de choses (la gestion des cookies, des certificats https, et plein de choses qui sont optionnelles comme la géolocalisation, le support des webcams, etc).
En se basant sur un moteur existant on peut aussi expérimenter et ajouter des fonctionnalités si on a besoin. Inutile de repartir de zéro et de tout réinventer.
… sinon, il y a NetSurf, avec une implémentation simple, propre et légère d'un navigateur web, et le support du Javascript (en utilisant le moteur duktape) qui arrive doucement. Les contributions sont les bienvenues, comme partout!
D'ailleurs, le dépôt "classqm" n'est pas le dépôt officiel de Haiku (qui ne prend pas de trema, au passage).
La situation pour Haiku est un peu compliquée en ce moment:
- Le dépôt officiel est http://download.haiku-os.org/haiku-repositories/master/ . Il ne contient que le système d'exploitation lui-même.
- Il existe un dépôt "haikuports" semi officiel: http://packages.haiku-os.org/haikuports/master/ . Il est géré par les développeurs de Haiku, mais à terme il doit être peuplé automatiquement à partir des recettes du projet HaikuPorts (https://github.com/haikuports/haikuports). HaikuPorts et Haiku sont indépendants, mais les paquets systèmes de Haiku dépendent de paquets présents dans Haikuports. Du coup, il est difficile de s'en passer (et il est hébergé sur les serveurs de Haiku, inc).
- Enfin, il existe plusieurs dépôts supplémentaires: classqm, fatelk, uwolke, … (un peu similaire aux PPA chez Ubuntu).
Haiku essaie d'avoir une approche un peu plus décentralisée de la gestion des paquets, avec plusieurs dépôts parmi lesquels on peut faire son choix pour avoir tout plein d'applications. Ceci permet aussi d'être très réactif aux demandes de packaging sur ces dépôts indépendants.
Il y a deux/trois ans, j'habitais du côté de Nantes et on avait http://www.mon-panier-bio.com/distributeur/terre-de-bio-panier-bio-local-loire-atlantique/ , commande par internet, livraison sur ton lieu de travail (en essayant de livrer plusieurs personnes dans la même entreprise pour limiter les déplacements inutiles). Il y avait beaucoup de légumes mais aussi des laitages et de la viande, avec sur le site internet toutes les informations sur les producteurs.
Voilà, Linux est un noyau, et ce qui est important, c'est pas le noyau, c'est ce qui tourne autour. Du coup c'est tout de suite plus clair quand on parle de GNU/Linux. Et clairement, un Debian GNU/kFreeBSD est plus proche de "l'écosystème Linux" qu'un Android, alors qu'il n'utilise pas une ligne de code du noyau Linux. Il me semble donc évident qu'il y a un problème avec le nom "écosystème Linux", là.
Donc, on peut peut-être parler de l'"écosystème GNU", mais c'est un peu réducteur, car sur une distribution Linux classique il y a bien plus que les outils GNU. Alors, on dit quoi? X11+GNU+Linux, mais du coup on exclus Wayland et Mir? Juste GNU, mais on inclus Haiku?
Finalement, peut être qu'il n'y a pas vraiement de limite nette et franche, et que chacun prend les morceaux qui l'intéressent pour en faire ce qu'il veut. C'est ça qui est bien, avec le logiciel libre.
La playroutine de Hively Tracker peut fonctionner sur n'importe quoi. La preuve avec le music disc Planet Hively et sa liste assez impressionnante de plateformes supportées: http://www.pouet.net/prod.php?which=49931
Il faut quand même compter quelques mégaoctets de RAM pour le faire fonctionner, car il précalcule pas mal de waveforms en RAM pour optimiser sa vitesse (et oui, il y a au moins un cas ou je n'ai pas pu l'utiliser car je n'avais que des kilo octets de RAM).
Moins gourmand en RAM (celui ci tient dans une centaine de Ko pour le coup), mais un peu plus en CPU (principalement parce qu'il utilise des nombres flottants), il y a Sawteeth. Le tracker lui-même ne fonctionne que sur Haiku mais la playroutine a été portée sous Mac OS X par son auteur original et sur bitbox par moi-même (un CPU ARM sans OS). Sur la bitbox je n'ai pas pu le faire fonctionner à vitesse suffisante (168MHz, pas d'unité flottante matérielle, on est à la louche à 50% de la vitesse nécessaire en utilisant absolument tout le CPU).
Sawteeth ne sait faire que de la synthèse, tandis que Hively Tracker, lui, peut aussi inclure des samples il me semble.
Sinon, dans les trucs un peu plus "mainstream" (dans la demoscene en tout cas), la plupart du temps il faut combiner un tracker avec support des VST (souvent Renoise) et un synthétiseur sous forme de VST (par exemple 4klang). Ensuite, la musique est exportée dans un format spécifique. Avec 4klang, le rendu d'une musique est parfois difficile à faire en temps réel, une approche fréquement utilisée est de générer un fichier son décodé en RAM au chargement, puis de le lire "bêtement" pendant l'exécution. Mais du coup c'est assez gourmand en RAM.
Dans le genre il y a aussi hivelytracker et protrekkr pour Linux, ainsi que Sawteeth pour Haiku. Aucun des trois n'a besoin de 20% d'un CPU pour fonctionner (prévoir un Pentium II 233 ou quelque chose du genre).
C'est dommage de démonter un C64 pour récupérer seulement la puce son (qui n'a jamais été vendue séparément).
Et surtout je ne suis pas sur que ça soit nécessaire. On trouve encore en vente des clones de l'AY-3-8912 (dont l'AY8930 avec quelques fonctions supplémentaires plutôt sympa), ou alors on peut faire un truc soi-même comme le propose ce projet Kickstarter et comme le fait aussi lft (http://linusakesson.net/music/chipmusic.php) avec en particulier le Chipophone, le "Hardware Chiptune", et "The Swan" par exemple.
La carte semble utiliser un dsPIC, c'est un microcontrôleur avec des instructions DSP. Donc, la synthèse FM est faite… avec du logiciel dans cette puce.
Le même logiciel pourrait sans doute fonctionner sur n'importe quel CPU de ces 15 dernières années.
Cependant, il y a des problèmes à utiliser un PC "normal" pour faire de la musique: il faut un temps de réaction très rapide entre "j'appuie une touche sur mon clavier midi" et "le son sort des haut parleurs", ce qui n'est pas si simple qu'il n'y parait. Il faut que ça soit très fiable pour l'utiliser en "live" pendant un concert. Il ne faut pas que le PC qui fait tourner tout ça décide de faire un accès au disque dur et freeze pendant une seconde. Il ne faut pas que avast se mette à hurler "la base de définition virale à été mise à jour" en même temps (ou n'importe quel effet sonore de l'OS utilisé).
Tout ça est possible mais un petit peu compliqué. Et ça pose aussi des questions de support technique, ou il faut aider les gens à tout faire marcher sur des configurations très différentes. En fournissant à tout le monde le même matériel bien maîtrisé, il n'y a pas ce problème.
Enfin, il est beaucoup plus facile de vendre du matériel que du logiciel, surtout libre.
Il me semble que FTP ne spécifie pas vraiment de format pour la liste des fichiers que le serveur doit envoyer, et qu'en général ça ressemble franchement à un ls -l. Alors, est-ce qu'il y a des clients/serveurs FTP qui vont avoir des problèmes avec ces quotes inattendues?
[^] # Re: pour un nouvel élan vers la gloire médiatique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal A l'heure où Owncloud, CozyCloud et NextCloud font du bruit, Tracim continue son bonhomme de chemin. Évalué à 3.
XKCD
^WCommitStrip pertinent: http://www.commitstrip.com/fr/2016/06/20/coder-bingo/[^] # BeOS le faisait il y a 15 ans!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Playtag : paramètres de lecture audio/vidéo en métadonnées. Évalué à 2.
Sous BeOS et Haiku, ce genre d'infos sont stockées dans des xattrs au niveau du système de fichiers. ça évite de "pourrir" le fichier lui-même avec des tags bizarres.
[^] # Re: Moi aussi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Baseband GSM libre: aucun progrès ?. Évalué à 7.
Nouveau, c'est pour écrire un driver pour un GPU existant, pas pour refaire un GPU.
Il ne faut pas croire qu'un FPGA ou un DSP sont des trucs magiques pour avoir un système super rapide. D'abord, ça ne fait que du numérique, alors qu'une bonne partie du travail pour un modem GSM/GPRS/3G/4G est analogique (démodulation, traitement du signal, etc). Et même avec un FPGA, il va être compliqué de faire un truc qui mouline assez vite pour traiter toutes les données.
En plus de ça, on ne peut pas se mettre à faire du GSM comme ça, il faut passer toutes les homologations pour avoir le droit de se connecter au réseau (sinon, le modem est blacklisté et se fera jeter par les antennes relais).
Faire la rétro ingénierie d'une puce existante n'a pas d'intérêt, les specs des réseaux de téléphonie mobile sont connues et il "suffit" de les implémenter. Mais, c'est énormément de travail. Et, le temps que tu aies fini ton petit modem GSM, tout le monde est déjà passé à la 4G et tu as 3 générations de retard. Mais bon, il faut bien commencer quelque part.
Dès qu'on touche un peu au matériel, ça devient compliqué d'avoir quelque chose de purement communautaire. Il faut comprendre que pour ce genre de matériel, on travaille avec des équipements qui coûtent le prix d'une maison. Il faut pas attendre qu'un Richard Stallman du GSM se lance là dedans sur ses fonds propres. ça ne pourra se faire que si une entreprise le décide.
Une fois la solution libre publiée, il reste encore le problème de la produire. Est-ce qu'on peut faire confiance aux fondeurs d'ASICs pour ne pas trafiquer le design et y insérer un mouchard? Est-ce qu'on peut vraiement forker le design pour en faire une version améliorée, ou est-ce que les coûts sont trop élevés pour que ça soit raisonnable? Le libre ne réglera pas tous les problèmes du côté du matériel.
[^] # Re: Nomenclature
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Du neuf, enfin !. Évalué à 2.
En fait c'est pour uniformiser avec les autres sytèmes à la pomme:
- iOS: pour les iBidules (iPhone, iPad)
- macOS: pour les macBidules (macBook, mac pro, etc.)
- watchOS: pour les montres (iWatch, ah zut ça commence par un i?)
# MacOS, glorieuse époque?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Du neuf, enfin !. Évalué à 5.
Même pas, le système des Macintosh à l'époque s'appellait… "system". Ce n'est qu'à partir de la version 7.6 qu'on a commencé à parler de MacOS, donc vers 1997. Pas l'époque la plus glorieuse pour Apple, qui a ce moment là essayait de vendre son OS à UMAX et Daystar Digital, tout en en essayant de ne pas avoir trop de BeOS sur leurs propres machines
[^] # Re: wtf
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal DMOZ resurgit. Évalué à 3.
En fait ça s'écrit MORPEUG mais ça se prononce MEUPORG. Ou alors c'est l'inverse?
[^] # Re: Bug ferme chez tmux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Il faut utiliser mosh!
[^] # Re: Les licenses courtes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 4.
D'ailleurs, il ne faut pas confondre la GPL de GNU avec celle d'Affero (souvent appelée AGPL pour éviter les confusions). Donc, c'est important de protéger le nom, qui peut sinon être repris avec une license complètement différente. Protéger le contenu de la license, par contre, ça n'a d'intérêt que pour limiter la prolifération des licences (du genre "je prend la GPL mais je rajoute une exception qui rend mon truc incompatible avec la GPL d'origine").
[^] # Re: Les licenses courtes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 4.
Après vérification, c'est 3 ans seulement (oups). C'est la section 3b de la licence (pour la GPL2, j'ai pas vérifié la GPL3):
Et il y a deux cas ou ce n'est pas nécessaire:
- Si on distribue directement les sources avec le logiciel,
- Ou, si on redistribue a titre non-commercial, dans ce cas on peut "faire suivre" l'offre de récupération du code que l'on a soi-même reçu.
Ça ne pose pas trop de problèmes quand on met un logiciel en téléchargement sur internet (il suffit dans ce cas de mettre un lien vers les sources juste à côté du lien vers le binaire). C'est plus pénible quand par exemple on veut vendre un CD d'installation d'une distribution Linux contenant du code sous GPL (et pas forcément les sources qui vont avec, faute de place).
[^] # Re: Les licenses courtes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Choisir une licence : facile à comprendre ?. Évalué à 5.
Tout ça, sans parler du fait que la licence GPL est effectivement compliquée à lire, et surtout, contraignante aussi pour ceux qui décide de diffuser du code sous GPL (essayez un jour, pour voir). Il faut diffuser le code source (bon ok, ça ça va), mais aussi, il faut être prêt à donner le code source de n'importe quelle version précise du logiciel à toute personne qui le demande, et ce, jusqu'à 10 ans après la diffusion de la dite version.
Ce genre de restrictions, ça devient très vite compliqué à gérer, aussi bien quand on est un particulier et qu'on a juste envie de partager un bout de code, que quand on est une entreprise ou une association et qu'on veut se lancer dans le libre. Juste pour savoir ce qu'on a le droit de faire ou pas, il faut embaucher un juriste. Du coup, la solution la moins coûteuse, c'est de prendre une licence plus facile à lire. A moins d'être la FSF et d'avoir une armée de juriste rompus à ce genre d'exercice. Mais dans le monde du libre, c'est rare.
Un autre aspect, c'est que ça me paraît difficile de "vendre" du logiciel comme étant libre, mais d'expliquer qu'il y a des conditions d'utilisations aussi longues que le CLUF de Windows. Même si elles sont peut être moins restrictives, il faut les lire pour le savoir, et je ne pense pas que ça soit quelque chose qu'on peut demander à tous les utilisateurs. Comme le dit le journal: avez-vous lu votre licence?
Finalement, une licence courte et facile à lire, c'est une très bonne arme contre le FUD, non?
# KiCad collaboratif
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le matériel libre où en sommes nous ?. Évalué à 5.
C'est une très bonne nouvelle que quelqu'un se penche enfin sur le travail collaboratif et le suivi de modifications avec KiCad. Même en l'utilisant tout seul pour quelques modestes projets open hardware, c'est quelque chose dont j'aurais bien besoin (mais pas assez pour avoir commencé à développer quelque chose).
Merci!
[^] # Re: Regex
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les mini sites pour apprendre à coder. Évalué à 4.
Et aussi le Regex Golf: http://regex.alf.nu/
[^] # Re: aidons les (si on peut)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Plonkileaks ou l'humour au pays du secret bancaires. Évalué à 1.
ça coûte rien d'essayer!
Et en l'occurrence, il semble s'agir d'une association et non d'une entreprise. Je suppose à but non lucratif ou équivalent mais je ne connaît pas la loi suisse dans ce domaine.
[^] # Re: Recul
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Bitkeeper essaye de rattraper l'histoire en passant Open Source. Évalué à 3.
N'oublions pas qu'il existe un outil dans le standard POSIX: SCCS.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sccs.html
Cela dit, je n'ai jamais vu personne l'utiliser, pour le moment.
[^] # Re: Moteur ≠ Navigateur
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Il faut sauver le soldat Firefox!. Évalué à 5.
Je rapelle que WebKit est un logiciel libre, quand même. Comme "pas d'alternative", c'est un peu gros…
Sinon, pour le côté innovant côté interface utilisateur et modularité, il y a http://www.uzbl.org/.
[^] # Re: A propos du W3C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Il faut sauver le soldat Firefox!. Évalué à 10.
Je ne vois pas pourquoi le fait d'utiliser un moteur existant empêcherait d'apporter quelque chose du point de vue technique (on peut toujours envoyer des patches ou les garder dans son fork), et surtout pour le respect des utilisateurs.
Pour avoir beaucoup contribué au portage de WebKit sur Haiku et au navigateur web associé (à plein temps pendant un peu plus d'un an), écrire un port de WebKit nécessite beaucoup de code natif (pour l'accès au réseau, pour le rendu graphique, etc) et on a quand même un contrôle assez fin sur plein de choses (la gestion des cookies, des certificats https, et plein de choses qui sont optionnelles comme la géolocalisation, le support des webcams, etc).
En se basant sur un moteur existant on peut aussi expérimenter et ajouter des fonctionnalités si on a besoin. Inutile de repartir de zéro et de tout réinventer.
… sinon, il y a NetSurf, avec une implémentation simple, propre et légère d'un navigateur web, et le support du Javascript (en utilisant le moteur duktape) qui arrive doucement. Les contributions sont les bienvenues, comme partout!
[^] # Re: Troll java
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Ancestris est disponible pour Haiku. Évalué à 8.
D'ailleurs, le dépôt "classqm" n'est pas le dépôt officiel de Haiku (qui ne prend pas de trema, au passage).
La situation pour Haiku est un peu compliquée en ce moment:
- Le dépôt officiel est http://download.haiku-os.org/haiku-repositories/master/ . Il ne contient que le système d'exploitation lui-même.
- Il existe un dépôt "haikuports" semi officiel: http://packages.haiku-os.org/haikuports/master/ . Il est géré par les développeurs de Haiku, mais à terme il doit être peuplé automatiquement à partir des recettes du projet HaikuPorts (https://github.com/haikuports/haikuports). HaikuPorts et Haiku sont indépendants, mais les paquets systèmes de Haiku dépendent de paquets présents dans Haikuports. Du coup, il est difficile de s'en passer (et il est hébergé sur les serveurs de Haiku, inc).
- Enfin, il existe plusieurs dépôts supplémentaires: classqm, fatelk, uwolke, … (un peu similaire aux PPA chez Ubuntu).
Haiku essaie d'avoir une approche un peu plus décentralisée de la gestion des paquets, avec plusieurs dépôts parmi lesquels on peut faire son choix pour avoir tout plein d'applications. Ceci permet aussi d'être très réactif aux demandes de packaging sur ces dépôts indépendants.
[^] # Re: ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal #WeMakeSeitan. Évalué à 2.
Peut-être ici: http://www.mon-panier-bio.com/distributeur/local/ou-trouver-panier-bio-france/
Il y a deux/trois ans, j'habitais du côté de Nantes et on avait http://www.mon-panier-bio.com/distributeur/terre-de-bio-panier-bio-local-loire-atlantique/ , commande par internet, livraison sur ton lieu de travail (en essayant de livrer plusieurs personnes dans la même entreprise pour limiter les déplacements inutiles). Il y avait beaucoup de légumes mais aussi des laitages et de la viande, avec sur le site internet toutes les informations sur les producteurs.
Faut regarder si ça existe pas loin de chez toi.
[^] # Re: RMS a raison
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Où est le "vrai Linux"?. Évalué à 6.
Voilà, Linux est un noyau, et ce qui est important, c'est pas le noyau, c'est ce qui tourne autour. Du coup c'est tout de suite plus clair quand on parle de GNU/Linux. Et clairement, un Debian GNU/kFreeBSD est plus proche de "l'écosystème Linux" qu'un Android, alors qu'il n'utilise pas une ligne de code du noyau Linux. Il me semble donc évident qu'il y a un problème avec le nom "écosystème Linux", là.
Donc, on peut peut-être parler de l'"écosystème GNU", mais c'est un peu réducteur, car sur une distribution Linux classique il y a bien plus que les outils GNU. Alors, on dit quoi? X11+GNU+Linux, mais du coup on exclus Wayland et Mir? Juste GNU, mais on inclus Haiku?
Finalement, peut être qu'il n'y a pas vraiement de limite nette et franche, et que chacun prend les morceaux qui l'intéressent pour en faire ce qu'il veut. C'est ça qui est bien, avec le logiciel libre.
[^] # Re: Y'pas k'la FM
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Shield Arduino pour faire de la musique FM. Évalué à 2.
La playroutine de Hively Tracker peut fonctionner sur n'importe quoi. La preuve avec le music disc Planet Hively et sa liste assez impressionnante de plateformes supportées: http://www.pouet.net/prod.php?which=49931
Il faut quand même compter quelques mégaoctets de RAM pour le faire fonctionner, car il précalcule pas mal de waveforms en RAM pour optimiser sa vitesse (et oui, il y a au moins un cas ou je n'ai pas pu l'utiliser car je n'avais que des kilo octets de RAM).
Moins gourmand en RAM (celui ci tient dans une centaine de Ko pour le coup), mais un peu plus en CPU (principalement parce qu'il utilise des nombres flottants), il y a Sawteeth. Le tracker lui-même ne fonctionne que sur Haiku mais la playroutine a été portée sous Mac OS X par son auteur original et sur bitbox par moi-même (un CPU ARM sans OS). Sur la bitbox je n'ai pas pu le faire fonctionner à vitesse suffisante (168MHz, pas d'unité flottante matérielle, on est à la louche à 50% de la vitesse nécessaire en utilisant absolument tout le CPU).
Sawteeth ne sait faire que de la synthèse, tandis que Hively Tracker, lui, peut aussi inclure des samples il me semble.
Sinon, dans les trucs un peu plus "mainstream" (dans la demoscene en tout cas), la plupart du temps il faut combiner un tracker avec support des VST (souvent Renoise) et un synthétiseur sous forme de VST (par exemple 4klang). Ensuite, la musique est exportée dans un format spécifique. Avec 4klang, le rendu d'une musique est parfois difficile à faire en temps réel, une approche fréquement utilisée est de générer un fichier son décodé en RAM au chargement, puis de le lire "bêtement" pendant l'exécution. Mais du coup c'est assez gourmand en RAM.
[^] # Re: Y'pas k'la FM
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Shield Arduino pour faire de la musique FM. Évalué à 5.
Dans le genre il y a aussi hivelytracker et protrekkr pour Linux, ainsi que Sawteeth pour Haiku. Aucun des trois n'a besoin de 20% d'un CPU pour fonctionner (prévoir un Pentium II 233 ou quelque chose du genre).
[^] # Re: Y'pas k'la FM
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Shield Arduino pour faire de la musique FM. Évalué à 4.
C'est dommage de démonter un C64 pour récupérer seulement la puce son (qui n'a jamais été vendue séparément).
Et surtout je ne suis pas sur que ça soit nécessaire. On trouve encore en vente des clones de l'AY-3-8912 (dont l'AY8930 avec quelques fonctions supplémentaires plutôt sympa), ou alors on peut faire un truc soi-même comme le propose ce projet Kickstarter et comme le fait aussi lft (http://linusakesson.net/music/chipmusic.php) avec en particulier le Chipophone, le "Hardware Chiptune", et "The Swan" par exemple.
[^] # Re: Pourquoi faire ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Shield Arduino pour faire de la musique FM. Évalué à 6.
La carte semble utiliser un dsPIC, c'est un microcontrôleur avec des instructions DSP. Donc, la synthèse FM est faite… avec du logiciel dans cette puce.
Le même logiciel pourrait sans doute fonctionner sur n'importe quel CPU de ces 15 dernières années.
Cependant, il y a des problèmes à utiliser un PC "normal" pour faire de la musique: il faut un temps de réaction très rapide entre "j'appuie une touche sur mon clavier midi" et "le son sort des haut parleurs", ce qui n'est pas si simple qu'il n'y parait. Il faut que ça soit très fiable pour l'utiliser en "live" pendant un concert. Il ne faut pas que le PC qui fait tourner tout ça décide de faire un accès au disque dur et freeze pendant une seconde. Il ne faut pas que avast se mette à hurler "la base de définition virale à été mise à jour" en même temps (ou n'importe quel effet sonore de l'OS utilisé).
Tout ça est possible mais un petit peu compliqué. Et ça pose aussi des questions de support technique, ou il faut aider les gens à tout faire marcher sur des configurations très différentes. En fournissant à tout le monde le même matériel bien maîtrisé, il n'y a pas ce problème.
Enfin, il est beaucoup plus facile de vendre du matériel que du logiciel, surtout libre.
# Orthographe
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Cryptocat a disparu. Évalué à -4.
La réfome de l'orthographe ne dit pas qu'on peut faire n'importe quoi. "onion", c'est en anglais. En français, c'est oignon ou ognon.
[^] # FTP?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La sortie de `ls` vient de changer. Évalué à 4.
Il me semble que FTP ne spécifie pas vraiment de format pour la liste des fichiers que le serveur doit envoyer, et qu'en général ça ressemble franchement à un ls -l. Alors, est-ce qu'il y a des clients/serveurs FTP qui vont avoir des problèmes avec ces quotes inattendues?