Sytoka Modon a écrit 4544 commentaires

> Et ça complexifie les communications entre onglet, avec le reste du navigateur

Il y a aussi moyen de simplifier le code. Le mode multi-profile ne sers a rien. Cela date de l'époque Windows98 mais avec des PC qui gère le multi-utilisateurs, cette gestion interne dans firefox augmente le code et n'apporte rien sauf de temps en temps des emmerdes... On pourrait remplacer tout cela par un lancement de firefox avec une option en ligne de commande qui donnerait le chemin du profile, c'est tout.

Je suis connecté sur ma machine, disons A. Je me connecte via ssh -CX sur une machine B et je lance firefox en ligne de commande avec une page web, c'est le firefox de la machine A qui charge la page et non un nouveau firefox qui est lancé sur la machine B. Ce comportement est unique au produit de la fondation mozilla et ne se retrouve nul par ailleurs et heureusement, car c'est hyper chiant. Tout ce code pourrait être virer lui aussi car à mon sens il est totalement illogique et compliqué.

Bref, tout cela pour dire qu'il y a des points qui pourraient être simplifier sans que l'utilisateur en souffre, au contraire.

> Mandriva, la seule distribution européenne

TROP GROS !

Debian est très implanté en Europe, a mon avis plus que Mandriva en terme de développeur !

Mandriva est Franco Brésilien...

Bref, je ne vois pas ce que fait Mandriva ici.

Non, je ne suis pas d'accord. Ton truc n'est pas de l'humour car cela ne fait que banaliser le nazisme, en plus, c'est même pas drôle. Je continuerai a tout faire pour essayer de virer cet humour nul de ce site. Il y a plein d'autres moyens de faire de l'humour, et rigolo en plus.

Va faire un p'tit tour au mémorial de la paix à Caen, ou va faire un petit tour dans les camps de concentration et tu arrêteras de parler de nazis pour tout et n'importe quoi.

Il y a de l'humour qui chez moi ne passe pas car c'est un humour qui tend à banaliser le nazisme.

PS : seconde guerre mondiale : 50 millions de mort
PPS : 6 juin 44 : 10000 jeunes morts sur les plages du débarquement

Pendant très longtemps, pas une distrib linux ne fonctionnait sans Perl ;-)

Et puis, si le libre adopte cela, il y aura plein de bon codeurs dans le domaine et Apple pourra en embaucher.

Bref, il y a plein de bonne raison pour ne pas garder cela pour soit, surtout lorsqu'on est pas en position de monopole.

> Je crois que vous comprenez vraiment rien à l'application :)

Je dois dire que je ne trouve pas la dépêche très claire. Pour un projet qui est opérationnel depuis trois, si on s'en tiens à la dépêche elle même, on ne sais pas exactement de quoi il s'agit. Personnellement, je suis passé a une autre dépêche très rapidement.

Une seconde partie de dépêche avec un peu de copier coller du site acogit, plus de la sauce n'aurait pas non plus fait de mal.

Bref, il me semble que tout cela est très bien mais aurait nécessité une meilleure publicité.

Le marché des stations marchait encore sur la fin parce que pleins de logiciels n'étaient pas porté sur Linux et donc les clients étaient coincés par les solutions propriétaires.

Je me souviens qu'il y a 10 ans, les PC linux x86 allaient déjà plus vite que bien des stations (et pour bien moins cher).

Mais Catia ne tournait pas sous Linux, mais...

Bref, les stations ont disparus parce que tous ces gens là travaillent maintenant sous Windows ! Linux n'a récupéré qu'une petite partie du gâteau des stations à mon sens.

Et puis, c'est pas parce qu'il y a beaucoup de mec très bon ensemble qu'ils ne peuvent pas faire de conneries !

Génial. Ca marche nickel.

Infiniment merci

SGI a aussi une solution de type blade avec n cartes graphiques dedans... Je ne connais pas la solution d'IBM mais tout ce que j'ai vu avait la contrainte, une carte = un utilisateur. Pour cacher cela, ils mettent n cartes 3D dans le système central comme n jetons d'un programme propriétaire et cela devient une ressource limité à partager.

