Sytoka Modon a écrit 4565 commentaires

Les FAI français sont français donc doivent respecter le droit français. Je préfère cela a des log non maîtrisé au USA ou ailleurs...

Par ailleurs, si mes souvenirs sont bons, les log doivent être archivé après 3 mois et ne doivent plus être utilisé, sinon c'est une faute. Donc le FAI n'a plus accès au log après 3 mois en pratique. A vérifier...

A noter que thunderbird comme tous les produits de chez mozilla gère plutôt bien les certificats. Je m'en sers personnellement avec l'IGC du CNRS qui est très pratique.

Je ne sais pas si les autres lecteurs de courriels gèrent aussi bien les certifications...

Si mes souvenirs sont bons, seuls les derniers courriels sont accessible en offline chz gmail, j'appelle pas cela un mode déconnecté comme on le fait si bien avec IMAP ;-)

Ensuite, je ne mets pas mes courriels professionnels (et perso) chez Google mais tout le monde n'est pas ainsi !

Roundcube se sers de mysql comme cache afin d'accélérer l'affichage. En effet, normalement, on n'installe pas roundcube directement sur le serveur de courriel...

J'aime beaucoup le troisième exemple, c'est vraiment très jolie je trouve.

Une petite chose sympathique pour commencer

http://library.gnome.org/misc/release-notes/3.2/index.html.fr#epiphany

Cela permet de transformer une page web en application via epiphany qui se fait oublier. A noter que la webapp est indépendante des autres instances d'epiphany en cas de plantage (on aimerait pouvoir lancer n instance indépendante de firefox aussi facilement - personnellement j'en ai marre de toutes ses applications en mode serveur par défaut - geany, gedit...)

La révolution en cour

GTK 3.2 a un backend html5 via broadway. Qu'est ce que cela signifie ? On lance son application dans ce mode et via un navigateur, on se connecte sur une URL et hop, on utilise cette application. On peux ainsi utiliser gimp via firefox par exemple !

Cela signifie aussi que bientôt, nous pourrons développer des applications web comme des applications de bureau. De même, toute application de bureau (GTK) pourra être transformé en application web. Cela va vers une grande simplification et une grande unification.

C'est encore noté expérimental et pas toujours actif par défaut. On peux voir des exemples sur le blog suivant :

http://www.webupd8.org/2011/09/gtk-32-released-with-html5-allows.html

A mon sens, tout le reste est anecdotique, le backend broadway est la fonctionnalité fondamentale de ces derniers temps coté GTK/GNOME.

Marrant, je ne supporte ni les onglets, ni le mode conversation ;-) De plus, les boutons Repondre et ainsi de suite dans le courriel sont une aberration car ces boutons changent selon la disposition du courriel alors que dans la barre, ils étaient a une position fixe donc facile à retenir pour mon faible cerveau

Moi, j'aimais l'extension Redirect qui ne marche plus.

Bref, j'attends un support local du format MAILDIR plutot que mbox et un compactage transparent des boites. Les évolutions du moteur Gecko, pour un lecteur de courriel, cela ne justifie pas l'incrément de 1 dans les notes de versions ;-)

Putain, mais que fais tu encore là !

DLFP ne tombera pas dans le trous noir !

Idem pour moi ! Objectif, avoir une machine accessible via SSH, ou tout au moins sur tty0 le plus vite possible et quasiment à tous les coups.

En pratique, c'est cela que je fais. J'ai simplifié pour rester simple ;-)

Je suis dans la même situation. Par exemple, je dois envoyer des machines virtuelles qui sont sur une baie SAN. Je ne suis pas assurer à 100% que la baie soit accessible à la fin du boot du serveur, cela dépend du temps de boot de chaque équipement.

J'envoie donc les VM 5min après le boot du serveur...

Pour le déploiement d'image de poste, surtout de salle de cours, le multicast est effectivement idéal. Toute la salle se fait d'un coup.

Ici, on parle de déployer des applications sur un parc de machine en fonctionnement, qui n'a pas d'unité géographique. On n'est pas du tout dans le même contexte.

Avec des si, tu met Paris dans une bouteille ;-)

Justement, on ne veux pas forcément que cela soit simultané, ce qui oblige a un processus synchrone au final complexe à mettre en place d'un point de vue administration système. Par exemple, que faire si un poste plante ?

