Linux_GTI a écrit 168 commentaires

Il n'est pas d'une difficulté majeur d'installer un nouveau md5sum.

Je dis ça, c'est pour aider l'aure et lui éviter une nouvelle installation et mieux connaitre ce qui a été attaqué sur son système.

Je dis ça mais je dis rien. Tout le monde sait qu'une nouvelle installation from scrach est le meilleur remède...

> Sauf si ton binaire RPM est bidonné lui aussi...

Suffit de le vérifier.
rpm -V rpm
Et si t'as pas confiance en ta base de donnée, tu peux vérifier ce qui est installé en utilisant les valeurs du paquet.
rpm -V -p rpm-4.0.4-28mdk.i586.rpm

Tu peux aussi vérifier la signature du paquet :
rpm -K rpm-4.0.4-28mdk.i586.rpm

Les md5sum sont dispos :
rpm -q --dump rpm
ou en mode parano
rpm -q --dump -p rpm-4.0.4-28mdk.i586.rpm

Tu peux aussi contrôler le md5sum à la main:
rpm2cpio rpm-4.0.4-28mdk.i586.rpm | cpio -ivd
plus md5sum sur les fichiers.

Et si après tout ça si le craker passe inaperçu, c'est qu'il est très fort.

Si c'est un système rpm based.
vérification :
rpm -V -a
remplacement :
rpm -U --replacepkgs something*rpm
pour savoir a quel paquet est rattaché un fichier :
rpm -q -f [fichier]

Tout est dans "man rpm".

mais les choix techniques qui sont faits sont tout simplement délirants.

?!?

il faut 25 outils en userspace rien que pour charger les modules

0 outil userspace

/etc/modules.conf
# ALSA portion
alias char-major-116 snd (*)
alias snd-card-0 snd-sbawe

# OSS/Free portion
alias char-major-14 soundcore (*)
alias sound-slot-0 snd-card-0 (*)

# card #1
alias sound-service-0-0 snd-mixer-oss (*)
alias sound-service-0-1 snd-seq-oss (*)
alias sound-service-0-3 snd-pcm-oss (*)
alias sound-service-0-8 snd-seq-oss (*)
alias sound-service-0-12 snd-pcm-oss (*)

# sauvegarde/restauration mixer
post-install snd-card-0 /usr/sbin/alsactl restore >/dev/null 2>&1 || :
pre-remove snd-card-0 /usr/sbin/alsactl store >/dev/null 2>&1 || :

* Lignes pour la cohabitation avec OSS. Bientôt supprimées lorsqu'il n'y aura plus OSS.

Ajoutons /etc/init.d/alsactl pour sauvegarder le mixer à l'arrêt de la bécane (idem OSS).

ne parlons pas d'autodétection !

C'est pas aux drivers de faire la détection mais à un programme séparé. Sur Mandrake et SuSE la détection est faite. C'est le même principe que le reste (OSS, scsi, etc).

redhat a bien sorti un gcc2.96

C'est normal puisque ce n'est pas un 2.95 ni un 3.0. L'objectif étant d'être compatible source avec ces 2 compilos. 2.95 n'était pas un bon nom car non compatible binaire avec le 2.95 et 3.0 qui n'était pas sorti et lorsque 3.0 était sorti il n'était pas compatible binaire avec 2.96. Il fallait bien donner un nom à ce compilo mais sans faire croire qu'il était compatible avec 2.95 ni 3.0. Comme 2.96 est une branche de dev de gcc et que cette branche n'allait jamais sortir officiellement, le nom de 2.96 est correcte. Un 2.95rh pourrait faire croire que le compilo de redhat est compatible avec le 2.95, ce qui n'est pas le cas.

> bah c est pas nouveau
> y a des paquets debian qui ont des versions de softs jamais sortis aussi

C'est pas une bonne raison pour applaudir des deux mains.

Ça le gène si peu qu'il ne l'a pas encore sorti ... Alors que c'est "Le monsieur" 2.4 et qu'il bosse chez Conectiva. No comment.