Le problème vient de la conception même des cartes 3D, ATI ou nvidia. A ma connaissance, il n'y pas vraiment d'autres cartes 3D sur le marché qui aurait une conception autre. Mais je suis intéressé de savoir si cela existe.

C'est facile de basculer sur SMB1 ? Sur les avis du CERT, ils ne parlent que de filtrage de port ou d'arrêter le partage de fichier. J'ai pas vu ou ils disent de basculer sur SMB1.

Je dis cela pour les autres, moi, j'ai que des serveurs samba ;-)

Un des autres problèmes des cartes graphiques et que le changement de contexte est lent car il faut vider leur mémoire pour mettre celui d'un autre processus. D'ou une carte = un écran.

La technologie VirtualGL consiste en gros a tunneliser la sortie écran OpenGL en image jpeg pour l'envoyer sur le poste client via le réseau. Ainsi, on a l'affichage distant.

J'aurais bien voulu grâce à cette technologie pouvoir mettre plusieurs clients derrière mais cela ne marche pas. Le changement de contexte 3D donne des latences de plusieurs secondes... Non tolérable par les utilisateurs. Du coup, il y en a qui ont inventé un système de réservation.

Bref, tout cela pour dire que c'est quand même bien spécialisé et cela ne peut pas tout faire, notamment du multi-utilisateur.

L'avenir : l'itanium et le x86 vont partager normalement en 2010 le même socket. Un des buts est aussi de pouvoir mettre une puce de type reprogrammable afin de pouvoir cabler un calcul. Ainsi, toutes les puces ont un accès direct à la mémoire comme une machine NUMA. C'est un peu la généralisation de la la gamme Altix Itanium de SGI (450 et 4700) qui permet déjà l'intégration de telle carte FPGA. Je ne vois pas alors ce qui empêcherait nvidia de faire une puce graphique qui se greffe sur ce type de socket, les problèmes de latence mémoire seraient alors nettement réduits.

La carte d'acquisition est une double carte ASA qui utilise deux slots... De plus, il s'agit d'un laser de puissance qui doit avoir 15 ans d'age. Je ne mettrais jamais les doigts dans ce truc la. Tant que cela marche, ca marche !

Il reste quelques cas ou ces vieux PC tournent encore : sur les machines d'acquisition... Mais, la, on ne fait aucune mise a jour, cela tourne tant que cela pourra !

Pour information, j'ai comme cela un PC qui tourne avec des cartes ASA sous DOS. Comme il pilote un laser de puissance, le changer nous couterait plus de 130kE !

Je ne trouve pas cela hors sujet même si les situations ne sont pas le mêmes ni les objectifs des deux sites.Je ne vois pas le mal de parler des difficultés des PCInpact dans un commentaire, cela me semble même une meilleure place que d'en faire un journal ou un nouvelle à pars entière.

Il faut noter aussi que BFS ne gère pas les cgroup qui ne sont aps encore vraiment utilisé par les distributions mais qui sont bien intéressant pour cloisonner la puissance du CPU par grande classe de type de processus.

Bref, je ne pense pas que BFS va aller très loin... sauf peut être sur de l'embarqué.

En plus, Ingo est suffisamment intelligent pour reprendre les bonnes idées de BFS pour essayer des les remettre ailleurs avec son équipe si cela s'avère vraiment intéressant.

Heureusement qu'Ingo a plusieurs machines et pas que des petites machines vu la position qu'il occupe !

Je me réferrais a ce bout de mail sur la liste

"
To solve the fundamental problem, the plan is to replace /sbin/init
with an implementation that is able to handle kernel events. It will
allow us to modify the boot system for the early boot to become event
based, while keeping the existing boot stuff working. We could rewrite
sysvinit to become event based, or have a look at the existing boot
systems that handle kernel events. After checking the options and the
systems used in other distributions, upstart seems like the most
promising candidate. It is used by Ubuntu and Fedora at the moment,
and solves the problem in a backwards compatible way. The plan is to
change upstart to actually use /etc/inittab, to ease the switch
between sysvinit and upstart. We will also change the init.d script
handling to treat upstart jobs as init.d scripts, to provide an
alternative for architectures lacking upstart support. These changes
should make it transparent for the users which package provides
/sbin/init, and thus make it easier to migrate from sysvinit to
upstart.
"

