paulez a écrit 387 commentaires

Hum, je cite le manuel de grub legacy sur gnu.org,

This manual is for GNU GRUB (version 0.97, 8 May 2005).

Ça fait quand même plus de sept ans d'écart non ?

Tu m'expliques où je me fous de ta gueule dans la partie que tu cites ?

Ton journal m'interpelle, car depuis longtemps utilisateur de Arch Linux, j'ai pu en saisir trois principes de base :

1) rolling release rapide
2) kiss
3) AUR

Qu'est-ce que cela signifie par rapport à ton journal ?

1) Archlinux adopte au plus tôt les nouvelles versions upstream. Si tu veux rester sur technologies stables et éprouvées, Arch n'est pas faite pour toi. Si tu n'aimes pas le changement régulier, Arch n'est pas faite pour toi.

2) Archlinux patch au minimum l'upstream. La version de Grub sur mon système est actuellement la 0.97-21. Qu'est-ce que cela signifie ? Le mainteneur a du modifier 21 fois le paquet pour le faire fonctionner depuis la dernière release upstream. Trop de travail pour le mainteneur sans support upstream, le paquet n'est donc plus maintenu. Beaucoup de paquets dans cette situation subissent le même sort, Grub est simplement plus connu que les autres.

3) Si un truc ne te plaît pas dans Arch, tu peux le faire toi-même et le partager aux autres dans AUR.
Beaucoup de gens veulent garder grub-0.97, il est donc dans AUR. Parfait non ? Tu peux donc l'installer sans soucis, où est donc le problème ?
Si beaucoup de gens veulent garder les initscripts, parfait, ils s'associeront pour le maintenir dans AUR, et tu pourras continuer à les utiliser. Si tu es tout seul dans cas, il faudra t'y atteler alors ;-)

Voilà, ton journal m'interpelle parce que j'ai plus l'impression qu'il provient d'une incompréhension du fonctionnement d'Arch que d'un problème sur Arch en lui même.

C'est vrai que c'est éminemment plus constructif de publier/compléter un rapport de bogue plutôt que de poster un message "Han ça ne marche pas je change !"
Et même avec un peu de chance en faisant ça le bogue pourra être résolu, génial non ?

Grossièrement :

• convaincre : faire appel à la raison ;
• persuader : faire appel aux sentiments.

Donc non.

Les premières lignes électriques mises en place utilisaient du courant continu (il en existe encore de nombreuses), mais aujourd'hui les nouvelles lignes (et depuis pas mal de temps déjà) utilisent de l'alternatif. Source À cause de ces disparités la plupart des motrices supportent les deux types d'alimentation. Un exemple concret : le RER A est alimenté en continu sur sa partie RATP, et en alternatif sur sa partie SNCF (branches de Cergy et Poissy) ce qui empêche le matériel ne supportant pas ce type de courant de rouler sur ces branches. Source

L'intérêt du vélo libre service c'est de pouvoir facilement le combiner à d'autres moyens de transport. Dans le cas de la région parisienne un banlieusard peut faire la première partie du trajet en RER depuis sa banlieue lointaine, puis finir avec un vélo libre-service. Parce que se balader avec son vélo dans le RER en heure de pointe, c'est interdit.
Ensuite pas besoin de garder un vélo chez soi quand on manque de place, pas besoin de l'entretenir, etc. Je trouve d'ailleurs dommage que ce concept ne soit pas plus généralisé dans la proche banlieue, où il est difficile de circuler pour les cyclistes, ce qui impliquerait de faire des efforts dans l'aménagement urbain.

Ce comparatif est intéressant mais je trouve que les chiffres obtenus sont très loin de la réalité.