Ben """"""""""remercions"""""""""" Mandrake d'avoir initialisé cette mauvaise habitude.
Un mois après la sortie de la mdk 9.1, Linux 2.4.21 n'est toujours pas sorti... Alors que la mdk utilise un 2.4.21pre4 de fevrier 2003. Dans une semaine celà fera 3 mois...

> allors samuel , ton staff va encore sauter au plafond ? ;)

SuSE a sorti gcc 3.3 mais ils ont le bon goût d'ajouter "prerelease" :
http://www.suse.de/en/private/products/suse_linux/i386/new_features(...)

Je me trompe ou gnome 2.2.2 n'est pas sorti aussi.

Parce qu'il n'y a pas que la sécurité qui compte. Il y a aussi les performances. Demain Debian va sortir :
- "Trusted Palladium Debian"
et ça va marcher...

> > up2date est passé en mode démo... il faut s'inscrire, répondre à des questions tous les deux mois pour pouvoir utiliser de temps à autre, quand les serveurs sont pas trop chargés, leur outil de mise à jour

Tu peux utiliser un serveur rhn libre :
http://www.nrh-up2date.org/demo.html(...)

> D'un coté, il veut la GPL pour écarter apple et ms. De l'autre il veut la GPL pour lui permettre d'intégrer facilement les drivers proprios de type nvidia grace aux SYMBOLS_*. Comprends pas...

Parce qu'un driver en proprio dans Linux ne permet pas une "récupération" de linux. C'est totalement différent avec xfree86. Le driver proprio dans linux est dans un cadre bien délimité avec EXPORT_SYMBOL et ne va pas faire passer la vm, etc sous proprio.
Les sources sous GPL/BSD de linux le resterons. Et celà quelque soit la volonté d'une boite commerciale et même si elle ajoute 20 drivers propriétaires.

Par contre avec xfree86, la situation est différente. Une sociétée commerciale peut ajouter un driver, modifier en profondeur le serveur, le rendre incompatible avec les serveur xfree86 existant et sans fournir le moindre code.

De plus, Linux étant sous GPL tu ne peux pas faire une distribution avec des drivers proprio (il n'y a que knoppixfr qui l'a fait et pour moi knoppixfr a fait une connerie). Si tu livres Linux il faut que tous les codes soient disponibles ! Le driver proprio ne peut être qu'un add-on que tu récupères sur le web, un cdrom... Mais le driver proprio ne peut pas être un noyau Linux complet en binaire sans les sources ! Tu ne peux fournir QUE le driver en proprio.

> on est d'accord.

Non.

> Si XWin est en GPL, il est ferme a XFree86 puisque le code de XWin ne pourrait etre integré a XFree86.

Non.

C'est le code sous GPL qui ne pourra aller vers xfree86. Or initialement, il n'y aura aucun code sous GPL (xwin ne pouvant modifier le copyright d'un source qu'avec l'accord de l'auteur). Et si ton argument c'est de dire que xwin se ferme à xfree86, pense que xfree86 se ferme à tout les codes GPL. Et il y a plus de code sous GPL que sous BSD dans un système GNU/Linux (avec l'utilisation de librairie, c'est pas très génant)..

> Donc, pour une compatibilité complète, il faut que le source soit et reste en licence BSD ou MIT. Et pas GPL.

Oui. Mais ce n'est pas incompatible avec un projet sous GPL. Et parmis les avantages d'un projet GPL, c'est qu'il peut accèpter du code GPL. Ce qui n'est pas le cas d'un code BSD où le GPL est interdit (cherches du gpl dans xfree86 :-), il n'y en a pas).

Sinon, tu peux m'expliquer comme fait Linux pour avoir du code sous BSD?

Si tu comprends ça, tu comprendras aussi que xwin, le projet, peut être GPL avec des sources sous BSD qu'ils peuvent donner à xfree86.

> Et un projet sous GPL avec uniquement du code BSD, ca n'est pas possible d'apres ce que tu m'explique.

Pourquoi ?

(a) Le projet est GPL, ça veut dire, entre autre, qu'il faut pouvoir accéder aux sources si tu as le binaire.
(b) Le projet est BSD, ça veut dire, entre autre, que tu ne peut exiger d'avoir les sources si tu as le binaire.