Pour ce genre de chose, il vaut mieux à mon sens un système asynchrone clairement tolérant aux pannes et aux plantages des clients. Le P2P diminue très clairement la bande passante sur le réseau, limite la charge du serveur... Cette solution me semble bien plus robuste pour cette problématique.

C'est clair, il faudrait séparer xget du reste et le rendre autonome.

Coté doc, elle est vide car la commande semble super simple ! J'ai regardé du coté de murder, cela ne semble pas de la même échelle pour faire tourner les deux...

A mon sens, xget n'est pas forcément fait pour 200000 noeud mais sur un réseau local avec moins de 1000 noeuds, il me semble qu'il est le plus simple.

Comme perceus et rocks l'utilise, j'ai relativement confiance sur le fait qu'xget tourne encore dans quelques années. A vrai dire, une fois l'infrastructure en place, remplacer un outil de copie en P2P par un autre ne devrait pas être le point le plus bloquant.

La MoFo n'a pas les moyens de faire toutes les régressions sur toutes les versions d'OS sur le marché. Vouloir maintenir une LTS, c'est bien. Vouloir qu'ils soient les seuls à décider du bien et du mal, c'est aller trop loin.

Si on regarde la gestion du noyau Linux, c'est beaucoup plus souple comme manière de faire. Il y a des versions LTS et chacun peut encore les améliorer pour son environnement dans son coin. On voit d'ailleurs que des options changent de valeur par défaut dans le noyau officiel pour passer de A vers B puis reviennent vers A alors que les distributions sont en général rester sur la valeur A.

Bref, en terme de sécurité, il y a rarement une seule vérité !

debian a fait une erreur sur les certificats ssl et personne ne l'a vu. Ils l'ont corrigé très rapidement lorsqu'elle a été détecté en ajoutant une fonctionnalité à ssh qui n'était pas prévu (blacklist de certificat). A mes souvenirs, tout a été fait en 4 jours avant de faire l'annonce.

Combien de personne se sont fait attaqués ? Moi, aucun de mes serveurs n'a été attaqué.

Cette affaire a montrer aussi des lacunes du coté de SSH (pas de blacklist, des certif (clefs) à vie...) qui sont corrigés petit à petit (très très lentement)...

Je préfère une erreur annoncée, corrigée et assumée que ce que bien des entreprises font en cachant leur bidouillage avec une phraséologie primaire.

On parle ici de déployer sur son parc. Il y a toujours une machine sur le réseau P2P, le serveur.

Le P2P sur un réseau local, au sien d'un cluster, c'est une très bonne idée.

Trop de contrainte... En plus, il faut que tous les noeuds télécharge en même temps.

Je ne crois pas au multicast sauf dans quelques cas bien précis. Un système peer to peer a bien des avantages sur le multicast.

Un système en peer to peer pour faire cela et dédié au cluster, cela existe déjà. Cela s'appelle xget !

http://xcpu.sourceforge.net/xget/

C'est notamment utilisé par perceus et je crois rocks.

Debian a du changer de nom... En pratique, cela a perturber les utilisateurs 1 journée !

Donc d'un certain coté, tant pis pour eux. A vouloir être trop restrictif, les utilisateurs GNU/Linux seront tous sous iceweasel ou chromium !

Je rappelle que les brevets ne sont pas valable en Europe ! On peux aussi très bien avoir des dépôts pour nos distributions qui ne serait hébergé que chez nous. Il y a déjà eu le cas par le passé.

Enfin, cela marchait mal sur pas de programme d'installation. Idem pour XP. Avec Seven 64, cette fonctionnalité marche enfin.

Il ne faut jamais dire jamais !

Les navigateurs supportait le GIF a une époque ou celui-ci était sous brevet outre atlantique. D'ailleurs je me souviens que pour les droits, on les demandait au site (serveur) et non au client (navigateur). Pourquoi cela ne serait pas pareil sur le H264.

Sinon, Firefox déléguera le H264 à l'OS au dessous ou a un greffon. C'est pas plus mal non plus. Je ne suis pas fanatique des logiciels qui refont tout en interne ;-)

Je suis d'accord que notre système n'est pas parfait mais en terme de temps homme pour le maintenir, c'est pas mal, on arrive a le faire.