François B. a écrit 363 commentaires

Et si tu ne pédales pas assez vite, la machine n'est plus alimentée ?

Avant de dire une connerie, on se renseigne un minimum ;-)

Tous les sites d'utilisateurs sur p.d.o sont dans ce cas (essaye par exemple p.d.o/~daenzer pour les pilotes dri des vieilles cartes ati.) C'est le cas depuis la compromission des 4 serveurs de Debian. Ils profitent du fait que les serveurs soient en vrac pour faire d'un coup les migrations qu'ils voulaient faire progressivement (mise en place de LDAPv3 par exemple.)

Donc le problème de redirection, c'est dû à l'équipe web ou d'administration des serveurs, pas des utilisateurs eux-même (qui ne peuvent pas se connecter pour le moment sur les serveurs.)

D'après http://www.debian.org/doc/manuals/project-history/ch-detailed.en.ht(...) la rex date de décembre 1996...

Sinon, à la question est-ce que je l'ai utilisée, la réponse est oui : c'étais la deuxième version de Debian que j'ai utilisée. J'ai en effet commencé avec buzz...

<nostalgie>
Ca file un coup de vieux tout ça ! C'était sur un Cyrix P166+, 32Mo RAM, 2Go DD, Asus P/I P55 T2P4C, SB16 PnP, NE2K ISA, Diamond Stealth 3D2000, écran Sony 15sfII. Enfin bon, j'utilise encore l'écran et la carte son :-)
</nostalgie>

Hum... l'article n'a pas été relu avant la mise en ligne j'espère ! Il y a plusieurs fois inversion entre «b» et «d» (ndb-client ou ndb-server à la place de nbd-client ou nbd-server.) De même, les devices utilisés sont /dev/nb[0-7] d'après mon MAKEDEV. Ah oui, en passant, il est préférable d'utiliser /sbin/MAKEDEV pour ceux qui n'utilisent pas devfs afin d'être sûr de ne pas avoir de conflit de nom/majeur/mineur par la suite.

Voila, mes 2¢ ;-)

La question que je me pose toujours quand je vois ce genre de «statistiques», c'est quid des clusters (très souvent utilisés sur les serveurs de prods pour gagner en disponibilité). De plus, même s'ils sont moins utilisés, il y a aussi des systèmes qui tournent sur des machines virtuelles comme sur les mainframes (avec uml, vmware...)

Tout ça pour dire que de toutes façons, c'est du bidon !

De mémoire, et pour faire une copie en une seule fois :

cdrdao copy --source-device /dev/cdrom --source-driver plextor --device /dev/cdrecorder --driver generic-mmc --eject --speed 12

Bien sûr, les options sont à adapter à ta configuration...

Je tiens juste à préciser qu'IPsec n'est pas la seule solution pour chiffrer les données sur le lien radio, et je ne veux pas parler de stunnel ou ssh. En effet, j'utilise OpenVPN sur mon réseau sans fil et ça marche vraiment très bien. Les paquets sont chiffrés et authentifiés (certificat sur chaque machine) en utilisant la lib openssl (qu'il faut mettre à jour...)

Inconvénient : OpenVPN n'est qu'à l'état d'ébauche sous Windows, et expérimental sur freeBSD et netBSD.

Ca permettra peut-être de ne pas être obligé d'utiliser un mode de compatibilité x86 pendant tout le temps de l'amorçage... (voir le lien vers linuxbios un peu plus bas pour une alternative)

Ne regarde pas Ghost in the Shell: Stand Alone Complex épisode 3 alors ;-)

Personnellement, j'ai l'habitude de mettre un test sur le type de fichier (-type f pour un fichier classique) et de passer par xargs pour ne lancer la commande à exécuter sur les fichiers qu'une seule fois (gain de temps non négligeable si le nombre de fichiers retourné est grand).

De plus, pour ne pas être gêné par les espaces dans les noms de fichiers, on peut séparer les noms par un caractère nul au lieu d'un espace (couple d'options -print0 et -0 pour find et xargs).

Ma commande ressemble donc à :
find /dossier -type f \( -name "foo" -or -name "bar" \) -print0 | xargs -0 rm -rfv

Enfin, je voudrais pointer les options -iname et -lname de find qui permettent respectivement de faire correspondre le nom de fichier avec une casse non significative et de faire correspondre le nom du fichier pointé par un lien symbolique (-ilname combine les 2). Exemple d'utilisation de -lname pour savoir quand /etc/init.d/iptables est appelé par init :
find /etc -type l -path '/etc/rc?.d/*' -lname '*/iptables'

Note : les options que je donne ne sont disponibles que pour les versions GNU de find...

hum... tu es sûr de la config matérielle ?

Personnellement, j'ai une machine avec une P/I P55T2P4, et d'après le manuel papier, il n'est pas possible d'aller au-delà du pentium 200. Après une mise à jour du BIOS, je lui ai collé un pentium 233 mmx, mais il s'agit de la limite max d'après la doc de cette mise à jour...

D'autant plus que le "v" est inutile...