Un source BSD dans un projet GPL, permet de respecter la licence du projet. Par exemple pour (a), je peut fournir le source à quelqu'un qui a le binaire.

Un source GPL dans un projet BSD, ne permet pas de respecter la licence du projet. Par exemple pour (b), je ne peut pas refuser de fournir les sources si quelqu'un a le binaire.

xfree86 est sous BSD, je ne suis pas obligé de fournir les sources.
xwin est sous GPL, je suis obligé de fournir les sources. Il faut que la/les licences des sources respectent la licence du projet. La BSD ne dit pas que, si quelqu'un a le binaire on n'a pas le droit de fournir les sources ! Si c'était le cas, la BSD ne serait pas compatible GPL. (ok c'est un exemple stupide).

Je ne vois pas en quoi un source BSD est en confit avec un projet sous GPL. Tous ce que demande un projet GPL peut être respecté avec du code BSD ou du code dans le domaine public par exemple. Par contre un source GPL ne peut être mis dans un projet BSD ou alors j'ai raté un truc. De plus, pour qu'un projet soit GPL, il n'y a pas un quota de code GPL à respecter. Le projet peut être GPL avec 100 % de code sous BSD. Dans ce cas tu peux faire un fork et lancer un projet sous BSD. Par contre un projet sous GPL avec du code sous GPL, tu ne peux faire un fork et passer la licence du projet sous BSD.

Le problème des programmes sous BSD est qu'ils ne peuvent avoir de code sous GPL (mais il peuvent utiliser des librairies sous LGPL). Ça ne veut pas dire que la réciproque est vraie ! Jètes un coup d'oeil au source postgresql et tu verras qu'il n'y a aucun code sous GPL.

