Le projet OpenBSD est en difficulté et demande de l'aide pour payer sa facture d'électricité. Si la demande me paraît un peu brusque : « we are looking for a Canadian company who will take on our electrical expenses—on their books, rather than on our books », la suite de la discussion apporte une question intéressante, pourquoi payer pour ce que les autres utilisent gratuitement ?
En effet, le projet OpenBSD fournit gratuitement un système d'exploitation de qualité ainsi qu'un certain nombre de logiciels tel OpenSSH utilisés par une vaste population. Afin d'assurer cette qualité, le projet OpenBSD maintient des machines plus ou moins vieille permettant d'effectuer des tests et de découvrir des bugs qui seraient indécelables autrement. Bien sûr tout cela à un coût et le projet se retrouve avec une facture de 20 000 dollars d'électricité à payer.
Alors oui, le projet pourrait trouver d'autres moyens de financement que la donation telles la vente de T-shirts ou de CD. Mais la question est justement là, pourquoi ? Car, créer des T-shirts, assurer les stocks et l'envoi, entraîne un coût non seulement monétaire mais aussi coût humain qui ne peut être redistribué sur le cœur du projet, le développement du système d'exploitation.
Le projet OpenBSD fait économiser un bon paquet d'argent à des compagnies qui trouvent un système d'exploitation fonctionnel et ce gratuitement. Alors pourquoi ne pourrait-elle pas en contrepartie assurer une partie des frais liés au projet ? Les projets Open Sources sont-ils des vaches à lait ?
# Oui
Posté par Maclag . Évalué à 10.
Oui, et ce n'est pas comme si on découvrait ça aujourd'hui.
Là c'est une facture d'électricité et c'est assez grave, parce que ça veut dire que sans les dons, les serveurs s'arrêtent!
J'espère donc que les utilisateurs d'OpenBSD, quels qu'ils soient, vont au moins réaliser que s'ils attendent trop longtemps que d'autres se bougent, et bien ça pourrait bien être trop tard!
Mais tu peux reprendre le même raisonnement pour quasiment tous les projets Libres, car ils offrent presque tous leur produit gratuitement. Nombre de ces projets acceptent des dons, mais si on devait comparer l'argent reçu des dons avec le nombre d'utilisateurs, je pense que ça ferait peur. De même, tu peux demander aux dévs Libres ici s'ils estiment être justement rémunérés par les dons par rapport à leurs compétences et le temps passé sur leurs projets respectifs, je crois que certains grinceront des dents avant de répondre.
Et puis, il ne faut pas se leurrer: tu crois vraiment que les entreprises qui utilisent du Libre le font uniquement pour la qualité des outils, ou le fait que presque tout soit gratuit entre en ligne de compte?
Il est très facile de justifier l'achat d'un logiciel en compta, mais dans une boite "non familiale" (grosse PME et grande entreprise), il est extrêmement difficile de justifier un don même à un projet dont le produit est critique pour la boite.
"Qu'est-ce que je vais avoir en échange?
-Ben, euh… tu l'as déjà!
-Ok. Alors pourquoi on paie??"
La conclusion est donc oui, mille fois oui: un très grand nombre d'entreprises sont contentes que le Libre existe parce que ça leur permet d'avoir accès à un grand nombre de bons logiciels gratuitement. Et une fois que l'argument du gratuit est passé, faut se lever tôt pour ouvrir le porte-monnaie.
J'ajouterais que nombre de particuliers font la même chose, et je serais bien incapable de faire des dons pour tous les logiciels que j'utilise régulièrement avec plaisir sans me ruiner! Donc c'est sélectif et à l'humeur du moment.
[^] # Re: Oui
Posté par Zenitram (site web personnel) . Évalué à 8.
La question que je me pose, c'est pourquoi Fedora, CentOS, Debian et j'en passe arrivent à attirer les dons sans mendier, et pas BSD.
C'est quand même bizarre. Il a l'air aussi de manquer un côté "marketing" pour attirer les dons.
On parle de la grande utilité de BSD, mais en fait, est-ce si utile que ça? Est-ce vital? Si ils coupent, est-ce que Sony et autre grosse boite ne fera pas juste un petit effort pour choper un Linux et mettre leur truc proprio dessus (ce n'est pas difficile de jouer avec la GPL)? J'ai surtout l'impression qu'ils ont les chevilles bien enflées.
Mais aussi, pourquoi cette victimisation de "vache à lait" du journal? Personne ne les force, ils sont grands, ils ne sont pas une vache à lait, ils sont des gens qui ont décidé d'offrir sans contre-partie (ou alors il faut changer quelques chose sur leur site).
Donc : qu'ils coupent! On verra qui en a vraiment besoin et ils discuterons avec ces personnes. Il faut parfois montrer qu'on est utile et que personne ne peut faire mieux (moins cher).
[^] # Re: Oui
Posté par Joris Dedieu (site web personnel) . Évalué à 10.
des BSD sans doute veux tu dire ?
Prends un exemple. Si tu souhaites mettre en place une architecture DNS robuste, il te faut :
Cela te permet de conserver un service UP même lorsqu'une partie de ton infra est devenu vulnérable ou sous le feu d'une attaque.
La diversité permet de diluer les risques, c'est pourquoi, il est essentiel de pouvoir disposer d'un écosystème de logiciels vaste pour produire des services réseau viables.
Ce qui est important, ce n'est pas tant OpenBSD, que la possibilité pour les administrateurs système de pouvoir déployer une certaine variété de solutions. Une diminution du nombre de solutions disponibles entrainerai un retour vers des solutions propriétaires et serait pour le libre en général une mauvaise affaire.
Cette variété d'implémentations est également essentielle pour les développeurs à qui elle permet de confronter leurs idées à celles des autres.
Enfin pour ce qui est du cas spécifique d'OpenBSD, c'est une communauté qui a fait grandement avancer le libre entre autre sur les pilotes Wifi, sur l'implémentation des protocoles réseau, sur la gestion des chaines de caractères et sur un tas d'autres sujet.
Elle produit aussi un certain nombre de logiciels comme OpenSSH, OpenBGPD, OpenSMTPD, Mandoc … qui sont utilisés sous Linux comme sous tout un tas d'autres OS.
[^] # Re: Oui
Posté par Zenitram (site web personnel) . Évalué à -1.
"des" si tu veux, ça ne change pas l'idée : si les gens ont besoin, ils pourront payer.
a toi de convaincre que ce que tu dis est un vrai besoin.
[^] # Re: Oui
Posté par Krunch (site web personnel) . Évalué à 6.
Tous ces projets ont au moins une page « donation » :
http://www.debian.org/donations
https://fedoraproject.org/wiki/Donations
http://wiki.centos.org/Donate
Par contre, Fedora et CentOS étant sponsorisés directement par une entreprise qui paie au moins une partie de leurs développeursWgens et infrastructure, je ne suis pas sûr qu'on puisse les mettre dans la même catégorie que la plupart des BSD.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Oui
Posté par Zenitram (site web personnel) . Évalué à 2.
Page de don != mendier.
Et ils sont sponsorisés, ça veut dire que eux ont trouvé.
La question reste la même : pourquoi les xBSD n'ont pas de gros sponsor? est-ce utile?
Ce n'est pas en tournant l'idée dans tous les sens pour ne pas repondre qu'on y répondra, il reste que ces projets ne font pas la quète "on n'a pas de sous, même si on est utile". Ils font.
[^] # Re: Oui
Posté par totof2000 . Évalué à 6.
Je ne sais pas pourquoi OpenBSD n'arrive pas a recueillir assez de fonds, mais en tout cas NetBSD semble en recueillir assez. Et je n'ai rien entendu à propos de FreeBSD. A mon avis, OpenBSD est un peu victime du caractère de son leader et ne fédère pas autant que les autres. C'est dommage car comme précisé plus haut, OpenBSD a permis de grosses avancées dans le libre. Après tu parles de "mendier", mais un appel au don ne constitue pas pour moi de la mendicité : si tout le monde croit que OpenBSD a assez d'argent, personne ne donnera : donc de temps en temps un rappel ne fait pas de tort.
Celà dit, ils n'ont juste qu'à couper pendant quelques jours, juste pour voir le bruit que ça génèrera : a mon avis on en entendra parler.
[^] # Re: Oui
Posté par Spack . Évalué à 5.
Fedora est clairement sponsorisé par Red Hat et c'est maintenant aussi le cas de CentOS.
Debian aussi à une longue liste de sponsors et possède même un système que je trouve assez intelligent pour son infrastructure. Chaque machine est sponsorisé, ce qui permet de gérer les coûts associés.
La plupart des distributions Linux que j'ai essayé possèdent une page de ce type. La fondation OpenBSD, elle, semble assez jeune.
Il est clair que les entreprises vont sponsoriser les projets qui leurs sont utile. Cependant, se rendre utile passe aussi par un effort de communication.
Mon opinion n'est pas forcément celle reflétée par le journal. Il s'agit simplement d'un moyen de lancer
le trollla discussion sur un sujet que j'ai trouvé intéressant.[^] # Re: Oui
Posté par Misc (site web personnel) . Évalué à 10.
En fait, c'est plus subtile que ça. Fedora, Centos, Debian acceptent tous d'avoir des serveurs dans des data centers et des salles autre que les leurs.
Et je pense avoir lu ( mais j'ai pas de lien sur ça ) que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Ce qui du coup fait que les aides habituelles des facs, des hébéergeurs, etc ne s'appliquent pas, car ce n'est pas ce que le projet veux.
Des boites qui filent des thunes, y en a pas des tonnes. Ç'est plus complexe, faut passer par la compta, par la direction, etc. C'est faisable, mais je pense que la plupart des gens veulent pas se fatiguer pour ça.
Alors que des boites qui filent de l’hébergement gratos, ça se trouve. En france et sans être exhaustif, tu as Lost Oasis ( mageia, tuxfamilly, plf et plein de monde ), tu as gandi ( mageia encore ), tu as ovh ( filé un serveur pour l'ex AUFML ), tu as Free ( linuxfr ), ou Ikoula ( pour fedora-fr.org ), ou d'autres assoces ( le crans gère un serveur d'OSM, par exemple ).
Et ça se trouve car il y a moins de paperasse, tu en parles avec des gens qui comprennent le souci genre ton chef et son chef à lui tout au plus, et basta. Voir même, c'est ton coeur de métieur de filer des machines, donc tu dit juste "ça, y a une remise de 100%".
Ensuite, oui, ça aide d'avoir un sponsor qui peut payer, mais les projets arrivent assez souvent sans trop de mal à s'en passer.
[^] # Re: Oui
Posté par Kaane . Évalué à 10.
que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Raisons de sécurité mais pas que, voire même pas prioritairement. Theo avait expliqué dans une conférence il y a un moment (hop là petite excuse pour dire, j'ai cherché sur le net, j'ai pas retrouvé) que le fait de disposer de sa propre infrastructure lui permettait d'effectuer un bon nombre de tests qui sont difficilement réalisables sur des infrastructures tiers, à fortiori des infrastructures de gens qui gagnent leur vie avec.
Des trucs comme "je vais faire des broadcasts DHCP pourri en mode hammer"(1) ou encore "C'est parti pour deux heures de TCP fuzzing"(2) ce sont des choses que les hébergeurs pro (ou même les hébergeurs à but non lucratif mais avec quand même des accords à respecter) n’apprécient pas. En d'autres termes, a moins de pouvoir dédier complètement une branche indépendante de l'infrastructure, les risques de faire tomber tout le système en accueillant les serveurs OpenBSD chez soi sont loin d'être nuls. Et Théo craint tout simplement qu'à la deuxième ou troisième fois ou les tests réseaux assez particuliers qu'il lance plantent le cœur, on le prie gentiment de prendre ses cliques et ses claques et d'aller voir ailleurs.
(1) Technique qui consiste (entre autre) à tenter de renouveler des baux DHCP que l'on a pas instauré. Très pratique pour les attaques man in the middle
(2) Comme pour le code fuzzing, on envoie sur le réseau moult paquets TCP conforme à la norme, mais avec un contenu aléatoire. Vous seriez surpris du nombre de switchs et de routeurs (y compris de grande marque) qui tombent en quelques minutes maximum quand on commence à jouer à ça.
[^] # Re: Oui
Posté par flan (site web personnel) . Évalué à -6.
Je ne vois pas le rapport avec le fait d'avoir les serveurs du projet chez soi. Ou alors peut-être fait-il ses tests sur l'environnement de prod ??? Je n'espère pas, ça ruinerait toute la réputation de sérieux du projet.
[^] # Re: Oui
Posté par briaeros007 . Évalué à 1.
y'a un truc très bien qu'on a inventé qui s'appelle les VMs, les VLANs et la QoS
Ca permet de cloisonner les OS, les réseaux, et les ressources.
Et si tu te débrouille bien, tu fais mumuse sur la couche 3 et au dessus, et tu fous toutes tes VMs dans un seul hyperviseur dédié au test sur un réseau purement interne à l'hyperviseur (donc aucun paquet risque de partir). Tu fais planter que ta VMs, et au pire du pire du pire, tu fait juste planter l'hyperviseur.
Le seul truc où les Vms ne conviennent pas c'est dans tout ce qui est gestion du matos. Mais j'ai comme un doute que openbsd a des machines avec chaque type de carte réseau, chaque type de carte mère, … pour tester et valider les drivers
[^] # Re: Oui
Posté par Spack . Évalué à 10.
L'utilisation de VLANs n'empêche en rien de flinguer le réseau en cas de paquet mal formé. Les tests sont justement lancés dans ce but : faire planter le tout. Il est fort probable qu'un paquet arrive à faire planter le switch.
En utilisant une VM tu risques fort de te retrouver à déboguer l'hyperviseur ou tout autre pilote virtuel alors que tu avait un tout autre but en tête.
[^] # Re: Oui
Posté par briaeros007 . Évalué à 2.
Donc si tu as un paquet qui te fait tout planter, tu crois que tu t'en fous de savoir que ton bsd tient bien le paquet, vu que toute l'infra est par terre ?
Et puis heureusement que j'ai bien précisé la couche.
Si tu arrives à faire planter un switch vlan avec des données L3, donne moi la conf de ton switch que je ne l'achète pas.
[^] # Re: Oui
Posté par Gof (site web personnel) . Évalué à 3.
Le but est d'avoir un openBSD stable. Comme ça quand tu passe ton infrastructure en openBSD, ton infrastructure ne tombe pas par terre si un petit malin s'amuse avec des paquets malformés.
Les dev de openBSD n'ont de l'influence que sur les logiciels openBSD et ne veulent peut être pas perdre du temps à débugger ou contourner des problème dans des logiciels tiers pour avoir une infrastructure de test.
[^] # Re: Oui
Posté par Kaane . Évalué à 10.
Et si tu te débrouille bien, tu fais mumuse sur la couche 3 et au dessus, et tu fous toutes tes VMs dans un seul hyperviseur dédié au test sur un réseau purement interne à l'hyperviseur (donc aucun paquet risque de partir). Tu fais planter que ta VMs, et au pire du pire du pire, tu fait juste planter l'hyperviseur.
Et au final tu n'as pas testé ce que tu voulais tester.
Tester la résistance de la couche simulation réseau d'un hyperviseur c'est bien, mais c'est la couche OpenBSD native que tu veux tester. Dans le genre de tests que tu préconises il est impossible de savoir si c'est OpenBSD qui est en défaut ou si c'est l'émulation.
Le seul truc où les Vms ne conviennent pas c'est dans tout ce qui est gestion du matos.
Que ce soit au niveau des I/O, des latences, du comportement des paquets la version VM est très différente de la version hors VM. Bien entendu les deux sont compatibles l'une avec l'autre, mais même avec du matos dédié (c'est à dire que la VM a une exclusivité sur un port PCi et la carte réseau qui est branchée dessus) on a pas les mêmes comportement que ce soit au niveau TCP, réémissions de paquets, débit, mise en cache et j'en passe.
Mais j'ai comme un doute que openbsd a des machines avec chaque type de carte réseau, chaque type de carte mère
Pas chaque non, mais quand même franchement beaucoup, Théo a quasiment un exemplaire de chaque matériel supporté - ce qui veut dire qu'il peut construire une machine raisonnablement similaire si un bug critique est remonté. (Encore une autre raison de ne pas vouloir être hébergé ailleurs tiens.)
[^] # Re: Oui
Posté par cedric . Évalué à 1.
Ok, mais dans ce cas, si les seuls machines qui ont besoin d'etre allume 24h/24 sont pour ce genre de tests, pourquoi pas prendre des trucs genre ARM voir un ATOM qui consommeront une fraction de l'energie qu'il semble consommer.
[^] # Re: Oui
Posté par claudex . Évalué à 7.
Justement, ils veulent faire les tests sur les différentes architectures parce que les bugs n'apparaissent que sur certaines architectures.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui
Posté par Spack . Évalué à 5.
Eh oui, pas facile la vie d'un dev système.
[^] # Re: Oui
Posté par Zenitram (site web personnel) . Évalué à -3.
Je prend juste la phrase au vol, car elle me parait pertinente par rapport au problème du journal :
Dans ce cas, je ne vois pas pourquoi il doit demander que quelqu'un paye sa facture d'électricité d'un coup comme ça. Si il y a un bug critique remonté, celui qui a remonté le bug a un truc critique et donc peut payer la prestation, et le projet lisse alors les revenus sur l'année pour payer l'électricité, les salaires… Comme n'importe où ailleurs (c'est classique d'avoir des coûts fixes et de les lisser sur un certains nombre de contrats).
Sinon, c'est que ce n'est pas si critique que ça, et le matériel alors pas si utile que ça, autant l'arrêter et économiser l'éléctricité.
Autant je comprend les appels aux dons par des assos qui n'ont pas de "bug critique" (pour des assos "citoyennes", c'est difficile de montrer à des citoyens que ça impactera leur vie à long terme et la responsabilité est diluée), autant une entreprise qui a un bug critique sait le coût que c'est et c'est immédiat et j'avoue ne pas comprendre pourquoi il y a besoin de dons si ce projet technique a des bugs critiques. Le problème d'OpenBSD ne serait-il pas marketing et ne serait-ce pas ça qu'il faudrait changer? (Theo refuse de parler de déménagement, mais n'a pas parlé d'interdiction de remettre en cause son marketing ;-) )
[^] # Re: Oui
Posté par ZeroHeure . Évalué à 4.
Hum, si c'est un bug critique, il concerne (potentiellement) tout le monde.
Et puis avec ton système si le rapporteur du bug ne donne pas de sous on ne fait rien.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Oui
Posté par Zenitram (site web personnel) . Évalué à -2.
Non repéré avant par les autres, donc moins critique pour les autres.
Qui est "tout le monde"?
Ca ne me choque pas du tout. Chacun est libre, y compris de corriger gratos le bug sans avoir une seule manière de rentabiliser la chose à côté, mais après il ne faut pas venir se plaindre qu'on ne peut pas payer la facture d'électricité, c'est un choix.
Le libre n'est pas synonyme de correction gratos de bug, on a le choix.
[^] # Re: Oui
Posté par totof2000 . Évalué à 5.
Dans ce cas, OpenBSD aura du mal à tenir sa réputation d'OS sûr. Et dans ce cas, il n'a pas de valeur ajoutée par rapport aux autres OS. Ce serait un OS sur tant que les utilisateurs auraient les moyens de payer pour corriger les bugs qu'ils remontent. Et ça ne résoudrait pas les problèmes de tests en amont : OpenBSD a audité/réécrit pas mal de code, et les bugs ou failles qu'ils ont corrigées n'étaient pas des bugs/failles qu'on leur a remonté mais des trucs qu'ils ont trouvé eux-même. Sans matos pour tester, tu réduis l'efficacité de ces corrections.
[^] # Re: Oui
Posté par ZeroHeure . Évalué à 5.
The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography.
www.openbsd.org
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Oui
Posté par Kaane . Évalué à 6.
Non repéré avant par les autres, donc moins critique pour les autres.
La première personne qui rencontre un bug n'est pas forcément la seule affectée. Le fait qu'un paquet bizarre fasse planter une couche ou une sécurité chez une seule personne implique très souvent qu'en étudiant le bug à fond on puisse créer des exploits qui marcheront chez beaucoup de monde.
[^] # Re: Oui
Posté par briaeros007 . Évalué à 1.
enfin à t'écouter, théo c'est plus une maison qu'il a, c'est un hangar de 1500 m² avec 2 lignes 20 kv.
[^] # Re: Oui
Posté par Kaane . Évalué à 5.
Euh il suffit de voir si le paquet est arrivé au niveau de la VM ou pas …
Déjà non. Parce que une fois de plus le comportement d'un kernel dans un environnement VM n'est pas identique à celui d'un kernel (au niveau latence, I/O, cache, temps de réponse du pilote hardware); et ensuite même si s'était le cas il faut également vérifier que le paquet n'a pas été altéré ou dénaturé soit par le kernel hôte, soit par la couche émulation carte réseau, soit par le pilote virtualisé. C'est seulement en ayant vérifié tout cela que l'on peut commencer à se demander si oui ou non ce paquet présente un risque pour la machine. Comment s'assurer de tout ça ? En mettant des sondes. Problèmes : il faut maintenant s'assurer que les sondes n'altèrent pas et ne dénaturent pas le paquet réseau, qu'elles n'ont pas d'influence sur les I/O, le cache, le comportement du kernel hôte etc. Comment faire çà ? En mettant d'autres sondes qui … euh…
Le problème est exactement le même que celui du programme qui crashe systématiquement à l’exécution, sauf en mode debug ou il tourne comme une horloge.
enfin à t'écouter, théo c'est plus une maison qu'il a, c'est un hangar de 1500 m² avec 2 lignes 20 kv.
Je crois qu'il n'y a "que" 200 ou 300m² dédiés aux machines. Par contre 40kVA ca va être juste, déjà moi je fais sauter mes 36kVA parfois (en pur particulier hein).
[^] # Re: Oui
Posté par Misc (site web personnel) . Évalué à 6.
Ça se fait aussi. Le projet Mageia a son propre switch manageable dans le bout de rack alloué avec son petit range IP chez LO et on aurait pu demander plus si on avait besoin de plus. Le projet Fedora avait son propre cluster de build ARM dans un "rack" dans une université avant que ça parte dans un DC à phoenix. ( un truc fait maison du style http://blog.chris.tylers.info/uploads/IMAG0182a.jpg )
Quand à faire tomber les switchs, c'est pour ça qu'on a inventé les prises commandés par le réseau. Même si ça coute dans les 400€ sur amazon, ça reviens à être de l'infra comme le reste. Avec une console série style cyclades, tu peux même reflasher ton switch sans souci.
Ensuite, je veux bien reconnaitre que c'est plus rare de tomber sur des hébergeurs de ce genre, mais si 2 projets de distributions Linux arrivent à le faire, c'est que c'est pas non plus impossible. Donc je persiste sur le fait qu'il y a un choix de sécurité surtout, car le reste de ce que tu énonces me semblent être un faux problème.
[^] # Re: Oui
Posté par défense . Évalué à 7.
En fait la Fondation Free qui est, si je ne dis pas de bêtises, totalement indépendante de Free (mais toujours filiale d'Illiad).
Et elle héberge également des serveurs les miroirs proxad (Ubuntu, Debian, OpenSuse, sourceforge, mandriva, cygwin?, kernel? etc.), ainsi que des serveurs d'autres assos (l'April, OSM, VLC, dogmazic?, etc.)
[^] # Re: Oui
Posté par barmic . Évalué à 2.
Pour OpenBSD, c'est un projet qui édite tout de même OpenSSH et OpenSSL qui sont pas mal utilisée par toutes les distributions. Ça n'est pas anodin.
Ils en arriveront là, mais en dernier recours.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oui
Posté par Krunch (site web personnel) . Évalué à 10.
Ainsi qu'OpenVPN, OpenBIOS, OpenOffice, OpenJDK et OpenTTD.
Sinon en vrai, OpenSSH est développé par des gens d'OpenBSD mais le reste n'a rien à voir. Même si OpenSSL est utilisé dans OpenSSH et qu'OpenOffice a des fonctionnalités similaires à OpenBSD (pf).
Par contre, OpenSMTPD et OpenCVS sont liés à OpenBSD de la même manière qu'OpenSSH. Mais ils ne sont pas (encore?) fort utilisés par le reste du monde.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# par définition
Posté par Anonyme . Évalué à 10. Dernière modification le 19 janvier 2014 à 16:57.
parce que la licence choisie par le projet OpenBSD permet de l'utiliser sans contrepartie, tout simplement.
Si tu as un souci avec une licence, ne va pas taper sur les utilisateurs qui en respectent les règles, change de licence.
[^] # Re: par définition
Posté par Zenitram (site web personnel) . Évalué à -10.
Ca marche pareil pour la licence GPL (=tu ne dois rien à l'upstream dans les deux cas).
C'est de l'anti-BSD qui ne connait même pas de quoi il parle.
[^] # Re: par définition
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 19 janvier 2014 à 19:04.
En quoi est-ce que la personne à laquelle tu réponds a-t-il indiqué que le problème était spécifique à la licence BSD ? En quoi a-t-il sous-entendu que la GPL était différente sur ce point ?
[^] # Re: par définition
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 19 janvier 2014 à 19:13.
Parce qu'on est sur un site libriste et que généralement (99% du temps) c'est du discours de pro-copyleft?
Mais si c'est le 1% autre, je suis curieux de l'idée derrière le changement de licence (qui resterait dans l'idée de LinuxFr, donc libre).
Après, en effet, ça peut être du non libre… Et donc ma réactio nserait HS, je te l'accorde.
[^] # Re: par définition
Posté par navaati . Évalué à 6.
Heuuuuu, où est-ce qu'il a dit que c'était la BSD spécifiquement ? J'avais compris qu'y parlait des licences libres en général, mais bon…
[^] # Re: par définition
Posté par totof2000 . Évalué à 7.
Excuse-moi de te dire ça comme ça, mais là ta réaction est stupide, et tu passes pour un idiot. Va faire un tout sur fr.comp.os.bsd, regarde les intervenants et tu comprendras pourquoi.
[^] # Re: par définition
Posté par anaseto . Évalué à 7.
Mais ce qui devrait compter pour une entreprise ce n'est pas vraiment la licence mais la main d'œuvre pas chère derrière : si les gens d'OpenBSD devaient arrêter leurs machines et arrêter leur travail, une entreprise qui dépendrait fortement des logiciels fait par les gens d'OpenBSD, voire utiliserait carrément OpenBSD, si elle ne veut rien perdre à l'histoire, elle va se retrouver à devoir changer son infrastructure vers un autre OS si elle l'utilise, ou en tous cas au moins va devoir chercher un moyen de s'assurer qu'openssh, pf, etc.. qu'elle utilise continuent à être maintenus avec la même qualité d'audit et de test.
Au final ça va être plus cher que de donner quelques milliers d'euros à des gens qui visiblement se satisfont d'un minimum pour continuer à travailler. Pour une grande entreprise ça ne représente vraiment rien comme somme, et c'est beaucoup plus rentable que de payer des développeurs pour faire ce même travail, avec probablement en plus un moins bon résultat. S'ils en arrivaient à ne pas pouvoir payer leur électricité (ça m'étonnerait un peu quand même), il y aurait sans doute plus d'une entreprise qui aurait une mauvaise surprise.
Donc oui, se plaindre que les entreprises ne donnent rien (même si elles ne sont pas obligées), du moins jusqu'à ce qu'il semble que ce soit vital pour que leur négoce n'en prenne pas un coup stupidement, n'est peut-être pas justifié par la licence, mais quand même un peu par le bon sens.
[^] # Re: par définition
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Reste à savoir si une telle entreprise existe. Qu'il y ait des entreprises utilisant OpenBSD, ne fait aucun doute. Qu'il y ait des entreprises utilisant du code issue d'OpenBSD également. Qu'il y ait des entreprises dépendant fortement d'OpenBSD au même titre que Canonical dépend de Debian ou Netasq de FreeBSD c'est moins certain.
Le fait d'utiliser OpenBSD sur un parc de serveur, ou encore d'avoir piqué du code a un instant t pour répondre à un problème particulier ne fait pas la dépendance.
[^] # Re: par définition
Posté par Krunch (site web personnel) . Évalué à 8.
Est-ce que le fait d'utiliser OpenSSH compte ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: par définition
Posté par barmic . Évalué à 0.
et/ou OpenSSL ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: par définition
Posté par Krunch (site web personnel) . Évalué à 4. Dernière modification le 19 janvier 2014 à 23:28.
OpenSSH est principalement développé comme un composant d'OpenBSD. OpenSSL est un projet indépendant dont les développeurs ne sont pas affiliés à OpenBSD (que je sache).
Il me semble aussi qu'il existe plus d'alternatives viables à OpenSSL qu'à OpenSSH.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: par définition
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
OpenSSH est loin de représenter OpenBSD dans son ensemble. C'est un projet qui pourrait très bien survivre à OpenBSD ou être forker.
[^] # Re: par définition
Posté par gemegik . Évalué à 10.
… ou être intégré dans systemd
Zut, ne pas leur donner l'idée !
[^] # Re: par définition
Posté par totof2000 . Évalué à 4.
Il y a des fournisseurs de solutions de sécurité (firewall par exemple) clé en main qui se basent sur OpenBSD.
[^] # Re: par définition
Posté par thamieu . Évalué à 4.
Oui, la licence permet d'utiliser sans contrepartie, mais elle n'interdit pas toute forme de soutien pour autant. Je ne vois pas en quoi la licence constitue un frein au financement.
Où as-tu vu quelqu'un aller taper sur des utilisateurs ? Ça ressemble un peu à de la victimisation, ça…
[^] # Re: par définition
Posté par Anonyme . Évalué à 2.
je ne le dis pas
je cite Spack:
les utilisateurs sont les "compagnies qui trouvent un système d'exploitation fonctionnel et ce gratuitement" à qui Spack demande d'assumer un financement qui est volontairement non imposé par le contrat initial.
Le problème de Spack se situe sur le terrain de l'éthique, et les compagnies qui utilisent "un système d'exploitation fonctionnel et ce gratuitement" sans contrepartie aucune semblent avoir une éthique différente de la sienne. Si le projet OpenBSD avait voulu imposer une contrepartie financière à ces compagnies, il aurait choisit une autre licence.
Pour ce qui est de la victimisation, je n'ai pas compris le lien avec mon commentaire.
[^] # Re: par définition
Posté par thamieu . Évalué à 2.
Et alors, il est où le problème ? En s'interrogeant ainsi, Spack ne remet pas en cause le contrat initial, et ne parle pas de nouveau contrat.
Spack ne parle pas d'imposer de contrepartie à tous les utilisateurs d'OpenBSD. Il déplore qu'au regard des dépenses évitées par certains de ces utilisateurs, aucun n'ait décidé de contribuer aux charges du projet.
Tu écrivais que Spack allait « taper sur les utilisateurs qui [respectent les règles de la licence] », ce qui place Spack en position d'agresseur et les utilisateurs en position de victime.
[^] # Re: par définition
Posté par Spack . Évalué à 3.
Je n'aurais pas dit mieux moi même. On peut en effet s'interroger sur le côté éthique de la chose. Et je ne juge pas. Je lance simplement une interrogation. Un projet libre vie principalement de dons donc s'il permet à une entreprise d'économiser certains frais celle-ci pourrait être redevable en aidant ce dit projet.
Rien ne l'oblige dans le contrat c'est juste une façon de voir les choses. Si le projet est utile à l'entreprise, celle-ci peut l'aider à continuer.
# bazar/cathedral ...
Posté par briaeros007 . Évalué à 5.
Vu le nombre de personne qui font tourner du bitcoin, du seti@home, amha il y a la possibilité de demaner aux gens d'hébeger une partie de l'infra.
Certes les latences serait importances, mais tout serait répartie et redondée (et chiffrée bien sur).
On arrête pas de ressaser "cloud par ci, cloud par là". Ca serait justement une super démonstration du fonctionnement , et donc non seulement tu résouds ton problème de serveurs (avec un boulot considérable de mise en place, je l'accorde), mais tu te fais une superbe pub.
Par contre, OpenBSD ne souhaite ne pas changer de modèle même si ils ont un problème avec ce modèle.
J'ai envie de dire "tant pis".
De plus supposons que certains veulent donner :
Ca va vachement pousser les gens à aider
"J'ai besoin d'aide, mais j'ai pas envie de vous filer les infos pour pousser le bébé. Il faut me les demander uniquement à moi".
Pour avoir participer das des groupes (qui n'ont rien à voir avec les LL mais qui dépendent des serveurs), je sais que les dons ne contribuent que peux aux serveurs (de tête dans notre cas ça contribuait même pas pour le quart d'un kimsufi).
[^] # Re: bazar/cathedral ...
Posté par claudex . Évalué à 10.
Ça pose un énorme problème dès qu'il faut intervenir physiquement sur les serveurs, il faut courir aux quatre coins du monde pour faire le tour des machines. Il faut aussi s'attendre à des pannes du genre « oups, j'ai débranché, j'en avais besoin pour aspirer » et « oups, j'ai eu une surtension, tout a cramé » ou encore « je déménage, merci de récupérer les serveurs demain sinon je les jette ». Et sans compter la confiance qu'il faut accorder aux gens pour ne pas qu'ils partent avec l'infra.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bazar/cathedral ...
Posté par briaeros007 . Évalué à -1.
d'où l'idée de faire un cloud chiffrée.
La personne prête du temps cpu, stockage et mémoire. Si elle part, éteint son serveur , c'est suffisament redondée pour qu'il n'y a pas de perte. Au pire tu as perdu la tache qui était en train de tourner et elle se relance autre part.
C'est un peu comme un darknet sur internet, sauf que là c'est avec des machines :)
[^] # Re: bazar/cathedral ...
Posté par claudex . Évalué à 8.
Tu as beaucoup de temps CPU Vax, Alpha, Loogsoon… à prêter ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bazar/cathedral ...
Posté par briaeros007 . Évalué à 1.
J'aime ces approches constructives qui, plutôt que d'essayer de faire avancer une idée, cherche à tout pris tous les raisonnement pour ne pas avancer (mais ne propose rien à coté).
Est-ce impossible d'envisager une cross compile pour l'ensemble de tes environnements, et ne garder qu'une machine de chaque archi pour faire tourner les tests de non régressions en batch ?
Est-ce impossible d'envisager que ceux qui utilisent openbsd contribue à minima?
Et si une archi n'est plus utilisée, ben désolé, mais ça sert à rien de faire survivre un truc qui n'est pas utilisé (dis autrement, si elle est utilisée, il faut que les gens qui l'utilise assument aussi)
Moi j'utilise pas openbsd mais je serais prêt à prêter de mon temps CPU, même ARM si ça les amusent (j'ai un soc marvell qui me sert de serveur d'infra) car j'estime qu'openbsd est un projet sympa.
Mais bon c'est sur que si il faut essayer de voir que les cotés négatifs et pas voir comment on pourrait travailler autour, je comprend mieux pourquoi le monsieur veut bien qu'on lui paie tout, mais surtout pas jouer la transparence.
[^] # Re: bazar/cathedral ...
Posté par claudex . Évalué à 6.
Il faut voir mais j'en doute. Déjà, il faut au moins deux machines (une émettrice et une réceptrice) si tu fais des tests réseaux.
Il y a l'explication dans le journal et dans plusieurs commentaires. Les architectures différentes permettent de, parfois, mettre en évidence des bugs qui apparaissent partout mais de manière moins visible. Par exemple, un truc qui crash à chaque fois sur Vax mais seulement une fois sur cent sur i386.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bazar/cathedral ...
Posté par briaeros007 . Évalué à 0.
J'ai pas dis de ne pas developper/tester sur d'autres archis. J'ai du que ceux qui utilisaient les autres archis contribuaient pour ces archis.
Et si c'est vraiment de la détection de bug, amha on a plus vite fait d'étudier une archi vraiment exotique même si très peu puissante, car on aura beaucoup plus de chance de trouver des bugs comme ça. Et de proposer cette archi aux autres distrib linux (hence, des sous en plus:) )
[^] # Re: bazar/cathedral ...
Posté par Krunch (site web personnel) . Évalué à 2.
Ça s'appelle ds9k: http://dspace.dial.pipex.com/town/green/gfd34/art/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: bazar/cathedral ...
Posté par Krunch (site web personnel) . Évalué à 4.
Ce genre d'approche ne fonctionne que tant que tu fais des trucs limite purement applicatifs. Dès que tu dois faire des truc plus « système » (genre tests réseaux décrits ailleurs dans ces commentaires, tests de support de matériel ou même tests de performance) ça marche moins bien. J'ai travaillé sur une infrastructure de test pour un produit ayant un composant kernel de stockage et, bien que le cloud servait, on était content d'avoir deux racks de machines sur lesquelles on avait un accès physique facilement.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: bazar/cathedral ...
Posté par briaeros007 . Évalué à -3.
J'ai répondu au dessus :)
Les tests réseaux marchent très très bien en VMs.
Les tests de support matériels marchent moins bien, mais comme j'ai écris au dessus : je crois pas que theo ait un exemplaire de chaque carte réseau qui sera utilisée par openbsd …
pour les perfs, ça dépend ce que tu cherches. Si c'est pour valider une optimisation , une architecture virtualisée peut tout à faire convenir. Si c'est pour tester un système au limite effectivement ca ne sert à rien la virtu (overhead toussa). Mais ça ne sert à rien de le faire au niveau OS en avance de phase sur une plateforme qui n'a rien à voir, vu qu'il faut le faire sur la plateforme qui va héberger l'application nécessitant la charge (il y a tellement de paramètres qui rentrent en jeux).
[^] # Re: bazar/cathedral ...
Posté par Krunch (site web personnel) . Évalué à 7. Dernière modification le 20 janvier 2014 à 00:22.
Tant que tu veux pas tester l'interaction entre le driver et le hardware, certainement. Et tant que ton test ne fait pas planter le driver de l'hyperviseur (dont tu n'as pas le contrôle et que tu n'as pas l'intention de tester/débugguer).
Si tu as la garantie que la charge sur l'hyperviseur et les autres VMs avec lesquelles tu partages le matériel reste constante (et que le matériel lui même reste constant), effectivement. Il me semble qu'il y a des services de nuage qui permettent de réserver toute une machine physique pour une VM mais c'est pas le plus courant.
Au final, dans une VM, il y a du code (généralement noyau) qui ne peut pas vraiment être exercé par rapport à sur du vrai hardware. Ou s'il peut théoriquement l'être (fullvirt avec l'émulation de tous les composants matériel), il y a des scénarios qui vont être virtuellement (haha) impossibles à reproduire (nécessités de concurrence forte, bugs de firmware/hardware inconnus ou mal compris dont on veut quand même découvrir l'existence pour pouvoir les contourner,…).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: bazar/cathedral ...
Posté par briaeros007 . Évalué à 1.
je ne dis pas que tout peux être géré par les VMs et que le nuage c'est bon.
Par contre, j'émets des doutes sur le fait que plus de 50% des couts et de l'utilisation de l'infra ne puisse pas être supportée par du "nuage".
Et je ne parle pas du gain en sous sous, popularité et donc utilisation (donc rapport de bug, utilisation sur une plus grande variété de matériel, donation, …) si une telle solution était adoptée.
[^] # Re: bazar/cathedral ...
Posté par Zenitram (site web personnel) . Évalué à 2.
Question curieuse : quel gain par rapport à un KVM (clavier/écran/souris, pas la virtualisation) + reboot IP branché sur un réseau complètement séparé (le KVM/Reboot sur l'accès distant sur le réseau de l'hebergeur, le réseau des machines de test sur un switch ou routeur en circuit fermé où du moins sur un autre réseau que celui du KVM/Reboot)?
A part évidement si tu dois bidouiller le matos (mais il me semble que c'est rare de jouer avec du branchement à chaud), la je vois.
[^] # Re: bazar/cathedral ...
Posté par Krunch (site web personnel) . Évalué à 4.
Dans mon cas, il y avait du bidouillage de matos. Principalement des changements de disques pour faire des tests de perf sur différents modèles et pour tester le remplacement à chaud. Même si c'était aussi partiellement virtualisable. Il y avait aussi une petite partie « graphique » qui ne se comportait pas pareil sur la console série et sur la « vraie » console (mais effectivement, avec un bon KVM ça devait pouvoir être contournable).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: bazar/cathedral ...
Posté par vincent LECOQ (site web personnel) . Évalué à 3.
Si l'idée leur prends de faire une vm qui leur permettrait de construire un cloud sécurisé et redondant, j'heberge de suite un noeud sur mon pitit dédié
[^] # Re: bazar/cathedral ...
Posté par fravashyo . Évalué à 10.
oui mais non, apparemment les charges en électricité sont aussi parce qu'ils testent leur OS sur quantité d'architecture (ce qui permet de soulever des bogues, comme expliqué dans le journal) :
http://www.openbsd.org/plat.html
Donc un don en serveur, en espace ne sera pas suffisant. Je ne pense pas s'il y ait beaucoup de VAX en service chez Amazon ou Kimsufi.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: bazar/cathedral ...
Posté par Le Gab . Évalué à 2.
Et qui auraient une utilité à notre époque?
L'argument de portabilité aidant à la solidité du code ne justifie plus vraiment cette dépendance et dépense d'énergie.
Et puis, un code qui compile et testé sur VAX ou Motorola 881x0 ne veut pas dire qu'il ne se pétera pas la gueule en situation "stress" sur une autre plate-forme. Enfin, la page montre que l'abandon d'une plate-forme n'est pas une chose non-envisageable.
Il ne s'agit pas de limiter sa résistance au changement mais de faire les choses mieux.
Je respecte le projet OpenBSD, j'admire leur ténacité et leur rigueur mais moins leur entêtement et la grosse dépendance à De Raadt.
Évidemment, ce serait triste voire pathétique si ils n'arrivaient pas à couvrir leurs frais en électricité.
[^] # Re: bazar/cathedral ...
Posté par anaseto . Évalué à 4.
C'est plutôt le contraire qui est intéressant : il se peut qu'un certain bug peut être détecté plus facilement sur une certaine plateforme tout en étant quand même réel dans d'autres, et que tester sur les certaines vieilles architectures aide donc à découvrir de vrais bugs qui se manifestent sur les architectures courantes.
Je pense que pour eux arrêter ce travail de test est justement faire les choses moins bien, et que c'est d'ailleurs un des points caractéristiques du projet.
Si les opinions de De Raadt concernant ce problème n'étaient pas partagés par la plupart des développeurs ça se verrait sur la liste de diffusion, et ce n'est pas le cas visiblement.
Il ne faut pas s'étonner qu'OpenBSD suive un chemin plus à son rythme, et avec des objectifs un peu spéciaux : ils n'ont justement pas d'entreprise derrière qui les incite à telle ou telle fonctionnalité, et si c'est leur problème justement maintenant, c'est aussi peut-être ce qui fait son intérêt, et leur permet une certaine liberté quand à ce qu'ils considèrent comme des priorités.
[^] # Re: bazar/cathedral ...
Posté par barmic . Évalué à 5.
Je doute, vu les faibles moyens financiers et humains du projet qu'ils fassent ça uniquement parce que ça fait joli sur la page d'accueil du projet de dire que ça fonctionne sur VAX.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: bazar/cathedral ...
Posté par Tonton Th (Mastodon) . Évalué à 8.
C'est assez impressionnant à voir en vrai aussi…
[^] # Re: bazar/cathedral ...
Posté par Thom (site web personnel) . Évalué à 3.
Le bordel, on dirait une brocante !
Ça doit être dur de s'y retrouver…
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: bazar/cathedral ...
Posté par Tonton Th (Mastodon) . Évalué à 4.
Non, en fait. Il utilise un système sophistiqué à base de Maroilles pour pouvoir revenir de façon fiable à la cuisine.
[^] # Re: bazar/cathedral ...
Posté par totof2000 . Évalué à 2. Dernière modification le 20 janvier 2014 à 16:11.
Joli musée !!!
J'aurais du lui envoyer ma SS4, mes SPARC IPX, mes ultra1 et mes Ultra5 plutôt que de les balancer …. Le problème, c'est que ça coute cher en frais de port (c'est lourd ces engins …).
[^] # Re: bazar/cathedral ...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Quand ça l’intéresse, il se déplace.
[^] # Re: bazar/cathedral ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il me semble que le build de Debian tourne déjà (en partie) sur un cluster Amazon…
[^] # Re: bazar/cathedral ...
Posté par Krunch (site web personnel) . Évalué à 4.
"Non, c'est juste pour les expériences"
https://linuxfr.org/news/llvm-3-4-et-clang-3-4#comment-1513877
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Principe du don
Posté par Khaos (site web personnel) . Évalué à -9.
J'avoue ne pas bien comprendre le point soulevé par ce journal.
Un projet Open Source reçoit énormément de dons. C'est même comme ça qu'il vit.
Et le don le plus important ce n'est pas l'argent mais les compétences des devs déjà.
Il faudrait donc que les sociétés, sous prétexte qu'elles sont des sociétés et donc gagnent de l'argent, payent pour profiter du don des autres ?
Vous imaginez un peu la même chose pour les restos du coeur ? Tout le monde donne de la nourriture mais il faudrait payer pour la manger ? (Bon j'avoue je n'y connais rien à leur organisation mais je ne crois pas que les bénéficiaires doivent payer)
Dans ce cas autant directement faire payer l'accès au code si l'on considère que l'utiliser gratuitement c'est "mal"
Personne n'est TENU de participer en quoi que ce soit, c'est en partie le principe du libre.
[^] # Re: Principe du don
Posté par Zylabon . Évalué à 8.
Certes, au demeurant, je comprend qu'ils l'aient mauvaise. Sony et Apple se gavent en grande partie grâce à leur code pendant qu'ils sont en train de calculer s'il ne devraient pas éteindre telle machine parce que tout le monde se fous de cette architecture et que que ça consomme un max.
Après, ya pas un problème du coté du "B" de BSD ?
Please do not feed the trolls
[^] # Re: Principe du don
Posté par briaeros007 . Évalué à 0.
z'avaient qu'a faire du gpl.
Poussez pas --> [|]
[^] # Re: Principe du don
Posté par barmic . Évalué à 4.
Et maintenant si tu lisais avant de commenter ? Il ne reproche rien à personne. Il dit qu'ils n'ont plus les moyens de financer l'électricité de leurs serveurs et il demande si une entreprise ne veut pas leur payer l'électricité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Principe du don
Posté par Khaos (site web personnel) . Évalué à 2.
Si, si, j'ai bien tout lu.
Le dernier paragraphe est plutôt clair je trouve. Il ne demande pas si une entreprise veut payer, il cherche à culpabiliser les entreprises qui utilisent OpenBSD sans contrepartie.
En tous cas c'est comme ça que je le comprends (d'où ma réaction), mais peut-être que j’interprète mal le terme "vache à lait"
Je trouve juste triste que l'on transforme le principe du don en culpabilisation de celui qui reçoit.
[^] # Re: Principe du don
Posté par barmic . Évalué à 6.
Ce que Spack dis on s'en fout. De Raadt ne reproche rien à personne (en tout cas dans son message de demande d'aide). Donc expliquer que si ça leur va pas, ils ont cas faire payer l'accès au code source, ben c'est une remarque adressée aux développeurs d'OpenBSD qui s'appuie sur une remarque qu'ils n'ont jamais faite.
Je note bien que le journal est larmoyant et qu'il est en décalage avec la communication du projet, mais ça ne t'interdit pas de lire la source de ce dernier.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Principe du don
Posté par Khaos (site web personnel) . Évalué à 0.
Je comprends mieux le moinssage de mon premier commentaire du coup.
Effectivement je commente les propos du journal et non de la source. (Comme l'indiquait ma première phrase)
Il ne me viendrait jamais à l'idée de dire quoi faire aux gens de chez OpenBSD.
Mes confuses à ceux qui l'ont cru.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.