Exemple sur l'archive de jEdit :
$ jar tf jedit.jar | grep ^META-INF/
META-INF/
META-INF/MANIFEST.MF

Je ne sais pas s'il est libre, mais un bon dictionnaire français est le TLFI. Il est créé par des organismes d'état (CNRS, ATILF et université Nancy 2), donc il serait dommage de s'en priver puisqu'il provient de nos sous ;-)

Un des points très intéressant à mon avis est la possibilité de rechercher un mot en entrant un mot qui se prononcerait de la même manière (par exemple aurnhiteaureink --> ORNITHORYNQUE).

URL : [http://atilf.inalf.fr/tlfv3.htm(...)]

Note : je ne sais pas trop ce que vaut cette version car elle est toute nouvelle et je ne l'ai pas encore beaucoup utilisée (avant j'utilisais la version disponible ici : [http://zeus.inalf.fr/tlf.htm(...)])

Autre question qui peut t'aider à trouver la réponse à la tienne :

Est-ce qu'il est légal d'obliger les élèves du lycée d'acheter des manuels scolaires précis ?

Dans ton cas, un école privée a encore plus de libertés qu'une école publique, à mon avis ...

En ce qui concerne la version d'une bibliothèque Java, il existe des champs prévus à cet effet dans META-INF/MANIFEST.MF (pour ceux qui ne connaissent pas Java, il s'agit du fichier décrivant l'archive Java, et entre autre quelle est la classe principale dans le cas d'un jar auto-exécutable).

Tous les détails se trouvent ici : http://java.sun.com/j2se/1.4/docs/guide/versioning/spec/VersioningS(...)

Voici un exemple tiré de la page ci-dessus :

Manifest-version: 1.0

Name: java/util/

Specification-Title: Java Utility Classes

Specification-Version: 1.3

Specification-Vendor: Sun Microsystems Inc.

Implementation-Title: java.util

Implementation-Version: build57

Implementation-Vendor: SunMicrosystems. Inc.

Si l'on obtient un instance de Package décrivant le paquet en question (java.util dans notre exemple), les méthodes getImplementationVersion() et getSpecificationVersion() vont nous retourner respectivement "build57" et "1.3". Voir : http://java.sun.com/j2se/1.4/docs/api/java/lang/Package.html(...)

Bien sûr, le problème est que tout le monde ne connait pas l'existence de cette gestion des versions, et qu'en pratique c'est très peu utilisé. Mais dans le cas où c'est fait correctement, si on peut localiser le jar ou s'il est placé dans le répertoire des extensions, on peut l'utiliser.

Pour respecter les 4 libertés du libre, Sun n'est pas obligé de mettre les sources en téléchargement. En effet, les sources doivent être disponibles pour les utilisateurs. Cela veut donc dire qu'ils peuvent ne distribuer les sources que sur des CDs dans les boîtes, voire ne les distribuer que sur demande.

Si le produit est commercial (ne pas confondre avec propriétaire ;-)), cela ne serait pas surprenant que la diffusion des sources soit limitée.

En revanche, rien n'empêche ensuite un client ayant acheté le produit de mettre les sources en téléchargement ...

En effet, il ne faut pas que n'importe qui puisse écrire dans /usr/local. Mais rien n'empêche un utilisateur spécifique d'écrire dedans ... Sur mes machines (Debian), /usr/local est SGID src. Donc tout utilisateur faisant partie du groupe src peut écrire dans /usr/local. Reste maintenant à savoir qui mettre dans le groupe src. Y mettre tous les utilisateurs est certainement une erreur !

De plus, afin de faciliter l'installation et la suppression de programmes externes à la distribution, il existe un outil très pratique : GNU Stow [http://www.gnu.org/software/stow/(...)]. Pour l'utiliser, on a un répertoire /usr/local/stow dans lequel on crée un répertoire par application que l'on installe à la main. Lorsqu'on compile un soft qui utilise autoconf, il suffit de passer --prefix=/usr/local/stow/mon-soft à ./configure. Une fois le make install réalisé (avec un utilisateur qui a le droit d'écrire dans /usr/local/stow, pas forcément root), il suffit de faire "stow mon-soft" pour créer des liens symboliques depuis le répertoire mon-soft vers les répertoires adaptés dans /usr/local.

Ensuite, si vous voullez enlever un soft, il suffit de faire "stow --delete mon-soft" et de supprimer le répertoire (on n'est pas obligé de le faire dans l'ordre là).

Avantages de stow :
- on n'est pas obligé d'être root et on garde une bonne sécurité (à mon avis) ;
- on peut désinstaller facilement un soft ;
- on évite d'écraser par erreur des fichiers déjà existants : stow prévient lors d'un conflit.

Jigdo n'est pas comme dit dans la nouvelle un outil qui permet de créer de manière simple des images ISO de la Debian (même s'il les reconsitutue). En fait, il s'agit d'un outil qui permet de télécharger plus facilement une ISO sans pour autant nécessiter sur le serveur un fichier contenant la dite image. L'image est reconstituée à partir des fichiers téléchargés individuellement (par wget) et autour desquels on remet le "liant" (description du fs ...) de l'image.

