Cette version 4.2 est dédiée à la mémoire du développeur Jun-ichiro "itojun" Itoh Hagino qui est mort le 29 octobre. Itojun est l'auteur de la pile IPv6 des systèmes d'exploitation de type BSD. Parmi les nouveautés, citons :
- Le passage à Xenocara (c'est le nom qu'utilise OpenBSD pour parler du projet X.org modulaire) qui est basé sur X.Org 7.2 et ajoute de nombreux correctifs.
- Cette nouvelle version 4.2 se caractérise avant tout par une grosse amélioration des performances réseau. Selon Henning Brauer on passe ainsi de 29 à 58 MBit/s sur une machine Soekris 4801. Cette performance accrue de la pile réseau est sensible surtout lors de l'utilisation du firewall pf. Ainsi OpenBSD 4.2 essaye le plus possible d'éviter de faire appel à malloc pour router les paquets ce qui améliore les performances de 100%. L'utilisation des routines IPSEC se fait à meilleur escient ce qui entraîne une nouvelle amélioration de 5%. Enfin la vérification des paquets (checksumming) ne s'effectue que lorsque c'est nécessaire et on gagne encore 10%.
- Amélioration des performances sur i386 et amd64, due à la réécriture du TLB shootdown.
- Support des disques et partitions de plus de 1 To (avec une limite provisoire à 2 To pour les partitions).
- Support de FFS2 qui autorise les attributs étendus et utilise des pointeurs de 64 bits.
- Ajout du Load Balancing IP dans CARP
- Améliorations de pkg_add qui est maintenant plus robuste et peut gérer sainement beaucoup plus de scénarios différents lors des mises à jour.
Cette version d'OpenBSD propose également un grand nombre de pilotes parmi lesquels on peut citer :
- Support natif du Serial-ATA (ahci, jmb, sili)
- Nouveau driver réseau pour carte Ethernet 10Gb Tehuti Networks
- Support des variations de fréquence et de voltage pour les machines multiprocesseurs i386 ou AMD64
- Meilleur support des machines de type Xserve G4
- Support des puces Intel i965GM
Comme toujours OpenBSD reste attentif aux architectures non-x86 et améliore le support des plates-formes :
- sparc64 (avec notamment le support de UltraSparc IIIi en PCIe).
- alpha (AlphaServer 1200 et AlphaServer 4100).
- hppa
Le système de ports d'OpenBSD propose plus de 4,500 ports dont :
- GNOME 2.18.
- GNUstep 1.14.
- KDE 3.5.7 et koffice 1.6.3.
- Xfce 4.4.1.
- Open Motif 2.3.0.
- OpenOffice.org 2.2.1.
- Mozilla Firefox 2.0.0.6.
- PostgreSQL 8.2.4.
- GHC 6.6.1 (amd64 et i386 seulement).
Les principaux outils d'OpenBSD ont également été améliorés (OpenBGPD, OpenNTPD, OpenOSPF, hoststated, OpenSSH).
Rappelons que le projet est développé par des volontaires, et qu'il est financé par la vente de T-shirts, de posters et de CD. Si vous utilisez régulièrement OpenBSD n'oubliez pas de soutenir son développement.
Enfin, comme pour chaque nouvelle version, une chanson originale a été écrite et est disponible. Intitulée "100001 1010101" elle appelle au partage libre des bits.
Une interview très intéressante de nombreux développeurs OpenBSD est disponible sur le site d'ONLamp.
PS : Cette dépêche a été initiée par Chl. Comme il est actuellement en congés la dépêche est publiée par une autre personne que l'auteur initial.
Aller plus loin
- OpenBSD (3 clics)
- Les nouveautés de la version 4.2 (1 clic)
- La liste complète des changement (2 clics)
- Le journal des news OpenBSD (0 clic)
- Une longue interview des développeurs sur OpenBSD 4.2 (1 clic)
# Chanson
Posté par Aardvark . Évalué à 7.
[^] # Re: Chanson
Posté par Nicolas Legrand (site web personnel) . Évalué à 7.
[^] # Re: Chanson
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Simple et beau, bon c'est pas vraiment les termes qui me viennent à l'esprit quand j'y pense.
Installer le système sans la documentation à coté, ça me semble relever de l'exploit (pour quelqu'un qui ne connais pas j'entends). Par contre la documentation est très bien faite.
Bon pour une utilisation bureautique, ça m'a pas l'air d'être encore ça.
Est-ce qu'il y a un système genre HAL dans les *BSD pour les branchement à chaud?
[^] # Re: Chanson
Posté par Antoine . Évalué à 3.
/sbin/reboot ?
[^] # Re: Chanson
Posté par zul (site web personnel) . Évalué à 4.
Sous NetBSD, ca a été l'objet d'un SoC http://netbsd-soc.sourceforge.net/projects/hal/ qui devrait être intégré dans NetBSD 5 ( oui I know NetBSD 4 n'est pas encore sorti).
Pour OpenBSD, il me semble qu'il existe quelquechose mais je ne me rappelle plus le nom.
De toute facon, le kernel gere une bonne partie du plug n play. Il n'y a donc pas besoin de reboot. hal permet surtout à l'userland de faire des actions lorsqu'il détecte ce genre de chose.
[^] # Re: Chanson
Posté par Thomas . Évalué à 2.
Cohérent plutôt. Et pour beau, c'est une beauté pour hackers, elle n'est pas visuelle.
Bon pour une utilisation bureautique, ça m'a pas l'air d'être encore ça.
C'est pas vraiment le but de l'OS non plus.
Par contre pour un firewall par exemple, c'est vraiment *vraiment* agréable.
[^] # Re: Chanson
Posté par Nicolas Legrand (site web personnel) . Évalué à 5.
Après le point de vue des types est simple : ils ne s'adressent pas à des débutants, ne cherchent pas à être les plus populaires, ni les premiers à implémenter un truc. Si on connaît UNIX, qu'on trouve normal de lire la documentation, OpenBSD est un vrai plaisir.
C'est avant tout en lisant la doc et en voyant comment ils conçoivent leur système et avec quelle philosophie que l'on voit l'intérêt du système. Peut-être que certains croient que c'est un système de barbu qui passent leur temps à compiler, leur philosophie au contraire et de faire des binaires qui fonctionneront sur un maximum de machine et que l'utilisateur n'ait pas à compiler son système. Le code doit rester simple ainsi que les outils.
Par exemple pour configurer le WiFi, on n'utilise que ifconfig(8) et pas des iwconfig, wlanconfig etc... Alors effectivement y a pas encore de support du WPA dans le kernel (il faut aussi comrpendre que les dev préfèrent utiliser d'autres méthodes d'encryption et d'authentification genre IPSec, du authpf que des trucs comme WPA, 802.1x, EAP-TTLS...), mais quand il sera là, je suis sûr que ça sera simple et beau. Moi je ne suis pas pressé, rien ne sert de courir, il faut arriver à point (tout le thème de la chanson de la 4.2 !).
Je ne regrette même pas aptitude et APT quand j'utilise les outils de mis à jour du système et des packages, alors que j'en prends en intraveineuse depuis des années (et que je continuerai d'ailleurs).
Je trouve aussi que c'est le système le plus innovant. OK, c'est pas un système qui vous permettra d'installer la dernière alpha de firefox deux jours avant sa sortie, mais beaucoup de leurs projets repris ailleurs méritent le détour, les plus connus étant OpenSSH, PF, CARP.
Voili voilou, moi je trouve que c'est un système bien pour tout, il est énormément développé sur portable donc du coup y a un bon support. Ce qui est agréable c'est qu'il s'éteind vite et s'allume vite, qu'il ne lance pas dhclient si la machine n'est pas branché, bref c'est cool, tout ça avec un vieil init BSD simple, tellement simple.
Alors après si ça vous dit rien n'utilisez pas :-), moi j'adore.
[^] # Re: Chanson
Posté par psychoslave__ (site web personnel) . Évalué à 2.
C'est vraiment la fonctionnalité dont je ne pourrais plus me passer, entre les clefs usb et les disques usb, pour une utilisation en bureautique, je trouve ça vraiment important.
[^] # Re: Chanson
Posté par Psychofox (Mastodon) . Évalué à 1.
Bref tu devras lâcher la souris de temps en temps...
[^] # Re: Chanson
Posté par ErrTu . Évalué à 1.
Il y aussi amd(8) pour monter automatiquement et de façon transparente un volume. Par exemple : "cd /le/point/de/montage" et le tour est joué.
# Architectures supportées
Posté par Pierre Jarillon (site web personnel) . Évalué à -4.
Mon seul regret, c'est que BSD ne soit pas sous licence GPL, OpenBSD aurait eu plus de contributeurs et de succès... C'est le fond de ma pensée, mais ne tombez pas dans le troll plus que nécessaire !
[^] # Re: Architectures supportées - le pied dedans
Posté par nicodache . Évalué à 10.
Et puis, la licence BSD est quand même reconnue libre par la FSF (http://www.fsf.org/licensing/licenses/index_html#OriginalBSD(...) et donc le soucis des contributeurs n'est pas du à la licence, mais au niveau exigé par OpenBSD, et le manque d'intérêt. ou p'tet autre chose.
c'est vendredi, j'ai marché dedans toussa, rien à foutre, déchainez-vous sur mon cadavre ;)
[^] # Re: Architectures supportées - le pied dedans
Posté par IsNotGood . Évalué à -1.
Beaucoup de développeurs n'aiment pas la BSD. Ils veulent avoir la garantit que ce qui est libre reste libre (soucis permanent de la GPL/FSF). La licence est un soucis.
Il ne faut pas "diaboliser" les licences BSD, mais il faut reconnaitre que ça ne plait pas à beaucoup.
Le succès de GNU/Linux s'explique en parti par une forte utilisation de la licence GPL ou équivalent (licence copyleft).
> déchainez-vous sur mon cadavre ;)
Je prend le cerveau car j'ai un petit appétit.
[^] # Re: Architectures supportées - le pied dedans
Posté par Psychofox (Mastodon) . Évalué à 4.
Avec des arguments comme ça on peut tourner autour du pot longtemps. Vu la quantité de licences libres existantes, on peut facilement en déduire que ces 2 licences ne remportent de loin pas tous les suffrages.
A vrai dire, je ne crois pas que ça ait un quelconque rapport avec la licence, mais plus un question d'image et de buts.
[^] # Re: Architectures supportées - le pied dedans
Posté par IsNotGood . Évalué à 4.
> Avec des arguments comme ça
Il faut être un brin honnète. La GPL est la licence la plus utilisé dans le libre. Ce n'est pas pour rien. Elle a des exigences explicites. Les développeurs la prennent en connaissance. Donc, en moyenne, un projet sous GPL trouvera plus facilement des développeurs qu'un projet sous BSD.
> Vu la quantité de licences libres existantes, on peut facilement en déduire que ces 2 licences ne remportent de loin pas tous les suffrages.
Ben la (L)GPL dépasse les 50 % et de loins dans une distribution Linux.
Démonstration avec FC6 (core+extra) :
[admin@one rsync]$ repoquery --queryformat "%{LICENSE}\n" -a | egrep -v "^$" | grep -i gpl | wc
5702 7437 37168
[admin@one rsync]$ repoquery --queryformat "%{LICENSE}\n" -a | egrep -v "^$" | grep -i -v gpl | wc
1938 3132 22317
[admin@one rsync]$
GPL : 5702 (74,6 %)
non-GPL : 1938 (25,4 %)
> mais plus un question d'image et de buts.
Mais oui...
[^] # Re: Architectures supportées - le pied dedans
Posté par IsNotGood . Évalué à 0.
[^] # Re: Architectures supportées - le pied dedans
Posté par Anonyme . Évalué à 3.
Ensuite, concernant le manque de développeurs chez OpenBSD, je ne pense pas du tout que ce soit dû à la licence. Chez FreeBSD, ils n'ont pas ce problème.
Concernant la GPL, elle est à la mode, en même temps que les GNU/Linux. Le vent changera peut-être dans quelques temps :-)
Après, on ne vas pas troller sur BSD/GPL. Les deux licences ont clairement leurs avantages et leurs défauts. J'ai une préférence pour la licence BSD (la "vraie" licence dite "libre" à mes yeux, dans le sens où l'on fait ce que l'on veut), mais la GPL a quand même l'énorme avantage de faire vivre le libre (dans le sens où chaque modification est réinjectée en GPL).
Ce sont juste deux philosophies différentes, et je ne crois pas que ce soit la licence BSD la cause du manque de développeurs chez OpenBSD.
[^] # Re: Architectures supportées - le pied dedans
Posté par IsNotGood . Évalué à 3.
Et ?
Fedora c'est 4 architectures supporté : ppc, ppc64, i386, x86_64.
Mais si tu veux pleins d'architecture, regarde du côté de Debian ou Gentoo. Et que ça soit ces deux dernières ne change pratiquement rien aux "stats" que j'ai donné.
> Concernant la GPL, elle est à la mode
Elle est à la mode depuis plus 15 ans...
Ce n'est plus une mode dans ce cas.
[^] # Re: Architectures supportées - le pied dedans
Posté par Gniarf . Évalué à 4.
(c'est vendredi, c'est permis)
[^] # Re: Architectures supportées - le pied dedans
Posté par IsNotGood . Évalué à -1.
J'ai hésité entre 3 et 4. Mais i386 et x86_64 c'est bien différent. Voir comme *BSD, ou Debian qui ont mis du temps pour supporter x86_64.
Enfin, ça dépend ce que tu mets dans architectures. PS3 c'est une architecture différente ? Linux sur PS3 c'est principalement une Fedora.
Les iMac pour i386 c'est une architecture différente ? Fedora le supporte (+1 :-)).
Fedora peut tourner sur les IBM System Z (de façon chaotique, OK, +0,5).
Fedora c'est aussi la base de OLPC (+0,5).
Etc.
[^] # Re: Architectures supportées - le pied dedans
Posté par Jérôme Pinot (site web personnel) . Évalué à 3.
C'est tellement différent que le futur kernel 2.6.24 ne proposera qu'une seule et unique architecture x86 à la place des i386 et x86_64 actuels...
[^] # Re: Architectures supportées - le pied dedans
Posté par rewind (Mastodon) . Évalué à 4.
De plus, OpenBSD n'utilise pas la BSD original, mais une dérivée, la licence ISC [2].
[1] http://dwheeler.com/essays/gpl-compatible.html
[2] http://en.wikipedia.org/wiki/ISC_license
[^] # Re: Architectures supportées - le pied dedans
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
J'aurais plutôt dit que la FSF la considère comme compatible avec la
GPL... Ça serait tout de même trop fort qu'elle puisse oser la
considérer comme non libre !
[^] # Re: Architectures supportées
Posté par beagf (site web personnel) . Évalué à 10.
Moi je les remercie d'utiliser la licence BSD vu que je la préfère à la GPL. C'est une question de gouts, il en faut pour tout le monde. Comme on dit : "Tous les degouts sont dans la nature..."
[^] # Re: Architectures supportées
Posté par ouah (site web personnel) . Évalué à 2.
[^] # Re: Architectures supportées
Posté par Aardvark . Évalué à 1.
[^] # Re: Architectures supportées
Posté par JoeBlack . Évalué à 2.
[^] # Re: Architectures supportées
Posté par psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: Architectures supportées
Posté par Troy McClure (site web personnel) . Évalué à 4.
Pas tout a fait quand même:
http://en.wikipedia.org/wiki/Windows_CE
It is supported on Intel x86 and compatibles, MIPS, ARM, and Hitachi SuperH processors.
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 9.
Comparé Windows, OpenBSD au noyau linux, ce n'est pas très "juste". Le noyau Linux supporte peut-etre plus de plateforme (et encore y'a beaucoup de branches // pour mips et arms pour avoir un support décent) mais quand il s'agit d'une distrib complete, c'est beaucoup moins impressions.
My 2 cts.
Concernant le nombre de licence GPL vs BSD, il faudrait prendre en compte tous ces développeurs qui sont obligés d'utiliser la GPL parce qu'ils utilisent une lib GPL. Forcement avec des choses contaminantes (splashh), on obtient de plus gros résultats.
Les contributions aux projets communautaires sous licence BSD ne disparaitront jamais. Alors arretez d'être de mauvaise foi. Le code ne disparait pas comme ca. Et si il est réutilisé dans un logiciel propriétaire, je préfère de loin qu'il utilise un truc "standard" qu'un truc sale codé par eux et qui ne marchera que pour eux. Si la première pile TCP avait été sous GPL, je préfère pas voir l'état de l'Internet aujourd'hui :).
My 4 cts.
[^] # Re: Architectures supportées
Posté par IsNotGood . Évalué à -4.
Sachant que GNU/Linux est un système complet et "au top", c'est impressionnant. GNU/Linux est de loins le meilleur. Dans la catégorie "je sacrifie tout pour être un maximum portable", GNU/Linux n'est pas le meilleur.
> il faudrait prendre en compte tous ces développeurs qui sont obligés d'utiliser la GPL parce qu'ils utilisent une lib GPL.
C'est très marginal. Le cas le plus notoire est Qt. Mais Qt est aussi dispo en version non GPL. Donc celui qui veut faire un programme sous BSD (par exemple) avec Qt le peut. S'il prend la licence GPL, il ne l'a pas fait car il y était obligé.
> Forcement avec des choses contaminantes
FUD Microsoftien.
> Les contributions aux projets communautaires sous licence BSD ne disparaitront jamais.
Effectivement, ça ne disparait jamais. Si on les a vu, ça ne disparait jamais. Mais, par exemple, MS peut forker OpenBSD et on ne voit jamais les contributions de MS. MS peut y ajouter des brevets et diffuser. Même avec les sources, on n'a pas le droit d'utiliser (sauf passage par la case taxe brevet).
Si Linux était sous BSD, on n'aurait aucune garantit de voir toutes les contributions d'Intel, Red Hat, IBM, etc...
Ça fait une différence énorme pour certains.
> Alors arretez d'être de mauvaise foi.
Arrêtez d'être de mauvaise foi et de faire croire que les licences BSD et GPL c'est la même chose. Ce n'est pas la même chose.
L'une défend activement le caractère libre d'un programme, l'autre non. L'une est copyleft, l'autre est copyright.
Après c'est une question de gout et d'objectif. Mais ce n'est pas la même chose.
> Si la première pile TCP avait été sous GPL, je préfère pas voir l'état de l'Internet aujourd'hui :).
Je ne vois pas le rapport.
C'est grave pour le web que Firefox soit sous GPL ?
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 8.
Définis "au top" et indique en particulier la métrique. En plus ci-dessus, on ne parle que de linux, pas de GNU/Linux. La portabilité (et la lisibilité) de la glibc sont des choses toutes relatives pour avoir mis les mains dedans.
Tu ne pense peut-etre qu'a Qt, mais il y'a plein de petites librairies fort utiles qui ne sont que sous GPL (readline me vient à l'esprit mais bon il en existe surement d'autres sans equivalent clair sous une licence moins contaminante (je persiste et je signe).
Le problème des brevets, je crois pas que la GPL resoult le problème. C'est cool, IBM a permis à Linux d'utiliser les RCU mais à personne d'autres. GPL ou pas, le code est mort (dans le sens inutile pour les autres) parce que patented. Mais bon c'est dans Linux donc hourra pour eux !!!
> C'est grave pour le web que Firefox soit sous GPL ?
Si firefox etait sous licence BSD, Microsoft pourrait prendre méchamment le code du moteur de rendu html et possiblement le greffer dans IE. Voir même utiliser un XUL plus ou moins modifié. Mon dieu c'est horrible, il va "piquer" du code libre. Et on pourra aussi supprimer 90% des hacks des sites webs ...
Des gens préféreront utilisé IE avec ce nouveau moteur plutôt que Firefox. C'est qu'ils n'ont pas compris les enjeux du libre. On n'y peut rien à par leur expliquer. En attendant, ca sera globalement mieux pour tout le monde. Et ca n'a rien enlevé à la valeur ajoutée de firefox. Comme quoi, ca peut être grave que Firefoix soit sous GPL.
[^] # Re: Architectures supportées
Posté par IsNotGood . Évalué à -1.
Trouve moi un cas où la GPL a contaminé du code. Je persiste et je signe.
Ça n'est JAMAIS arrivé. La GPL v2 existe depuis 15 ans !
> ca peut être grave que Firefoix soit sous GPL.
La GPL c'est le mal. OK, on a compris.
[^] # Re: Architectures supportées
Posté par Zenitram (site web personnel) . Évalué à 7.
C'est toujours un long débat sur ce mot...
Mon point de vue est que si j'insère une seule ligne de code GPL dans 1 000 000 de lignes de code proprio à moi, je dois passer mes 1 000 000 de ligne en GPL pour pouvoir diffuser le programme, et pas seulement diffuser la ligne de code en question.
La GPL, par son utilisation, impose sa licence sur du code qui n'est pas à elle. Elle contamine donc, puisque l'impact de cette licence n'est pas seulement sur son code, mais mon code aussi.
Choisir la GPL est un choix, on fait ou on ne fait pas, c'est une licence.
Et il faut bien être conscient que cette licence empiète sur mon droit de choisir une licence pour mon code : elle me contamine, elle m'impose des choses sur mon travail.
C'est un choix (et c'est pour ça que je diffuse en LGPL : j'estime n'avoir aucunement le droit moral de dire aux autres la licence qu'ils doivent utiliser pour leur code).
[^] # Re: Architectures supportées
Posté par Romain . Évalué à 7.
Si tu veux faire du proprio, tu ne pompes pas de lignes GPL.
Donc soit tu fais du code propriétaire et dans ce cas là tu n'exploites pas le libre, soit tu fais du libre jusqu'au bout et tu as le droit de réutiliser le travail des autres.
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 1.
Mais elle empeche l'utilisation du code GPL dans la BSD et tous ses dérivés et bien d'autres licences "libre". Par contre ils peuvent prendre sans problème (sans jamais rien rendre en retour vu que le "nouveau code" est contaminé par la GPL). Comme quoi, y'a pas que les méchants Microsoft et co qui pompent du code sans rien rendre en retour !!!
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à 5.
Ce qui empeche que le code soit inséré dans du proprio par une glue BSD.
En gros elle empeche les licence libres qui ne garantissent pas que l'utilisateur conservera sa liberté.
Mais elle n'empeche pas de trouver et comprendre les algorithmes sous jacents au fonctionnement d'un logiciel.
Comme quoi, y'a pas que les méchants Microsoft et co qui pompent du code sans rien rendre en retour !!!
T'as déja essayé d'avoir les sources de windows, connaitre leur algorithme d'attribution de la mémoire etc?
Et sous linux/projet GPL, tu as essayé aussi ?
Ca donne quoi alors ?
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 1.
Quelle liberté perd-il ? Il est toujours autant libre d'utiliser des logiciels libres si il le souhaite. En quoi le fait que du code GPL soit dans un logiciel propriétaire (à supposer que ce soit possible) le priverait de quelques libertés que ce soit ? Personne ne l'oblige à utiliser ledit logicel, ou à se passer du logiciel dont vient ce bout de code. L'utilisateur est toujours aussi libre ...
Les algorithmes des dits systèmes sont en general plus ou moins bien expliqué dans différents ouvrages. Par contre, lire du code GPL est très dangereux en soit, parce qu'en suite, il faut faire extrement attention à ne pas réutiliser les mêmes petites astuces, les mêmes petits trucs etc (juste changer le nom des variables, ca s'appelle une violation de GPL). Extraire uniquement les algorithmes d'un gros morceau de code reste quelquechose de relativement difficile.
Lire du code proprio serait tout aussi dangereux mais bon, on risque moins la, faudrait pouvoir le lire :)
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à 0.
juste les libertés du LL lié au code GPL. Mais bon visiblement ça ne semble pas compter pour toi, du moment que les dvp peuvent s'amuser eux, l'utilisateur a pas son mot a dire... Tant pis si il est aussi dvp.
Exemple .
Du code de BSD est mis dans une pile TCP/IP d'un os très connu.
Tu aimerais bien pouvoir comprendre son fonctionnement, voir l'optimiser pour ta liaison satellite à multiple saut d'une latence de 5 seconde en RTT.
Avec le code BSD normalement tu peux. Mais la, pas de bol, il est encapsulé dans du code proprio, et tout ce que tu sais c'est que bidul et machin l'ont écrit en partie. Tu as bien des sources du projet initial, mais bien entendu qui ne correspondent en pas grande chose (modif, incorporation dans d'autres codes,...) a celui que tu fait tourner.
Par contre, lire du code GPL est très dangereux en soit, parce qu'en suite, il faut faire extrement attention à ne pas réutiliser les mêmes petites astuces, les mêmes petits trucs etc (juste changer le nom des variables, ca s'appelle une violation de GPL)
Tu as des méthodes pour éviter ca. Comme l'un lis le gpl et sort la doc. L'autre implémente à partir de la doc.
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 1.
Globallement, ca ne change rien du point de vue de l'utilisateur / developpeur BSD (le code est tjs la, libre comme l'air) ou du point de vue de l'utilisateur developpeur du systeme pas libre (le code n'est toujours pas libre). Par contre, on peut esperer que globalement, la pile TCP de l'os bien connu mais pas libre soit un peu moins buggé et peu plus proche de la norme et ca c'est bien.
Laissez les utilisateurs / developpeurs faire leur choix. Si ils ne veulent pas du libre, cela ne sert à rien de l'imposer.
Pour la second point, rien à dire c'est possible. Ca demande juste le double de ressource (enfin beaucoup plus que ca par rapport à du code juste réutilisable), ressource que beaucoup de projets n'ont pas ...
[^] # Re: Architectures supportées
Posté par IsNotGood . Évalué à 1.
BSD a fait le choix d'une licence qui est compatible proprio. Donc MS, par exemple, peut tout reprendre et faire du proprio. Ajouter des extensions non documenté, sans source, avec brevets, pourrir les normes sans qu'on sache ce qui est fait, etc...
C'est le choix BSD. Il faut le respecter. GPL n'a pas fait ce choix. Le choix de la GPL c'est : ce qui est libre doit rester libre et ne jamais devenir proprio. Idem pour les travaux dérivés.
> Par contre, on peut esperer que globalement, la pile TCP de l'os bien connu mais pas libre soit un peu moins buggé et peu plus proche de la norme et ca c'est bien.
C'est limite n'importe quoi pour l'aspect norme. Si n'est pas compatible, du moins avec MS, c'est simplement car MS ne le veut pas.
MS a fait son java, il n'est pas compatible avec le java de Sun. Tu peux faire des rapport de bug, ça ne changera rien. Tu peux fournir les correctifs, ça ne changera rien.
IE respecte de plus en plus les standards. Ce n'est pas car il y a un navigateur sous BSD et que MS a pu récupérer les sources et corrections, c'est car Firefox concurrence IE. Que Firefox soit sous GPL ou pas ne change rien sur ce point.
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 2.
Je ne vois pas en quoi Microsoft a besoin d'une pile BSD pour ecrire des extensions non documentés, et des brevets. Je ne vois donc pas ou veut en venir l'argument. Il peut le faire en partant d'une pile BSD comme d'autre chose. BSD ne prone pas ce genre de chose, ne l'aide pas.
C'est tellement facile d'écrire une jvm. Je comprend pas pourquoi tu n'en a pas ecrit une plus tot entièrement libre pendant toutes ces années ou la jvm de sun était fermé. Lance la pierre sur MS, je crois pas que les jvm libres non-sun soient parfaites aussi. Faut arrêter de taper sur MS parce que c'est MS. Ecrire une jvm c'est complexe ...
Le reste est du même caractère fallacieux. Evidemment, la concurrence joue un rôle important dans le fait que IE s'améliore (et ca aurait pu etre autre chose que firefox). Mais ca n'enleve pas qu'avec un moteur BSD, MS aurait pu le prendre et s'en servir comme base, et on aurait un moteur plus performant. Tu peux tourner ca comme tu veux, ca reste vrai !!!!
[^] # Re: Architectures supportées
Posté par IsNotGood . Évalué à 0.
T'as raison, il n'en a pas besoin. Qu'il y ait des piles (ou n'importe quoi) sous BSD ne va pas pousser MS ou n'importe qui à respecter les standards.
Il est plus facile de respecter les standards que de tenter d'en créer un autre. Il est stupide si on n'a pas un monopole de ne pas respecter les standards.
Donc ceux qui ne respecte pas les standards, c'est car ils ne le veulent pas. C'est tout.
> Mais ca n'enleve pas qu'avec un moteur BSD, MS aurait pu le prendre et s'en servir comme base, et on aurait un moteur plus performant. Tu peux tourner ca comme tu veux, ca reste vrai !!!!
T'as encore raison. Mais j'ai dit :
- "C'est limite n'importe quoi pour l'aspect norme".
J'en ai rien à foutre que IE soit super performant car il y pioché du code BSD. Je veux qu'il respecte les normes, qu'il n'enferme pas l'utilisateur. Tu peux fournir tout le code BSD que tu veux, si MS ne veut pas respecter les standards, MS le ne fera pas.
Maintenant tu peux toujours dire que MS c'est des gentils et toussa et qu'on peut lui donner du code car MS ne va faire que des choses gentilles, avec des licences gentilles, sans brevets, etc mais je n'y crois pas 2 secondes.
Donne un super greffon à MS pour MS-Office afin d'avoir des supers import/export d'ODF, MS n'en voudra pas.
Donne un super greffon à MS pour MS-Office afin de corriger les conneries de OOXML (le format des dates, certains non respect de la norme XML, etc), MS n'en voudra pas.
Que les greffons soient sous BSD ou non.
Mettre du code sous BSD peut aider les entreprises. Beaucoup d'entreprise sont "gentilles" et respectent les standards. L'intention est louable et je la respecte. Vraiment. Mais la BSD permet aussi les brevets, les tivolisations, DRM, etc...
Si l'intention c'est d'aider que les boites qui font du proprio (par exemple il faut payer pour avoir une licence) mais qui ne pourrisse pas le libre avec les brevets, DRM etc, pas de problème. Faites une BSD-bis qui interdit les brevets, etc... Même si ça n'impose pas la disponibilité du code source, ça me convient. Je pourrait même peut-être la proposer à mon bosse.
La BSD c'est libre, mais libre aussi de faire toutes les saloperies du proprio (pas de source, brevet, DRM, tivolisation, etc).
Désolé mais je ne veux pas que mon code aide ce type de truc. Mon code sera donc incompatible BSD (mais pas forcément sous GPL, bien que probablement sous GPL :-)).
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 2.
Désolé mais je ne veux pas que mon code aide ce type de truc. Mon code sera donc incompatible BSD (mais pas forcément sous GPL, bien que probablement sous GPL :-)).
Je ne vois pas en quoi ton code même sous BSD aide à ce genre de chose. Si ce code n'existait pas, il l'écrirait. Le BSD aide juste à avoir une base de code plus ou moins propre disponible. On peut poser un brevet sur un code GPL, un code BSD ou un code proprio. Mais bon, on ne doit pas pouvoir en poser sur un concept existant, aka ils ont pas le droit de prendre du code BSD et de poser un brevet sur une idée implémenté par ce code. IBM entre autre a posé des brevets sur des idées qu'ils ont implémentés en GPL. Le code est disponible en GPL (les RCU par exemple) mais on ne peut pas l'utilliser. C'est donc un non-argument (et je t'ai deja repondu sur le sujet dans ce fil ...).
Concernant les DRM, je ne vois pas le rapport non plus. On peut avoir des implémentations de DRM libre. La tivolisation, c'est un truc pour contourner la GPL2. Comme quoi, la GPL ne protège pas de tous les maux. .On peut evidemment écrire une nouvelle license encore plus illisibile que la précédente a chaque fois qu'un petit malin arrive à la contourner mais bon ca ne changera rien, les profiteurs auront tjs une guerre d'avance
Le but de la BSD c'est de donner du code librement. Et c'est tout. Il y'aura toujours des gens pour en abuser mais personne n'oblige à utiliser les produits desdites compagnies. Quand il n'y aura plus d'acheteurs pour leur connerie, ils se rangeront.
[^] # Re: Architectures supportées
Posté par Zenitram (site web personnel) . Évalué à 4.
La GPL (v2 c'est sûr, peut-être v3 aussi malgré les tentatives de la FSF...) permet la Tivoïsation, faudra trouver une autre licence si tu veux éviter la Tivoïsation. Mais je n'ai pas encore trouvé une licence libre qui empêche par avance toutes les conneries faisables, faudra que tu prennes le risque qu'on fasse un truc que tu n'avais pas prévu...
Un DRM, c'est une serrure et une clé, et empêcher que tu sortes l'½uvre DRMisée du coffre dans lequel il est, et surtout on essaye de t'empêcher de copier la clé.
Si tu fait un DRM libre, la clé sera librement copiable, donc le DRM n'aura plus d'effet.
C'est du FUD de Mr Olivennes que tu nous fais sur ce coup...
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à -1.
exemple volontairement exagéré
Donc si un bourreau vient te voir et te demande de lui fournir le fusil et les cartouches pour te tuer, tu lui fournirais sous prétexte que "ben il peut aussi venir avec le sien, donc autant lui fournir le miens".
Gpl dis plutot "si il veut me tuer, il le fera avec SON fusil. Le mien c'est que pour la chasse au lapin".
Comme quoi, la GPL ne protège pas de tous les maux
Et la gplv3 est jamais sortie quand elle a vu ce problème. Non non pas du tout.
La fsf etc..., ils ont jamais voulu faire respecter l'esprit de leur licence en proposant ...
- un site des violations (gpl violations)
- des attaques en justices (avec accord a l'amiable ou pas)
- des "updates" des licences pour se mettre à jour en fonction des contournement de la licence qui sont apparus justement.
Le but de la BSD c'est de donner du code librement.
La question était :
En gros elle empeche les licence libres qui ne garantissent pas que l'utilisateur conservera sa liberté.
Et constate que la c'est plus du tout le meme discours que tu nous tient.
avant c'était "Ou est ce que l'utilisateur perd ses libertés".(je cite : Quelle liberté perd-il ?)
Et quand on te le démontre par A+B , tu nous sort un autre but, qui est louable certe, mais qui a rien a voir.
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 2.
La question était :
En gros elle empeche les licence libres qui ne garantissent pas que l'utilisateur conservera sa liberté.
> Et constate que la c'est plus du tout le meme discours que tu nous tient.
avant c'était "Ou est ce que l'utilisateur perd ses libertés".(je cite : Quelle liberté perd-il ?)
Et quand on te le démontre par A+B , tu nous sort un autre but, qui est louable certe, mais qui a rien a voir.
Je constate surtout que je vois pas le rapport. Je ne vois pas quelle liberté l'utilisateur a-t-il perdu ? Si il fait le choix d'acheter une musique drmisé, c'est son choix, ca peut paraitre stupide mais ca reste son choix. Personne ne l'a obligé à le faire.
Pourrais tu me montrer le cheminement logique qui prouve que l'utilisateur perd des libertés (à cause d'un code BSD)
Second point : je ne vois pas le rapport entre 'le but de BSD' et la ligne que tu paste ensuite. Enfin je ne vois pas en quoi c'est contradictoire et en quoi ce but est en opposition à mes propos auparavant. Pourrais tu la aussi me décrire ton cheminement logique ?
Quand à la logique d'au dessus sur le fusil et les balles, les bras m'en tombent et je ne sais que répondre face à une logique aussi tordu. Vas tu aussi accuser les découvreurs de l'energie atomique des morts à Hiroshima ? Genre le code BSD on le laisse aux méchants propriétaires pour qu'ils nous spollient avec ...
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à -1.
Euh ...; tu rigole ?
La si tu vois pas après tout ce qu'on a dis, je vois pas ce que je peux faire pour toi par contre.
Enfin je ne vois pas en quoi c'est contradictoire et en quoi ce but est en opposition à mes propos auparavant.
Le but est pas "contradictoire" , ca a juste rien a voir. C'est ce que je disais.
On parlais de la liberté de l'utilisateur , et là tu nous dis "c'est pour avoir du code libre".
En fait , pour avoir du code libre, pourquoi BSD ? Pourquoi pas WTFPL ? ca conviendrais bien mieux.
Si il fait le choix d'acheter une musique drmisé, c'est son choix, ca peut paraitre stupide mais ca reste son choix. Personne ne l'a obligé à le faire.
Comment ca ca a rien a voir avec ce dont on parle?
Le LL est là pour garantir des libertés à l'utilisateurs.
Et tu dis "oui nous on garanties pas les libertés tout au long de l'utilisation de notre code parce que l'utilisateur a fait le choix de prendre des licences qui ne le garantisse pas". Tu fait pas du libre si l'utilisateur peut pas avoir les libertés dans ce cas, c'est tout.
C'est d'ailleur ce qui est reproché.
Alors ensuite dire "Mais sion fait du libre ... mais on ne garantie rien à l'utilisateur si quelqu'un reprend le code" alors que faire du libre c'est justement garantir des libertés à l'utilisateur.
Et rejeter le problème sur l'utilisateur est assez ... nul.
Ca doit etre la meme chose avec les bugs hein "Ah ce con d'utilisateur a encore fait une connerie".
Pourrais tu me montrer le cheminement logique qui prouve que l'utilisateur perd des libertés (à cause d'un code BSD)
Code BSD -> code proprio issu de BSD (on a rajouté un printf et mis une gui au dessus et on a mis l'ensemble sous proprio).
L'utilisateur utilise sous jacentement du code "libre" ... mais ne peut rien faire avec car sous licence proprio. Cool.
Mais non la c'est la faute de l'utilisateur qui osé ne pas prendre le projet bsd (qu'il ne connaissait pe pas initialement, ou qui ne convenait pas completement a ses besoins, ou qui a été forcé par son patron , ou ...) . C'est sa faut entière et pleine de pas avoir les libertés que lui confèrerait le code initial.
No comment.
Vas tu aussi accuser les découvreurs de l'energie atomique des morts à Hiroshima ?
Oh, ils le font très bien tout seuls. Ils ont dit après le test de trinity "maintenant on est tous des sacrés fils de putes".
Mais bon, pour revenir dans le sujet, heureusement que j'avais marqué :
exemple volontairement exagéré
Mais visiblement tes yeux sont très ... pointilleux sur les caractères qu'ils veulent bien laisser passer au nerfs optiques. Je ne vois pas d'autres explications pour ne pas voir l'avertissement, et ne pas voir que je ridiculise juste le coup du "mais non c'est normal qu'on puisse réutiliser ceci, car sinon ils l'auraient fait eux même".
Genre le code BSD on le laisse aux méchants propriétaires pour qu'ils nous spollient avec ...
Libre interprétation de tes propres propos. Je ne me prononcerais pas dessus.
[^] # Re: Architectures supportées
Posté par Moonz . Évalué à 6.
On a un logiciel libre (BSD ou GPL), que l'utilisateur ne veut pas utiliser pour x raison plus ou moins bonne.
On a un logiciel propriétaire qui propose la même chose, mais en propriétaire. Supposons, puisque tu fais une telle fixation sur le méchant propriétaire qui repique sans rien redonner, qu'ils aient repiqué sans vergogne sur du code BSD, parce qu'ils veulent pas faire de logiciel libre.
Supposons maintenant que le code n'a jamais été en BSD, mais en GPL. Qu'est-ce qu'il se passe maintenant ?
-> Soit ils réécrivent eux même le nécessaire.
-> Soit ils ne font pas de logiciel propriétaire.
-> (je te vois venir "soit ils le font en GPL". Oui mais non, on vient de dire que c'était une mAIchante entreprise Kapitaliste qui jamais ô grand jamais n'acceptera de partager (et puis quoi encore ?) avec la communauté, c'est d'ailleurs pour ça qu'ils avaient repiqué du code BSD pour en faire du proprio)
Dans les deux cas, pourrais tu s'il te plait m'expliquer ce que l'utilisateur a gagné dans le fait que le projet ait été en GPL et non en BSD ? Pour moi, ça se réduit à néant...
[^] # Re: Architectures supportées
Posté par Thomas Douillard . Évalué à 3.
Attention, ceci pourrait heurter les sensibilités
Le troll peut provoquer des dégâts irrémédiables.
******************
[ Répondre ] Ce commentaire est-il pertinent ou inutile
Pire, il a peut être perdu l'opportunité d'utilsier un super logiciel (proprio, mais il s'en fout.)
[^] # Re: Architectures supportées
Posté par Psychofox (Mastodon) . Évalué à 4.
AHAHAHAHAHAHAHA
argument de l'année !
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à -1.
Faut lire plus que les deux lignes du commentaire. L'argument vaut ce qu'il vaut, mais il est là, ... lui.
[^] # Re: Architectures supportées
Posté par Psychofox (Mastodon) . Évalué à 5.
Très mauvais exemple et reflexion nulle.
On va prendre un exemple concret, qui est sujet de cette news : OpenBSD.
Moi, Psychofox, je suis un utilisateur de OpenBSD. Imaginons que la société Minimou décide de vendre un fork de OpenBSD sous licence proprio appelé Minimou Vasistas Server 2008. Moi, PsychoFox, je ne perds aucune de mes libertés en tant qu'utilisateur de OpenBSD.
Où est le danger ? Où sont mes pertes de libertés ? Où sont les pertes de libertés des gens qui ont écrits du code sous licence BSD ?
Si un crétin décide d'acheter Minimou Vasistas Server 2008, c'est son problème. Il ne perd pas de liberté puisqu'il choisit sciemment de se limiter en acceptant une licence propriétaire.
[^] # Re: Architectures supportées
Posté par patrick_g (site web personnel) . Évalué à 6.
Certes toi en tant qu'individu (geek, informé, capable d'évaluer et de choisir) tu n'aura rien perdu et tu pourra continuer à utiliser OpenBSD. En revanche pour l'immense majorité des gens qui sont pris dans la monstrueuse machine commerciale de Minimou et bien OpenBSD n'existera tout simplement pas et le seul truc qu'ils verront c'est que Vasistas Server 2008 est un putain de bon OS très sécurisé. Tes contributions et ton code aura renforcé un monopole qui deviendra de plus en plus indéboulonnable.
La BSD encourage ce type de comportement de la part de Minimou.
En terme de théorie des jeux la licence BSD encourage la défection alors que la licence GPL force à la coopération.
[^] # Re: Architectures supportées
Posté par Romain . Évalué à 2.
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à 2.
(Ca existe aussi entre deux codes proprio : les != problèmes de licences par exemple).
Ensuite certe, il faut le voir... mais c'est vrai pour tous les comportements illégaux ;)
Sinon, patrick_g a mieux expliqué que moi ce que je voulais dire.
[^] # Re: Architectures supportées
Posté par Romain . Évalué à 1.
[^] # Re: Architectures supportées
Posté par inico (site web personnel) . Évalué à 3.
Zlib est detectable dans beaucoup de logiciel proprios.
Tout comme libpng, openssl, qt ...
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 4.
C'est le nouveau surnom de RMS ?
[^] # Re: Architectures supportées
Posté par ErrTu . Évalué à 8.
La licence BSD est une licence libre très simple à comprendre (en 3 lignes on fait difficilement mieux), utilisée principalement par des personnes bien plus intéressées par la technique et l'élégance du code source (sans oublier leur liberté personnelle) que par les discussions interminables sur les licences ; que le code puisse être réutilisé dans un programme propriétaire importe peu. La licence BSD propose la liberté de partager avec _tout le monde_, ce qui est dans les objectifs d'au moins un des systèmes d'exploitation *BSD.
Il est vrai que du code sous licence BSD est utilisé par des sociétés pour faire du propriétaire, mais beaucoup d'entre-elles (bien plus que ce que l'on pourrait croire) jouent le jeu et contribuent en retour.
Du moment qu'il y a des standards pour communiquer et de la documentation pour écrire des pilotes, tout va pour le mieux dans le meilleur des mondes. Chacun est libre de choisir sa voie ; celle que la FSF montre n'est pas la seule à mériter l'intérêt des développeurs du libre.
[^] # Re: Architectures supportées
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Un exemple, la base de données Ingres issue de la même souche que Postgresql. Après un brillant départ, Ingres a périclité alors que Postgresql a continué à se développer. Le code source de Ingres vient d'être publié, mais c'est trop tard.
[^] # Re: Architectures supportées
Posté par vjm . Évalué à 6.
[^] # Re: Architectures supportées
Posté par Pierre Jarillon (site web personnel) . Évalué à -2.
À partir de là on peut imaginer ce qui aurait pu se passer :
- Postgresql aurait gagné plusieurs années dans son développement.
- Oracle n'aurait pas vaincu Ingres.
- Postgresql aurait été aux bases de données ce que Apache est aux serveurs web.
[^] # Re: Architectures supportées
Posté par Moonz . Évalué à 6.
Car, comme chacun le sait, c'est la GPL qui a permis à Apache d'arriver là où il en est...
> Ingres aurait été fourni avec son code
Ou pas fourni du tout
> Postgresql aurait gagné plusieurs années dans son développement.
> Oracle n'aurait pas vaincu Ingres.
> Postgresql aurait été aux bases de données ce que Apache est aux serveurs web.
Faut que tu m'expliques l'implication directe, là...
[^] # Re: Architectures supportées
Posté par Jean-Philippe (site web personnel) . Évalué à 3.
Un choix que quasiment tout le monde fait par défaut la ou leurs besoins ne sont pas du tout adaptés ?
(tiens ca marche pour Mysql)
[^] # Re: Architectures supportées
Posté par Psychofox (Mastodon) . Évalué à 3.
Si Minimou Vasistas Server 2008 s'impose auprès du public. Ben soit, qu'il en soit ainsi. C'est la loi du marché. S'il hérite de code de qualité, au moins on pourra avoir sur la conscience que le grand public ou les personnes moins soucieuses de leur liberté auront au moins quelque chose de qualité. Ce qui dans le cadre d'une utilisation sur internet, est la bienvenue. Et ça n'en fera (peut-être) pas une machine zombie. C'est toujours ça de gagné.
Et dans ce cas la OpenBSD pourrait toujours se faire de la publicité grâce à la license isc qui impose que le copyright notice reste dans chaque copie.
[^] # Re: Architectures supportées
Posté par patrick_g (site web personnel) . Évalué à 2.
Ha ha ha !!
Trop drôle. Si Microsoft est en position de monopole c'est la loi du marché et on ne peut rien y faire. Les gens ont, en conscience et en connaissance de cause, décidé de rejeter OpenBSD au profit de Microsoft ? C'est vraiment ça ta théorie ?
La vérité c'est que les gens n'ont jamais entendu parler d'OpenBSD et que les ordinateurs qu'ils achètent chez carrouf ou à la Fnac sont livrés avec Vista. Pour eux ordinateur=Windows.
Tout le boulot fait sous licence BSD sert potentiellement à renforcer ce monopole.
Quand à ta vision angélique qui affirme qu'au moins cela sert à disséminer du code de qualité ce qui serait pour le bénéfice de tous je pense que c'est être naïf que de penser cela. Certes cela dissémine du code de qualité MAIS cela renforce le monopole de Microsoft qui peut donc se servir de cette puissance pour imposer ses protocoles propriétaires au détriment des standards reconnus. Le bénéfice de tous est dans ce cas contrebalancé par l'affaiblissement des standards libres....ce qui est néfaste pour tous !
Le fait d'aider (indirectement et potentiellement) Microsoft en écrivant du code BSD cela signifie donc aider le .doc au détriment d'odf, aider le wma au détriment de vorbis...etc etc
Grâce au code BSD Microsoft peut avoir un OS de meilleure qualité et donc conserver sa puissance gigantesque pour imposer ses normes.
Si le monde entier utilisait les BSD et Linux alors écrire du code sous BSD n'aurait aucun effet néfaste même si il était repris par des boites propriétaires. Comme, dans ce cas de figure hypothétique, le monde entier utilise des OS libres le fait que le code soit repris ne ferait perdre aucune liberté aux utilisateurs.
Dans le monde réel peu de gens utilisent des OS libres et donc écrire du code sous licence BSD permet de renforcer le monopole actuel des firmes propriétaires.
[^] # Re: Architectures supportées
Posté par Psychofox (Mastodon) . Évalué à 4.
je n'ai pas dit ça. Je dis que la position de monopole n'a rien à voir avec la licence des projets libres.
La licence BSD ne renforce le monopole de rien du tout. Le monopole de boites comme Microsoft est essentiellement lié à des pratiques commerciale. Et la part de code BSD dans un logiciel microsoft doit être ridicule face au reste. Si ce code en question n'était pas disponible, MS aurait de toute façon suffisemment de moyens et de developpeurs pour coder les briques manquantes.
n'importe quoi. Tu mélanges des trucs qui n'ont rien à voir.
Prouve moi en quoi la licence GPL empêche microsoft d'avoir une quelconque position de monopole et on en reparlera.
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 3.
La désinformation par Ms est un fléau, celles des partisans de GNU/Linux ne vaut pas mieux.
Tant que les GNU/Linuxiens continueront à pleurer pour un truc qui fait bien du msn et qui lit du flash correctement, bah il n'y aura rien à faire. La liberté aura perdu.
Les logiciels sous BSD n'ont rien à voir avec le monopole de MS. Je préfère largement un windows sécurisé, fonctionnel et tout qu'autre chose. Ca nous eviterai les multiples spam bots et zombie box. Des gens informés utilisent des formats ouverts pour toutes leur communication ( ogg, jabber, odt) sous Windows alors que des tas de gens désinformés continuent d'utiliser msn, les mp3 et des .doc sous GNU/Linux. Qui est le plus pour le libre entre ces deux catégories de gens ?
Informons les gens si vous voulez voir plus de libre. Et arretez la désinformation massive (genre la BSD favorise les monopoles et autres conneries plus grosses que vous).
[^] # Re: Architectures supportées
Posté par Anonyme . Évalué à 4.
J'ai l'impression, et ça me fait vraiment mal, que la licence BSD est choisie parce qu'on aime le libre, alors que la GPL est choisie parce qu'on hait Microsoft.
Je me trompe ?
[^] # Re: Architectures supportées
Posté par Zenitram (site web personnel) . Évalué à 5.
Réponse courte : Oui.
Réponse longue : on choisit la GPL quand on aime le libre, et quand on souhaite que ce qu'on a fait soit utilisé/réutilisé/modifié/etc par des gens qui ont la même philosophie. Rien à voir avec Microsoft.
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à 0.
Tu sais qu'il y a des GNU/Linuxiens qui ne pleurent pas du tout pour ça, et qu'il y a des bsdien (moins il est vrai ) si ?
Quant les BSDiens (ou les linuxiens, voir les opensolariens) arrêteront de croire qu'ils sont meilleurs que les autres, plus beau, plus intelligents, ont tout mieux compris, et peuvent traiter les autres comme de la merde, on aura fait un grand pas en avant ... Et t'as vu même pas de ms dedans!
Bordel y'a qu'a voir les trolls de theo de raadt pour se rendre compte que tout n'est pas beau au pays d'openbsd (pas dis que tout était moche non plus hein, ni que tout est beau au pays de linux).
[^] # Re: Architectures supportées
Posté par zul (site web personnel) . Évalué à 4.
M'enfin tout ce thread tend à essayer de démontrer que la GPL elle sent meilleure le libre que le reste, tout ca, que la GPL protège le libriste et tout. Et les GNU/Linuxiens sont de toute facon majoritaire dans le monde libre.
Theo ne trolle pas si souvent que ca et souvent pour des choses importantes amha. Theo est surement un des plus gros défenseur du libre....
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à 1.
Que la GPL est plus orienté libre pour l'utilisateur final parce qu'elle oblige a contribuer et n'autorise pas la reprise dans le proprio.
C'est un avantage ... et un inconvénient.
Theo est surement un des plus gros défenseur du libre....
Ce sur quoi je n'ai rien dis. Juste dis que c'était un GROS trolleur. Et ça c'est un un fait.
[^] # Re: Architectures supportées
Posté par kimelto . Évalué à 4.
Tient ?! Une licence qui defend ta liberté te force à faire quelquechose !? Si elle te force c'est que tu n'as pas le choix... et elle te prive donc d'une liberté...
Bizarre pour une licence qui veut les défendres !
La GPL est parti en guerre contre les logiciels privateurs et à cause de ca elle devient de moins en moins permissive :(
Où est l'esprit de la licence MIT, MIT où travaillait RMS !
http://fr.wikipedia.org/wiki/Licence_MIT
http://fr.wikipedia.org/wiki/Massachusetts_Institute_of_Tech(...)
[^] # Re: Architectures supportées
Posté par Gniarf . Évalué à -1.
[^] # Re: Architectures supportées
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Explication brève : http://www.linux-france.org/prj/jargonf/G/Godwin.html
Explication longue : http://fr.wikipedia.org/wiki/Loi_de_Godwin
[^] # Re: Architectures supportées
Posté par Gniarf . Évalué à 2.
[^] # Re: Architectures supportées
Posté par FreeB5D . Évalué à 2.
Ca peut aussi être le stalinisme ou le franquisme .
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 4.
Justement, RMS a créé le copyleft en réaction aux chercheurs qui partaient du MIT au profit de boîtes privées (c'était l'époque des Lisp Machines) où le code du MIT était réutilisé sans publication des modifications.
[^] # Re: Architectures supportées
Posté par jarodender . Évalué à 3.
Dans ton raisonnement, c'est la seule chose sur laquelle je ne suis pas d'accord. D'après mes souvenirs, quand tu utilises du code BSD, tu es obligé de le préciser quelque part (licence + source)... donc d'une manière ou d'une autre, le projet initial est connu.
De toute façon BSD ou GPL ont leur raison d'être.
GPL
avantages :
- incite à la coopération (développement accéléré)
inconvénients :
- les logiciels proprios l'évitent à tout prix (perte au niveau des normes dès qu'il y a un monopole)
BSD
avantages :
- permet de le réutiliser partout (c'est bien pour les normes et la concurrence proprio/libre)
inconvénient :
- n'oblige pas à ce que l'ajout de code soit sous BSD (non viral) et donc encourage le proprio à l'utiliser sans redonner les améliorations (car on n'est pas dans une monde de Bisounours).
La polémique n'a d'intérêt que pour le(s) développeur(s) ou l'entreprise qui emploie le(s) développeur(s), à eux de voir où est leur intérêt (100% proprio, Proprio+BSD ou 100% GPL,...), le reste c'est du trollage
[^] # Re: Architectures supportées
Posté par herodiade . Évalué à 7.
- permet de le réutiliser partout (c'est bien pour les normes et la concurrence proprio/libre)
plutôt, pour bien montrer les priorités :
- permet de le réutiliser partout (est compatible avec les softs sous GPL, LGPL, CDDL, MPL, ... et accessoirement avec le proprio (ce qui peut être bien pour les normes))
Parce que les développeurs de logiciels sous licence MIT ou BSD, je crois qu'ils sont généralement beaucoup plus intéressés par la réutilisation de leur code sans restriction par d'autres logiciels libres, que par le proprio (qui est plutôt un « side effect » qu'on juge négligeable). La compatibilité a toujours été importante en informatique, surtout la compatibilité entre « frères du libre ». Exemple : xorg et sa licence.
Ou pour le dire autrement : en choisissant la BSD, on se prive de pouvoir punir le proprio, généralement parce qu'on juge plus important de ne pas priver nos cousins du libre, sans discrimination, que de se laisser dicter une conduire par le proprio (dont on se fiche éperdument).
À part ça, je ne remercie pas Pierre Jarillon d'avoir pourri la dépêche en lançant ce troll (dans lequel je viens de marcher, imbécile de moi).
[^] # Re: Architectures supportées
Posté par patrick_g (site web personnel) . Évalué à 2.
Clair que c'est dommage que ce soit parti en vrille mais bon.....
[^] # Re: Architectures supportées
Posté par ph11 . Évalué à 2.
Le problème c'est que la firme derrière Minimou Vasistas Server 2008 a 10000 fois plus d'argent et de force de frappe marketing que les devs d'OpenBSD. C'est son système Minimou Vasistas Server 2008 qui va s'imposer auprès du public et tout les efforts de code, de rapports de bugs, de documentation....etc que tu aura donné seront repris sans vergogne par cette firme prédatrice. Certes toi en tant qu'individu (geek, informé, capable d'évaluer et de choisir) tu n'aura rien perdu et tu pourra continuer à utiliser OpenBSD. En revanche pour l'immense majorité des gens qui sont pris dans la monstrueuse machine commerciale de Minimou et bien OpenBSD n'existera tout simplement pas et le seul truc qu'ils verront c'est que Vasistas Server 2008 est un putain de bon OS très sécurisé. Tes contributions et ton code aura renforcé un monopole qui deviendra de plus en plus indéboulonnable.Sauf que Minimou , avec ses finances et sa politique de marketing, sait faire passer des vessies pour des lanternes et a donc la capacité de vendre à la majortité des gens un SE faillible, instable, se rapprochant du télécran. Alors, si par l'integration de code BSD - ce qui se fait déjà! - cet os se débarrasse de ses inconvénients, on ne peut que s'en réjouir. Après, si les gens ne prennent même pas le temps de lire la licence d'utilisation ki_stipule_kon_doit_cayday_son_ame_à_minimou_pour_utilizay_Vatistas et ki_a_la_valeur_juridik_d'un_kontra, c'est leur problème. Une autre utilisation d'openBSD par des proprios pourrait être par exemple de créer un SE spécialisé exclusivement pour une ou plusieurs applications comme pour la MAO, comme il existe Ubuntu Studio, il pourrait il y avoir une station unix pro tools ou cubase qui tournent à présent que sur des OS généralistes et doivent s'y adapter ce qui aboutit à un système lourd. Avec un OS optimisé pour leurs logiciels supportant leurs protocoles nativement, celui-ci serait infiniment plus léger, réactif et stable. En se basant sur un système libre existant, et éprouvé, ils pourraient aboutir rapidement à un projet valable et gagneraient des années par rapport au temps que cela leur prendrait s'ils devaient concevoir le système à partir de rien. Ils pourraient très bien utiliser linux, mais je doute que leur objectif soit de faire un OS libre.[^] # Re: Architectures supportées
Posté par ph11 . Évalué à 2.
Au moins, tu sauras que son fusil est de bonne qualité.
[^] # Re: Architectures supportées
Posté par Anonyme . Évalué à 6.
Que l'on aime ou pas Microsoft, je crois que le jour où ils s'inspireront *vraiment et complètement* d'un système unix sous licence BSD, ils sortiront un vrai système, stable et cohérent. Mais non, ils préfèrent dépenser des millions à pondre un OS comme Vista dont personne ne veut.
C'est là où la mentalité de la licence BSD est clairement différente de celle sous GPL : aider l'informatique. Il y a des tanches qui ne savent pas programmer, qui ne savent pas faire de produits, qui se foutent de leurs clients. Qui trinque dans ces cas-là ? Des utilisateurs.
Que l'entreprise se fasse des thunes, on s'en fout. Mais qu'elle ai au moins l'intelligence de se baser sur un code propre, approuvé, sécurisé et fonctionnel, plutôt que de partir de néant. Tout le monde y est gagnant. Et c'est pour cela que j'approuve la licence BSD.
[^] # Re: Architectures supportées
Posté par ph11 . Évalué à 1.
À moins que ce soient des applis comme wine qui deviendraient très efficaces.
Cela inciterait plus de gens à migrer s'ils ont la possibilité d'avoir leurs logiciels préférés.
[^] # Re: Architectures supportées
Posté par Moonz . Évalué à 3.
Heu... là, non :)
Si quelqu'un repique, disons, le nouveau scheduler de FreeBSD, en fait un truc pas libre et dépose un brevet, ça tiendra pas deux minutes puisque le code BSD aura l'antériorité...
> pas de source, DRM, tivoisation
Aussi dérangeant que de retrouver la pile TCP de BSD dans Windows... Au final, c'est l'utilisateur FINAL qui choisit s'il veut un système proprio/avec DRMs ou un système libre (que ce soit GPL ou BSD). D'ailleurs,
* la tivoisation, ça a été fait sur du code GPL
* on peut très bien faire un système DRM en GPL
[^] # Une preuve?
Posté par Zenitram (site web personnel) . Évalué à 2.
Une preuve s'il te plait.
Pour moi, si personne ne l'a fait (sérieusement, vraiment libre...), c'est que ça doit pas être si évident...
[^] # Re: Architectures supportées
Posté par Psychofox (Mastodon) . Évalué à 7.
oouuuuh c'est vrai c'est tellement mal.
C'est vrai, j'oubliai aussi que la GPL empêche aussi les utilisateurs de Fedora de télécharger des images pédophiles. Elle empêche aussi les terroristes d'installer un linux embarqué pour créer des missiles en vue de détruire Disneyland et me garantie que Fedora ne sera jamais utilisé par un psychopathe pour se mettre en contact via sa messagerie jabber avec d'éventuelles victimes.
GPLallah est grand ! Béni soit la Fedora !
Non sérieux, des fois il faut enlever sa chasuble et arrêter de se la raconter illuminé en débitant des anneries toutes droites copiées d'une plaquette promotionnelle d'une secte. Un peu d'esprit critique et de reflexion ! Une licence ne devrait pas être censée empêcher ses utilisateurs de faire des choses illégales/immorales/non conformes à une éthique/qui ne te plaisent pas. C'est le but des lois, pas des licences. Les licences sont la pour spécifier des termes de distribution d'un logiciel dans le cadre légal des lois sur les droits d'auteur et du copyright.
Si ce que tu veux vraiment, c'est tout pleins de restrictions qui empêche des usages qui ne te plaisent pas, c'est que tu veux vivre dans le monde proprio. Dans ce cas la je te conseille d'écrire ta licence ton EULA qui interdit à tes utilisateurs de se branler le mardi entre 13h35 et 17h12, de jouer aux echecs et d'aimer la musique Country. Plus une licence est longue et remplie de clauses contraignantes (comme la GPL), plus elle se rapproche du proprio.
[^] # Re: Architectures supportées
Posté par Moonz . Évalué à 2.
En quoi ça le rend responsable du choix de l'utilisateur ?
> C'est limite n'importe quoi pour l'aspect norme.
Ça peut aider pour éviter les implémentations involontairement foireuses. Mais je suis d'accord que si quelqu'un veut pas respecter les standards, qu'il y ait du code BSD disponible ou pas ne changera rien.
[^] # Re: Architectures supportées
Posté par Nicolas Legrand (site web personnel) . Évalué à 0.
[^] # Re: Architectures supportées
Posté par Moonz . Évalué à 0.
[^] # Re: Architectures supportées
Posté par IsNotGood . Évalué à 2.
Si t'as notion du partage c'est "maintenant que j'ai repompé je vous plus rien et je ne partage rien si je veux", effectivement la GPL n'est pas pour toi.
La GPL c'est : "je partage avec ceux qui accèpte de partager". Ça c'est pour les travaux dérivé et le code, pour l'utilisation, l'analyse du code, etc la GPL partage avec tout le monde.
MS peut mettre Firefox dans Windows. Et ça serait une bonne idée.
[^] # Re: Architectures supportées
Posté par Moonz . Évalué à 1.
[^] # Re: Architectures supportées
Posté par IsNotGood . Évalué à 3.
Idem pour d'autres licences.
Si tu mets du GPL dans du proprio et que tu veux que l'ensemble reste proprio, tu dois passer tes lignes GPL sous une licence proprio.
Ce n'est pas un problème de "contamination", c'est un problème de compatibilité. La GPL ne veut pas être compatible avec le proprio. La GPL se veut être libre et donc le proprio ne peut pas être compatible avec la GPL. Le proprio ne veut pas être libre et donc la GPL ne peut pas être compatible avec le proprio. Ça va dans les deux sens.
> Et il faut bien être conscient que cette licence empiète sur mon droit de choisir une licence pour mon code
Connerie. Tu utilises la licence que tu veux. Comme celui qui utilise la GPL choisi la licence qu'il veut pour son code. Il a décidé que son code doit être GPL et que les travaux dérivés de son code doivent être sous GPL. C'est son code que ça concerne. Si tu veux mettre ton code dans le sien, son code est concerné et pas seulement le tien.
> elle me contamine, elle m'impose des choses sur mon travail.
Et toi tu veux imposer que la GPL soit compatible avec ton code, avec les conditions d'utilisation de ton code, avec le proprio, etc....
Tu imposes aussi des choses, tu es contaminant pour reprendre ta mauvaise terminologie.
Mais en fait, c'est simplement incompatible et c'est tout.
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à 3.
Ben l'insère pas. Tu as un flingue sur la tempe pour l'insérer ?
Si j'insère une seule ligne proprio dans 1 000 000 de lignes de code GPL A MOI ,je dois tout passer en proprio (suivant la licence du bout proprio).
Un partout, la balle au centre.
Ma vie a moi : il y a une librairie open source qui me semblait super bien : libnids. Elle est sous gpl. Pour mon boulot je devais faire un truc qui pouvait l'utiliser ou me la pseudo recoder (en faisant bcp plus crade, bcp moins testé etc...).
J'ai posé la question a mon boss , en lui disant "voila ce qu'elle permet. Voila ce que demande la GPL". Il m'a dis "non on est une petit entreprise , je vois pas comment on peut essayer de vendre un truc , meme avec du support, si on le "donne" a coté.".
Bon bref, il a pas trouvé de business plan viable. Ben devine quoi j'ai deux versions : une avec libnids pour des tests internes. Version qui ne sortira pas, et une version sans. (Pour la petite histoire j'ai d'abord fait sans. Puis suite a des bugs, j'ai mis libnids à la place de ma couche , sachant que cette librairie avait moins de chance que la mienne de planter ;))
[^] # Re: Architectures supportées
Posté par Zenitram (site web personnel) . Évalué à 4.
Je n'ai jamais dit le contraire.
Je dis juste qu'il faut être conscient que :
- La GPL, certaines licences proprio sont "virales"
- La LGPL, la BSD, certaines licences proprio ne sont pas "virales" car elles ne t'empêche pas de choisir ta licence pour du code à coté.
Dans tous les cas, si on ne veut pas parler de viralité, il y a cette grosse différence d'empiètement sur la liberté du développeur de choisir la licence de son code complètement à coté qui ne fait qu'appeler le code GPL à prendre en compte. Comment l'appeler autrement? Incompatible? Non, ce n'est pas ça de mon point de vue, j'appellerai une licence incompatible si je ne peux pas mettre du code à moi avec ma licence dans le fichier source avec la licence, pour la modifier. La GPL va plus loin, il suffit de lier statiquement pour que boom la licence t'embête (alors que pour contourner, tu passes par un appel système et hop la GPL devient LGPL, mais c'est chiant, lent etc...).
Pour moi, il y a 3 types de licences :
- Type BSD : tu fais ce que tu veux du code reçu et du tiens
- Type LGPL : tu fais ce que tu veux de ton code, mais tu es contraint pour faire évoluer le code reçu
- Type GPL : tu es contraint pour faire évoluer le code reçu et ton
code.
Après, c'est ma vision à moi, je n'oblige personne à la prendre :).
[^] # Re: Architectures supportées
Posté par IsNotGood . Évalué à -1.
Elles ne sont pas "virales" ou des conneries dans ce goût (qui viennent du département FUD de MS), elles sont incompatibles. Point barre.
Jamais rien a été contaminé. Mal-heu-reu-se-ment !
> la liberté du développeur
La GPL cible plus la liberté de l'utilisateur, et tous les utilisateurs.
> choisir la licence de son code complètement à coté
Pitié, on sait que la GPL n'est pas toujours adaptée aux librairies. La FSF le sait si bien qu'il y a la LGPL. La grande grande majorité des librairies est sous LGPL. Il n'y a qu'une petite poignée de petites librairies qui sont sous GPL. Et les grosses (typiquement Qt) sont aussi disponibles sous une licence qui permet de lier avec du non compatible GPL. On peut discuter si c'est bien ou pas, mais c'est comme ça, c'est le choix du développeur. Toi qui parle de liberté du développeur à utiliser la licence qu'il veut, tu ne devrais pas y être insensible.
> mais tu es contraint pour faire évoluer le code reçu
Non. Tu fais évoluer si tu veux et que si tu redistribues.
[^] # Re: Architectures supportées
Posté par Zenitram (site web personnel) . Évalué à 2.
Non, c'est justement ce que je reproche (faut bien reprocher de temps à autre, quand on est trop d'accord c'est mauvais signe ;-) ), ils auraient dû laisser le "L" qui signifiait "Library" pour le préciser. En mettant "Lesser", ils essayent de l'amoindrir.
Je leur reproche de ne pas être cohérent sur ce coup : si ils acceptent qu'un truc proprio fasse un appel système à une appli GPL, ils devraient laisser aussi un appel statique faire appel à l'appli.
La GPL différencie la technologie (appel système contre appel statique), et je trouve personnellement que c'est dommage de différencier la technologie.
PS : ça veut dire que je trouve dommage qu'on puisse fournir un CD Redhat Entreprise avec des applis non libres à coté d'applis GPL aussi! C'est la cohérence et la neutralité technologique qui manquent.
[^] # Re: Architectures supportées
Posté par reno . Évalué à 2.
[^] # Re: Architectures supportées
Posté par imalip . Évalué à 2.
Raaaaaaahhhhh putain mais arretez avec ce mensonge de merde !
Si on utilise une lib GPL *RIEN* n'oblige a utiliser la GPL pour son propre code. Ca oblige a utiliser une licence compatible avec la GPL. Et il y en a un paquet qui le sont, y compris la BSD, X11, MIT, zlib.
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 4.
Ben si, désolé (enfin, sauf si le code en question reste interne et n'est jamais distribué à qui que ce soit...). C'est d'ailleurs pour lever cette obligation que la LGPL a été créée.
Ca oblige a utiliser une licence compatible avec la GPL.
Non c'est l'inverse : si on écrit un programme sous GPL on peut utiliser toute bibliothèque écrite sous une licence compatible (l'ensemble bibliothèque + programme devenant lui-même sous GPL lorsqu'il est redistribué comme un tout). La compatibilité ne marche que dans un seul sens.
[^] # Re: Architectures supportées
Posté par FreeB5D . Évalué à 1.
Un bibliothèque et un programme n'ont aucune distinction .
Ce sont tous les deux du code exécutable .
La LGPL a été crée pour permettre de combiner le code avec du logiciel proprio logiciel incompatible avec la GPL .
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 4.
Ce sont tous les deux du code exécutable .
La distinction est dans la notion d'oeuvre dérivée qui sous-tend l'application de la GPL (ou de la LGPL, d'ailleurs). La GPL fait appel au copyright pour délimiter l'extension des oeuvres soumises à la licence (dans la v3 : «To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission», dans la v2 : «a "work based on the Program" means either the Program or any derivative work under copyright law»).
Mettons une bibliothèque A et un programme B faisant des appels à la bibliothèque A. Alors :
- B est considéré comme une oeuvre dérivée de A dans la mesure où la présence de A est nécessaire au fonctionnement de B (si je retire A, B ne marche plus)
- Au contraire, A est indépendante de B : en tant que bibliothèque, elle n'a pas besoin de B
Ainsi si A est sous GPL, on ne peut pas distribuer B sous une autre licence que la GPL.
Par contre, B peut être distribué sous GPL sans que A le soit (si tant est que la licence de A est compatible avec la GPL).
[^] # Re: Architectures supportées
Posté par FreeB5D . Évalué à 0.
Mais à mon avis cette interprétation de la GPL est trop restrictive :
- déjà elle met beaucoup de monde hors-la-loi :
Supposons que A c'est kernel32.dll (ou user32.dll ou autre DLL système Window$) et B un programme GPL .
Beaucoup de gens lient B sous GPL avec A propriétaire, ils sont hors la loi .
- en liens dynamiques le programme ne garde pas de copie de la lib GPL :
la bibliothèque est partagée par les différents programmes en mémoire, et donc elle n'est copiée par aucun programme en particulier .
Ce qui est interdit, c'est par exemple de prendre le fichier algogénial.c et de le foutre dans un logiciel proprio .
<trolldudimanche> de toute façon la GPL c'est une blague, la seule licence qui respecte entièrement les 4 libertés définies par Stallman c'est le domaine public </trolldudimanche>
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 2.
Beaucoup de gens lient B sous GPL avec A propriétaire, ils sont hors la loi .
Non, parce que la GPL fait des exceptions pour les bibliothèques de base du système (cherche "System Libraries" dans le texte de la GPL v3 par exemple).
en liens dynamiques le programme ne garde pas de copie de la lib GPL
On se fiche de savoir si le programme "garde une copie" ou pas. Ce qui compte c'est la notion d'oeuvre dérivée (ou de "version modifiée" dans la GPL v3). Si un programme a besoin d'une bibliothèque pour fonctionner (que cette dernière soit liée dynamiquement ou statiquement), alors il doit respecter les termes de la licence de la bibliothèque.
Si ce n'était pas le cas la GPL n'aurait aucun intérêt par rapport à la LGPL (ou vice-versa).
PS : le domaine public n'est pas une licence...
[^] # Re: Architectures supportées
Posté par briaeros007 . Évalué à 2.
C'est un point qui reste très flou pour moi.
Qu'est ce qui empêche d'avoir une bibliothèque avec la même API (et abi) q'une GPL mais codé par soi ?
En quoi est ce interdit par la GPL? Car c'est quand même ce que ça veut dire en cas de liaison dynamiques!
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 2.
Ben, rien ne l'interdit, mais si une telle bibliothèque n'existe pas, la question ne se pose pas...
[^] # Re: Architectures supportées
Posté par lasher . Évalué à 2.
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 2.
Oui, et alors ? Il faut comprendre la portée d'une conditionnelle. Quand je dis "si une telle bibliothèque n'existe pas", ça veut dire qu'il faut examiner au cas par cas. S'il existe une implémentation des pthreads sous licence GPL, cela constitue un cas d'école intéressant. Mais la plupart des bibliothèques ("find /usr/lib -name *.so") n'ont pas d'équivalent interchangeable, parce qu'elles implémentent une API qui leur est propre.
[^] # Re: Architectures supportées
Posté par lasher . Évalué à 0.
Ensuite, je pense que tu peux au moins citer le cas de choses comme Mono, gnu classpath (au moins avant que Java ne soit vraiment libéré), les libc (qui ont des api -- voire des abi -- stables), etc.
En fait, dès qu'on parle « standard » (bon, ça, pas forcément) mais surtout de normes, il n'y a plus rien à dire, GPL, BSD, ou proprio, par définition, il faut pouvoir « interchanger » les appels de fonction (POSIX est l'exemple le plus criant, mais comme c'est un gros morceau de logiciel, je me permets de le recaser ici).
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 2.
Oui bien sûr. Mais ces bibliothèques ne sont pratiquement jamais sous GPL, parce que le but est de fournir un socle stable pour toutes les applications.
(note : GNU classpath est sous GPL mais avec une exception bizarrement rédigée qui implique qu'on peut tout de même lier des applis propriétaires avec)
En fait, dès qu'on parle « standard » (bon, ça, pas forcément) mais surtout de normes, il n'y a plus rien à dire, GPL, BSD, ou proprio, par définition, il faut pouvoir « interchanger » les appels de fonction
Oui mais si tu regardes dans un /usr/lib par exemple, la plupart des libs ne sont pas des implémentations de standards.
(c'était déjà dans mon message précédent, j'en déduis que tu oublies de lire les messages auxquels tu réponds...)
quand tu me cites mais que tu oublies la partie où je fais comprendre que j'ironise gentiment
Oh, tu es fâché parce que je n'ai pas cité ton smiley ?
Blague à part, c'est mignon de supputer la bêtise sans comprendre que mon argument était de portée générale et non spécifique à pthreads.
[^] # Re: Architectures supportées
Posté par lasher . Évalué à 1.
[^] # Re: Architectures supportées
Posté par Gniarf . Évalué à 3.
en fait la plateforme Alpha a carrément eclipsé les deux autres (Mips, PowerPC), oui.
[^] # Re: Architectures supportées
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Microsoft avait fait une couche d'adaptation des instructions 32 bits Intel vers le 64 bits alpha. Après un an de travaux, le directeur de digital a préféré jeter l'éponge car il payait une centaine de personnes pour obtenir un NT qui fonctionnait plus lentement que sur intel et qui coûtait beaucoup plus cher.
C'était très dévalorisant pour Alpha, un microprocesseur très en avance sur son temps.
C'est à peu près ce qui s'est passé avec les autres processeurs sur lesquels Microsoft s'est cassé les dents.
[^] # Re: Architectures supportées
Posté par Gniarf . Évalué à 3.
Alpha comme indiqué dans cet article et dans la version anglaise ca a duré bien plus longtemps
[^] # Re: Architectures supportées
Posté par inico (site web personnel) . Évalué à 1.
Dommage vu que la beta était vraiment sympathique.
[^] # Re: Architectures supportées
Posté par Antoine . Évalué à 1.
Que cherches-tu à prouver exactement ? L'OS lui-même fonctionnait, tout le problème était de faire fonctionner les applis x86 sur un processeur non-x86. A ce que je sache les *nix libres ne font pas mieux avec les applis x86 propriétaires.
pour obtenir un NT qui fonctionnait plus lentement que sur intel et qui coûtait beaucoup plus cher
Plus cher ?? C'est surtout le CPU qui était beaucoup plus cher à l'achat. En clair, le plantage commercial n'est pas dû à Microsoft mais à l'Alpha lui-même qui, bien que très performant, a subi la concurrence frontale du Pentium Pro et de ses successeurs beaucoup moins chers (grâce aux économies d'échelle dont bénéficie Intel).
Avant de vouloir faire passer les ingénieurs MS pour des guignols il vaudrait mieux faire preuve soi-même d'un minimum de rigueur...
[^] # Re: Architectures supportées
Posté par Gniarf . Évalué à 2.
la GPL v2 qui a fait avancer le libre depuis 10 ans ou la v3 qui est la plus grosse connerie depuis ne pas avoir enlevé et exilé MdI sur une ile déserte dès le départ ? puisqu'en pratique elle va rendre non redistribuable sous forme binaire des tas de projets libres
[^] # Re: Architectures supportées
Posté par FreeB5D . Évalué à 5.
Ce qui est tout l'intérêt de *BSD .
# Intéressant !
Posté par remyd1 . Évalué à 3.
En particulier :
"Support des disques et partitions de plus de 1 To (avec une limite provisoire à 2 To pour les partitions)."
Cool pour un serveur de fichier. Espérons que FreeNAS s'en inspirent puisque basé sur BSD.
L'amélioration des performances réseau est aussi une très bonne chose, en particulier pour une personne qui veut miser sur un pare-feu très sécurisé...
Vaut-il mieux miser sur un pare-feu sous BSD avec packet filter ou sous Linux avec iptables.... ??
[^] # Re: Intéressant !
Posté par patrick_g (site web personnel) . Évalué à 4.
D'après les tuto qu'on peut lire sur le net la syntaxe de pf est quand même bien plus simple et logique. Maintenant il existe aussi des distros Linux qui sont faites spécifiquement pour jouer le rôle de firewall et y'a une interface web d'administration qui est très simple à utiliser (SmoothWall ou IPCop).
C'est une question de gout et d'habitude je pense.
[^] # Re: Intéressant !
Posté par remyd1 . Évalué à 2.
Il n'y a qu'à voir toutes les alertes de sécurité concernant NuFW...
Mon but ici n'était évidemment pas de faire un troll, mais c'est une vraie question que je me pose... Packet Filter a l'air également meilleur au niveau des performances pour le traitement des trames, mais je ne crois pas qu'il y ai autant de possibilités que dans iptables.
[^] # Re: Intéressant !
Posté par Victor STINNER (site web personnel) . Évalué à 5.
http://secunia.com/advisories/17754/ - NuFW Packet Parsing Denial of Service Vulnerability (2005-11-29) => DoS
http://secunia.com/advisories/19046/ - NuFW TLS Socket Handling Denial of Service (2006-02-28) => DoS
http://secunia.com/advisories/26546/ - NuFW Time Based Filtering Rules Security Bypass (2007-08-21) => troué
http://secunia.com/advisories/27442/ - NuFW "samp_send()" Buffer Overflow Vulnerability (2007-10-30) => Dos
Seul un bug est exploitable : celui qui permet d'outrepasser les règles de filtrage basées sur le temps. Il faut comprendre ce que ça implique : si on bloque les connexions entre 22h et 5h, et bien un utilisateur pourra quand même se connecter la nuit. Mon dieu, c'est horrible ! Sauf que pour ouvrir une connexion, l'utilisateur doit déjà être authentifié et NuFW doit accepter son paquet (càd que l'admin autorise explicitement le flux, ce qui n'est pas autorisé est bloqué par défaut).
Il ne faut penser que la sécurité d'un logiciel repose sur le nombre de bulletins de sécurité. Beaucoup d'éditeurs (allez, citons Microsoft au pif) corrigent silencieusement des bugs (parfois critiques) dans des mises à jour sans en informer l'utilisateur. Sauf qu'avec une analyse différentielle, on peut retrouver ce genre de magouille... Et il y a toujours un grand débat entre « bug » et « vulnérabilité ». Relisez l'histoire du dernier bug IPv6 pour vous poiler :-)
[^] # Re: Intéressant !
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Avec l'URL c'est plus utile :
http://www.coresecurity.com/?action=item&id=1703
Court extrait :
2007-02-20: First notification sent by Core.
2007-02-26: OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote (...)
2007-02-26: Core considers a remote denial of service a security issue (...)
2007-02-28: OpenBSD team indicates that the bug (...)
2007-03-05: Core develops proof of concept code (...)
(.......)
2007-03-09: OpenBSD team changes notice on the project's website to "security fix" (...)
[^] # Re: Intéressant !
Posté par zul (site web personnel) . Évalué à 2.
http://www.openbsd.org/errata42.html.
Notons en particulier la taille de l'advisory sur OpenSSL par rapport à celui de FreeBSD par exemple.
http://security.freebsd.org/advisories/FreeBSD-SA-07:08.open(...)
[^] # Re: Intéressant !
Posté par Romeo . Évalué à 1.
L'errata est disponible pour tout le monde, le lien est présent dès la page d'accueil.
[^] # Re: Intéressant !
Posté par reno . Évalué à 1.
Je me souviens avoir du téléchargé 20Mo de patch de sécurité sur une distrib Linux toute fraiche..
Au moins avec OpenBSD, avec la distribution de patch sous forme source, tu peux utiliser un modem, pas besoin d'accès haut débit..
[^] # Re: Intéressant !
Posté par Gniarf . Évalué à 3.
[^] # Re: Intéressant !
Posté par bubar🦥 (site web personnel) . Évalué à 2.
la transparence et le côté open-source force à ce suivi.
c' est sûr que Checkpoint, par son côté closed-source, s' attribue plus de temps avant de publier des corrections. mais ça veut pas dire qu' il est pas troué...
si Iptables gèrent un paquet de protocole en natif ça ne veux pas dire que il est "plus complet" que PF. Sur PF si tu veux faire du SIP (vo/ip) il te faudra monter un proxy pour cela, car pf ne sait pas gérer le suivi de connections sur ce protocole.
Donc il me semble qu' on peux dire plutôt quelque chose comme "pour arriver aux mêmes buts, PF et Iptables nécessitent des voies (admin) différentes.
non ?
bon c' est sûr qu' a titre personnel, je préfères largement iptables à PF, mais c' est certainement parceque je suis feignant. (et si NuFW présente un jour une interface web de configuration de type "objet" j' y saute)
[^] # Re: Intéressant !
Posté par Victor STINNER (site web personnel) . Évalué à 2.
NuFW (fichier nuauth.conf) se configure avec un éditeur de texte pour le choix des modules et leurs options. Par contre, les ACLs (ce qui évolue le plus) se configurent avec l'interface web Nuface :
http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuFace
[^] # Re: Intéressant !
Posté par Eric Leblond (site web personnel) . Évalué à 1.
- d'utilisateurs
- de groupes
- d'applications
- de système d'exploitation
Pas grand chose à voir donc avec une distribution dédiée pare-feu dont le but est de fournir une interface "simplifiée" d'administration.[^] # Re: Intéressant !
Posté par zul (site web personnel) . Évalué à 2.
Personnellement je préfère la syntaxe de pf. Mais il faut reconnaitre que netfilter a un nombre très impressionnant de developpeurs et qu'ils ont pu developper des proxy pour les 3/4 des protocoles qui font des choses sales (en commencant par ftp, sip et cie). Tout dépend donc de tes besoins.
Concernant l'amélioration des performances réseaux, il est bien sûr intéressant mais la façon dont il a été fait frise l'hérésie totale du point de vue du logiciel ( et violation de l'abstration mbuf). Mais cela reste un point de vue personnelle :).
# ISO
Posté par ouah (site web personnel) . Évalué à 3.
3.3 - Does OpenBSD provide an ISO image for download?
Starting with OpenBSD 4.2, for select platforms, yes!
Note, this ISO is not the same as the official CD set. These images are for single platforms, and do not include any of the pre-compiled packages, stickers, or artwork that the official CD set does.
[^] # Re: ISO
Posté par Anonyme . Évalué à 1.
Ca ne m'a pas empêché d'acheter ma 4.2 release, la semaine dernière :-)
[^] # Re: ISO
Posté par bubar🦥 (site web personnel) . Évalué à 2.
# Xen
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Xen
Posté par manu_fred . Évalué à 1.
[^] # Re: Xen²
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
A mon avis, ils font erreur sur ce point car pouvoir tourner en paravirtualisé, en plus d'être efficasse en terme de performance, est très productif tant au niveau développement système que pour un administrateur système de base tel que moi !
Dommage, c'est pas demain que je vais avoir un OpenBSD chez moi. Je n'ai aucune machine à lui dédier entièrement.
[^] # Re: Xen²
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne crois pas qu'ils aient dit le contraire.
J'ai l'impression qu'ils disent juste que c'est un trou de sécurité potentiel supplémentaire.
(comme tout code supplémentaire, pour traduire ce qu'ils disent en gros : ce sont les même gars qui ont fait des trous de sécu dans le code d'avant qui codent la virtualisation, et tu crois qu'ils vont arrêter de faire des trous juste parce que c'est de la virtualisation?)
[^] # Re: Xen²
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Il n'empêche que je continue à ne pas être d'accord sur le fond. Avec la paravirtualisation, l'OS invité n'a accès qu'a quelques hypercalls, en nombre réduit et lus et relus alors que donner l'accès au matériel est bien plus dangereux.
Si le dom0 est bien verrouillé (dans un VLAN différent, sur une autre carte réseau...), j'ai le sentiment (aucune preuve) que l'on augmente la sécurité : en diminuant les possibilités d'accès au matériel du guest, en permettant le contrôle de ce guest de manière indirecte. Par exemple, en faisant un snapshot LVM depuis le dom0, on peut vérifier régulièrement et sans que le guest ne s'en rende compte, de l'intégrité du système de fichier de ce guest.
Bref, il n'y a aucun argument aujourd'hui qui me donne envie de monter un serveur qui ne soit pas paravirtualisé.
[^] # Re: Xen²
Posté par Psychofox (Mastodon) . Évalué à 4.
c'est un question de point de vue et tout dépend à quoi on le compare.
imaginons les cas suivants :
1) 5 machines, chacune dédiée à une application spécifique.
2) 1 machine avec 5 applications différentes
3) 1 hôte de virtualisation avec 5 machines virtuelles dédiées chacune à une application.
Les leaders du projet OpenBSD partent du postulat que la solution 3) est forcément moins sécurisée que la solution 1) car des potentiels trous de sécurités peuvent exister et que l'architecture x86 ne l'est pas.
Par contre c'est sur que si tu compares la solution 1) avec la solution 3), il est vrai que la solution 3) est plus sécurisée.
Je crois que c'est de la que vient l'incompréhension, à la fois ici, et dans la mailing list. Il faut d'abord préciser quelle archi on compare...
[^] # Re: Xen²
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu ne te serais pas emmêlé les pinceaux?
Tu voulais dire que la solution 3 est plus sécurisé que la solution 2 (que tu comparerais) plutôt?
[^] # Re: Xen²
Posté par Psychofox (Mastodon) . Évalué à 2.
[^] # Re: Xen²
Posté par Zenitram (site web personnel) . Évalué à 6.
C'est du code, donc potentiellement troué.
Non, car le matériel, c'est du matériel, il peut mourrir cramé je m'en fou, ce qui est important est la sécurité des données, et un soft qui a accès à la machine entière ne pourra quand même pas avoir accès à d'autres applications sur d'autres machines.
Le matériel, c'est du matériel, réplicable.
Les données, c'est sensible, leur accès aussi.
Si tu te fous de la sécurité, ou que la sécurité nécessaires à tes données est moins importante que ta réduction de cout, OK.
Mais si tu crois qu'une solution 1 serveur avec 5 VM est plus secure que 5 machines avec pas de VM, tu as gobé le marketing des vendeurs de VM, je ne t'embaucherai jamais comme conseil sécurité.
[^] # Re: Xen²
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Par contre, j'ai un certain de serveur pour mon laboratoire de recherche et pour moi la sécurité est meilleure en paravirtualisé.
- Il est plus facile d'avoir un service - un OS donc je le fait et je n'ai pas deux services sur la même machine.
- Corrolaire du premier point, j'ai moins de machine physique, je consomme moins et j'ai des machines plus récentes et non des vieux clous.
- Il est facile de migrer une machine virtuelle d'un serveur physique sur un autre. S'il le faut, je la cloisonne dans un VLAN.
- Je fais des backup à chaud via LVM sans que la machine ne s'en rende compte. Il est alors trivial de voir si j'ai toujours l'intégrité des binaires.
- La machine n'a aucun accès à une carte graphique... Pour sortir, elle doit franchir les hypercall de Xen. Selon la config faite sur le dom0, la machine virtuelle ne peut pas écouter ce qui se passe sur le réseau.
- Ayant gagné en productivité, j'ai pu dissocier des services de serveur, réduire le nombre de serveur physique et augmenter le nombre de serveurs virtuels.
Donc au global, je considère que j'ai gagné en sécurité. Le modèle 1 => un service, un OS, une machine physique n'est pour moi pas réalisable en pratique.
[^] # Re: Xen²
Posté par ErrTu . Évalué à 2.
Le paravirtualisé, c'est pratique, ça apporte des fonctionnalités intéressantes, ça fait économiser de l'argent, ça fait consommer moins d'électricité et ça sauve des ours.
Mais si jamais un des OS virtualisés est infecté, alors il est possible que l'hyperviseur se fasse infecté lui-aussi. Et là, c'est la catastrophe car depuis l'hyperviseur on peut modifier toutes les OS virtualisés et ces-derniers ne peuvent s'en prémunir. Même si l'OS virtualisé est une forteresse imprenable, il tombera quand même si sa mémoire est modifiée par l'hyperviseur.
[^] # Re: Xen²
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
> que l'hyperviseur se fasse infecté lui-aussi.
Oui mais comment remontes-tu au dom0 ?
Je suis d'accord, si le dom0 tombe, c'est la cata mais avoir 50 machines physiques qui ont chacun un service et un seul, faut aussi arriver à le gérer d'un point de vue sécurité...
Si tu remontes du guest vers le dom0 via la couche réseau, tu peux aussi faire l'hypothèse que si tes OS sont les mêmes, un pirate arrivera à faire la même chose entre deux machines physiques...
Xen n'est pas idéal mais je n'ai pas l'impression que la sécurité soit plus mauvaise. Il y a des points négatifs mais il y en a aussi des positifs.
[^] # Re: Xen²
Posté par Zenitram (site web personnel) . Évalué à 5.
Drôle de postulat.
Xen est un logiciel, fait par des humains qui ont pour habitude de faire des bugs dans les logiciels. Pourquoi Xen dérogerait-il à la règle?
Tu nous parles de la couche réseau, on parle depuis le début du code exécutable que tu rajoutes en plus à ta machine, code qui peut être buggé. On s'en fout de la couche réseau, le risque est identique quelque soit la solution.
Tu ajoutes une voie supplémentaire possible pour un attaquant, et tu crois qu'il ne va pas essayer de l'utiliser? Ouvre les yeux, regarde ce que tu fais : tu rajoutes des possibilités d'attaque.
Le pire est que tu peux avoir X applis robustes aux attaques, il en faut une, et une seule, pour que tes applis se fasse trouées dans le cas où une petites faille locale sur Xen arrive.
Donc il faut que tu puisses garantir que aucune de tes X applis n'a de trou de sécurité, ça démultiplie les risques de façon importante.
Tu es prêt à prendre le risque? OK, mais informe quand même tes supérieurs, sinon ça pourra te faire très très mal...
De plus, un administrateur d'une de tes applis peut très bien vouloir attaquer les autres applis, il lui suffit d'une faille locale de Xen pour qu'il ait accès aux autres applis comme il veut, sans besoin de droits sur ces autres applis. Super.
On a jamais dit le contraire. On a juste dit que la sécurité ne fait pas partie des points positifs, et est même un point négatif.
Faut juste le savoir quand tu utilises Xen. Après, tout dépend de ton niveau de sécurité demandé. Si il est faible, OK. Si il est haut, tu as fais une connerie dans ton choix de solution technique, surtout si tu n'as pas indiqué au décideur qu'il y a un risque potentiel d'attaque.
[^] # Re: Xen²
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Tu peux faire cela sans Xen mais pas avec les mêmes moyens...
Ensuite, il est clair qu'il y a un curseur au niveau de la sécurité. Si ton curseur est haut, tu ne vas pas mettre ta machine sur le courant EDF car tout remontes dedans et tu va avoir une pièce qui fera cage de Faraday... Avec 10 machines virtuelles dans un hôte Xen, au niveau électrique, cela doit être le bordel pour récupérer quoi que ce soit...
Ensuite, je ne sais pas pour vous mais pour moi, je fais de tout, du support utilisateur à l'appel d'offre national... Du coup, soit la sécurité est torché car le sytème d'information trop compliqué, trop de machine, trop de panne... Avec Xen, j'ai retrouvé du temps donc j'ai pu améliorer la sécurité de chaque poste. Au global, mon système d'information est plus sain et plus clair.
Certes, mon système n'est pas infaillible mais je ne suis pas le seul à le faire... Je préfère avoir deux serveurs sans X minimaliste et bien gérer sous Xen que deux machines qui font serveur avec X comme on en voit beaucoup.
Si j'ai trois serveurs web à faire sous apache, je monte trois machines sous Xen et chaque serveur n'a que les paquets et les modules Apache qu'il faut. Combien de fois j'ai vu des serveurs Apache avec bien trop de module d'activé !
[^] # Re: Xen²
Posté par Psychofox (Mastodon) . Évalué à 2.
Et c'est la qu'on oppose le cas par cas et la pratique.
Dans ton cas, tu as des moyens techniques et humains limités, donc tu dois daire un compromis. Mais dans l'absolu une archi 1 machine 1 os 1 appli serait plus sécurisée.
Bref tout le monde est d'accord, mais la pratique montre parfois qu'il est nécessaire de faire des compromis et des choix dans ce métier en fonction de ses besoins et moyens.
[^] # Re: Xen²
Posté par lasher . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.