Si on arrive à vendre des boîte de jeux vidéo sans le DVD dedans, on devrait pouvoir vendre un DVD de Haiku sans problème. Le but n'est pas vraiment que les gens l'utilisent pour installer Haiku, mais plus de faire un "souvenir" de la version publiée. Un peu comme un musicien qui publierait sa musique en Vinyl plutôt qu'en CD ou en téléchargement en ligne.
ça c'est intéressant. Il s'agit d'un lien sponsorisé, donc osdisc.com reverse des sous à distrowatch quand on l'utilise. Mais toujours rien pour Mageia ni pour Haiku…
(j'ai bien vérifié le fonctionnement du partenariat sur osdisc.com et c'est bien comme ça que ça marche: l'achat via un lien sponsorisé entraîne le versement de 40% du montant à la personne propriétaire du lien, il n'y a pas de partenariat qui donne un pourcentage des ventes sur un CD ou un DVD donné).
Je n'en suis pas certain. Pour les DVD avec pochettes imprimée, DVD imprimé, cellophanage, etc, il faut commander un minimum de 500 DVDs. Je ne pense pas que osdisc fonctionne comme ça, il est possible qu'ils gravent les DVDs à la demande ou en lots plus petits (il s'agira donc de DVD-R et pas d'un "vrai" DVD pressé). En tout cas vu le nombre de distributions proposées et le volume de ventes annoncé (200 000 DVD en 15 ans toutes distributions confondues).
Il y a plein d'entreprises qui proposent ce que je cherche pour la production du DVD. Osdisc n'en fait pas partie. L'avantage éventuel est qu'ils proposent la distribution, mais ça pose d'autres problèmes. Par exemple, si j'ai besoin d'un stock de DVDs à distribuer pendant le FOSDEM ou le Capitole du Libre, est-ce qu'ils peuvent m'en envoyer, à quel prix et dans quel délai?
La question est donc, pourquoi je devrais passer par osdisc plutôt que par un autre fabricant de DVDs?
Autant si un jour j'ai envie d'imprimer des T-Shirts, je sais que je vais aller voir freewear pour plein de raisons (affichage clair de la somme reversée au projet, présence dans certains évènements autour du logiciel libre, etc), autant là, je ne vois pas pourquoi je devrais passer par osdisc.
ça a marché pour les versions précédentes de Haiku (2009 à 2012, on en a pas refait depuis). Je ne suis pas certain que les gens l'achètent vraiment pour installer Haiku, plutôt pour financer le projet (on vend ça à prix libre avec un minimum permettant de couvrir les frais de production et d'expédition), et pour fêter la publication d'une version (chose peu fréquente chez nous) avec un objet souvenir. C'est pour ça que je suis assez attentif à faire quelque chose qui soit joli et propre.
Je n'ai aucun problème avec ça. Ils font ce qu'ils veulent, comme je l'ai indiqué dans mon journal, ils en ont tout à fait le droit.
La question, pour mon choix personnel, c'est est-ce que je dois acheter chez eux ou pas? Est-ce que certaines distributions Linux ont effectivement rejoint leur programme de partenariat? Est-ce que pour Haiku on devrait leur laisser gérer la distribution des DVDs (ça me ferait du travail en moins, ça me va bien), ou est-ce qu'il vaut mieux prendre ça en charge par d'autres moyens?
Avec le fil de commentaires au-dessus j'ai la réponse à certaines de ces questions: l'aspect visuel du DVD et du packaging ne me convient pas. C'est déjà une raison suffisante pour trouver une autre solution. Je suis tout de même intéressé par la réponse aux autres questions, pas pour attaquer OSDisc dans ce qu'ils font, mais pour savoir si je dois les éviter ou si au contraire ils sont sympas et je ferais bien d'acheter mes supports d'installation chez eux.
Et je suis aussi intéressé pour savoir s'il existe des alternatives, du coup, parce que l'idée ne me paraît pas bête dans l'ensemble.
En fait ça me dérange pas qu'ils distribuent du logiciel libre et les coût sont assez raisonnables. Ce qui m'inquiète plus c'est de savoir si les DVDs distribués sont présentables. Quand on en fabrique nous même on essaie de le faire avec un DVD de qualité (on est obligés d'en commander au moins 500 d'un coup pour avoir un DVD pressé et pas juste un DVD-R), une jolie pochette imprimée, etc.
Je voudrais au moins savoir à quoi ressemble leur DVD, est-ce qu'ils font tout ça où est-ce qu'ils se contentent d'envoyer un DVD-R avec le nom écrit au feutre dessus? Si effectivement ils font un travail propre et de qualité, alors on pourrait sans doute devenir partenaire et ça m'éviterait de gérer moi même la vente de DVDs. Mais le fait qu'ils ne nous aient pas contacté pour nous demander si on avait un visuel à mettre sur le DVD et sa pochette m'inquiète un peu.
C'est pour ça que je fais cette demande d'information ici avant d'aller plus loin.
Pour tous les projets qui ont besoin de miroirs c'est important d'avoir ce genre de service sous la main. Merci à SWITCH et à tous les autres: osuosl, free, … de fournir ce service aux projets qui le nécessitent.
Je préfère avoir une liste de miroirs indépendants comme le faisait sourceforge qu'un hébergement qui ne dépend que d'une seule entreprise comme c'est le cas aujourd'hui avec github. La consolidation fragilise les choses, dans ce cas précis.
Le gestionnaire de paquets utilise Curl actuellement, donc il faut positionner les variables d'environnement habituelles et ça devrait marcher (lancer pkgman ou HaikuDepot depuis un shell avec ces variables, du coup).
Pootle n'est pas fait pour traduire de la documentation
La traduction de la documentation date d'avant l'internationalisation du système et la mise en place de Pootle.
Et je vais te décevoir mais il y a un troisième outil utilisé par des applications tierces: https://i18n.kacperkasper.pl/ (ou je pense qu'il y a encore quelques trucs à traduire).
La dernière fois que quelqu'un lui en a parlé, la réponse a été "that ship has sailed" ("ce bateau a quitté le port").
Il sait que ça existe, mais ça fait presque 20 ans qu'il est passé à autre chose. Comme la plupart des gens qui ont travaillé chez Be, avant de rejoindre Palm, Android, Google, Apple, …
Il n'y a que la petite équipe de Haiku pour regarder encore 20 ans en arrière et croire cue c'est là que se trouve le futur ;)
En ce moment il publie dans The Monday Note une série d'article sur ses 50 ans de carrière. Le chapitre sur Be devrait arriver bientôt.
Sur ST les samples sont joués au CPU, en écrivant dans les registres de volume de l'AY. En général ceci est fait à partir d'une interruption timer pour gérer la fréquence. Ces registres de volume étant seulement sur 4 bits, ça limite un peu les choses.
Sur Atari STe, il y a en plus de la puce (qui est un YM2149, presque la même chose que l'AY-3-8912 mais pas tout à fait), deux canaux DMA pour les samples.
Précision sur l'Amiga: les canaux DMA n'utilisent certes pas le CPU, mais font des accès à la chipram, ce qui empêche le CPU d'y accéder en même temps. Ce dernier est donc tout de même ralenti, à moins de s'arranger pour travailler uniquement en fastram (la mémoire étendue isolée du chipset et inaccessible par les canaux DMA).
HivelyTracker ne permet pas d'utiliser des samples si je me souviens bien. Il est dérivé de AHX (pour Amiga) et fonctionne avec un synthétiseur en temps réel.
Pour protrekkr, en effet je pense que la version de hitchhikr est la plus à jour (elle était hébergée sur Google Code il me semble, avant que ça ferme). Je ne sais pas si des évolutions sont nécessaires. Peut-être que le programme fait tout ce qu'on attend de lui et qu'il n'y a pas tellement besoin de changements?
hitchhikr pourra faire la maintenance si nécessaire, ou bien je peux aussi m'en occuper (en tant que responsable du port vers Haiku, j'ai déjà un peu touché à son code).
Ben oui, le financement participatif ne supprime pas le besoin de faire du marketing et de la publicité. Il permet juste de regrouper les gens qui ont un besoin commun mais qui ne sont pas prêts à en assurer le coût à 100%.
Il y a plein de variantes. Par exemple les "bounties", typquement sur le site bountysource, ou on peut mettre des promesses de dons sur une fonctionnalité. Le développeur qui l'implémente récupère le pactole. Personellement ce fonctionnement en mode "chasseur de primes" ne me plaît pas trop (je ne dirai pas non si par hasard je résoud un bug et que j'apprends que quelqu'un avait misé de l'argent dessus, mais bon).
Tu as aussi Liberapay qui lui se place dans un mode d'économie du don: un développeur (ou n'importe qui, la plateforme est ouverte à tous) reçoit des dons anonymes et donc nécessairement sans contrepartie. Mais les gens sont-ils prêt à financer ça sans contrepartie? Il faut aller le leur expliquer et là encore, ça demande du temps. Mais au moins on est pas obligé, on peut aussi s'inscrire sur Liberapay et juste attendre que les dons arrivent.
Tu as encore les sites du type Patreon, ou l'idée est que les gens donnent de l'argent pour financer le travail de quelqu'un (développeur, artiste, …) et en échange vont avoir accès à un genre de "zone VIP" avec un apperçu du travail en avant-première, etc. Dans ce cas on retombe dans l'inconvénient des campagnes de type Kickstarter: faire vivre ce genre de plateforme demande du temps de la part de la personne financée.
De façon générale, si tu as un logiciel générique qui répond à un besoin récurrent d'entreprises, tu peux t'en sortir en vendant le support, le déploiement, et le développement pour personnaliser ce logiciel pour les besoins exacts de chaque client.
C'est possiblement moins de rentrée d'argent que si tu vendais le logiciel tel quel avec une licence par nombre de postes installés ou je ne sais quoi. Mais d'un autre côté ça peut permettre d'être moins cher qu'un concurrent qui développerait un truc à partir de zéro pour chaque client.
Il y a quelques mois, Mozilla avait présenté une taxonomie des projets libres, avec plusieurs types de projets selon la gouvernance, le financement, etc. C'est probablement bon à relire pour voir les modèles qui semblent les plus pertinents du point de vue de la perrenité et de l'efficacité.
On en arrive là parce que le modèle communautaire n'a pas marché. Quand on est une entreprise et qu'on veut faire du logiciel libre et le diffuser gratuitement, il faut bien trouver un "modèle d'affaires" (business model), une façon de faire rentrer des sous.
Il y a des projets pleinement communautaires, parce qu'ils sont gros, et que du coup plusieurs entreprises/fondations/… peuvent y contribuer. Je pense à Linux, à WebKit, à clang par exemple.
Et il y a des projets plus petits, portés par une seule entreprise dont c'est le métier principal. On pourrait se dire "ils pourraient fournir le logiciel libre gratuitement, et vendre le support". Oui mais voilà, quand en plus on est sur un mode "service" (comme github ou gitlab), on est quand même un peu obligé de fournir du support sur le produit.
Ils pourraient aussi facturer les nouveaux développement à la première personne qui les demande (ou bien en partageant via des bounties/crowdfunding), mais ça serait très cher, et si la personne qui paie sait que ça finira par être libre, elle peut aussi bien décider d'attendre que quelqu'un paie à sa place.
En ce qui me concerne, je travaille dans une entreprise qui utilise beaucoup de logiciel libre. Gitlab (déployé en interne), Linux, iptables, …
Cependant, jusqu'à maintenant on n'a que peu contribué. Notre démarche va être (on y réfléchit) d'avoir des développeurs avec un peu de temps réservé (par exemple une journée par mois) pour contribuer à du logiciel libre. Les logiciels ont vraiment besoin de contributeurs, et faire en sorte que les entreprises paient avec du temps de leurs employés, plutôt qu'avec de l'argent, ça serait peut être intéressant. Pour le projet libre qui récupère les contributions, pour l'employé qui peut faire du logiciel libre, et pour l'entreprise qui bénéficie des nouvelles fonctionnalités ainsi réalisées, d'employés contents qui sont plus motivés, et de retombées en terme d'image de marque.
Si plus de monde se met à faire ce genre de choses, alors on pourra avoir du logiciel communautaire bien maintenu. Sinon, à un moment donné il va falloir se décider à passer à la caisse. Et si une entreprise voit qu'elle ne récupère pas de contributions valables en publiant ses sources, il est probable qu'elle arrête de s’embarrasser avec ça. C'est là qu'on tombe dans le modèle "open core". Du Libre en version "on aimerait bien, mais ça paie pas les salaires à la fin du mois".
A moins d'avoir des développeurs super forts (ou d'aimer les régressions), optimiser le code nécessite de le comprendre et de pouvoir faire des changements profonds sans avoir peur de tout casser.
Ce n'est pas parce qu'un algorithme est complexe que le code doit être illisible. Il doit être possible d'écrire les choses de façon modulaire et réutilisable, ce qui permet en plus d'appliquer le même algorithme (ou quelques morceaux) pour optimiser d'autres choses.
C'est très pénible (mais pas impossible) à faire en C, et plus confortable en C++ (pas de commentaire sur les autres langages que je ne connaît pas assez bien pour en juger).
Si ton code est un tas de spaghetti, tu ne peux pas le modifier facilement pour le rendre plus efficace. S'il est propre et bien architecturé, tu peux remplacer une structure de données ou un algorithme sans devoir tout remettre en question.
Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?
[^] # Re: Bénéfices
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à -3.
"bonjour, vous êtes une entreprise qui ne fait pas du tout ce que je veux, vous pourriez svp tout changer à votre produit pour me faire plaisir?"
Je vais aller commander mes DVDs chez un fabricant qui fabrique ce dont j'ai besoin, merci.
[^] # Re: Le projet GNU suit le projet Linux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien GNU Kind Communications Guidelines. Évalué à 3. Dernière modification le 23 octobre 2018 à 12:29.
Il y a déjà ça:
https://www.contributor-covenant.org
https://www.contributor-covenant.org/adopters
Mais ça va probablement faire comme pour les licenses, il va y'en avoir deux ou trois avec des problèmes de compatibilité, je suppose.
[^] # Re: Bénéfices
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à 6.
Si on arrive à vendre des boîte de jeux vidéo sans le DVD dedans, on devrait pouvoir vendre un DVD de Haiku sans problème. Le but n'est pas vraiment que les gens l'utilisent pour installer Haiku, mais plus de faire un "souvenir" de la version publiée. Un peu comme un musicien qui publierait sa musique en Vinyl plutôt qu'en CD ou en téléchargement en ligne.
[^] # Re: Bénéfices
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à 3.
ça c'est intéressant. Il s'agit d'un lien sponsorisé, donc osdisc.com reverse des sous à distrowatch quand on l'utilise. Mais toujours rien pour Mageia ni pour Haiku…
(j'ai bien vérifié le fonctionnement du partenariat sur osdisc.com et c'est bien comme ça que ça marche: l'achat via un lien sponsorisé entraîne le versement de 40% du montant à la personne propriétaire du lien, il n'y a pas de partenariat qui donne un pourcentage des ventes sur un CD ou un DVD donné).
[^] # Re: Bénéfices
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à -1.
Je n'en suis pas certain. Pour les DVD avec pochettes imprimée, DVD imprimé, cellophanage, etc, il faut commander un minimum de 500 DVDs. Je ne pense pas que osdisc fonctionne comme ça, il est possible qu'ils gravent les DVDs à la demande ou en lots plus petits (il s'agira donc de DVD-R et pas d'un "vrai" DVD pressé). En tout cas vu le nombre de distributions proposées et le volume de ventes annoncé (200 000 DVD en 15 ans toutes distributions confondues).
Il y a plein d'entreprises qui proposent ce que je cherche pour la production du DVD. Osdisc n'en fait pas partie. L'avantage éventuel est qu'ils proposent la distribution, mais ça pose d'autres problèmes. Par exemple, si j'ai besoin d'un stock de DVDs à distribuer pendant le FOSDEM ou le Capitole du Libre, est-ce qu'ils peuvent m'en envoyer, à quel prix et dans quel délai?
La question est donc, pourquoi je devrais passer par osdisc plutôt que par un autre fabricant de DVDs?
Autant si un jour j'ai envie d'imprimer des T-Shirts, je sais que je vais aller voir freewear pour plein de raisons (affichage clair de la somme reversée au projet, présence dans certains évènements autour du logiciel libre, etc), autant là, je ne vois pas pourquoi je devrais passer par osdisc.
[^] # Re: Bénéfices
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à 5.
ça a marché pour les versions précédentes de Haiku (2009 à 2012, on en a pas refait depuis). Je ne suis pas certain que les gens l'achètent vraiment pour installer Haiku, plutôt pour financer le projet (on vend ça à prix libre avec un minimum permettant de couvrir les frais de production et d'expédition), et pour fêter la publication d'une version (chose peu fréquente chez nous) avec un objet souvenir. C'est pour ça que je suis assez attentif à faire quelque chose qui soit joli et propre.
[^] # Re: Bénéfices
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à 3. Dernière modification le 22 octobre 2018 à 14:45.
Je n'ai aucun problème avec ça. Ils font ce qu'ils veulent, comme je l'ai indiqué dans mon journal, ils en ont tout à fait le droit.
La question, pour mon choix personnel, c'est est-ce que je dois acheter chez eux ou pas? Est-ce que certaines distributions Linux ont effectivement rejoint leur programme de partenariat? Est-ce que pour Haiku on devrait leur laisser gérer la distribution des DVDs (ça me ferait du travail en moins, ça me va bien), ou est-ce qu'il vaut mieux prendre ça en charge par d'autres moyens?
Avec le fil de commentaires au-dessus j'ai la réponse à certaines de ces questions: l'aspect visuel du DVD et du packaging ne me convient pas. C'est déjà une raison suffisante pour trouver une autre solution. Je suis tout de même intéressé par la réponse aux autres questions, pas pour attaquer OSDisc dans ce qu'ils font, mais pour savoir si je dois les éviter ou si au contraire ils sont sympas et je ferais bien d'acheter mes supports d'installation chez eux.
Et je suis aussi intéressé pour savoir s'il existe des alternatives, du coup, parce que l'idée ne me paraît pas bête dans l'ensemble.
[^] # Re: oui....
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à 4.
En effet:
Je vais donc faire réaliser des DVDs avec impression couleur et pochette en carton, ce sera mieux.
[^] # Re: oui....
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vous connaissez osdisc?. Évalué à 4.
En fait ça me dérange pas qu'ils distribuent du logiciel libre et les coût sont assez raisonnables. Ce qui m'inquiète plus c'est de savoir si les DVDs distribués sont présentables. Quand on en fabrique nous même on essaie de le faire avec un DVD de qualité (on est obligés d'en commander au moins 500 d'un coup pour avoir un DVD pressé et pas juste un DVD-R), une jolie pochette imprimée, etc.
Je voudrais au moins savoir à quoi ressemble leur DVD, est-ce qu'ils font tout ça où est-ce qu'ils se contentent d'envoyer un DVD-R avec le nom écrit au feutre dessus? Si effectivement ils font un travail propre et de qualité, alors on pourrait sans doute devenir partenaire et ça m'éviterait de gérer moi même la vente de DVDs. Mais le fait qu'ils ne nous aient pas contacté pour nous demander si on avait un visuel à mettre sur le DVD et sa pochette m'inquiète un peu.
C'est pour ça que je fais cette demande d'information ici avant d'aller plus loin.
[^] # Re: Une page qui se tourne
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fin du service SWITCHmirror . Évalué à 3.
Pourquoi, ton gestionnaire de paquets ne sait pas faire de P2P?
[^] # Re: Une page qui se tourne
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fin du service SWITCHmirror . Évalué à 4.
Pour tous les projets qui ont besoin de miroirs c'est important d'avoir ce genre de service sous la main. Merci à SWITCH et à tous les autres: osuosl, free, … de fournir ce service aux projets qui le nécessitent.
Je préfère avoir une liste de miroirs indépendants comme le faisait sourceforge qu'un hébergement qui ne dépend que d'une seule entreprise comme c'est le cas aujourd'hui avec github. La consolidation fragilise les choses, dans ce cas précis.
[^] # Re: Http_proxy
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 1. Évalué à 4. Dernière modification le 03 octobre 2018 à 13:50.
Le gestionnaire de paquets utilise Curl actuellement, donc il faut positionner les variables d'environnement habituelles et ça devrait marcher (lancer pkgman ou HaikuDepot depuis un shell avec ces variables, du coup).
[^] # Re: pouët pouët et jeu perdu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 1. Évalué à 5.
J'ai plein de bazar pour BeOS ici: http://pulkomandy.tk/~beosarchive/
Mais sans le nom ça va être difficile de trouver.
[^] # Re: traduction
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 1. Évalué à 3.
Deux raisons:
Et je vais te décevoir mais il y a un troisième outil utilisé par des applications tierces: https://i18n.kacperkasper.pl/ (ou je pense qu'il y a encore quelques trucs à traduire).
[^] # Re: Jean-Louis Gassée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 1. Évalué à 10.
Je me le permets parce que je fais partie de la dite équipe. On se prend au sérieux, mais pas trop quand même.
[^] # Re: Jean-Louis Gassée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 1. Évalué à 10. Dernière modification le 30 septembre 2018 à 18:34.
La dernière fois que quelqu'un lui en a parlé, la réponse a été "that ship has sailed" ("ce bateau a quitté le port").
Il sait que ça existe, mais ça fait presque 20 ans qu'il est passé à autre chose. Comme la plupart des gens qui ont travaillé chez Be, avant de rejoindre Palm, Android, Google, Apple, …
Il n'y a que la petite équipe de Haiku pour regarder encore 20 ans en arrière et croire cue c'est là que se trouve le futur ;)
En ce moment il publie dans The Monday Note une série d'article sur ses 50 ans de carrière. Le chapitre sur Be devrait arriver bientôt.
[^] # Re: Trackers <3
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal OpenMPT 1.28 : OPL & concours. Évalué à 3.
Sur ST les samples sont joués au CPU, en écrivant dans les registres de volume de l'AY. En général ceci est fait à partir d'une interruption timer pour gérer la fréquence. Ces registres de volume étant seulement sur 4 bits, ça limite un peu les choses.
Sur Atari STe, il y a en plus de la puce (qui est un YM2149, presque la même chose que l'AY-3-8912 mais pas tout à fait), deux canaux DMA pour les samples.
Précision sur l'Amiga: les canaux DMA n'utilisent certes pas le CPU, mais font des accès à la chipram, ce qui empêche le CPU d'y accéder en même temps. Ce dernier est donc tout de même ralenti, à moins de s'arranger pour travailler uniquement en fastram (la mémoire étendue isolée du chipset et inaccessible par les canaux DMA).
[^] # Re: Liste non exhaustive
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal OpenMPT 1.28 : OPL & concours. Évalué à 4.
HivelyTracker ne permet pas d'utiliser des samples si je me souviens bien. Il est dérivé de AHX (pour Amiga) et fonctionne avec un synthétiseur en temps réel.
Pour protrekkr, en effet je pense que la version de hitchhikr est la plus à jour (elle était hébergée sur Google Code il me semble, avant que ça ferme). Je ne sais pas si des évolutions sont nécessaires. Peut-être que le programme fait tout ce qu'on attend de lui et qu'il n'y a pas tellement besoin de changements?
hitchhikr pourra faire la maintenance si nécessaire, ou bien je peux aussi m'en occuper (en tant que responsable du port vers Haiku, j'ai déjà un peu touché à son code).
[^] # Re: Faire la différence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'avenir des projets communautaires face aux sirènes de la finance. Évalué à 3.
Ben oui, le financement participatif ne supprime pas le besoin de faire du marketing et de la publicité. Il permet juste de regrouper les gens qui ont un besoin commun mais qui ne sont pas prêts à en assurer le coût à 100%.
Il y a plein de variantes. Par exemple les "bounties", typquement sur le site bountysource, ou on peut mettre des promesses de dons sur une fonctionnalité. Le développeur qui l'implémente récupère le pactole. Personellement ce fonctionnement en mode "chasseur de primes" ne me plaît pas trop (je ne dirai pas non si par hasard je résoud un bug et que j'apprends que quelqu'un avait misé de l'argent dessus, mais bon).
Tu as aussi Liberapay qui lui se place dans un mode d'économie du don: un développeur (ou n'importe qui, la plateforme est ouverte à tous) reçoit des dons anonymes et donc nécessairement sans contrepartie. Mais les gens sont-ils prêt à financer ça sans contrepartie? Il faut aller le leur expliquer et là encore, ça demande du temps. Mais au moins on est pas obligé, on peut aussi s'inscrire sur Liberapay et juste attendre que les dons arrivent.
Tu as encore les sites du type Patreon, ou l'idée est que les gens donnent de l'argent pour financer le travail de quelqu'un (développeur, artiste, …) et en échange vont avoir accès à un genre de "zone VIP" avec un apperçu du travail en avant-première, etc. Dans ce cas on retombe dans l'inconvénient des campagnes de type Kickstarter: faire vivre ce genre de plateforme demande du temps de la part de la personne financée.
[^] # Re: Et vous, vous faites quoi?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'avenir des projets communautaires face aux sirènes de la finance. Évalué à 2.
De façon générale, si tu as un logiciel générique qui répond à un besoin récurrent d'entreprises, tu peux t'en sortir en vendant le support, le déploiement, et le développement pour personnaliser ce logiciel pour les besoins exacts de chaque client.
C'est possiblement moins de rentrée d'argent que si tu vendais le logiciel tel quel avec une licence par nombre de postes installés ou je ne sais quoi. Mais d'un autre côté ça peut permettre d'être moins cher qu'un concurrent qui développerait un truc à partir de zéro pour chaque client.
Il y a quelques mois, Mozilla avait présenté une taxonomie des projets libres, avec plusieurs types de projets selon la gouvernance, le financement, etc. C'est probablement bon à relire pour voir les modèles qui semblent les plus pertinents du point de vue de la perrenité et de l'efficacité.
# Liste non exhaustive
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal OpenMPT 1.28 : OPL & concours. Évalué à 5.
Dans les trackers libres et toujours plus ou moins vivants, il y a aussi:
Et encore plein d'autres
# Et vous, vous faites quoi?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'avenir des projets communautaires face aux sirènes de la finance. Évalué à 10.
On en arrive là parce que le modèle communautaire n'a pas marché. Quand on est une entreprise et qu'on veut faire du logiciel libre et le diffuser gratuitement, il faut bien trouver un "modèle d'affaires" (business model), une façon de faire rentrer des sous.
Il y a des projets pleinement communautaires, parce qu'ils sont gros, et que du coup plusieurs entreprises/fondations/… peuvent y contribuer. Je pense à Linux, à WebKit, à clang par exemple.
Et il y a des projets plus petits, portés par une seule entreprise dont c'est le métier principal. On pourrait se dire "ils pourraient fournir le logiciel libre gratuitement, et vendre le support". Oui mais voilà, quand en plus on est sur un mode "service" (comme github ou gitlab), on est quand même un peu obligé de fournir du support sur le produit.
Ils pourraient aussi facturer les nouveaux développement à la première personne qui les demande (ou bien en partageant via des bounties/crowdfunding), mais ça serait très cher, et si la personne qui paie sait que ça finira par être libre, elle peut aussi bien décider d'attendre que quelqu'un paie à sa place.
En ce qui me concerne, je travaille dans une entreprise qui utilise beaucoup de logiciel libre. Gitlab (déployé en interne), Linux, iptables, …
Cependant, jusqu'à maintenant on n'a que peu contribué. Notre démarche va être (on y réfléchit) d'avoir des développeurs avec un peu de temps réservé (par exemple une journée par mois) pour contribuer à du logiciel libre. Les logiciels ont vraiment besoin de contributeurs, et faire en sorte que les entreprises paient avec du temps de leurs employés, plutôt qu'avec de l'argent, ça serait peut être intéressant. Pour le projet libre qui récupère les contributions, pour l'employé qui peut faire du logiciel libre, et pour l'entreprise qui bénéficie des nouvelles fonctionnalités ainsi réalisées, d'employés contents qui sont plus motivés, et de retombées en terme d'image de marque.
Si plus de monde se met à faire ce genre de choses, alors on pourra avoir du logiciel communautaire bien maintenu. Sinon, à un moment donné il va falloir se décider à passer à la caisse. Et si une entreprise voit qu'elle ne récupère pas de contributions valables en publiant ses sources, il est probable qu'elle arrête de s’embarrasser avec ça. C'est là qu'on tombe dans le modèle "open core". Du Libre en version "on aimerait bien, mais ça paie pas les salaires à la fin du mois".
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 3.
A moins d'avoir des développeurs super forts (ou d'aimer les régressions), optimiser le code nécessite de le comprendre et de pouvoir faire des changements profonds sans avoir peur de tout casser.
Ce n'est pas parce qu'un algorithme est complexe que le code doit être illisible. Il doit être possible d'écrire les choses de façon modulaire et réutilisable, ce qui permet en plus d'appliquer le même algorithme (ou quelques morceaux) pour optimiser d'autres choses.
C'est très pénible (mais pas impossible) à faire en C, et plus confortable en C++ (pas de commentaire sur les autres langages que je ne connaît pas assez bien pour en juger).
Si ton code est un tas de spaghetti, tu ne peux pas le modifier facilement pour le rendre plus efficace. S'il est propre et bien architecturé, tu peux remplacer une structure de données ou un algorithme sans devoir tout remettre en question.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 4.
Oui, c'est pas impossible à faire avec Gitlab mais c'est pénible.
Gerrit permet aussi de merger un commit avant que les suivants ne soient prêts, par exemple.
Ce n'est pas forcément moins souple, c'est juste une façon différente de travailler.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 6.
Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?