Pierre Carrier a écrit 199 commentaires

Pour F15 ?? C'est dispo depuis F11 (soit 1 an). D'ailleurs c'est indiqué sur la page que tu cites :

-- 8< --
Fedora 13 users can opt to use it? (and probably work on it?)

Yes, if you give the installer the "btrfs" option on boot it will allow you to install onto a Btrfs fs. It's been an option since Fedora 11. The box I'm currently working on is Fedora 11 with a Btrfs root. Of course it is much faster and much more stable in Fedora 13.
-- >8 --

Dans F15 il est prévu d'enlever l'option pour le rendre disponible dans l'interface de partitionnement en gardant ext4 par défaut.

Si, c'est lié. C'est parce que beaucoup pensent que la distinction majuscule-minuscule disparaît alors que le problème est l'ordre différent des caractères a A b B c C d D etc.

Du coup :
- a-Z c'est aAbBcCdD...zZ
- A-Z c'est AbBcCdD...zZ

Ulrich Drepper vous explique tout : https://bugzilla.redhat.com/show_bug.cgi?id=217359

En très gros, simple est l'antonyme de complexe, facile celui de compliqué.

Les anglophones entretiennent AMHA moins la confusion entre simple et et easy.

Et pour ne pas mélanger ma réponse technique à mon jugement personnel, lui "inutile", sur ton commentaire qui n'est pas le seul dans ce cas et certainement pas le pire :

Quand quelqu'un ne connait que peu voire pas une situation, ça me gêne profondément qu'il y porte un préjugé (si quiconque se sent offusqué je sors la définition) sur la compétence des admins ou la pertinence de leur approche.

Certains problèmes sont suffisamment complexes pour que les mecs qui s'y confrontent doivent faire des choses inhabituelles et/ou peu maintenables. Ce n'est pas nécessairement parce qu'ils sont moins intelligents ou cultivés que vous. Et quand bien même vous auriez mieux, ça passe toujours mieux de le présenter avec humilité plutôt que dédain.

Par ailleurs, c'est peut-être divertissant de basher le monde de l'entreprise, les protocoles conçus par Microsoft, les technos dépassées depuis les années 80 ou 90, mais certains d'entre nous y sont confrontés à titre professionnel et n'ont pas forcément la liberté de s'en plaindre (je ne parle pas pour moi, ça m'amuse). Comprenez que ça puisse être fatigant d'avoir ce genre de réactions quand on essaye d'échanger autour.

Il fallait JumpStart'er (= installer automatiquement Solaris par le réseau) plus d'une centaine de serveurs SPARC reposant sur OpenBoot, dans un environnement où BOOTP/DHCP n'est pas envisageable pour des raisons qui ne nous regardaient pas.

Par ailleurs le cas réel est que les machines devaient être configurées en /16 mais se trouvaient sur des segments correspondant aux /24. Chaque segment est couvert par une carte Ethernet sur le serveur de JumpStart.

Ce serveur tourne sous Linux dans une architecture de virtualisation distribuée. Dans le cas réel le gros du travail est fait par iptables.

Merci aux participants. Si quelqu'un veut plus d'explications sur ce qui ne marche pas chez lui, répondez à mon mail :)

Dans le cas de Cygwin, le prix par machine est pour le support uniquement donc le modèle de souscription décrit sur http://www.redhat.com/rhel/renew/faqs/#6 ne s'applique pas. Je ne me lancerai pas dans un débat là-dessus, je bosse pour Red Hat. Par ailleurs la forme que prend ce support est aussi très différente (notamment pas de 24x7).

Pour Cygwin ce modèle ne s'applique pas.

Et tous les paquets fournis dans Cygwin sont toujours supportés.

Les prix ne dépendent donc ni du nombre d'utilisateurs, ni du nombre de paquets, mais du nombre de machines sur lesquelles vous installez Cygwin et pour lesquelles vous voulez du support.

Non, mais maintenant c'est rare :)
Ceci dit ça marche parfaitement, d'ailleurs je regrette l'absence de tcp_wrappers pour certains services !

Exactement, même si l'IP de chacun est dans le réseau de l'autre (les masques sont suffisamment larges dans les 2 sens). Ceci dit je me tais, ça aide :)

j'ai une solution en 3 lignes (je la met car je pense que ce n'est pas celle attendue) :
$ echo 'cela
fonctionne
déjà'

Non, j'ai donné la config de la carte réseau et avec celle-ci, les paquets ne sont pas traités.

>> Je rends ça plus explicite dans le post.
> Ce n'est pas juste un coup de pub pour ton blog en tout cas, et ça c'est bien.

L'aspect publicitaire est ironiquement indiqué dans le journal... Si ça peut te rassurer je me contre-balance du nombre de visites sur mon blog, cf la nature des contenus ces derniers temps...

