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?
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).
Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
Pas très efficace la protection pour le coup, je suis dans l'UE et j'ai eu droit à cette boite de dialogue en installant un autre navigateur. Qui s'occupe de porter plainte au lieu de raler sur les forums?
[^] # 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?
[^] # 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é à 8.
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 6.
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 3.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 4.
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 10.
Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 4.
Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
[^] # Re: Pub
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows 10 fait la publicité de Edge pendant l'installation de Firefox et Chrome !. Évalué à 2.
Pas très efficace la protection pour le coup, je suis dans l'UE et j'ai eu droit à cette boite de dialogue en installant un autre navigateur. Qui s'occupe de porter plainte au lieu de raler sur les forums?