Cet outil permet par exemple de réduire très fortement la place nécessaire au stockage des ISO (un paquet disponibles sur plusieurs images n'est présent qu'une seule fois sur le serveur) et ne nécessite pas rsync (ce qui était le cas du PIK, Pseudo Image Kit, précédemment utilisé) qui est souvent filtré par les firewall d'entreprise.

Enfin, jigdo n'est pas restreint aux ISO de la Debian. Il peut être utilisé partout où quelqu'un veut distribuer sur le net une image ISO.

Bon, je vous laisse lire le mini-HOWTO, il est vraiment très bien fait (je l'ai lu ce matin). Vous n'êtes pas obligé de le lire pour utiliser jigdo, mais ça permet de comprendre comment ça fonctionne.

Moi, ce que je critique, c'est qu'ils ont fait une annonce alors qu'aucun correctif n'existe. D'après eux, c'est une solution acceptable d'avoir un utilisateur non privilégié d'exploité (ce qui permet par la suite d'utiliser une faille locale pour devenir root). De plus, ils considèrent normal que tout le monde mette à jour leur openSSH avec une version qui n'a pas été testée de manière extensive, et qui surtout n'est pas totalement fonctionnelle. Je me répète, mais la compression et PAM ne fonctionnent pas sur certains systèmes.

Si ce n'est pas du foutage de gueule, alors défoulez vous avec le [-], mais je ne suis pas de cet avis ...

Voici l'alerte de sécurité chez Debian [http://lists.debian.org/debian-security-announce/debian-security-an(...)]. Les non anglophobes devraient avoir peur en la lisant.

En effet, il semblerait que même si ISS a changé de méthode (hum ...), ça reste caché ... De plus, la nouvelle version ne corrige pas le problème, mais ne permet la compromission que d'un compte non privilégié. Cela ouvre donc la porte à l'utilisation de tout escalation de privilège ou tout exploit local !

De plus, vu le peu de temps donné, ainsi que le manque d'informations sur la faille font qu'aucun paquet corrigé n'est disponible pour la potato. De même, la version pour la woody n'a pas été testée par l'équipe QA et peut donc tout casser, en plus de ne pas être totalement fonctionnelle (compression indisponible sur certains systèmes, PAM indisponible) !

Bien sûr, il ne faut pas critiquer quelqu'un qui divulgue une faille de sécurité sur un LL, mais là je trouve qu'ils poussent le bouchon un peu trop loin. D'abord l'affaire apache, maintenant openSSH, je commence vraiment à apprécier de moins en moins ISS ...

PS : rien à voir, mais états-unien est un mot très laid... C'est dans le dictionnaire cette horreur ?

Au moins, ça évite de dire "américain" qui est plus général. Il ne faut pas croire qu'ils sont tous aussi débiles qu'aux Etats-Unis en Amérique ...

C'est vrai qu'aujourd'hui, avec les dernières JVM, il n'est plus utile d'avoir recours au double-checked locking étant donné que le coût des blocs synchronized a fortement baissé.

Lorsque j'ai entendu parler de ce problème, j'ai voulu voir si devoir faire deux tests ne faisait pas perdre le temps gagné en ne passant pas dans un bloc synchronized. Résultat des courses avec la JVM 1.4, que ça soit en interprété ou avec hotspot (client et serveur) : laisse tomber, c'est quasiment la même chose. Donc autant déclarer toute la méthode synchronized.

De plus, une petite recherche dans la base de données de bugs chez SUN montre qu'il n'existe aucun bug ouvert ressemblant à ça ... Il a probablement été résolu (du moins pour la JVM de SUN) : http://search.java.sun.com/Search/java?qt=+%2Bstate%3Aopen+%2B%22do(...) (il faut être enregistré (gratuit) sur le JDC pour accéder à cette page)

De plus, un énorme clin d'oeil aux fans est fait en intégrant le chasseur de primes Fett dans un rôle majeur, ainsi que son magnifique vaisseau, le Slave 1, qui est le premier à faire la jonction entre les deux trilogies.

Et bien non, il y avait déjà un lien entre les deux trilogies dans le premier épisode : Grido.
Pour ceux qui n'auraient pas fait le lien, il s'agit d'un des copains d'Anakin. Dans l'épisode 4, il est chasseur de prime et veut vendre Solo dans un bar à Mos Esley.
Un collègue vient de me dire que Grido est présent également dans le 2, mais je ne l'ai pas encore vu :-(

Dans les versions plus anciennes de tar, il s'agissait de l'option I (i majuscule) pour traiter les archives bz2. Malheureusement, I est aussi utilisé par tar sur Solaris, alors les développeurs GNU ont préféré utiliser une autre option pour éviter les problèmes de compatibilité dans les scripts. Si aucune des deux options ne fonctionne, c'est que ton tar est vraiment trop vieux ...

ça devrait réjouire ceux qui protestaient contre la no-disponibilité des textes de lois En effet, mais il faut qu'ils incluent également un service de traduction loi -> français ...