Quand je disais "Je rends ça plus explicite dans le post", je voulais dire que j'avais pris en compte ta remarque en améliorant la rédaction. C'est sympa d'avoir des retours, je dois avouer que j'ai rédigé l'article en 5min à partir du problème posé par chat à un ami.[/mavie]


> Aucune comparaison avec ZFS sans sauvegarde, c'est _vraiment_ un disque de mon NAS qui vient de se péter ce soir.

Ah toutes mes condoléances. Pas de sauvegarde, pas de chocolat !

> Mon poste est à prendre au premier degré si on veut, c'est vraiment une bonne idée que de faire des défis, j'aime bien et en réseau il n'y en a pas ( Si ce n'est quand on est admin-sys et que cela nous arrive -_-' ) Et de la même manière je n'ai vraiment pas compris ce qui n'allait pas.

Effectivement le problème réel (plus complexe que la prochaine version du défi) m'a demandé de reproduire le problème avec 2 stations Sparc, une machine avec virtualisation et 2 switches avant de pouvoir réaliser ce qui se passait vraiment...

Le but n'est évidemment pas de protéger formellement le serveur du reste du réseau. Par contre ce genre de mécanisme ça réduit effectivement pas mal les chances d'interaction avec le reste du monde, on peut supposer que 10.1.x.x aura plus de mal à se connecter en http dessus, qu'un utilisateur standard sur celui-ci aura plus de mal à se connecter en ftp sur 10.2.x.x, etc.

Ça n'était pas rare il y a quelques années de limiter l'accès à un service via hosts.allow/hosts.deny.
C'est aussi à peu près équivalent au principe désuet de rsh où on fait confiance à l'environnement matériel et aux administrateurs des machines. La pratique de filtrer l'accès à des services via l'IP distante est aussi courante.
Ici ça serait un moyen simple et léger de restreindre l'ensemble des interactions réseau.

Ça n'est pas le seul mécanisme de protection, ça n'est pas un mécanisme formel non plus, et ça n'a aucune importance pour le problème.

D'ailleurs avec la version plus complexe du problème que je posterai plus tard, vous verrez la raison exacte pour cette configuration... Elle est valable.

Je me répète : cas d'école.

Le problème à résoudre :
"Les clients envoient des requêtes en broadcast, un service sur le serveur doit y répondre ;"

Je rends ça plus explicite dans le post.

Ce problème est bien sûr ramené à un cas d'école pour ne pas alourdir l'énoncé. Dans la vraie vie les règles iptables ne sont pas vides non plus, et les switchs font du routage.

Et quand bien même, certaines entreprises mettent tout leur intranet en 10.x.x.x par exemple et font des sous-réseaux par zone géographique, services, équipes, etc.

Et pour ta comparaison avec ZFS sans sauvegarde, je te suggère de jeter un œil au monde bancaire par exemple. Ces contraintes réseau ne sont pas exceptionnellement ridicules.

Je viens de recevoir des informations de la part du responsable du support Cygwin au sein de Red Hat, ce n'est pas déraisonnable mais pas un cadeau non plus. D'un autre côté des demandes d'ajouts de fonctionnalités peuvent être faits, ils seront poussés upstream le cas échéant.

3 types de support, comme indiqué sur le site ouaibe de Red Hat sur http://www.redhat.com/services/custom/cygwin/ :

- Support développeur. Tarifs annuels par siège.
- Support utilisateur. Tarifs annuels par système.
- Modèle licensing, linking hors GPL. Tarifs annuel ou triannuel par client (ie éditeur logiciel utilisant Cygwin) et produit, pas de limites sur le nombre de copies.

N'hésitez pas à me demander plus d'infos, bien que je n'aie ni commissions/bonus ni responsabilités là-dedans :)

Supporté peut-être, mais c'est un service spécifique... Une souscription RHEL N'est PAS suffisante.

Voir http://www.redhat.com/about/news/prarchive/2010/Q4FY10.html :

Cash and investments at February 28, 2010 totaled $970.2 million after repurchasing approximately $90.1 million, or 3.1 million shares, of common stock in the quarter.

Et http://en.wikipedia.org/wiki/Competition_law :

Section 2. Every person who shall monopolize, or attempt to monopolize, or combine or conspire with any other person or persons, to monopolize any part of the trade or commerce among the several States, or with foreign nations, shall be deemed guilty of a felony, and, on conviction thereof, shall be punished by fine...."

Vider les caisses pour se taper des procès, ça serait quand même un peu con.

Il me semble que l'auteur "principal" ou à défaut original c'est quand même id software... Qui devrait avoir son mot à dire. Ou alors Illfonic va payer des royalties.

Je pense qu'on peut surtout y voir (je suis pas absolument certain du tout) :

