Igor Genibel a écrit 48 commentaires

Exactement, c'est sur quoi nous sommes en train de travailler. Ce n'est pas évident de changer tout un système d'authentification comme ça, à la volée, ce nouveau service n'est pas encore disponible mais va l'être d'ici peu.

C'était ce que était proposé aux hébergés jusqu'à hier soir comme l'a expliqué Julien. Ce n'est dornévant plus le cas.

Un problème de droit sur un fichier de configuration d'un des services.

Bonjour,

ce lien est pour le moment inactif suite aux évolutions que nous avons apporté au système d'authentification.

Nous travaillons sur ce point pour pouvoir le rendre actif d'ici peu.

En aucun cas !
Le processus de validation des packages a été amélioré par l'arrivée des des branches «testing» et «unstable». Même si cela fait depuis un certains temps que nous cotoyons ces branches, elles ne sont pas aussi mûres que leur age nous permettrait de le penser. Il ne faut pas forcément seulement voir ces branches. Il y a toute la structure d'acceptation des packages (passage d'un branche à l'autre), toute la structure permettant de gérer la sécurité, le nombre important de package avec des dépendances et des inter-dépendances lourdes et complexes, ....
La période de freeze est là pour prendre un photo à un moment donné pour corriger tous ces soucis. Et sur plus de 12000 packages ce n'est pas un mince affaire.
Dire que ce projet louable va accélérer le release est faux.

Malheureusement je pense le contraire.

En effet, cette «outils» permet à beaucoup de personnes de packager des softs et de les rendre disponibles ce qui peut-être louable vu le délais d'acceptation d'un volontaire dans le projet.
Mais le problème du délais vient du fait que beaucoup plus de package seront susceptibles d'avoir de bug «release-critical» et ce sont essentiellement ces bugs qui ralentissent le processus, car il faut statuer sur le devenir du package, sur le devenir de ces bugs, ....
Voilà l'explication principale.

Il faut bien que l'argent passe quelque part ! Autant que ce soit dans des films de merde plutôt que dans les armes... Enfin bon, c'est ce que j'en dis

L'intérêt suscité par les RMLL est-il si ridicule qu'il n'y ait aucun commentaire de soutien, de demande complémentaire d'explication, que sais-je encore ?

Je suis attristé de voir que les lecteur de Linuxfr soient si peu réceptif à cette nouvelle.

Personnellement je suis attristé mais si c'est le bon choix, alors, je vous suis. Étant très attaché à l'ABUL et donc au RMLL qui, faut-il le rapeller, est la seule rencontre permettant de discuter de libre au sens général et non exlusivement technique.

Il ne faut en aucun cas que cette manisfestation périsse. Soutenez cette merveilleuse initiative prise par Pierre Jarillon (pas seulement lui mais rendons à César ce qui appartient à César).
Merci

Il est très fortement déconseillé d'utiliser des miroirs du site security.debian.org car, concernant les mises à jour de sécurité, il faut une «confiance» absolue.

De plus, il n'y a aucun mirroir officiel concernant security.debian.org. C'est une décision qui a été prise il y a quelques temps déjà par l'équipe de sécurité de Debian.

Ceci dit, il y a des mirroirs et vous pouvez néanmoins les utiliser. Mais attention.

Pas de chance ni pour toi ni pour moi alors ;)

Est-ce si peu important que cette news doivent passer en second plan ?

J'ai presque peur pour ma debian.

je dirais plus simplement, «j'ai presque peur» tout court...

Malheureusement non, ça prendrait trop de ressources sur les serveurs (calcul et où temps).

Par contre, un truc qui serait interressant sur les serveurs officiels (pas les mirroirs) serait un faire tourner un «aide» ou un «tripwire» sur les fichiers mis à disposition. Cela permettrait d'avoir un niveau de confiance supérieur.

De plus l'utilisation des attributs étendus des systèmes de fichiers ext2/ext3 permettrait aussi d'éviter ce genre de problème.

Mais ces solutions sont coûteuses dans le sens où il faut faire de l'administration active et non passive comme c'est le cas maintenant.