J'ai lu cela comme une annonce du scénario le plus probable... A mon sens, c'est pas encore tranché définitivement pour squeeze car il faut intégrer dans upstart la gestion des scripts init pour être conforme a la LSB.

Dans le même ordre d'idée, debian va aussi basculer vers GRUB2 pour Squeeze, si cela marche bien entendu.

Erlang est un langage qui a été développé pour cela. On peut modifier son code à chaud pour mettre des mises à jour de sécurité.

C'est intéressant comme concept et je pense que cela va se propager petit à petit comme philosophie. Déjà avec le noyau et ksplice, on peut recharger un module à chaud...

Pour les serveurs, on pourrait laisser le serveur traiter les requêtes en cours et utiliser la nouvelle version pour les requêtes suivantes... C'est un peu ce que fait ssh lorsqu'on le relance. J'utilise comme QPSMTP comme serveur de mail qui fork pas mal d'instance pour répondre à la charge et régulièrement, il fork son processus principal... Une mise à jour se fera donc automatique au fork suivant (c'est pas un fork au sens UNIX du terme...). Parfois, on n'est pas à 10mn pour une mise à jour de sécurité si on peut éviter un interruption de service.

Je sais bien, j'ai déjà lu la dépêche... Mais je pense que su tu fais un sondage sur linuxfr avec comme question :

Comprenez-vous la phrase : << générateur d'application centré autour d'un générateur de formulaire avec une persistance de fichiers au format N3 >> et êtes vous capable d'expliquer en pratique par un exemple concret ce qu'elle veut dire ?

Je suis persuadé que plus de 90% des gens de ce site répondrons NON.

J'ai vaguement travaillé il y a 4 ans avec des personnes qui bossaient sur les ontologies donc je vois a peu près ce que signifie une ontologie. Mais je ne suis pas sur que beaucoup de personne savent ce qu'il y a derrière.

Bref, ta réponse ne me satisfait pas du tout car je demandais juste si on pouvait avoir une explication avec du français de base, sans acronyme et des exemples concrets. Pour moi, ta phrase : << générateur d'application centré autour d'un générateur de formulaire avec une persistance de fichiers au format N3 >>, je la lis sans problème mais elle est vide de sens car je ne vois pas ce que tous ces mots mis bout à bout ont comme relation dans la vraie vie.

Quand au lien que tu donnes, je suis désolé mais cela parle un charabia qui est pour moi incompréhensible... Il faut que tu comprennes que les personnes de ce site ne sont pas du tout proche du domaine que tu évoques dans tes nouvelles. C'est très bien d'en parler mais cela passe en premier par une étape de sensibilisation à la matière. Il faut commencer par partager le vocabulaire et les habitudes du domaine.

Ce serait possible d'avoir la prochaine fois un paragraphe expliquant en français "de base" à quoi cela sers en pratique. Bref, des exemples pratique d'utilisation. Je crois que nous sommes nombreux a n'avoir pas compris grand chose dans l'objectif du logiciel et dans son utilisation.

Il y a aussi un avantage, chaque script est un processus indépendant... En cas de plantage, bogue, on a une très grande indépendance des services les uns par rapport aux autres.

Moi je suis pour rester simple, orthogonal, indépendant... Cela permet la robustesse mais aussi l'évolution.

Moi j'aime bien les scripts shell. On a ainsi un système souple qui se modifie facilement. Il est aussi facile de deboguer un script....

Pour moi, une grande force d'UNIX est justement d'avoir encore plein de bout de sa config qui se font en script (BASH pour la plupart). Je ne suis pas sur que mettre de la syntaxe avec du méta langage permettent à terme une telle souplesse et une telle durée de vie.

On peu avoir un init en script qui soit parallèle...