(Aspect "spécialisé")
- Que les gens qui écrivent/achètent ces magazines apprécient/valorisent la diversité, l'estiment ;
- Qu'il y a beaucoup de gens s'intéressant assez à l'informatique pour acheter des magazines/en avoir besoin (plutôt que de demander à son ami qui connaît comment changer le fond d'écran) qui s'intéressent à Linux (c'est quand même un public précis) ;

(Aspect "communautaire")
- Qu'il y a relativement beaucoup de gens motivés pour écrire/publier ces magazines sur Linux par rapport aux autres sujets ;
- Que les linuxiens sont plus prêts à "financer" le monde du libre, et donc à payer pour des articles, que le reste des informaticiens ;

(Aspect "peu mercantile")
- Que les contributeurs à ces magazines le font/feraient même avec des gains faibles, ce qui favorise la quantité dans cette presse (des magazines peuvent survivre malgré des recettes faibles).

Spyware ? Machine virtuelle. Problème en moins.

http://tools.ietf.org/html/rfc4180

6. Fields containing line breaks (CRLF), double quotes, and commas
should be enclosed in double-quotes. For example:

"aaa","b CRLF
bb","ccc" CRLF
zzz,yyy,xxx

7. If double-quotes are used to enclose fields, then a double-quote
appearing inside a field must be escaped by preceding it with
another double quote. For example:

"aaa","b""bb","ccc"

Gnome enlève les icônes dans les menus et les boutons.

http://www.osnews.com/story/21935/GNOME_To_Drop_Icons_in_But(...)

Sans aucune volonté de troll, il vaudrait peut-être mieux utiliser autre chose. Xfce, peut-être ? Je ne sais pas ce qu'il en est, mais les applications comme F-spot seraient sûrement mieux intégrées qu'avec KDE (je ne parle pas que du thème).

Bonne chance pour la suite !

Exemple de gestion des conflits : tu veux installer vim, ça désinstalle nvi.

Gestion des alternatives : tu veux installer vim et as déjà nvi, on te demande vers lequel tu veux que /usr/bin/vi pointe.

Et tu pourrais peut-être argumenter au lieu d'affirmer que "c'est un peu n'importe quoi".

Pour les conflits je commence à penser qu'il est possible de faire une bonne distro qui ne les gère pas, en abandonnant au moins partiellement FHS (en:Filesystem_Hierarchy_Standard) et en utilisant des scripts de configuration des alternatives. La meilleure solution pour ce problème est, en cas d'alternatives conflictuelles, de ne fournir que le paquet que Je préfère.


Le problème de dépendances inverses étant coûteux, certaines sous-solutions pourraient-elles être précalculées côté serveur et/ou mises en cache côté client ?

On devrait pouvoir splitter le graphe des paquets en sous-graphes "intéressants" en ramenant toutes les versions d'un paquet à un nœud avec pour poids une fonction logarithmique sur le nombre de versions (O(n) sur le nombre de paquets), en le désorientant (O(n) sur le nombre de dépendances), en réduisant les chaînes isolées (conserver la longueur originale dans le poids des liens, O(n log n) sur le nombre de dépendances déversionnées il me semble), en calculant l'arbre couvrant minimal (en:Minimum_spanning_tree, à peu près linéaire d'après Wikipedia), puis en tronçonnant l'arbre comme un bourrin.

Il y a plusieurs techniques à essayer pour tronçonner, mais j'ai le sentiment qu'on aurait facilement de jolis sous-graphes dans lesquels précalculer.
De toute façon je suis définitivement moins bon que les gens qui bossent là-dessus et n'y pense que vaguement dans le bus, mais j'avais envie de le raconter ;)


Pour revenir à ton outil steckdenis, fais gaffe à ce que tu veux calculer à chaque opération : nombre d'entre elles sont des mises à jour.
Or à chaque mise à jour on "désinstalle" la version actuelle et "installe" la nouvelle. Et "souvent" il "suffit" de vérifier que ça n'impacte personne.
Bref l'opération la plus courante est peu coûteuse dans le cas général, essaye de conserver cette propriété !

Il y a un super algo en O(n) basé sur une fable de La Fontaine ([http://en.wikipedia.org/wiki/Cycle_detection#Brent.27s_algor(...)]) pour résoudre parfaitement le problème des dépendances inverses. J'ai un prototype de preuve en 50 caractères de Brainfuck en tête mais pas la place dans la marge pour le reproduire !

Pas faux ;)

steckdenis, gères-tu les dépendances circulaires (en:Circular_dependency) ?

Il y en a un paquet dans Debian : http://debian.semistable.com/debgraph.out.html

En leur absence, les paquets et leurs dépendances forment un graphe acyclique orienté [http://en.wikipedia.org/wiki/Directed_acyclic_graph].

Amusez-vous bien avec ces quelques liens...