Articles précédents : BSD
- [11] En route vers FreeBSD 7
- [13] Des nouvelles de FreeBSD
- [47] FreeBSD utilise les pilotes Linux
- [12] ZFS porté sur FreeBSD 7
- [41] Sortie de FreeBSD 6.2
- [28] Sortie de NetBSD 3.1
- [56] Sortie d'OpenBSD 4.0
- [27] Intel seulement open pour le business
- [113] L'alternative BSD
- [4] Sortie de NetBSD 3.1 RC1
Liens connexes
- OpenBSD (1176 clics)
- Les nouveautés de la version 4.2 (660 clics)
- La liste complète des changement (313 clics)
- Le journal des news OpenBSD (276 clics)
- Une longue interview des développeurs sur OpenBSD 4.2 (347 clics)
Dépêche modérée par
Dépêche éditée par
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.
![[fr]](../../../images/fr.png)
OpenBSD (1176 clics)![[en]](../../../images/en.png)
Les nouveautés de la version 4.2 (660 clics)-
La liste complète des changement (313 clics)
-
Le journal des news OpenBSD (276 clics)
-
Une longue interview des développeurs sur OpenBSD 4.2 (347 clics)
> Lire la suite (153 commentaires, moyenne: 2,6). [dépêche : 4559 caractères]
- 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.
Chanson
Comme toujours lors de la sortie d'OpenBSD je trouve la chanson amusante, et en particulier les dessins qui vont avec.
-
[^]Re: Chanson
Posté par Nicolas Legrand () le 02/11/2007 à 13:34. (lien). Évalué à 7.J'avoue que je suis assez fan aussi et que j'ai envie d'avoir plein de poster et de t-shirt. D'ailleurs, quand on me demande pourquoi j'utilise OpenBSD, je réponds que le poisson est tellement kiki que j'ai envie d'en installer partout. Heureusement le système est aussi simple, beau, efficace et performant.
-
[^]Re: Chanson
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 03/11/2007 à 21:03. (lien). Évalué à 1.J''ai installé openBSD vers mai-juin par curiosité.
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 () le 03/11/2007 à 23:57. (lien). Évalué à 3.Est-ce qu'il y a un système genre HAL dans les *BSD pour les branchement à chaud?
/sbin/reboot ?-
[^]Re: Chanson
Posté par zul (Jabber id, page perso, ) le 04/11/2007 à 10:36. (lien). Évalué à 4.Sous FreeBSD, HAL tourne très bien.
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 () le 05/11/2007 à 14:53. (lien). Évalué à 2.Simple et beau, bon c'est pas vraiment les termes qui me viennent à l'esprit quand j'y pense.
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 () le 06/11/2007 à 13:38. (lien). Évalué à 5.Franchement, je trouve ça marrant, c'est ce qu'on pouvait entendre de Linux il y a quelques temps "pour un firewall, c'est bien". Moi je trouve OpenBSD bien comme système tout court et je l'utilise dans la vie de tous les jours pour le travail et les loisirs. Évidemment c'est pas fluffy flashy comme un GNU/Linux, mais le système est tout simplement simple et clair, parce que bien documenté.
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 Mathieu Stumpf (Jabber id, page perso, ) le 07/11/2007 à 12:34. (lien). Évalué à 2.Bon d'accord, mais est-ce qu'il y a une gestion des branchements de périphériques de masse à chaud?
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 () le 07/11/2007 à 15:39. (lien). Évalué à 1.il n'y a pas d'équivalent à udev si c'est ce que tu recherches. Mais bon un branchement à chaud n'est pas si compliqué que ça. Un petit tail de /var/log/messages suivi d'un sudo mount /dev/<ledevicebranché> /point/de/montage ne prends pas 3 plombes non plus...
Bref tu devras lâcher la souris de temps en temps...-
[^]Re: Chanson
Posté par ErrTu () le 07/11/2007 à 16:07. (lien). Évalué à 1.Il y a hotplugd(8) qui permet d'effectuer automatiquement des actions lorsqu'on branche une clé usb, un cable réseau, ... (il y a un exemple de script dans la page de man).
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
Avec Intel, HPPA, Alpha et sparc64, ça fait quatre architectures supportées. Si on est loin de la vingtaine d'architectures que supporte Linux, le score est très au dessus de Microsoft qui s'est planté sur Alpha, Mips, PowerPC et Itanium pour retomber au score de 1 !
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 () le 02/11/2007 à 00:29. (lien). Évalué à 10.Supported platforms
OpenBSD is officially supported on the following platforms. Official support means that the release install media is known to work, that the architecture can self-compile itself, and that most of the basic tools exist on the architecture. As well, releases always exist, and there are attempts to make snapshots available on a regular basis.
alpha Digital Alpha-based systems
amd64 AMD64-based systems
armish ARM-based appliances (by Thecus, IO-DATA, and others)
hp300 Hewlett-Packard HP 9000 series 300 and 400 workstations
hppa Hewlett-Packard Precision Architecture (PA-RISC) systems
i386 Standard PC and clones based on the Intel i386 architecture and compatible processors
landisk IO-DATA Landisk systems (such as USL-5P) based on the SH4 cpu
luna88k Omron LUNA-88K and LUNA-88K2 workstations
mac68k Motorola 680x0-based Apple Macintosh with MMU
macppc Apple New World PowerPC-based machines, from the iMac onwards
mvme68k Motorola 680x0-based VME systems
mvme88k Motorola 881x0-based VME systems
sgi SGI MIPS-based workstations
sparc Sun sun4, sun4c and sun4m class SPARC systems
sparc64 Sun UltraSPARC systems
vax Digital VAX-based systems
zaurus Sharp Zaurus C3x00 PDAs
Active porting efforts
The following ports are not officially supported, and are not on par with supported platforms, but they are being worked on actively and may hopefully become supported platforms in the future. There is normally no official release for these architectures yet, but normally the in-progress source code is checked into the repository, and there is an attempt to start making snapshots.
aviion Motorola M881x0-based Data General AViiON systems
hppa64 Hewlett-Packard Precision Architecture (PA-RISC) 64 bit systems
solbourne Solbourne ``IDT'' Sparc-like S3000, S4000 and S4000DX systems
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 () le 02/11/2007 à 07:04. (lien). Évalué à -1.> donc le soucis des contributeurs n'est pas du à la licence
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 () le 02/11/2007 à 07:13. (lien). Évalué à 4.beaucoup de développeurs n'aiment pas non plus la GPL.
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 () le 02/11/2007 à 08:02. (lien). Évalué à 4.> beaucoup de développeurs n'aiment pas non plus la GPL.
> 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
-
[^]Re: Architectures supportées - le pied dedans
Posté par Pas d'utilisateur! le 02/11/2007 à 08:42. (lien). Évalué à 3.Bon, tout d'abord, on est loin des "6" architectures supportées, mais alors bien loin...
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 () le 02/11/2007 à 09:25. (lien). Évalué à 3.> Bon, tout d'abord, on est loin des "6" architectures supportées, mais alors bien loin...
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 () le 02/11/2007 à 10:11. (lien). Évalué à 4.moi j'en vois que deux. et deux variantes en 64 bits
(c'est vendredi, c'est permis)--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.-
[+] [^]Re: Architectures supportées - le pied dedans
Posté par IsNotGood () le 02/11/2007 à 10:37. (lien). Évalué à -1.> moi j'en vois que deux. et deux variantes en 64 bits
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 (page perso, ) le 02/11/2007 à 13:19. (lien). Évalué à 3.J'ai hésité entre 3 et 4. Mais i386 et x86_64 c'est bien différent.
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 () le 02/11/2007 à 08:10. (lien). Évalué à 4.La licence, c'est leur choix, ils font ce qu'ils veulent. Et l'important pour le reste du monde, c'est que ça soit compatible avec la GPL, comme l'explique très bien [1].
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 (Jabber id, page perso, ) le 03/11/2007 à 20:54. (lien). Évalué à 2.> Et puis, la licence BSD est quand même reconnue libre par la FSF
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 !--
Th. Thomas.
-
-
[^]Re: Architectures supportées
Posté par beagf (page perso, ) le 02/11/2007 à 09:02. (lien). Évalué à 10.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 !
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
-
[^]Re: Architectures supportées
-
[^]Re: Architectures supportées
Posté par JoeBlack (Jabber id, ) le 02/11/2007 à 13:27. (lien). Évalué à 2.Vivre libre et ne pas mourir :)
-
[^]Re: Architectures supportées
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 03/11/2007 à 21:04. (lien). Évalué à 1.C'est toi Mac Leod?
-
-
-
-
-
[^]Re: Architectures supportées
Posté par Troy McClure (page perso, ) le 02/11/2007 à 09:03. (lien). Évalué à 4.le score est très au dessus de Microsoft qui s'est planté sur Alpha, Mips, PowerPC et Itanium pour retomber au score de 1 !
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 (Jabber id, page perso, ) le 02/11/2007 à 09:31. (lien). Évalué à 9.En même temps, y'a combien de distributions qui supportent plus de 4 architectures ( ne parlons pas de 10 ca sera malhonnête de ma part).
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 () le 02/11/2007 à 10:23. (lien). Évalué à -4.> mais quand il s'agit d'une distrib complete, c'est beaucoup moins impressions.
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 (Jabber id, page perso, ) le 02/11/2007 à 11:13. (lien). Évalué à 8.>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.
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 () le 02/11/2007 à 11:25. (lien). Évalué à -1.> sous une licence moins contaminante (je persiste et je signe).
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 (page perso, ) le 02/11/2007 à 12:19. (lien). Évalué à 7.Trouve moi un cas où la GPL a contaminé du code
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 () le 02/11/2007 à 12:32. (lien). Évalué à 7.Le principe de la GPL est justement de favoriser la diffusion de logiciels libres par la contamination comme tu dis.
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 (Jabber id, page perso, ) le 02/11/2007 à 13:40. (lien). Évalué à 1.Si la GPL empechait uniquement l'utilisation dans le code proprio, on pourrait l'excuser (et encore, je préfére un bon bout de code libre dans un logiciel proprio qu'une mauvaise implémentation écrite par leurs doigts).
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 () le 02/11/2007 à 14:36. (lien). Évalué à 5.Mais elle empeche l'utilisation du code GPL dans la BSD et tous ses dérivés et bien d'autres licences "libre".
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 ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par zul (Jabber id, page perso, ) le 02/11/2007 à 15:07. (lien). Évalué à 1.> En gros elle empeche les licence libres qui ne garantissent pas que l'utilisateur conservera sa liberté.
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 () le 02/11/2007 à 15:14. (lien). Évalué à 0.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
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par zul (Jabber id, page perso, ) le 02/11/2007 à 15:32. (lien). Évalué à 1.Ton utilisateur developpeur a fait le choix d'une plateforme non-libre. C'est son choix. Il devrait savoir que son choix a des conséquences sur ses futurs développements.
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 () le 02/11/2007 à 16:46. (lien). Évalué à 1.> Ton utilisateur developpeur a fait le choix d'une plateforme non-libre.
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 (Jabber id, page perso, ) le 02/11/2007 à 17:04. (lien). Évalué à 2.Tes argumentations ressemblent vraiment de moins en moins à quelquechose.
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 () le 02/11/2007 à 17:48. (lien). Évalué à 0.> 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.
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 (Jabber id, page perso, ) le 02/11/2007 à 18:14. (lien). Évalué à 2.> 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 :-)).
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 (page perso, ) le 02/11/2007 à 18:58. (lien). Évalué à 4.Désolé mais je ne veux pas que mon code aide ce type de truc.
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...
On peut avoir des implémentations de DRM libre.
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 () le 02/11/2007 à 19:01. (lien). Évalué à -1.Si ce code n'existait pas, il l'écrirait.
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par zul (Jabber id, page perso, ) le 02/11/2007 à 19:37. (lien). Évalué à 2.> 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.
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 () le 02/11/2007 à 20:01. (lien). Évalué à -1.Je ne vois pas quelle liberté l'utilisateur a-t-il perdu ?
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par Moonz () le 02/11/2007 à 20:54. (lien). Évalué à 6.Résumons....
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 () le 04/11/2007 à 18:01. (lien). Évalué à 3.*** Disclaimer ***
Attention, ceci pourrait heurter les sensibilités
Le troll peut provoquer des dégâts irrémédiables.
******************
Pour moi, ça se réduit à néant...
[ 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 () le 02/11/2007 à 21:07. (lien). Évalué à 4.Je ne vois pas quelle liberté l'utilisateur a-t-il perdu ?
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.
AHAHAHAHAHAHAHA
argument de l'année !-
[+] [^]Re: Architectures supportées
Posté par briaeros007 () le 02/11/2007 à 23:29. (lien). Évalué à -1.sauf que l'argument il est dvp après ...
Faut lire plus que les deux lignes du commentaire. L'argument vaut ce qu'il vaut, mais il est là, ... lui.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
[^]Re: Architectures supportées
Posté par PsychoFox () le 02/11/2007 à 21:17. (lien). Évalué à 5.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.
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 (page perso, ) le 02/11/2007 à 21:54. (lien). Évalué à 6.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.
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 () le 02/11/2007 à 23:13. (lien). Évalué à 2.Après il ne faut pas se leurrer, si vous pensez qu'il n'y a jamais de code GPL utilisé dans des logiciels propriétaires, c'est que vous vivez dans le monde de Bisounours.
-
[^]Re: Architectures supportées
Posté par briaeros007 () le 02/11/2007 à 23:31. (lien). Évalué à 2.sauf que c'est illégal, donc si tu le vois, tu peux faire qqch.
(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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par Romain () le 03/11/2007 à 00:01. (lien). Évalué à 1.Le fait est que tu n'as pas accès au code d'un logiciel propriétaire, donc que de toute façon quand c'est fait tu ne peux pas le savoir.
-
[^]Re: Architectures supportées
Posté par inico (Jabber id, page perso, ) le 03/11/2007 à 12:34. (lien). Évalué à 3.Ca dépend.
Zlib est detectable dans beaucoup de logiciel proprios.
Tout comme libpng, openssl, qt ...--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
-
-
-
[^]Re: Architectures supportées
-
-
[^]Re: Architectures supportées
Posté par ErrTu () le 03/11/2007 à 00:01. (lien). Évalué à 8.Mais il restera toujours une poignée d'irréductibles utilisateurs soucieux de leurs libertés - et tous les développeurs d'OpenBSD - pour faire avancer le projet. Ceux-là ne nagent pas pour gagner, ils ne perdront jamais.
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 (page perso, ) le 04/11/2007 à 09:57. (lien). Évalué à 3.La licence BSD a été créée pour permettre à des étudiants de Berkeley d'utiliser leurs travaux pour monter leur entreprise. Ceci était fait dans la logique des années 80 où le but était de vendre du code compilé.
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 () le 04/11/2007 à 14:22. (lien). Évalué à 6.Super exemple, PostgreSQL est sous licence BSD...
--
vjm-
[+] [^]Re: Architectures supportées
Posté par Pierre Jarillon (page perso, ) le 05/11/2007 à 12:39. (lien). Évalué à -2.Que ce serait-il passé si le logiciel de départ avait utilisé la licence GPL au lieu de BSD ? Ingres aurait été fourni avec son code.
À 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 () le 05/11/2007 à 12:54. (lien). Évalué à 6.> Postgresql aurait été aux bases de données ce que Apache est aux serveurs web.
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 (page perso, ) le 06/11/2007 à 21:04. (lien). Évalué à 3.- Postgresql aurait été aux bases de données ce que Apache est aux serveurs web.
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 () le 03/11/2007 à 08:26. (lien). Évalué à 3.tu mélanges libertés des utilisateurs et marketing.
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 (page perso, ) le 03/11/2007 à 11:03. (lien). Évalué à 2.>>> Ben soit, qu'il en soit ainsi. C'est la loi du marché.
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 () le 03/11/2007 à 12:08. (lien). Évalué à 4.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 ?
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.
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
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 (Jabber id, page perso, ) le 03/11/2007 à 14:03. (lien). Évalué à 3.La seule chose qui favorise le monopole c'est la désinformation et le manque de connaissance globale des problèmes.
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 Pas d'utilisateur! le 03/11/2007 à 17:15. (lien). Évalué à 4.Je me sens obligé de sortir de dire que j'approuve complètement ce message.
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 (page perso, ) le 03/11/2007 à 17:49. (lien). Évalué à 5.Je me trompe ?
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 () le 05/11/2007 à 11:18. (lien). Évalué à 0.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.
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).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par zul (Jabber id, page perso, ) le 05/11/2007 à 15:27. (lien). Évalué à 4.Je suis tout à fait d'accord sur ce point. Ca vaut pour tout le monde ...
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 () le 05/11/2007 à 19:00. (lien). Évalué à 1.Pas totalement (que d'incompréhension mes aïeux)
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
-
[^]Re: Architectures supportées
Posté par kimelto () le 03/11/2007 à 11:16. (lien). Évalué à 4.En terme de théorie des jeux la licence BSD encourage la défection alors que la licence GPL force à la coopération.
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 () le 03/11/2007 à 14:07. (lien). Évalué à -1.je suppose que les diverses associations loi 1901 de défense des libertés individuelles qui te demandent une inscription pour gonfler leurs chiffres donc leur représentativité et une cotisation du genre un euro l'année tu les traites de nazis aussi ?
--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.-
[^]Re: Architectures supportées
Posté par Pierre Jarillon (page perso, ) le 04/11/2007 à 09:42. (lien). Évalué à 2.Et un point Godwin !
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
-
-
[^]Re: Architectures supportées
-
-
[^]Re: Architectures supportées
Posté par Antoine () le 03/11/2007 à 15:53. (lien). Évalué à 4.Où est l'esprit de la licence MIT, MIT où travaillait RMS !
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 () le 03/11/2007 à 16:43. (lien). Évalué à 3.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é
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 () le 04/11/2007 à 09:30. (lien). Évalué à 7.Pour les avantages de la BSD, je formulerai différemment :
- 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 (page perso, ) le 04/11/2007 à 15:32. (lien). Évalué à 2.>>> À 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).
Clair que c'est dommage que ce soit parti en vrille mais bon.....
-
-
-
[^]Re: Architectures supportées
Posté par ph11 () le 07/11/2007 à 21:38. (lien). É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 () le 07/11/2007 à 20:47. (lien). Évalué à 2.>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".
Au moins, tu sauras que son fusil est de bonne qualité.
-
-
-
[^]Re: Architectures supportées
Posté par Pas d'utilisateur! le 02/11/2007 à 19:08. (lien). Évalué à 6.Le plus bel exemple que j'ai à donner pour comprendre l'intérêt de la licence BSD reste MacOS X. Apple, contrairement à Microsoft, a parfaitement compris qu'en se basant sur les sources de FreeBSD, ils auraient tout à y gagner.
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 () le 07/11/2007 à 22:06. (lien). Évalué à 1.Mais si MS créait un système entièrement basé sur BSD, le problème , pour eux serait, que cela rendrait trop facile pour les devs de porter leurs logiciels proprio MS sous BSD ou linux.
À 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 () le 02/11/2007 à 20:30. (lien). Évalué à 3.> brevet
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 (page perso, ) le 02/11/2007 à 22:30. (lien). Évalué à 2.* on peut très bien faire un système DRM en GPL
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 () le 02/11/2007 à 21:43. (lien). Évalué à 7.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 :-)).
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 () le 02/11/2007 à 20:24. (lien). Évalué à 2.> BSD a fait le choix d'une licence qui est compatible proprio
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
-
[^]Re: Architectures supportées
Posté par Moonz () le 02/11/2007 à 14:27. (lien). Évalué à 0.Et si je veux faire du libre non-GPL, je ne pompe pas de ligne GPL non plus ? Bel esprit de partage...
-
[^]Re: Architectures supportées
Posté par IsNotGood () le 02/11/2007 à 16:51. (lien). Évalué à 2.> Et si je veux faire du libre non-GPL, je ne pompe pas de ligne GPL non plus ? Bel esprit de partage...
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
-
-
-
-
[^]Re: Architectures supportées
Posté par IsNotGood () le 02/11/2007 à 13:59. (lien). Évalué à 3.> La GPL, par son utilisation, impose sa licence sur du code qui n'est pas à elle.
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 () le 02/11/2007 à 14:31. (lien). Évalué à 3.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.
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 ;))--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par Zenitram (page perso, ) le 02/11/2007 à 15:44. (lien). Évalué à 4.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).
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 () le 02/11/2007 à 17:09. (lien). Évalué à -1.> - La GPL, certaines licences proprio sont "virales"
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 (page perso, ) le 02/11/2007 à 19:04. (lien). Évalué à 2.La FSF le sait si bien qu'il y a la LGPL.
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
-
-
-
-
-
-
-
-
-
[^]Re: Architectures supportées
Posté par imalip (page perso, ) le 03/11/2007 à 00:37. (lien). Évalué à 2.développeurs qui sont obligés d'utiliser la GPL parce qu'ils utilisent une lib GPL.
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.--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: Architectures supportées
Posté par Antoine () le 03/11/2007 à 15:59. (lien). Évalué à 4.Si on utilise une lib GPL *RIEN* n'oblige a utiliser la GPL pour son propre code.
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 () le 03/11/2007 à 18:02. (lien). Évalué à 1.Whaou le troll !
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 .--
Linux çapu, mais quand Windows est concerné Linux c'est génial .-
[^]Re: Architectures supportées
Posté par Antoine () le 04/11/2007 à 00:14. (lien). Évalué à 4.Un bibliothèque et un programme n'ont aucune distinction .
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 () le 04/11/2007 à 20:05. (lien). Évalué à 0.Si B est compatible GPL, il n'y a aucun problème puisqu'on peut le mettre sous GPL .
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>--
Linux çapu, mais quand Windows est concerné Linux c'est génial .-
[^]Re: Architectures supportées
Posté par Antoine () le 05/11/2007 à 01:29. (lien). Évalué à 2.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 .
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 () le 05/11/2007 à 11:23. (lien). Évalué à 2.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.
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!--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Architectures supportées
Posté par Antoine () le 05/11/2007 à 13:27. (lien). Évalué à 2.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 ?
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 () le 06/11/2007 à 13:16. (lien). Évalué à 2.Ah bon ? Donc les implémentations libres ou proprio des pthreads n'ont pas la même api (voire abi) ? :-)
-
[^]Re: Architectures supportées
Posté par Antoine () le 07/11/2007 à 11:00. (lien). Évalué à 2.Donc les implémentations libres ou proprio des pthreads n'ont pas la même api (voire abi) ?
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 () le 07/11/2007 à 12:58. (lien). Évalué à 0.Je comprends parfaitement ce qu'est « une conditionnelle » comme tu le dis si elliptiquement bien. Maintenant, quand tu me cites mais que tu oublies la partie où je fais comprendre que j'ironise gentiment -- à la limite de la bêtise, c'est-à-dire quand tu coupes mon smiley, tu fais dire à ma phrase autre chose que ce que je voulais je pense.
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 () le 07/11/2007 à 17:41. (lien). Évalué à 2.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)
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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Architectures supportées
Posté par Gniarf () le 02/11/2007 à 10:44. (lien). Évalué à 3.Microsoft s'est planté sur l'Alpha ? première nouvelle.
en fait la plateforme Alpha a carrément eclipsé les deux autres (Mips, PowerPC), oui.--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.-
[^]Re: Architectures supportées
Posté par Pierre Jarillon (page perso, ) le 02/11/2007 à 23:36. (lien). Évalué à 2.Oui, Microsoft s'est planté sur l'Alpha : http://fr.wikipedia.org/wiki/DEC_Alpha
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 () le 03/11/2007 à 00:38. (lien). Évalué à 3.ah pardon, Mips et PowerPC c'en est resté avec la version 3.51 de Windows NT et des ventes de moins de 100 licences pour l'un d'eux (PowerPC je pense), une demande quasi inexistante.
Alpha comme indiqué dans cet article et dans la version anglaise ca a duré bien plus longtemps--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.-
[^]Re: Architectures supportées
Posté par inico (Jabber id, page perso, ) le 03/11/2007 à 12:39. (lien). Évalué à 1.Jusqu'a Windows 2000 dont la version RTM pour alpha aurait été compilé et utilisé en interne chez Microsoft.
Dommage vu que la beta était vraiment sympathique.--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
-
-
[^]Re: Architectures supportées
Posté par Antoine () le 03/11/2007 à 16:06. (lien). Évalué à 1.Microsoft avait fait une couche d'adaptation des instructions 32 bits Intel vers le 64 bits alpha.
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 () le 02/11/2007 à 09:58. (lien). Évalué à 2.> Mon seul regret, c'est que BSD ne soit pas sous licence GPL, OpenBSD aurait eu plus de contributeurs et de succès...
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--
The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
-
[^]Re: Architectures supportées
Intéressant !
Une bonne nouvelle cette sortie.
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 (page perso, ) le 02/11/2007 à 09:08. (lien). Évalué à 4.>>> Vaut-il mieux miser sur un pare-feu sous BSD avec packet filter ou sous Linux avec iptables.... ??
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 remy_d1 () le 02/11/2007 à 09:19. (lien). Évalué à 2.En fait, j'ai déjà administré et configuré un Pare-feu sous iptables. Cependant, concernant les distribs spécifiques du type smoothwall et IPCop, je me méfie de la couche rajoutée par le côté "simplifié".
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 (Jabber id, page perso, ) le 02/11/2007 à 10:04. (lien). Évalué à 5.Quoi ! NuFW troué ? INL, société éditrice de NuFW, a choisi la transparence : les bugs corrigés pouvant affecter la sécurité sont marqués « correctif de sécurité ». Voici l'ensemble des bulletins de sécurité depuis la naissance du projet (~5 ans) :
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 (Jabber id, page perso, ) le 02/11/2007 à 10:44. (lien). Évalué à 3.Relisez l'histoire du dernier bug IPv6 pour vous poiler :-)
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 (Jabber id, page perso, ) le 02/11/2007 à 11:36. (lien). Évalué à 2.Tant qu'on rigole sur la transparence de OpenBSD sur la sécurité, pensez à patcher votre OpenBSD fraichement moulé 4.2 parce qu'il y'a au moins 2 "erratas" aka bug de sécurité à distance ( dans dhcpd et dans openssl) cf
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 !
-
[^]Re: Intéressant !
Posté par reno () le 04/11/2007 à 07:18. (lien). Évalué à 1.La sécurité c'est un "processus pas un logiciel".
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 !
-
-
-
-
-
[^]Re: Intéressant !
Posté par bubar () le 02/11/2007 à 11:22. (lien). Évalué à 2.que NuFW est de nombreuses alertes de sécurité est plutôt une bonne chose : 1Suivi. 2.transparence.
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 (Jabber id, page perso, ) le 02/11/2007 à 11:36. (lien). Évalué à 2.(et si NuFW présente un jour une interface web de configuration de type "objet" j' y saute)
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 (page perso, ) le 02/11/2007 à 11:45. (lien). Évalué à 1.Juste pour recadrer un peu, il ne faut pas confondre NuFW et une interface de configuration. NuFW est une application qui enrichit les critères de filtrages de Netfilter/iptables en ajoutant les notions :
- d'utilisateurs
- de groupes
- d'applications
- de système d'exploitation
-
-
-
[^]Re: Intéressant !
Posté par zul (Jabber id, page perso, ) le 02/11/2007 à 09:24. (lien). Évalué à 2.Je dirai que ca concerne beaucoup tes compétences d'admin.
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
Et maintenant ils distribuent même les (le) iso! Bon par contre y a pas les auto-collants avec:)
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.
Xen
OpenBSD ne supportait pas Xen et j'avoue que c'est pour cela en partie que je ne l'utilise pas. Le support d'OpenBSD en tant que guest Xen est-il meilleur ou en est-on au même point que sur la version précédente ?
-
[^]Re: Xen
Posté par manu_fred () le 04/11/2007 à 17:19. (lien). Évalué à 1.Une news est récemment passée à ce sujet sur GCU : [http://www.gcu.info/2437/2007/10/25/de-la-securite-des-lutin(...)]. Pour résumer, on peut dire que c'est pas demain la veille que ça sera supporté de base.
-
[^]Re: Xen²
Posté par Sytoka Modon (page perso, ) le 04/11/2007 à 21:03. (lien). Évalué à 3.Je vois que les commentaires en suivant ton lien sont toujours aussi sympathique concernant les autres OS que le leur ;-)
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 (page perso, ) le 04/11/2007 à 21:21. (lien). Évalué à 2.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 (...)
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 (page perso, ) le 05/11/2007 à 08:09. (lien). Évalué à 3.Oui, je suis d'accord avec toi. C'est exactement ce qu'ils disent avec une façon de parler assez dénigrante envers le boulot des autres mais je ne suis pas au fait de ce genre de liste de diffusion. C'est peut être du second degré...
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 () le 05/11/2007 à 09:58. (lien). Évalué à 4.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.
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 (page perso, ) le 05/11/2007 à 10:20. (lien). Évalué à 2.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.
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²
-
-
-
[^]Re: Xen²
Posté par Zenitram (page perso, ) le 05/11/2007 à 10:25. (lien). Évalué à 6.l'OS invité n'a accès qu'a quelques hypercalls, en nombre réduit et lus et relus
C'est du code, donc potentiellement troué.
alors que donner l'accès au matériel est bien plus dangereux
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.
Bref, il n'y a aucun argument aujourd'hui qui me donne envie de monter un serveur qui ne soit pas paravirtualisé.
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 (page perso, ) le 05/11/2007 à 14:36. (lien). Évalué à 3.Je ne lis pas le marketing des magazines foireux...
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 () le 05/11/2007 à 16:23. (lien). Évalué à 2.Non, la sécurité n'est pas meilleure en paravirtualisé (en pratique, pas en théorie).
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 (page perso, ) le 05/11/2007 à 16:53. (lien). Évalué à 1.> Mais si jamais un des OS virtualisés est infecté, alors il est possible
> 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 (page perso, ) le 05/11/2007 à 17:14. (lien). Évalué à 5.Tu bases ton raisonnement sur le postulat que Xen n'a aucun bug qui permet à une application de prendre le contrôle de l'OS hôte.
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.
Il y a des points négatifs mais il y en a aussi des positifs.
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 (page perso, ) le 05/11/2007 à 18:13. (lien). Évalué à 3.Je n'ai jamais dis que Xen est sans faille, je dis qu'il y a des points positifs dans l'approche. Au niveau API, l'API de Xen au niveau réseau est bien plus simple que celle d'une carte réseau du coup tu limites les possibilités de ce que peux faire un guest. Ensuite, selon comment tu configures ton dom0, tu peux empêcher un guest d'utiliser en pratique la libpcap même s'il est root dessus.
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 () le 06/11/2007 à 10:41. (lien). Évalué à 2.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.
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 () le 06/11/2007 à 18:52. (lien). Évalué à 2.Je pense que ta question a déjà été posée lorsque les gens ont expliqué que faire un chroot ou un jail n'était pas non plus la panacée. Cloisonner peut aider à limiter les dégâts, mais pour le coup, je suis d'accord avec d'autres intervenants dans ce fil : un matériel/un service, ça reste dans l'absolu plus sécurisé. Maintenant, les notions de sécurité évoluent en fonction de la façon dont tu évalues les risques (sensibilité des données, etc).
-
-
-
-
-
-
-
-
Cette page a été générée par Templeet en 0.47s (dont 0.0363 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.