Si tu écris un fichier .c, tu es le propriétaire et peut décider de la licence. Par exemple tu vas choisir BSD car tu veux que le source soit utilisé dans un projet proprio ou xfree86 ou xwin...
Tu peux aussi refuser une utilisation "proprio" (c'est très vague) de ton source et dans ce cas tu le met sous GPL. Dans ce cas, ton source ne peut être utilisé que dans un projet (L)GPL.
Lis la licence GPL.

Exemple :
$ head -45 /usr/src/linux/drivers/net/bsd_comp.c
/*
* Update: The Berkeley copyright was changed, and the change
* is retroactive to all "true" BSD software (ie everything
* from UCB as opposed to other peoples code that just carried
* the same license). The new copyright doesn't clash with the
* GPL, so the module-only restriction has been removed..
*/

/* Because this code is derived from the 4.3BSD compress source:
*
* Copyright (c) 1985, 1986 The Regents of the University of California.
* All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* James A. Woods, derived from original work by Spencer Thomas
* and Joseph Orost.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
$

C'est un source sous BSD dans Linux.
Puis regarde /usr/src/linux/COPYING qui est le copyright de Linux (c'est la GPL). Donc le fichier bsd_comp.c est considéré comme GPL sous Linux (car la BSD n'est pas incompatible avec la GPL et la GPL est une BSD avec des exigences supplémentaires) et est considéré BSD sous netBSD. Le licence de netBSD exige des sources sous BSD pour netBSD, mais un source GPL ne peut pas être mis dans un projet BSD (celà va à l'encontre d'exigences de la BSD).

Il y a un petit fil de discussion ici avec d'autres pointeurs qui parle de GPL/proprio EXPORT_SYMBOL_GPL, EXPORT_SYMBOL etc...:
http://linuxfr.org/comments/186264.html(...)

> Mais le probleme n'est pas de connaitre la difference, mais de savoir si la GPL est adaptee a XWin.

Pour savoir si BSD ou GPL est plus adapté, il faut connaitre les différences.

> et permettre sans restriction le backportage de code de XWin vers XFree86
> Et ca ca ne peut se faire qu'en conservant une licence compatible, i.e. BSD ou MIT.
Aucun problème. Projet sous GPL source sous BSD. D'ailleur ils seront forcément sous BSD ou alors il faut l'accord de celui qui a le copyright pour changer la licence. Voir un peu plus haut où c'est discuté.

> comme precise dans des posts plus haut, si le code est en GPL, il est bloque en GPL.

Je parle de projet et non de code. Linux a plein de code sous BSD et les *BSD pioche du code de linux comme linux récupère du code *BSD.

> La ou je veux en venir, c'est qu'il faut arreter de contraindre et commencer a eduquer.

Certe. Mais pour que ça marche, on peut rêver. Si Linux était sous BSD, je ne suis vraiment, mais vraiment, pas convaincu qu'IBM, Sun, HP, etc... aurait fait autant de retour à la communauté.

De plus dire que BSD marche pour xfree et donc il ne faut rien changé est un peu léger comme argument. Tu n'as pas connu l'époque ou il y avait des serveurs x11 d'une somme rondelette, basé sur xfree86, et qui apportait rien à la communauté sinon de pouvoir utiliser une carte graphique. Informix est un dérivé de postgres et ça n'a pas aidé postgresql.

Pour moi, si la GPL/LGPL peut-être utilisé, il faut l'utiliser. J'espère que sur ce point on est d'accord. Je ne dis pas que la GPL est +forcément+ mieux que BSD pour xwin. Dans le domaine des noyaux, on a du GPL (linux) et du BSD (*BSD). Linux marche bien. Je ne vais pas conclure que c'est grace à la GPL. Mais il est meilleur pour le logiciel libre d'avoir du (L)GPL que du BSD. Je ne vais pas conclure qu'il faut du 100 % GPL et évité tout proprio. Les mécanismes comme EXPORT_SYMBOL sont là pour gérer avec souplesse un bon compromis ouverture aux proprios et conservation de la disponibilité du code.

Enfin, si xwin passe sous GPL, il y a un choix côté licence. Soit BSD avec xfree86, soit GPL avec xwin. Avoir le choix n'est pas un mal. Si xfree86 est plus utilisé à cause des contributions des sociétés commerciales ou parcequ'il y a des versions proprios basées sur xfree86 qui sont très utilisées, tant mieux pour xfree86. Si c'est xwin, tant mieux pour la communauté car la GPL défend mieux mon "intérêt" contrairement à la BSD ou tout est possible.

Il y a une opportunité pour avoir un serveur x11 sous GPL. Il serait dommage de ne pas la saisir. Surtout que ça ne va pas faire de "mal" à xfree86.

La GPL c'est mieux selon moi.
Imagine que tout ce qui constitue une distribe GNU/Linux soit sous BSD.
Alors IBM (par exemple) peut diffuser une distribe avec pleins d'extensions bien proprio, une pile tcpip non standard, une libc qui envoye des infos sur ton installation et ça sans fournir les sources, sans que tu puisses contrôler, adapter ton système. Si IBM fait bien son boulot, sa distribe devient un succès. Tout le monde l'utilisent mais on a pas les sources. Bref on se retrouve avec un système bien proprio. La GPL est là pour éviter ce type de dérive. On peut remarquer que les boîtes bien proprios n'aime pas la GPL mais n'hésite pas à piocher dans les produits BSD.
La GPL n'interdit pas un programme propriétaire d'utiliser des programmes GPL (mon programme propriétaire peut utiliser Linux, sed, etc...). La LGPL permet de linker un programme propriétaire. Globalement ce sont de bonnes licences qui défendent l'utilisateur (qui peut auditer les sources, les adapter, etc...) et n'ignorent pas le geste généreux de la part du développeur d'avoir "ouvert" les sources.

Par contre, la GPL est problématique pour les drivers, les extensions. C'est dans ces cas particulier qu'il faut utiliser des systèmes comme EXPORT_SYMBOL et EXPORT_SYMBOL_GPL.

Prends Apple. Il utilise xfree86. Actuellement Appel fournit les sources. Mais Apple n'est pas obligé. Par exemple, Appel pourrait faire une version de xfree86 qui empêche d'affichage des applis qui n'ont pas été développer avec leur version de xfree86 payante.

Avec BSD toute les dérives sont possibles.

Très juste. Les sources BSD sont compatibles avec un projet GPL. Par contre un source sous GPL n'est pas compatible avec un projet BSD. C'est à cause de ça qu'il faut un "semblant" de double licence : projet -> GPL, sources -> BSD.

Un source GPL dans xwin GPL (ce qui tombe sous le sens :-)) ne pourra pas être mis dans xfree86. D'où l'intervention de ce que j'appelai abusivement la double licence/copyright.

Par contre, le système EXPORT_SYMBOL_GPL et EXPORT_SYMBOL est nécessaire pour qu'une société Toto diffuse des drivers propriétaires pour un xwin GPL. Car même si les sources sont BSD, c'est la GPL qui prévaut dans un projet GPL. Par contre, Toto ne peut difuser que le driver et non xwin avec le driver. Sinon Toto doit fournir tout les sources. Ce qui normalement empêche un distributeur de GNU/Linux/xwin de distributer ces drivers propriétaires. Mais on voit que certains ne s'en privent pas ...

J'ai testé une woody lorsqu'elle est sortie. J'ai eu la même impression.
La debian est orienté serveur mais je ne la conseillerai pas pour un serveur ni pour quoique ce soit d'autre.
Heureusement que redhat a diminué son support à 1 an sinon la debian n'a pratiquement aucun intérêt (sauf que c'est une distribe non commerciale).

l'auteur de l'article est dans le moule du public de dlfp. Ne surtout pas critiquer mdk ou debian. Ou sinon il faut utiliser des formules concensuels comme :
- debian c'est "has been" mais c'est normal car c'est fait pour les "pointeurs".
- ma mandrake plante sur mon PC mais je cours acheter la nouvelle version qui doit surement corriger le problème.

M'enfin, si c'est ce que demande le peuple...

Merci de préciser ce que je viens dire :-)

Pour que du code passe de xmin à xfree86 il faut qu'il soit sous BSD et GPL. GPL sous xwin et BSD sous xfree86. S'il n'est que GPL il ne peut pas passer sous xfree86.

> quel est l'interet d'un telmecanisme pour XFree86 ou un projet forké comparable ?

Le même que pour Linux. Ceux qui font des modifications du "coeur" de xwin doivent fournir les sources (Apple qui fournit les sources mais n'est pas obligé, etc...). Par contre, la licence doit être double pour cohabiter avec XFree86 (MIT/BSD et GPL). C'est actuellement pratiqué par Linux. Par exemple Le code sous linux d'un driver est GPL mais il est possible d'utilise ce même code ou un dérivé sous BSD (sans restriction quoi) hors de Linux (pour les composant sous BSD/GPL). Par exemple pour faire un version spécialisé pour solaris. Ce principe est utilisé pour acpi qui est en parti développé par Intel. Ça permet à Intel de fournir les sources à Linux et respecter la GPL. Ça permet aussi à Intel d'utiliser ce travail pour Windows sans que tout Windows soit sous GPL.

Les devs doivent se protéger explicitement d'un fork proprio le "coeur" (qui est un travail fourni par la communauté) avec l'utilisation de EXPORT_SYMBOL_GPL et authoriser les drivers proprios avec EXPORT_SYMBOL comme le fait Linux.

J'aimerai bien un passage sous GPL avec le mécanisme EXPORT_SYMBOL_GPL de Linux. Les api critiques, proche du fonctionnement interne de X seront en EXPORT_SYMBOL_GPL, et le nécéssaire pour faire un driver sera en EXPORT_SYMBOL.

> Sinon ca va être le bazarre.
c'est un problème de standard. Il est évident que le fork va pas casser l'api existante. De plus, xfree n'est pas la seul implémentation x11 et Qt, Gtk marche sur les autres serveurs x11.

> notons aussi l'imposante doc : imposante et excellente ! le tout sous "OPEN PUBLICATION LICENSE Draft v0.4, 8 June 1999". La majorité de la doc est aussi traduite en Français. Impressionnant.

Rien de très exitant. L'annonce en français : http://www.redhat.fr/news/article/131.html

Apparament ces solutions font suite au rachat de ArsDigita et C2Net. Heureusement, redhat a changé la licence. Tant mieux...

Faudrait que la news signale que c'est du logiciel libre et non seulement de l'utilisation de logiciel libre (ce qui est partiellement faut puisqu'il faut une machine java (jre)).
licence : http://www.redhat.com/licenses/ccmpl.html(...)