Je fais tourner une solution classique Nagios + Ndo + Centreon avec ~25k checks toutes les cinq minutes sur une architecture répartie (avec un collecteur vérifiant 16k services / 5 min) avec moins de 1seconde de latence sur tous les pollers (contre plus de 300 dans l'étude présentée par l'article) et des temps de démarrage inférieurs à 20s (contre plus de 300s dans l'étude).

Les chiffres que j'obtiens sont donc deux ordres de grandeur inférieur à ceux obtenus dans l'étude. Cet écart est trop important pour être anodin.

Je ne doute pas que Centreon-engine et centreon-broker apportent par rapport à NDO et Nagios, par contre je déplore fortement le cloisonnement entre ces différentes solutions qui pourraient évoluer de concert.

En effet entre temps Ndoutils 1.5 est sorti, corrigeant un de ses principaux problèmes (transmission synchrone) et jouissant de nombreuses optimisations, pourtant Centreon n'est pas compatible.

Entre temps Nagios 3.4 est sorti avec une légère optimisation mais encore boguée, Nagios 4 qui devrait apporter d'importants gains en performance est dans les tuyaux.

Si tous les efforts se concentraient sur Nagios, peut-être que celui-ci avancerait plus vite, plutôt que d'avoir plusieurs produits quasiment identiques avec chacun leurs problèmes et leurs avantages. Pourquoi ne pas résoudre les problèmes d'une seule solution et de ressembler tous ses avantages plutôt que de faire une course de clones ?

PS : ndoutils 1.5.2 a été publié vendredi dernier, qu'on ne me réponde pas que ce projet est mort ;-)

Nagios fait beaucoup d'io disque (lecture des fichiers de résultat) mais à priori ce déficit de performance est corrigé avec des versions de VMWare récentes.

D'après l'article de Wikipedia une liaison à courant continu est plus efficace qu'une ligne en courant alternatif uniquement sur de très longues distances (500 à 1000 Km en liaisons aériennes) à cause du courant capacitif sur celles-ci. Dans le cas de la France je ne sais pas s'il y a beaucoup de liaisons où ça serait avantageux.

La liaison IFA_2000 a été réalisée en continu pour des critères spécifiques à la liaison entre deux pays différents, toujours selon Wikipedia, c'est donc un cas particulier aussi.

Pour synchroniser mes calendriers caldav et agendas carddav (formats utilisés par Owncloud et Davical) j'utilise les applis présentées sur le site dmfs.org. Par contre elles sont payantes (le prix est raisonnable) et pas encore open-source, l'auteur a promis de libérer le code lorsqu'une version finale sera publiée.

Peut-être utilises-tu systemd, qui par défaut ne supporte pas d'utiliser l'heure du bios comme heure locale ?

Oui et ça me permet de booter avec une rapidité démentielle.

Quelques exemples : Canonical, Red Hat, Mysql, Talend.

Et à quand Linuxfr en ipv6 ? :D

DFLP serait-il un facteur de centralisation du web ?

Le parallèle est facile : les utilisateurs de facebook.com ne postent que sur facebook.com car sinon ils n'ont aucune chance d'être lus, les utilisateurs de linuxfr.org doivent-ils poster sur linuxfr.org pour avoir une chance d'être lu ? À quand un Facebook décentralisé ? À quand un DFLP décentralisé ?

Avec Centreon tu peux déporter la partie Nagios sur un serveur distant.

Cela correspondrait à ton besoin. Tu ajoutes ton WRT en tant que nagios séparé. Centreon s'occupera de récupérer les infos nécessaires aux graphes et de les générer. Toute l'historisation conservée en base de données et qui prend de la place sera stockée sur une base de données que tu peux placer n'importe où.

La solution sera autonome car en cas d'indisponibilité de Centreon, le serveur Nagios continue à fonctionner et tu peux toujours accéder à son interface standard. Elle prendra peu de place si le nombre de services est faible.
Par contre Nagios faisant beaucoup d'écritures disque, et supposant que ton WRT utilise un stockage de type Flash, il faudrait utiliser un tmpfs pour stocker les fichiers temporaires de Nagios afin d'éviter de détruire le stockage qui doit avoir un nombre d'écriture limité. Cela permettra aussi d'augmenter les performances de Nagios.

La doc Gentoo : http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/distutils/index.html (l'exemple donne un ebuild de deux lignes, pas mal)

Le prototype de package python pour Archlinux : https://projects.archlinux.org/abs.git/tree/prototypes/PKGBUILD-python.proto

Pour faire un rpm c'est expliqué dans la doc : http://docs.python.org/distutils/builtdist.html

Les autres je ne connais pas.

Vous qui faites du sed/cut/awk/grep sur vos fichiers de log et lisez les messages du kernel consciencieusement, vous faites comment si vous avez un parc de plusieurs centaines de machines, avec des dizaines d'applicatifs différents ?
Normaliser le format des logs permettrait de remonter tout cela sur un serveur central, qui permettrait d'obtenir tous les évènements survenus sur le parc sur des critères bien précis.
Le rêve quoi !
Pas mal de logiciels essaient déjà de faire ça, mais c'est toujours très difficile à généraliser à cause de la multitude de formats. Si on crée une norme à ce niveau, cela permettrait de simplifier grandement ce type d'analyse.

La plupart des distributions ont des templates pour packager des logiciels python utilisant distutils, utiliser cet outil (qui peut également générer des rpms) me parait être la meilleure manière pour rendre ton logiciel le plus facilement empaquetable.

Ben surtout, ce qui fait la différence entre un store un package manager, […] chose que les linuxiens ne savent pas faire et apparemment débectent.

Et alors qu'est Ubuntu Software Center ?

J'utilise CalDAV-Sync et CardDAV-Sync.
Le code n'est pas open-source mais l'auteur a prévu de le rendre open-source pour la version 1.0 selon le wiki de Davical.

Pour ce faire, j'utilise les protocoles Caldav et Carddav avec un serveur Davical (plus d'infos sur la mise en place sur mon blog).

Ces protocoles sont supportés par :
- mon client lourd Evolution sous Linux ;
- mon smartphone perso sous Android sous condition d'achat d'un connecteur correspondant ;
- mon smarphone pro sous iOs qui malgré sa mauvaise image d'ouverture s'intègre parfaitement avec cette solution alternative nativement ;
- un client web très agréable qui s'appelle Calendav.

Ils permettent la synchronisation d'un calendrier (Caldav) et des contacts (Carddav). J'ai choisi d'utiliser ceux-ci car ils me paraissaient être les plus répandus. C'est vrai que certains logiciels assez utilisée ne les supportent pas, comme Thunderbird.

Bien sûr en plus de cela j'utilise Imap pour synchroniser mes mails et XMPP pour la messagerie instantanée, le tout avec authentification LDAP pour que mes utilisateurs n'aient à gérer qu'un seul compte.

C'est donc possible de se passer de Google tout en gardant une facilité d'utilisation, la difficulté de la configuration passée.

C'est possible sur mon Xperia ray, ce qui est fort pratique.

Il n'y a pas de double sens, simplement tout le monde oublie le ne de la négation maintenant.