Ce qu'il faut néanmoins savoir, c'est que l'on peut contourner le problème en changeant le User-Agent envoyé par le navigateur. Mais cela implique que l'on puisse le changer.

Pour ma part, j'utilise Konqueror avec un User-Agent positionné sur MSIE5.5 .... pour accéder à mes comptes sur la société générale (http://logitelnet.socgen.com/(...) ), le serveur est «bluffé» et tout se passe bien.

Note: j'ai déjà envoyé deux lettres aux responsables de ce site sans réponse de leur part :-/ Espérons que la masse fera bouger les choses (si masse il y a).

Je serais plutôt d'avis d'attendre que les fonctionnalités manquantes soient activées avant de faire un comparatif. Je pense tout même que la charge sera moins importante mais un peu plus que les graphes du moment ;)

Mon cher Olivier Mengué sache que maintenant ton nom restera gravé dans toutes les fortunes fracophones du monde.

Un grand merci à toi et à Fabien ;)

Nous utilisons du raid 5. Quand même, on veux une certaine pérénité des données en utilisant un maximum l'espace disque disponible.

En ce qui concerne le MX secondaire il est là pour ces coups durs. Donc si le stockage est inaccessible, il temporise, c'est son but.

Le fait que ce soit du RAID soft engendre quelques contraintes:
- le raid soft n'est pas aussi performant que le raid hard;
- le raid soft c'est pas cher;
- le raid soft avec des disques IBM c'est pas bien ;)

En fait tout dépend du niveau de sollicitation des données. Mais nous ne sommes pas insatisfait du raid soft. Nous l'utilisons donc nous l'aimons ;)

Non, nous avons un MX secondaire qui stocke les mails en attendant.

Concernant les pbs, c'est, à mon avis, plus des problèmes physiques de disques (qui sont pas mal sollicités) que des services qui sont offerts.

Il est vrai que notre maigre budget ne nous permets pas d'avoir des bêtes de courses (quoi que ;)) et que l'essentiel des contraintes se trouvent sur la machine de stockage. N'ayant pas les moyens de nous offrir autre chose que du raid soft, nous en subissons, malheureusement, les conséquences, qui étaient, somme toute, inattendues.

Voilà pour les éclaircissement

Pour être plus précis, Rafou ;)

Le projet s'appelle Debian.Les distributions qui sont fournies sont: Debian GNU/Linux et bientôt Debian GNU/Hurd

Il y aura peu être des distributions comme Debian GNU/BSD et Debian GNU/Win32 qui sont deux projets en cours.

Donc Debian GNU/Linux c'est le type de distribution et non le projet Debian.

Rien ne te force à changer pour TuxFamily. TuxFamily s'éforce d'offrir ce dont les utilisateurs ont besoin.
Ceux qui sont hébergés sur TuxFamily sont venus de leur plein grès et font évoluer les choses à leur niveau.
Tu dis que TuxFamily est dépassé. Je dirai que non ;) Nous n'avons jamais eu la prétention d'être un «SourceForge like». Mais l'évolution suit son cours.
Par contre, en ce qui concerne Java, ça ne sera pas possible mais rien ne t'empêche de mettre des applet, du moment que celle-ci soient libres ;)

Ce qu'il faut, ce sont des machines puissantes.
En effet pour le crawl et l'indexation les machines sont vraiment à genoux. De plus pour répondre au requêtes des internautes, il faut aussi une machine susceptible d'assurer le travail.

Sur Ecila en ce moment:
2 machines Bi 866 2Go et 70Go de disques pour répondre aux requêtes
2 Machines Bi 866 1Go avec une baie de 200Go pour crawler et indexer.

Je ne suis pas d'accord avec ta réponse.
> Avoir un idéal de LL et travailler pour une boite qui fait du propriétaire parce qu'il faut bien manger, c'est cohérent.

Non, je travaille pour une société qui ne fait que du libre. Je développe et contribue au logiciels libres et je vis bien. Ce n'est pas incompatible.

Ce qui est incompatible c'est de vouloir vivre du logiciel libre en ayant un modèle similaire à celui des entreprises faisant du propriétaire.