> C'est bien simple, d'après ce que je lisais, il n'y a tout simplement pas
> de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop
> de trucs plus urgents à faire) à consacrer à un compilateur quelconque.
Pas beaucoup - pas assez - mais un petit peu quand même (de la main d'oeuvre). Par ex. :
- Un ou deux employés de Coverity (boite qui maintient un fork de gcc dédié à l'analyse statique de code) sont des développeurs d'OpenBSD (au moins Ted Unangst)
- Marc Espie, qui maintient depuis longtemps les semi forks de gcc (2.95 et 3.3.5 + patchs propolice) dans le système de base et dans les ports (4.0, 4.1, 4.2), et qui a les droits en écriture/commit dans le vrai depot svn de gcc
- Un certain nombre de développeurs ont cultivé des compétences liées, en ré-écrivant récemment le lint d'OpenBSD pour en faire un outil puissant et moderne (à la place de l'ancien lint, peu utilisable car floodeur de false positives)
- Maintenance, depuis longtemps,d'une paire de versions de gcc très adaptées à leurs besoins
- Et un paquet de spécialistes sur les « architectures minoritaires » (hppa, arm, mvme88k, ppc, sparc, ...).
Ce n'est certainement pas assez pour développer seuls un nouveau compilateur C complet, mais tout de même bien utile pour collaborer, avec d'autres, sur un compilateur déjà existant et bien architecturé. Au final ça ne fera sûrement pas un compilateur aussi complet (nombres de langages supportés) ou optimisé que gcc, mais fera probablement un bel outil complémentaire de gcc, pratique pour ceux qui ont les mêmes besoins qu'eux. Pas de raisons de s'en plaindre : ça n'enlève rien à personne, et ça profitera à certains.
Pour faire un peu d'informatique prédictive/fumeuse/astrologique ;), mon paris, c'est que ça donnera d'ici quelque temps un petit compilateur :
- C only (car ils n'ont pas besoins de C++ ou autre dans le système de base (sauf pour grof, mais il sera sûrement remplacé...))
- très rapide (car c'est un problème immédiat de gcc dont ils souffrent depuis longtemps, et qui leur coûte du temps)
- ayant une relative compatibilité avec les extensions gcc (ils en utilisent, et en auront besoin pour les ports)
- intégrant des fonctionnalités utiles pour la sécurité (puisqu'ils maintiennent déjà de nombreuses extensions de ce type dans leur fork "in house" de gcc)
- supportant un nombre décent d'architectures (puisque c'est capital pour eux et pour NetBSD)
- produisant du code peu optimisé (parce que ça demande beaucoup de travail et n'est pas une priorité immédiate pour eux, en tout cas moins importante que la rapidité de compilation)
> Ben qu'il nous casse pas les couilles avec ça et qu'il désactive les
> warnings s'il veut coder comme porc.
Visiblement, tu te méprend sur le sens de sa remarque.
À titre indicatif, le noyau d'OpenBSD est compilé, en boucle, sur toutes les archs, avec par défaut (en dur dans les Makefile) :
cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wstack-larger-than-2047
Et leur version de gcc dipose d'un certain nombre de warnings suppélementaires, en rapport avec leurs priorités (dont le -Wstack-larger-than-x plus haut, et -Wbounded (pour faire des verifs contre les débordements), -Wformat (pour faire des verifs contre les possibilites de format string vulnerabilities).
Bref on ne peut vraiment pas dire qu'ils soient contre l'idée générale des Warnings du compilo, mais plutôt qu'ils voudraient plus de warnings sur les choses ayant un impact sur la sécurité, et un meilleur rapport signal/bruit.
>> every GCC update is an engineering nightmare,
> Comment il sait ça?
> OpenBsd n'est même pas à la version 4 de gcc...
Mar Espie est un développeur de gcc depuis longtemps (il a accès en écriture au depot svn de gcc et a pas mal contribué...). Ce qui lui donne à la fois plus de crédibilité et de légitimité que toi, trolleur de linuxfr (as-tu contribué au projet gcc ?). Je pense qu'il sait mieux que toi ce qu'apporte (ou pas) la version 4 de gcc...
Et cela lui donne, peut-être aussi, le droit d'indiquer ses souhaits et deceptions au sujet de certaines orientations *politiques* du projet (par exemple à l'époque où il avait soutenu la proposition d'intégrer propolice dans gcc).
Accessoirement, son reproche central, le fait que, pour des raisons purement politiques (et en conflit avec l'interet technique) le frontend et le backend soient mélangés est un reproche fortement partagé par Linus Torvalds, et a motivé l'écriture et le choix de la licence de sparse.
FAQ de sparse, par Linus Torvalds :
Q. Why not just use gcc?
A. Gcc is big, complex, and the gcc maintainers are not interested in
other uses of the gcc front-end. In fact, gcc has explicitly
resisted splitting up the front and back ends and having some common
intermediate language because or religious license issues - you can
have multiple front ends and back ends, but they all have to be part
of gcc and licensed under the GPL.
This all (in my opinion) makes gcc development harder than it should
be, and makes the end result very ungainly. With "sparse", the
front-end is very explicitly separated into its own independent
project, and is totally independent from the users. I don't want to
know what you do in the back-end, because I don't think I _should_
know or care.
Q. Why not GPL?
A. See the previous question: I personally think that the front end
must be a totally separate project from the back end: any other
approach just leads to insanity. However, at the same time clearly
we cannot write intermediate files etc crud (since then the back end
would have to re-parse the whole thing and would have to have its
own front end and just do a lot of things that do not make any sense
from a technical standpoint).
I like the GPL, but as rms says, "Linus is just an engineer". I
refuse to use a license if that license causes bad engineering
decisions.
Sparse étant, disons, un demi-compilateur, tu vois qu'il y a d'autres gens très respectable qui font la même chose que les devs OpenBSD, à savoir maintenir un outil, en parallèle à gcc, pour pallier aux mêmes limitations artificielles (car politiques) de gcc.
OpenBSD supporte officiellement des archis très vieilles et lentes comme Vax. Et ils ont pour habitude de compiler tout le cvs en boucle (pour intercepter les problèmes de portabilité - tout les devs n'ont pas un Vax ou un mac68k à la maison - et en même temps pour stresser la VM sur ces diverses archs normalement peu utilisées (donc moins testées)).
Ils n'ont pas les moyens financiers de Linux (nombreuses sociétés et particuliers impliqués dans le dev/testing kernel et la libc + distros pour réparer en aval), pour s'offrir de gros clusters de Vax, Zaurus, hppa et de mac68k (et payer la note d'éléctricité !) à chaque fois qu'un header d'X.org ou de la libc change.
On peut donc aisément comprendre leur besoins de compilations rapides.
D'autre part, et au moins pour le moment, il ne s'agit pas de *remplacer* gcc par pcc (ni même de produire les binaires finaux de certaines archs avec pcc). Je crois que pour le moment l'intéret immédiat est simplement de disposer d'un compilo très rapide, pour accélérer le développement et la remontée de bugs, mais gcc reste là. D'après les explications que j'ai pu lire, c'est la motivation déterminante (et non une guerre de religion sur la licence).
(ps: accessoirement, recompiler tout le système avec un nouveau compilateur permet aussi de trouver de nouveaux bugs dans le système : Anders Magnusson dit avoir trouvé plein de bugs en compilant le userland NetBSD avec pcc).
À vrai dire, Linus Torvalds est loin d'avoir ton opinion (et loin de partager le sens de l'éthique de Jiri et des quelques développeurs madwifi en cause) :
Actually, normally I *do* have such a trust. It's why I have no problem
with drivers that are dual-GPL/BSD, and in fact, I've told people that I
don't want them to turn them into GPL-only, because that is simply not polite.
Maintenant, il faudrait quand même savoir de quoi on parle.
1- Dans le passé, les devs OpenBSD se sont ridiculisés dans une affaire similaire mais dans l'autre sens (importation de code GPL dans leur cvs en re-licensant illégalement sous BSD), pas brillante, qui a viré en scandale bordélique et peu reluisant (ce qui devrait inviter tout le monde à plus de prudence). Il y a clairement des problèmes de coopération entre les OS libres, et ce n'est pas très bon pour nous, utilisateurs d'OS libres. Je ne vois vraiment pas de bonne raisons de s'en réjouir.
2- Il serait préférable d'éviter de se faire une opinion trop vite à partir de son opinion générale sur les licences et sans considérer l'histoire du code et le domaine et le contexte auxquels elles s'appliquent. Le fait de choisir la GPL dans le cas précis du code de Reyk (HAL retro-engeneeré) ne pourrait pas aisément se justifier par un souhait (par ailleurs légitime) de protéger ce code contre une potentielle « proprétarisation ». Les OS propriétaires ont déjà une implémentation de référence de ce HAL fournie par Broadcom, qui est et restera plus complète. Et pour cause : le HAL libre est développé par rétroengenérie de ce HAL propriétaire. Ainsi, le passage du pilote ath sous GPL ne protègerai ce code, en pratique, que d'une chose : la réutilisation et l'amélioration de ce code par un OS libre mais non-GPL (comme OpenSolaris et les *BSD). Et ce précisément dans un domaine où la coopération entre développeurs des divers OS libres est très importante (et permise justement par la licence ISC choisie par OpenBSD : compatible avec la CDDL d'OpenSolaris, la BSD 3 et 4, et la GPL, donc avec les divers OS libres). Bref, dans ce contexte, la menace de propriétarisation est nulle, et le besoin de collaborer et partager entre OS est très important ; et une licence permissive est le seul terrain de collaboration possible (nb : je ne dis pas que la BSD est préférable à la GPL, je dis qu'il faut toujours considérer le contexte, sans aveuglement : GPL, BSD, LGPL, CC-By-SA : chacune a sa place, sa raison d'être).
3- On a pu lire quelques commentateurs faire la leçon aux devs OpenBSD, arguant que la licence BSD serait moins juste parce qu'elle ne force pas à donner en retour (« give back » qu'ils disaient). Et bin voila un bel exemple, merci pour la leçon de choses. Ici c'est utiliser la GPL pour ne pas donner en retour aux autres logiciels libres. Débat sur la légalité mis à part, vous trouvez ça juste, bien ou moral vous ? Ce n'est pas du tout l'esprit de la GPL, je ne retrouve pas dans cette attitude ce que j'apprécie dans cette licence.
4- Accuser OpenBSD de préférer le propriétaire au libre sous GPL est encore plus injuste : c'est tout de même grâce à l'intransigeance anti pilotes binaires des devs OpenBSD qu'un certain nombre de pilotes wifi peuvent être libres (dont celui-ci). Dans le cas des pilotes Atheros, il existe justement une alternative propriétaire dont tout le monde (freebsdiens et linuxiens compris), sauf les devs OpenBSD, a du se contenter pendant des années. Parce qu'utiliser un driver (semi-)binaire/proprio (ou pire, ndiwrapper) est intolérable pour OpenBSD, Reyk a écrit et maintenu ce HAL libre. On peut tout dire sauf qu'ils sont coulants avec le proprio. Le choix d'une licence très permissive comme l'ISC, en l'occurrence, n'est certainement pas fait pour complaire au proprio. C'est le terrain idéal pour travailler ensemble toutes communautés libres confondues, coopération rendue nécessaire par l'absence de specs (et le code ainsi produit n'a quasiment aucune chance d'aboutir dans des OS proprios, qui ont déjà des drivers, plus complet et fonctionnels car écrit par ceux qui ont les specs). Si les devs OpenBSD avaient voulu empêcher la réutilisation de ce pilote par Linux, ils auraient utilisé une licence BSD 4 clauses (qui est admise, chez eux, et compatible avec leur noyau) et basta, Linux n'aurait pas peu le réutiliser (et peut-être qu'ils feront ça la prochaine fois ?).
5- C'est, je crois, une des motivations les plus courantes pour le choix de licences type ISC, BSD ou MIT : le voeux d'être le plus compatible et réutilisable possible avec les autres logiciels libres, de permettre le partage le plus étendu possible (sans se laisser dicter une conduite par le propriétaire ou la crainte du proprio. : dans le cas d'OpenBSD, le proprio est tout simplement complètement ignoré, hors du radar). En pratique, OpenSolaris contient un bon nombre de pilotes wifi développés par OpenBSD, et les commentateurs critiques de linuxfr devraient quand même se rappeller qu'ils auront peut-être un pilote libre grace au travail de Reyk et à l'intransigeance d'OpenBSD, avant de les critiquer si durement.
6- Un certain nombre des développeurs Linux (en particulier du coté de chez madwifi) ont, pendant longtemps et jusqu'à cet été, accusé le HAL libre r-e de Reyk d'être une violation illégale du copyright de Broadcom. Parallèlement, madwifi poussaient pour l'utilisation du HAL binaire et non libre de Broadcom. Et ce précisément à une époque où les devs d'OpenBSD lançaient des appels publics pour une grande coopération entre les OS libres sur la libération des drivers wifi (specs, développement et boycot). Il a fallu quelque chose comme deux ans pour que le SFLC (Software Freedom Law Center), ayant analysé le cas, lave le HAL libre Reyk de toutes ces accusations mesquines (en juillet 2007).
7- Pendant tout ce temps, OpenBSD s'est fadé presque tout seul la suite du r-e sur HAL, vu que la plus grande partie de la communauté linux (ormis un peu actif port madwifi-openhal) se contentait, bon grès mal grès, de drivers non libres. Ce en dépit des appels répétés à la coopération pour du wifi libre et des specs ouvertes de la part d'OpenBSD et Theo de Raadt. Vous pouvez bien imaginer qu'ils voient rouge lorsque, deux ans après, des devs Linux qui avaient refusé de coopérer et les avaient isolés avec des accusations infondées de violation de copyright récupèrent leur travail et tentent de le passer sous une licence incompatible avec leur travail.
8- Luis Rodriguez insistai lourdement, et depuis longtemps, auprès de Reyk pour qu'il « dual-licence » son code. Ce que Reyk a refusé. Donc en connaissance de cause. Il est dès lors franchement étonnant de voir Luis - qui sait donc parfaitement que le code est sous licence ISC only, et connaissant le souhait clair de l'auteur du code - cautionner et soutenir un patch qui vire la license ISC/BSD du code de Reyk.
Pour conclure, n'oublions pas que le véritable ennemi dans cette histoire, c'est Broadcom, qui ne donne pas de specs et rarement des drivers (quand ils en fournissent, c'est généralement si mauvais qu'il faut le ré-écrire, cf. l'histoire du pilote tg3 de Linux). À boycotter !
> Dans le cas de ce driver, elle l'autorise, c'est aux choix BSD ou GPL.
Absolument pas.
Une large part de l'ancien pilote était sous BSD (ISC) pure (pas en dual) et est re-licencé arbitrairement sous GPL pure (pas en dual).
> qui ont été mis par erreur en GPL en meme temps que les autres. Mais l'erreur a été corrigée
Pas du tout.
Le code de Reyk est toujours distribué sous GPL (sans qu'il y ai eu de « new substantial contributions », comme dirait le SFLC), par Nick Kossifidis, de mawdwifi, ici : http://madwifi.org/browser/branches/ath5k/ath5k_phy.c
Et la LGPL, bien qu'elle autorise l'édition de liens dynamique (-> .so) vers la bibliothèque sous cette licence, n'autorise pas les liens statiques (.a) si le logiciel utilisant la bibliothèque est sous une licence imposant des contraintes différentes ce qui peut parfois poser des problèmes pratiques).
Pour compléter la très juste remarque d'Alveric ci-dessus, qui précise que dans le champs du droit patrimonial, seuls les droits explicitement indiqués sont accordés, voici, pour comparaison, ce qu'autorisent les licences ISC (celle du pilote ath) et MIT/X11 :
Licence ISC :
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted,
Licence MIT/X11 :
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
LGPL v. 2.1 (+ diverses précisions et dispositions spécifiques pour l'édition de liens dynamiques, trop long à citer) :
we offer you this license, which gives you legal permission to copy,
distribute and/or modify the library.
> Là, ou je ne comprends plus rien, c'est qu'il parle de respect de licence. Or pour moi, on pouvait se torcher comme on voulait d'une licence BSD. Lui dit que la licence demande que la part "derivative work" soit suffisament importante pour ne pas s'approprier le code.
À la différence de la licence MIT, la licence BSD (et son dérivé la licence ISC) ne permet pas de re-licencer (changer la licence) le code source. C'est d'ailleurs la seule différence entre ces licences (il n'y a pas le mot « sublicence » dans les droits explicitement accordés par la BSD). La licence BSD (à 2 ou à 3 clauses) permet néanmoins l'ajout du fichier dans un logiciel sous une autre licence (elle s'applique fichier par fichier, pas sur l'ensemble d'un programme) : c'est l'esprit « partage étendu et sans discrimination » de la BSD.
Concernant le besoin d'avoir produit suffisamment de travail original dont Theo parle, c'est au sujet du copyright, du droit d'ajouter son nom dans la liste des « (c) Machin Chose », et pas du droit de changer la licence.
> Maintenant que le problème est réglé, il veux que chacuns reconnaissent ses fautes.
Le problème n'est pas encore réglé. Contrairement à ce qu'on peut lire ça et là, la violation de la licence est réellement mise en pratique ; il ne s'agit pas du diff envoyé sur la lkml (pas encore intégré dans les git de Linville ou Morton), mais du dépôt subversion de madwifi, qui distribue effectivement le code de Reyck (sous licence BSD/ISC seule) avec la licence modifiée.
Ah pardon, je me suis trompé. Merci pour la précision.
Du coups : n'y a-t-il pas un risque similaire à celui qui avais touché avivo ?
Si tout les développeurs intéressés signent un NDA d'AMD, et qu'AMD les contraint à ne pas releaser certains composants (ou traine à donner les accords), restera-t-il des personnes non liées par NDA pour reverse-ingeneerer ?
Sur le blog de David Airlie, qui est, si je ne m'abuse, le nouveau mainteneur de l'infrastructure DRM/DRI du noyau Linux, l'un des principaux développeurs Xorg, l'auteur du pilote avivo pour radeon R500 (un pilote dont la sortie a été retardé, d'ailleurs, du fait de problèmes avec le NDA - accord de non divulgation - qui liait Airlie à ATI/AMD), et qui travaille en arrière plan avec AMD sur ce projet d'ouverture des specs depuis plusieurs mois.
Il y a une potentielle source de confusion du fait de la multiplicité des pilotes, donc pour clarifier (et de ce que je retient de ses commentaires) :
- Un petit bémol : les specs seront disponibles sous NDA, à priori.
- AMD va fournir, en même temps que les specs, un pilote 2D fonctionnel mais basique (sous licence libre, supportant le modsetting, et conçu d'emblée pour être intégré dans xorg).
- Le pilote basique Avivo d'Airlie sera probablement abandonné au profit du pilote initié par AMD
- AMD s'engage aussi à répondre aux questions des développeurs en cas de besoin (les développeurs auront des contacts parmis les ingénieurs AMD).
- Airlie dit que, si les fonctionnalités 2D basiques sont déjà prètes, il faudra environ 6 mois pour avoir quelque chose d'utilisable sur le plan 3D.
- Le driver fglrx propriétaire continuera d'être « maintenu » par AMD et restera propriétaire.
À ce sujet, vous pouvez relire les études et statistiques menée par Google et CMU concernant les pannes sur de très larges échantillons de disques durs : http://linuxfr.org/2007/02/21/22103.html
Ces études confirment vos impressions : S.M.A.R.T. n'anticipe que rarement une panne prochaine du disque (mais lors que S.M.A.R.T s'alarme, il y a de fortes probabilités pour que le disque ne tienne plus longtemps).
> La situation d'un point de vu légal est si "floue", que Eben Moglen (un spécialité bien connu en droit de la FSF) a demandé du temps pour analyser la situation.
Je suppose que Moglen demande du temps pour évaluer la situation des divers fichiers sous double licence et non du cote de Reyk clairement violé (ou pour des raisons politiques : Moglen est un militant pour la GPL, ou parce que c'est le week-end,...).
Le HAL libre implémenté par Reyk Floeter est sous licence ISC seule, et cette licence dit mot pour mot qu'on n'est pas autorisé à enlever le texte de la licence du code (cf. ma citation plus haut : « provided that the above copyright notice and this permission notice appear in all copies »).
Partant : oui, tu a raison : il faut être soit profondément con, soit d'épaisse mauvaise fois pour affirmer qu'il y a un doute et qu'« enlever la licence qui dit qu'on ne peut pas enlever la licence pourrait être légal ». Floue, disais-tu ?
> La glibc est sous LGPL, tu peux include les fichiers d'entête dans du proprio et distribuer ton programme proprio
Bon exemple : la LGPL dispose d'un paragraphe spécial pour permettre, explicitement, l'inclusion d'en-têtes (section 3, « Object Code Incorporating Material from Library Header Files. »), justement parce que ce droit ne va pas de soi, et qu'il faut le préciser. La licence ISC ne prévoit pas une telle exception.
Franchement, le débat gagnerai en qualité si vous vous donniez la peine de lire les licences dont on parle...
Bah, non encore.
Mieux vaut éviter de croire aveuglément les commentaires d'utilisateurs sur Osnews, ils ne sont pas toujours plus informés qu'ici.
La licence en question - qui est désormais la licence préconisée par OpenBSD - n'est pas MIT-like. Elle a la forme, l'aspect, le look d'une licence MIT, ce qui peut induire des gens en erreur. Mais il faut vraiment lire les mots qui sont écrits dans les licences :
Une notable différence, en ce qui concerne notre cas, c'est qu'on peu lire dans la MIT : « Permission is hereby granted, [...], to sublicense, [...] ». La licence ISC, à contrario, n'autorise pas l'utilisateur à « re-licencer » le logiciel. Ça fait une belle différence dans l'affaire dont on parle.
Cette licence ISC donne les mêmes droits (et impose les mêmes restrictions) qu'une BSD à deux clauses, c'est pourquoi les développeurs d'OpenBSD l'assimilent à une BSD « simplifiée ».
Concernant la remarque du message grand-parent au sujet du droit (ou pas) de restreindre à la GPL du code sous double licence ISC/BSD + GPL (une partie du code concerné est ainsi), outre qu'enlever une des licences consiste à modifier un document contractuel (TdR dit que Eben Molgen indique que c'est illégal, moi je n'en sait rien), la GPLv2, justement, stipule ceci :
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
Or enlever d'un code sous double licence le choix de la licence BSD contrevient à cette exigence de la GPL, puisque ça consiste à ne pas donner tout les droits qu'on a reçu avec le code.
Tu semble avoir fort mal compris le problème.
Tu devrais vraiment te renseigner avant de lancer d'aussi abominables trolls de ton chapeau.
Si le code de Sam Leffler (dev de Broadcom et FreeBSD) est bien sous double licence, l'ath reverse-engeneeré par Reyk Floeter (du projet OpenBSD) n'est pas dual licencé !.
La seule licence utilisé par Reyk (la licence ISC, une BSD simplifiée) stipule quand même noir sur blanc (enfin, selon la couleur de ton term) :
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
Je grasse. Comment un développeur peut croire qu'il peut se permettre d'enlever cette licence du fichier et y coller une autre licence à la place ?!
(Je passe sur toute la partie « opinion » de ton troll - tu gagnerai cependant à connaitre un peu l'histoire mouvementé du hal reverse-engeneeré par Reyk, pour te faire une idée plus informée - et ça n'est pas trop intéressant pour moi de débattre avec quelqu'un avec une opinion toute faite avant d'être informé).
>> ODF réutilise et repose sur de nombreuses autres normes W3C/IEEE pré-existantes, éprouvées et concrètement implémentées auparavant.
> 1) Et ? Ca veut dire que magiquement il ne faut pas lire ces autres normes ?
Pas vraiment (quoique : les standards existants ont certainement leur raison d'être, et des implémentations qui vont avec).
En fait ça veut surtout dire qu'on utilise les standards, au lieu de marcher dessus. De même que les diverses RFC décrivant les couches et protocoles réseau fonctionnent bien entre elles. Si on devait réinventer une pile complète « à la TCP/IP », mais différente et incompatible chaque fois qu'on sort un nouveau protocole comme HTTP, SOAP etc., le monde de l'informatique n'avancerait pas beaucoup.
> 2) C'etait OASIS,
heu oui, désolé ; j'ai aussi mis des « IEEE » en lieu de place de « ISO » dans le commentaire. Étourderie, quand tu nous tient...
> est-ce que OpenXML fait ce qu'il doit faire correctement ou pas. C'est la seule question a se poser. Le reste c'est du delit du sale gueule et n'a rien a voir
En réalité, le fait qu'un nouveau standard fasse exactement la même chose qu'un standard déjà validé est une objection et un des rares motifs de rejet reconnus et valables pour l'ISO.
1- ODF réutilise et repose sur de nombreuses autres normes W3C/IEEE pré-existantes, éprouvées et concrètement implémentées auparavant. D'où des specs très compactes. À l'inverse OpenXML, réinvente presque systématiquement la roue, d'où un format qui se documente en plusieurs milliers de pages.
2- Il existe déjà un standard bureautique validé par l'IEEE, développé collégialement par de nombreuses sociétés (Microsoft en faisait parti, au sein de l'IEEE) : le format ODF. Il est de fait supporté par plusieurs logiciels/implémentations différents. Pourquoi l'IEEE validerai un format de plus, incompatible avec le précédent, développé par une seule entreprise, entaché de brevets ?
La question serait plutôt : faut-il accepter et valider la méthode habituelle de MS « faire tout, seul dans son coin et fouler les standards existants du pied » en leur décernant en plus cette fois la petite médial de la standardisation, ou considérer qu'il y a un standard existant, et que, pour une fois, MS ferait bien de le respecter comme tout le monde (et pas de la même façon qu'ils « supportent » html, css & co, si possible). Un peu comme les US et l'ONU quoi.
> Ils viennent parler de logiciels proprios sur plateforme proprio avec tous ses problèmes
En fait il a demandé (c'est vrai, maladroitement) des noms de logiciels libres pour protéger Windows XP (pas libre), et de fait, la dépêche parle aussi de ça (ClamWin).
Donc quelques pistes (je n'y connais pas grand chose, si vous avez d'autres idées...) :
- CoreForce (un port de Packet Filter, le pare-feu d'OpenBSD, sous Win)
- ClamWin (cf. dépêche)
- Winpooch
- WinPT (solution de chiffrement et signature numérique libre, basée sur GnuPG)
- OpenVPN et Stunnel (pour le chiffrement et auth des connexions)
- Password Safe (artistic licence, évolution d'un logiciel développé par Bruce Schneier pour conserver ses mots de passes de façon sécurisée), ou KeePass (même genre)
- Snare (un HIDS et analyseur de logs pour Win, sous GPL)
- TrueCrypt (un logiciel libre et multiplateforme de chiffrement des disques et partitions)
- Firefox et Thunderbird (bin oui, les virus aiment bien Outlook, et le support des auths sécurisées et du chiffrement & signature de Tunderbird est loin devant)
- OpenOffice en désactivant les macros
Au passage, et c'est une remarque que fait courament Theo de Raadt pour expliquer la licence d'OpenSSH : pour améliorer la sécurité de sa machine, il n'est pas inutile d'aider à l'amélioration de la sécurité des machines voisines, y compris des Windows (il suffit de penser aux conséquences des spams zombies, ou des saturations réseau causés par les vers affectants IIS).
Le doute concernant le respect de la propriété intellectuelle de SCO dans le code du noyau Linux a nuit à son utilisation dans certaines grosses sociétés, pendant des années. Ce n'est pas pour rien que Microsoft a financé SCO en 2003, date de début des procès (Microsoft a acheté une licence Unix à SCO au prix fort à cette époque).
Mais, et ce n'est certainement pas un hasard (les nombreux avocats de Microsoft ont certainement prévu l'issue du procès SCO), nous avons désormais un jeune et nouveau FUD du même type, tout frais, aux conséquences exactement similaires (introduisant un nouveau doute concernant la légalité de Linux) depuis quelques mois : les fameux 235 brevets que Microsoft possède et que Linux serait censé violer (selon MS).
Peut-être pas un hasard non plus, le fait que Novell soit le premier et le plus grand acteur du monde Linux a avoir accepté l'accord avec Microsoft concernant ces brevets. En effet Novell est maintenant la seule des grands distributeurs de Linux corporate vierge de ces grandes menaces virtuelles concernant la légalité de Linux (grâce à ce jugement, nous savons qu'ils possède les copyrights d'Unix, et leur accord avec Microsoft les lave du soupçon de violation de brevets).
Pas un hasard non plus, le fait que Novell pousse très fort des technologies justement brevetées par Microsoft sur le desktop Linux (Mono, serveur exchange-like, ...) : ils sont désormais les mieux placés pour racketter les utilisateurs en tirant parti de ces deux FUD (SCO et MS). Bravo l'artiste.
Remarquez que dans certains cas (surtout pour les portables Toshiba, Thinkpads, Sony, ...) les touches spéciales sont envoyées au système sous forme d'évènements ACPI (et non sous la forme d'input events).
Richard Hughes, un des mainteneurs de HAL vient de lancer un appel à contribution auprès les utilisateurs disposant de claviers problématiques de ce type : il estime que HAL permet de gérer ces cas particuliers de façon très propre, et avec une bonne granularité, depuis qu'il a mis en place un framework adapté, mais a besoin d'informations concernant les divers claviers. SVP, aidez-le si vous pouvez :
Vous pouvez aussi faire un tour sur la page des quirks si vous avez des problèmes avec l'hibernation, la mise en veille, ou avec la gestion du rétro-éclairage.
> Bon en fait je suis en train de repenser une application et avoir un pmo qui agis au niveau record ça me serait assez pratique.
Au cas où tu ne l'ai pas déjà fait, il pourrait être prudent de jetter un oeil sur les frameworks complets existants, faits par des gens qui connaissent les besoins caractéristiques (des fw qui sont utilisés en prod, par exemple), et pas par des étudiants qui croient découvrir la lanterne magique.
En outre le choix de licence (GPLv3) de phpmyobjet t'impose de passer ton appli sous ce régime, et de ne pas utiliser d'autres libs sous une licence incompatible (comme, au hasard, GPLv2, LGPL, openssl, ...), ce qui est un beau sacrifice pour une telle lib.
Outre les critiques adressées ici, un exemple tiré du code source :
public function getAttribute($name) {
if(isset($this->object_attribute[$name]))
return $this->object_attribute[$name];
return FALSE;
}
J'imagine que la gestion des exceptions, ou différencier les attributs inexistants des attributs vides, c'est secondaire chez PMO...
Aussi loin que je comprenne ton design (je ne suis pas dev PHP), chaque objet MyObject correspond exactement a une (et une seule) table. Et les MyMap permettent regrouper ces objets cote à cote avec des bon tableaux à l'ancienne. C'est bien, mais si on danse mais si tu veut faire du relationnel ?
ORM signifie « Object Relation Mapping » : le but est avant tout d'abstraire les relations entre les objets. S'ils s'agissait seulement de saupoudrer les noms de tables et colonnes d'une pincée de syntaxe objet-like, on aurait surement appelé ça OTR (comme object table mapping).
Pour rester dans les exemples bateau, imagine que j'ai une entité "Utilisateur" et une entité "Addresse" (un Utilisateur ayant une seule Addresse, pour
faire simple). Je souhaite évidement pouvoir faire des choses du type :
Dans cet exemple on voit comment la relation pourrait être "abstraite" de la couche de persistance. En outre on aimerais pouvoir charger paresseusement (lazy loading) les objets et leurs attributs. Surtout lorsqu'on va sélectionner en profondeur (ex. ne pas charger toute les tables traversées (en plus, a coups de "SELECT *" !) en mémoire lorsqu'on fait un $user->client->address->town->getPostcode() sur un objet précis alors que pour ses congénères on n'utilise que $user->getClient()).
Si j'ai bien compris, pour le moment, l'utilisateur doit gérer ces relations à la main en écrivant ses requêtes et en agrégeant/associant manuellement les objets d'une même « ligne » (sic) du tableau MyMap, et en moulinant à l'ancienne pour reconstruire les liens en deréférençant les fkeys. Mais alors, quel intérêt d'un ORM (ou même, d'une vue objet) ?
> Le design pattern de pmo est documenté
J'ai lu le manuel indiqué en lien dans le journal (ici c'est culture Unix, alors si le man ne documente pas tout et qu'il faut lire des divx pour connaitre l'API...), mais je crois que tu n'avais pas compris mes remarques.
> PMO implémente par exemple active record, et fait même plus que cela [...]. PMO est plus souple que ADOdb [...] et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.
Et sinon ça va les chevilles ?
> PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql
Ce que je voulais dire, c'est qu'ADOdb offre une API permettant de s'affranchir des petites différences de syntaxe SQL entre les divers moteurs (ce n'est pas seulement une façon d'unifier les drivers sgbd de php). Enfin bon c'est assez secondaire par rapport aux autres problèmes de PMO.
Je pense que ce que alpage te suggère, c'est tout simplement de mettre en oeuvre des design patterns pour ORM connus et éprouvés, plutôt qu'inventer le tient au hasard (et découvrir plus tard, lorsque tu sera tenu d'assurer une rétro-compatibilité, les limitations).
Déjà plusieurs fois implémenté en PHP, par exemple ici : http://phplens.com/lens/adodb/docs-active-record.htm
C'est un bon exemple : John Lim a une remarquable expérience en la matière, tu peut t'en inspirer, et peut-être aussi utiliser sa bibliothèque ADOdb pour bénéficier d'une abstraction sur l'accès au moteur SGBD, donc d'une meilleure portabilité (parce que MySQL, c'est bien, mais il existe d'autres morteurs de bados (comment ça, "sqlite roxor" ? :P)).
[^] # Re: Re ; Fin de gcc dans les *BSD ?
Posté par herodiade . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 5.
> de main d'oeuvre dans OpenBSD (parce que pas de temps libre, trop
> de trucs plus urgents à faire) à consacrer à un compilateur quelconque.
Pas beaucoup - pas assez - mais un petit peu quand même (de la main d'oeuvre). Par ex. :
- Un ou deux employés de Coverity (boite qui maintient un fork de gcc dédié à l'analyse statique de code) sont des développeurs d'OpenBSD (au moins Ted Unangst)
- Marc Espie, qui maintient depuis longtemps les semi forks de gcc (2.95 et 3.3.5 + patchs propolice) dans le système de base et dans les ports (4.0, 4.1, 4.2), et qui a les droits en écriture/commit dans le vrai depot svn de gcc
- Un certain nombre de développeurs ont cultivé des compétences liées, en ré-écrivant récemment le lint d'OpenBSD pour en faire un outil puissant et moderne (à la place de l'ancien lint, peu utilisable car floodeur de false positives)
- Maintenance, depuis longtemps,d'une paire de versions de gcc très adaptées à leurs besoins
- Et un paquet de spécialistes sur les « architectures minoritaires » (hppa, arm, mvme88k, ppc, sparc, ...).
Ce n'est certainement pas assez pour développer seuls un nouveau compilateur C complet, mais tout de même bien utile pour collaborer, avec d'autres, sur un compilateur déjà existant et bien architecturé. Au final ça ne fera sûrement pas un compilateur aussi complet (nombres de langages supportés) ou optimisé que gcc, mais fera probablement un bel outil complémentaire de gcc, pratique pour ceux qui ont les mêmes besoins qu'eux. Pas de raisons de s'en plaindre : ça n'enlève rien à personne, et ça profitera à certains.
Pour faire un peu d'informatique prédictive/fumeuse/astrologique ;), mon paris, c'est que ça donnera d'ici quelque temps un petit compilateur :
- C only (car ils n'ont pas besoins de C++ ou autre dans le système de base (sauf pour grof, mais il sera sûrement remplacé...))
- très rapide (car c'est un problème immédiat de gcc dont ils souffrent depuis longtemps, et qui leur coûte du temps)
- ayant une relative compatibilité avec les extensions gcc (ils en utilisent, et en auront besoin pour les ports)
- intégrant des fonctionnalités utiles pour la sécurité (puisqu'ils maintiennent déjà de nombreuses extensions de ce type dans leur fork "in house" de gcc)
- supportant un nombre décent d'architectures (puisque c'est capital pour eux et pour NetBSD)
- produisant du code peu optimisé (parce que ça demande beaucoup de travail et n'est pas une priorité immédiate pour eux, en tout cas moins importante que la rapidité de compilation)
[^] # Re: OpenBSD utilise gcc 3.3. Les nazes.
Posté par herodiade . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 8.
> warnings s'il veut coder comme porc.
Visiblement, tu te méprend sur le sens de sa remarque.
À titre indicatif, le noyau d'OpenBSD est compilé, en boucle, sur toutes les archs, avec par défaut (en dur dans les Makefile) :
cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wstack-larger-than-2047
Et leur version de gcc dipose d'un certain nombre de warnings suppélementaires, en rapport avec leurs priorités (dont le -Wstack-larger-than-x plus haut, et -Wbounded (pour faire des verifs contre les débordements), -Wformat (pour faire des verifs contre les possibilites de format string vulnerabilities).
Bref on ne peut vraiment pas dire qu'ils soient contre l'idée générale des Warnings du compilo, mais plutôt qu'ils voudraient plus de warnings sur les choses ayant un impact sur la sécurité, et un meilleur rapport signal/bruit.
>> every GCC update is an engineering nightmare,
> Comment il sait ça?
> OpenBsd n'est même pas à la version 4 de gcc...
Mar Espie est un développeur de gcc depuis longtemps (il a accès en écriture au depot svn de gcc et a pas mal contribué...). Ce qui lui donne à la fois plus de crédibilité et de légitimité que toi, trolleur de linuxfr (as-tu contribué au projet gcc ?). Je pense qu'il sait mieux que toi ce qu'apporte (ou pas) la version 4 de gcc...
Et cela lui donne, peut-être aussi, le droit d'indiquer ses souhaits et deceptions au sujet de certaines orientations *politiques* du projet (par exemple à l'époque où il avait soutenu la proposition d'intégrer propolice dans gcc).
Accessoirement, son reproche central, le fait que, pour des raisons purement politiques (et en conflit avec l'interet technique) le frontend et le backend soient mélangés est un reproche fortement partagé par Linus Torvalds, et a motivé l'écriture et le choix de la licence de sparse.
FAQ de sparse, par Linus Torvalds :
Sparse étant, disons, un demi-compilateur, tu vois qu'il y a d'autres gens très respectable qui font la même chose que les devs OpenBSD, à savoir maintenir un outil, en parallèle à gcc, pour pallier aux mêmes limitations artificielles (car politiques) de gcc.
[^] # Besoin de vitesse de compilation (au moins pendant les cycles de dev)
Posté par herodiade . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 10.
Ils n'ont pas les moyens financiers de Linux (nombreuses sociétés et particuliers impliqués dans le dev/testing kernel et la libc + distros pour réparer en aval), pour s'offrir de gros clusters de Vax, Zaurus, hppa et de mac68k (et payer la note d'éléctricité !) à chaque fois qu'un header d'X.org ou de la libc change.
On peut donc aisément comprendre leur besoins de compilations rapides.
D'autre part, et au moins pour le moment, il ne s'agit pas de *remplacer* gcc par pcc (ni même de produire les binaires finaux de certaines archs avec pcc). Je crois que pour le moment l'intéret immédiat est simplement de disposer d'un compilo très rapide, pour accélérer le développement et la remontée de bugs, mais gcc reste là. D'après les explications que j'ai pu lire, c'est la motivation déterminante (et non une guerre de religion sur la licence).
(ps: accessoirement, recompiler tout le système avec un nouveau compilateur permet aussi de trouver de nouveaux bugs dans le système : Anders Magnusson dit avoir trouvé plein de bugs en compilant le userland NetBSD avec pcc).
[^] # Re: Précision sur le fabriquant !
Posté par herodiade . En réponse au journal la vaccination GPL vs la liberté total BSD : le cas du drivers atheros. Évalué à 2.
Errr, oui s/Broadcom/Atheros/, merci pour la correction.
Un mauvais laspsus de ma part (je me suis battu avec le chipset Broadcom d'un Macbook pro il y a deux jours...).
[^] # Re: .
Posté par herodiade . En réponse au journal la vaccination GPL vs la liberté total BSD : le cas du drivers atheros. Évalué à 10.
source : http://lkml.org/lkml/2007/6/14/494
Maintenant, il faudrait quand même savoir de quoi on parle.
1- Dans le passé, les devs OpenBSD se sont ridiculisés dans une affaire similaire mais dans l'autre sens (importation de code GPL dans leur cvs en re-licensant illégalement sous BSD), pas brillante, qui a viré en scandale bordélique et peu reluisant (ce qui devrait inviter tout le monde à plus de prudence). Il y a clairement des problèmes de coopération entre les OS libres, et ce n'est pas très bon pour nous, utilisateurs d'OS libres. Je ne vois vraiment pas de bonne raisons de s'en réjouir.
2- Il serait préférable d'éviter de se faire une opinion trop vite à partir de son opinion générale sur les licences et sans considérer l'histoire du code et le domaine et le contexte auxquels elles s'appliquent. Le fait de choisir la GPL dans le cas précis du code de Reyk (HAL retro-engeneeré) ne pourrait pas aisément se justifier par un souhait (par ailleurs légitime) de protéger ce code contre une potentielle « proprétarisation ». Les OS propriétaires ont déjà une implémentation de référence de ce HAL fournie par Broadcom, qui est et restera plus complète. Et pour cause : le HAL libre est développé par rétroengenérie de ce HAL propriétaire. Ainsi, le passage du pilote ath sous GPL ne protègerai ce code, en pratique, que d'une chose : la réutilisation et l'amélioration de ce code par un OS libre mais non-GPL (comme OpenSolaris et les *BSD). Et ce précisément dans un domaine où la coopération entre développeurs des divers OS libres est très importante (et permise justement par la licence ISC choisie par OpenBSD : compatible avec la CDDL d'OpenSolaris, la BSD 3 et 4, et la GPL, donc avec les divers OS libres). Bref, dans ce contexte, la menace de propriétarisation est nulle, et le besoin de collaborer et partager entre OS est très important ; et une licence permissive est le seul terrain de collaboration possible (nb : je ne dis pas que la BSD est préférable à la GPL, je dis qu'il faut toujours considérer le contexte, sans aveuglement : GPL, BSD, LGPL, CC-By-SA : chacune a sa place, sa raison d'être).
3- On a pu lire quelques commentateurs faire la leçon aux devs OpenBSD, arguant que la licence BSD serait moins juste parce qu'elle ne force pas à donner en retour (« give back » qu'ils disaient). Et bin voila un bel exemple, merci pour la leçon de choses. Ici c'est utiliser la GPL pour ne pas donner en retour aux autres logiciels libres. Débat sur la légalité mis à part, vous trouvez ça juste, bien ou moral vous ? Ce n'est pas du tout l'esprit de la GPL, je ne retrouve pas dans cette attitude ce que j'apprécie dans cette licence.
4- Accuser OpenBSD de préférer le propriétaire au libre sous GPL est encore plus injuste : c'est tout de même grâce à l'intransigeance anti pilotes binaires des devs OpenBSD qu'un certain nombre de pilotes wifi peuvent être libres (dont celui-ci). Dans le cas des pilotes Atheros, il existe justement une alternative propriétaire dont tout le monde (freebsdiens et linuxiens compris), sauf les devs OpenBSD, a du se contenter pendant des années. Parce qu'utiliser un driver (semi-)binaire/proprio (ou pire, ndiwrapper) est intolérable pour OpenBSD, Reyk a écrit et maintenu ce HAL libre. On peut tout dire sauf qu'ils sont coulants avec le proprio. Le choix d'une licence très permissive comme l'ISC, en l'occurrence, n'est certainement pas fait pour complaire au proprio. C'est le terrain idéal pour travailler ensemble toutes communautés libres confondues, coopération rendue nécessaire par l'absence de specs (et le code ainsi produit n'a quasiment aucune chance d'aboutir dans des OS proprios, qui ont déjà des drivers, plus complet et fonctionnels car écrit par ceux qui ont les specs). Si les devs OpenBSD avaient voulu empêcher la réutilisation de ce pilote par Linux, ils auraient utilisé une licence BSD 4 clauses (qui est admise, chez eux, et compatible avec leur noyau) et basta, Linux n'aurait pas peu le réutiliser (et peut-être qu'ils feront ça la prochaine fois ?).
5- C'est, je crois, une des motivations les plus courantes pour le choix de licences type ISC, BSD ou MIT : le voeux d'être le plus compatible et réutilisable possible avec les autres logiciels libres, de permettre le partage le plus étendu possible (sans se laisser dicter une conduite par le propriétaire ou la crainte du proprio. : dans le cas d'OpenBSD, le proprio est tout simplement complètement ignoré, hors du radar). En pratique, OpenSolaris contient un bon nombre de pilotes wifi développés par OpenBSD, et les commentateurs critiques de linuxfr devraient quand même se rappeller qu'ils auront peut-être un pilote libre grace au travail de Reyk et à l'intransigeance d'OpenBSD, avant de les critiquer si durement.
6- Un certain nombre des développeurs Linux (en particulier du coté de chez madwifi) ont, pendant longtemps et jusqu'à cet été, accusé le HAL libre r-e de Reyk d'être une violation illégale du copyright de Broadcom. Parallèlement, madwifi poussaient pour l'utilisation du HAL binaire et non libre de Broadcom. Et ce précisément à une époque où les devs d'OpenBSD lançaient des appels publics pour une grande coopération entre les OS libres sur la libération des drivers wifi (specs, développement et boycot). Il a fallu quelque chose comme deux ans pour que le SFLC (Software Freedom Law Center), ayant analysé le cas, lave le HAL libre Reyk de toutes ces accusations mesquines (en juillet 2007).
7- Pendant tout ce temps, OpenBSD s'est fadé presque tout seul la suite du r-e sur HAL, vu que la plus grande partie de la communauté linux (ormis un peu actif port madwifi-openhal) se contentait, bon grès mal grès, de drivers non libres. Ce en dépit des appels répétés à la coopération pour du wifi libre et des specs ouvertes de la part d'OpenBSD et Theo de Raadt. Vous pouvez bien imaginer qu'ils voient rouge lorsque, deux ans après, des devs Linux qui avaient refusé de coopérer et les avaient isolés avec des accusations infondées de violation de copyright récupèrent leur travail et tentent de le passer sous une licence incompatible avec leur travail.
8- Luis Rodriguez insistai lourdement, et depuis longtemps, auprès de Reyk pour qu'il « dual-licence » son code. Ce que Reyk a refusé. Donc en connaissance de cause. Il est dès lors franchement étonnant de voir Luis - qui sait donc parfaitement que le code est sous licence ISC only, et connaissant le souhait clair de l'auteur du code - cautionner et soutenir un patch qui vire la license ISC/BSD du code de Reyk.
Pour conclure, n'oublions pas que le véritable ennemi dans cette histoire, c'est Broadcom, qui ne donne pas de specs et rarement des drivers (quand ils en fournissent, c'est généralement si mauvais qu'il faut le ré-écrire, cf. l'histoire du pilote tg3 de Linux). À boycotter !
[^] # Re: On m'aurait mentit ?
Posté par herodiade . En réponse au journal la vaccination GPL vs la liberté total BSD : le cas du drivers atheros. Évalué à 1.
Absolument pas.
Une large part de l'ancien pilote était sous BSD (ISC) pure (pas en dual) et est re-licencé arbitrairement sous GPL pure (pas en dual).
> qui ont été mis par erreur en GPL en meme temps que les autres. Mais l'erreur a été corrigée
Pas du tout.
Le code de Reyk est toujours distribué sous GPL (sans qu'il y ai eu de « new substantial contributions », comme dirait le SFLC), par Nick Kossifidis, de mawdwifi, ici : http://madwifi.org/browser/branches/ath5k/ath5k_phy.c
[^] # Re: On m'aurait mentit ?
Posté par herodiade . En réponse au journal la vaccination GPL vs la liberté total BSD : le cas du drivers atheros. Évalué à 3.
Pour compléter la très juste remarque d'Alveric ci-dessus, qui précise que dans le champs du droit patrimonial, seuls les droits explicitement indiqués sont accordés, voici, pour comparaison, ce qu'autorisent les licences ISC (celle du pilote ath) et MIT/X11 :
Licence ISC :
Licence MIT/X11 :
LGPL v. 2.1 (+ diverses précisions et dispositions spécifiques pour l'édition de liens dynamiques, trop long à citer) :
# Précision
Posté par herodiade . En réponse au journal la vaccination GPL vs la liberté total BSD : le cas du drivers atheros. Évalué à 10.
À la différence de la licence MIT, la licence BSD (et son dérivé la licence ISC) ne permet pas de re-licencer (changer la licence) le code source. C'est d'ailleurs la seule différence entre ces licences (il n'y a pas le mot « sublicence » dans les droits explicitement accordés par la BSD). La licence BSD (à 2 ou à 3 clauses) permet néanmoins l'ajout du fichier dans un logiciel sous une autre licence (elle s'applique fichier par fichier, pas sur l'ensemble d'un programme) : c'est l'esprit « partage étendu et sans discrimination » de la BSD.
Concernant le besoin d'avoir produit suffisamment de travail original dont Theo parle, c'est au sujet du copyright, du droit d'ajouter son nom dans la liste des « (c) Machin Chose », et pas du droit de changer la licence.
> Maintenant que le problème est réglé, il veux que chacuns reconnaissent ses fautes.
Le problème n'est pas encore réglé. Contrairement à ce qu'on peut lire ça et là, la violation de la licence est réellement mise en pratique ; il ne s'agit pas du diff envoyé sur la lkml (pas encore intégré dans les git de Linville ou Morton), mais du dépôt subversion de madwifi, qui distribue effectivement le code de Reyck (sous licence BSD/ISC seule) avec la licence modifiée.
http://madwifi.org/browser/branches/ath5k
http://madwifi.org/browser/branches/ath5k/ath5k_phy.c
[^] # Re: Et encore d'autres infos sur le sujet
Posté par herodiade . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 3.
Du coups : n'y a-t-il pas un risque similaire à celui qui avais touché avivo ?
Si tout les développeurs intéressés signent un NDA d'AMD, et qu'AMD les contraint à ne pas releaser certains composants (ou traine à donner les accords), restera-t-il des personnes non liées par NDA pour reverse-ingeneerer ?
# Et encore d'autres infos sur le sujet
Posté par herodiade . En réponse à la dépêche Un représentant d'AMD annonce l'ouverture des spécifications des Radeons. Évalué à 10.
Il invite les lecteurs de son blog à poser leurs questions concernant cette ouverture :
http://airlied.livejournal.com/50187.html
Il y a une potentielle source de confusion du fait de la multiplicité des pilotes, donc pour clarifier (et de ce que je retient de ses commentaires) :
- Un petit bémol : les specs seront disponibles sous NDA, à priori.
- AMD va fournir, en même temps que les specs, un pilote 2D fonctionnel mais basique (sous licence libre, supportant le modsetting, et conçu d'emblée pour être intégré dans xorg).
- Le pilote basique Avivo d'Airlie sera probablement abandonné au profit du pilote initié par AMD
- AMD s'engage aussi à répondre aux questions des développeurs en cas de besoin (les développeurs auront des contacts parmis les ingénieurs AMD).
- Airlie dit que, si les fonctionnalités 2D basiques sont déjà prètes, il faudra environ 6 mois pour avoir quelque chose d'utilisable sur le plan 3D.
- Le driver fglrx propriétaire continuera d'être « maintenu » par AMD et restera propriétaire.
[^] # Re: En pratique
Posté par herodiade . En réponse au journal SMART: Self-Monitoring, Analysis, and Reporting Technology. Évalué à 5.
http://linuxfr.org/2007/02/21/22103.html
Ces études confirment vos impressions : S.M.A.R.T. n'anticipe que rarement une panne prochaine du disque (mais lors que S.M.A.R.T s'alarme, il y a de fortes probabilités pour que le disque ne tienne plus longtemps).
[^] # Re: Tu es peu informé...
Posté par herodiade . En réponse au journal [Troll?] Sacré Théo. Évalué à 6.
Je suppose que Moglen demande du temps pour évaluer la situation des divers fichiers sous double licence et non du cote de Reyk clairement violé (ou pour des raisons politiques : Moglen est un militant pour la GPL, ou parce que c'est le week-end,...).
Le HAL libre implémenté par Reyk Floeter est sous licence ISC seule, et cette licence dit mot pour mot qu'on n'est pas autorisé à enlever le texte de la licence du code (cf. ma citation plus haut : « provided that the above copyright notice and this permission notice appear in all copies »).
Partant : oui, tu a raison : il faut être soit profondément con, soit d'épaisse mauvaise fois pour affirmer qu'il y a un doute et qu'« enlever la licence qui dit qu'on ne peut pas enlever la licence pourrait être légal ». Floue, disais-tu ?
> La glibc est sous LGPL, tu peux include les fichiers d'entête dans du proprio et distribuer ton programme proprio
Bon exemple : la LGPL dispose d'un paragraphe spécial pour permettre, explicitement, l'inclusion d'en-têtes (section 3, « Object Code Incorporating Material from Library Header Files. »), justement parce que ce droit ne va pas de soi, et qu'il faut le préciser. La licence ISC ne prévoit pas une telle exception.
Franchement, le débat gagnerai en qualité si vous vous donniez la peine de lire les licences dont on parle...
[^] # Re: Tu es peu informé...
Posté par herodiade . En réponse au journal [Troll?] Sacré Théo. Évalué à 7.
Mieux vaut éviter de croire aveuglément les commentaires d'utilisateurs sur Osnews, ils ne sont pas toujours plus informés qu'ici.
La licence en question - qui est désormais la licence préconisée par OpenBSD - n'est pas MIT-like. Elle a la forme, l'aspect, le look d'une licence MIT, ce qui peut induire des gens en erreur. Mais il faut vraiment lire les mots qui sont écrits dans les licences :
La license ISC (OpenBSD) :
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/share/m(...)
La license MIT :
http://www.opensource.org/licenses/mit-license.php
Une notable différence, en ce qui concerne notre cas, c'est qu'on peu lire dans la MIT : « Permission is hereby granted, [...], to sublicense, [...] ». La licence ISC, à contrario, n'autorise pas l'utilisateur à « re-licencer » le logiciel. Ça fait une belle différence dans l'affaire dont on parle.
Cette licence ISC donne les mêmes droits (et impose les mêmes restrictions) qu'une BSD à deux clauses, c'est pourquoi les développeurs d'OpenBSD l'assimilent à une BSD « simplifiée ».
Concernant la remarque du message grand-parent au sujet du droit (ou pas) de restreindre à la GPL du code sous double licence ISC/BSD + GPL (une partie du code concerné est ainsi), outre qu'enlever une des licences consiste à modifier un document contractuel (TdR dit que Eben Molgen indique que c'est illégal, moi je n'en sait rien), la GPLv2, justement, stipule ceci :
Or enlever d'un code sous double licence le choix de la licence BSD contrevient à cette exigence de la GPL, puisque ça consiste à ne pas donner tout les droits qu'on a reçu avec le code.
# Tu es peu informé...
Posté par herodiade . En réponse au journal [Troll?] Sacré Théo. Évalué à 10.
Tu devrais vraiment te renseigner avant de lancer d'aussi abominables trolls de ton chapeau.
Si le code de Sam Leffler (dev de Broadcom et FreeBSD) est bien sous double licence, l'ath reverse-engeneeré par Reyk Floeter (du projet OpenBSD) n'est pas dual licencé !.
La seule licence utilisé par Reyk (la licence ISC, une BSD simplifiée) stipule quand même noir sur blanc (enfin, selon la couleur de ton term) :
ref.: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/ar5xxx.(...)
Je grasse. Comment un développeur peut croire qu'il peut se permettre d'enlever cette licence du fichier et y coller une autre licence à la place ?!
(Je passe sur toute la partie « opinion » de ton troll - tu gagnerai cependant à connaitre un peu l'histoire mouvementé du hal reverse-engeneeré par Reyk, pour te faire une idée plus informée - et ça n'est pas trop intéressant pour moi de débattre avec quelqu'un avec une opinion toute faite avant d'être informé).
[^] # Re: quelques explications s'il vous plait
Posté par herodiade . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 10.
> 1) Et ? Ca veut dire que magiquement il ne faut pas lire ces autres normes ?
Pas vraiment (quoique : les standards existants ont certainement leur raison d'être, et des implémentations qui vont avec).
En fait ça veut surtout dire qu'on utilise les standards, au lieu de marcher dessus. De même que les diverses RFC décrivant les couches et protocoles réseau fonctionnent bien entre elles. Si on devait réinventer une pile complète « à la TCP/IP », mais différente et incompatible chaque fois qu'on sort un nouveau protocole comme HTTP, SOAP etc., le monde de l'informatique n'avancerait pas beaucoup.
> 2) C'etait OASIS,
heu oui, désolé ; j'ai aussi mis des « IEEE » en lieu de place de « ISO » dans le commentaire. Étourderie, quand tu nous tient...
> est-ce que OpenXML fait ce qu'il doit faire correctement ou pas. C'est la seule question a se poser. Le reste c'est du delit du sale gueule et n'a rien a voir
En réalité, le fait qu'un nouveau standard fasse exactement la même chose qu'un standard déjà validé est une objection et un des rares motifs de rejet reconnus et valables pour l'ISO.
[^] # Re: Dépêche ratée...
Posté par herodiade . En réponse au journal Ou est passé l'article sur le mauvais article du journal "Le point" à propos d'Ubuntu ?. Évalué à 5.
[^] # Re: quelques explications s'il vous plait
Posté par herodiade . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 9.
Je te recommande le logiciel Firefox, qui intègre un correcteur ;)
[^] # Re: quelques explications s'il vous plait
Posté par herodiade . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 9.
1- ODF réutilise et repose sur de nombreuses autres normes W3C/IEEE pré-existantes, éprouvées et concrètement implémentées auparavant. D'où des specs très compactes. À l'inverse OpenXML, réinvente presque systématiquement la roue, d'où un format qui se documente en plusieurs milliers de pages.
2- Il existe déjà un standard bureautique validé par l'IEEE, développé collégialement par de nombreuses sociétés (Microsoft en faisait parti, au sein de l'IEEE) : le format ODF. Il est de fait supporté par plusieurs logiciels/implémentations différents. Pourquoi l'IEEE validerai un format de plus, incompatible avec le précédent, développé par une seule entreprise, entaché de brevets ?
La question serait plutôt : faut-il accepter et valider la méthode habituelle de MS « faire tout, seul dans son coin et fouler les standards existants du pied » en leur décernant en plus cette fois la petite médial de la standardisation, ou considérer qu'il y a un standard existant, et que, pour une fois, MS ferait bien de le respecter comme tout le monde (et pas de la même façon qu'ils « supportent » html, css & co, si possible). Un peu comme les US et l'ONU quoi.
[^] # Re: logiciels libres permetant de sécuriser un minimum un winxp home
Posté par herodiade . En réponse à la dépêche Tests d'efficacité des antivirus Linux. Évalué à 9.
En fait il a demandé (c'est vrai, maladroitement) des noms de logiciels libres pour protéger Windows XP (pas libre), et de fait, la dépêche parle aussi de ça (ClamWin).
Donc quelques pistes (je n'y connais pas grand chose, si vous avez d'autres idées...) :
- CoreForce (un port de Packet Filter, le pare-feu d'OpenBSD, sous Win)
- ClamWin (cf. dépêche)
- Winpooch
- WinPT (solution de chiffrement et signature numérique libre, basée sur GnuPG)
- OpenVPN et Stunnel (pour le chiffrement et auth des connexions)
- Password Safe (artistic licence, évolution d'un logiciel développé par Bruce Schneier pour conserver ses mots de passes de façon sécurisée), ou KeePass (même genre)
- Snare (un HIDS et analyseur de logs pour Win, sous GPL)
- TrueCrypt (un logiciel libre et multiplateforme de chiffrement des disques et partitions)
- Firefox et Thunderbird (bin oui, les virus aiment bien Outlook, et le support des auths sécurisées et du chiffrement & signature de Tunderbird est loin devant)
- OpenOffice en désactivant les macros
Au passage, et c'est une remarque que fait courament Theo de Raadt pour expliquer la licence d'OpenSSH : pour améliorer la sécurité de sa machine, il n'est pas inutile d'aider à l'amélioration de la sécurité des machines voisines, y compris des Windows (il suffit de penser aux conséquences des spams zombies, ou des saturations réseau causés par les vers affectants IIS).
# bonne nouvelle, mais nous ne sommes pas débarassés des FUD
Posté par herodiade . En réponse au journal Novell Propriétaire d'Unix et d'UnixWare ?. Évalué à 6.
Mais, et ce n'est certainement pas un hasard (les nombreux avocats de Microsoft ont certainement prévu l'issue du procès SCO), nous avons désormais un jeune et nouveau FUD du même type, tout frais, aux conséquences exactement similaires (introduisant un nouveau doute concernant la légalité de Linux) depuis quelques mois : les fameux 235 brevets que Microsoft possède et que Linux serait censé violer (selon MS).
Peut-être pas un hasard non plus, le fait que Novell soit le premier et le plus grand acteur du monde Linux a avoir accepté l'accord avec Microsoft concernant ces brevets. En effet Novell est maintenant la seule des grands distributeurs de Linux corporate vierge de ces grandes menaces virtuelles concernant la légalité de Linux (grâce à ce jugement, nous savons qu'ils possède les copyrights d'Unix, et leur accord avec Microsoft les lave du soupçon de violation de brevets).
Pas un hasard non plus, le fait que Novell pousse très fort des technologies justement brevetées par Microsoft sur le desktop Linux (Mono, serveur exchange-like, ...) : ils sont désormais les mieux placés pour racketter les utilisateurs en tirant parti de ces deux FUD (SCO et MS). Bravo l'artiste.
[^] # Re: Quelle horreur !
Posté par herodiade . En réponse à la dépêche Une doc intelligible et détaillée sur XKb ? Mais oui... et en français.... Évalué à 10.
Richard Hughes, un des mainteneurs de HAL vient de lancer un appel à contribution auprès les utilisateurs disposant de claviers problématiques de ce type : il estime que HAL permet de gérer ces cas particuliers de façon très propre, et avec une bonne granularité, depuis qu'il a mis en place un framework adapté, mais a besoin d'informations concernant les divers claviers. SVP, aidez-le si vous pouvez :
* Mapping keys : unfucking one keyboard at a time, par Richard Hughes :
http://hughsient.livejournal.com/29730.html
* Et le superbe HAL Quirk Site :
http://people.freedesktop.org/~hughsient/quirk/
Vous pouvez aussi faire un tour sur la page des quirks si vous avez des problèmes avec l'hibernation, la mise en veille, ou avec la gestion du rétro-éclairage.
# Du plugin Plugin dans ses rapports avec les plugins de plugins
Posté par herodiade . En réponse à la dépêche Compiz Core 0.5.2. Évalué à 10.
-> Le greffon Plugin permet de modifier et d'étendre le comportement des greffons existants via de nouveaux greffons.
Qui a dit que la traduction des termes informatiques rendaient le texte moins compréhensible ? :P
[^] # Re: Mmmm, voyons voir...
Posté par herodiade . En réponse au journal PMO v 0.07 déjà. Évalué à 4.
Au cas où tu ne l'ai pas déjà fait, il pourrait être prudent de jetter un oeil sur les frameworks complets existants, faits par des gens qui connaissent les besoins caractéristiques (des fw qui sont utilisés en prod, par exemple), et pas par des étudiants qui croient découvrir la lanterne magique.
Peut-être quelque chose comme :
http://www.cakephp.org/
http://www.symfony-project.com/
http://seagullproject.org/
etc.
En outre le choix de licence (GPLv3) de phpmyobjet t'impose de passer ton appli sous ce régime, et de ne pas utiliser d'autres libs sous une licence incompatible (comme, au hasard, GPLv2, LGPL, openssl, ...), ce qui est un beau sacrifice pour une telle lib.
Outre les critiques adressées ici, un exemple tiré du code source :
public function getAttribute($name) {
if(isset($this->object_attribute[$name]))
return $this->object_attribute[$name];
return FALSE;
}
J'imagine que la gestion des exceptions, ou différencier les attributs inexistants des attributs vides, c'est secondaire chez PMO...
[^] # MultiDeskOS inside
Posté par herodiade . En réponse au journal PMO v 0.07 déjà. Évalué à 2.
ORM signifie « Object Relation Mapping » : le but est avant tout d'abstraire les relations entre les objets. S'ils s'agissait seulement de saupoudrer les noms de tables et colonnes d'une pincée de syntaxe objet-like, on aurait surement appelé ça OTR (comme object table mapping).
Pour rester dans les exemples bateau, imagine que j'ai une entité "Utilisateur" et une entité "Addresse" (un Utilisateur ayant une seule Addresse, pour
faire simple). Je souhaite évidement pouvoir faire des choses du type :
$user = Utilisateur::getByName("Mickael Kael");
$user->address->setTown("Muflin");
$user->save();
Dans cet exemple on voit comment la relation pourrait être "abstraite" de la couche de persistance. En outre on aimerais pouvoir charger paresseusement (lazy loading) les objets et leurs attributs. Surtout lorsqu'on va sélectionner en profondeur (ex. ne pas charger toute les tables traversées (en plus, a coups de "SELECT *" !) en mémoire lorsqu'on fait un $user->client->address->town->getPostcode() sur un objet précis alors que pour ses congénères on n'utilise que $user->getClient()).
Si j'ai bien compris, pour le moment, l'utilisateur doit gérer ces relations à la main en écrivant ses requêtes et en agrégeant/associant manuellement les objets d'une même « ligne » (sic) du tableau MyMap, et en moulinant à l'ancienne pour reconstruire les liens en deréférençant les fkeys. Mais alors, quel intérêt d'un ORM (ou même, d'une vue objet) ?
> Le design pattern de pmo est documenté
J'ai lu le manuel indiqué en lien dans le journal (ici c'est culture Unix, alors si le man ne documente pas tout et qu'il faut lire des divx pour connaitre l'API...), mais je crois que tu n'avais pas compris mes remarques.
> PMO implémente par exemple active record, et fait même plus que cela [...]. PMO est plus souple que ADOdb [...] et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.
Et sinon ça va les chevilles ?
> PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql
Ce que je voulais dire, c'est qu'ADOdb offre une API permettant de s'affranchir des petites différences de syntaxe SQL entre les divers moteurs (ce n'est pas seulement une façon d'unifier les drivers sgbd de php). Enfin bon c'est assez secondaire par rapport aux autres problèmes de PMO.
[^] # Re: Mmmm, voyons voir...
Posté par herodiade . En réponse au journal PMO v 0.07 déjà. Évalué à 2.
Un exemple de motif de conception en vogue en ce moment : http://fr.wikipedia.org/wiki/Active_record_%28motif_de_conce(...)
Déjà plusieurs fois implémenté en PHP, par exemple ici : http://phplens.com/lens/adodb/docs-active-record.htm
C'est un bon exemple : John Lim a une remarquable expérience en la matière, tu peut t'en inspirer, et peut-être aussi utiliser sa bibliothèque ADOdb pour bénéficier d'une abstraction sur l'accès au moteur SGBD, donc d'une meilleure portabilité (parce que MySQL, c'est bien, mais il existe d'autres morteurs de bados (comment ça, "sqlite roxor" ? :P)).