Ca tient la charge ? J'avais tenté la même chose avec LVM il y a quelques années mais c'était ingérable du fait de LVM...
Un point important serait lors des backup de ne sauver que les block qui ont été modifié depuis le dernier backup... Comment avoir cette liste des block modifié sur le serveur de base, via un snapshot LVM :
lvmsync semble intéressant ! J'ai pas encore testé. Il y a juste un truc qui me chiffonne, il faut faire un snapshot LVM sur la source juste pour avoir la liste des block modifié... LVM fait bien plus que cela donc ralentis... Il serait intéressant d'avoir un snapshot LVM qui liste juste les block modifié sans dupliqué ces block. On n'aurait alors aucune perte et performance quasiment. Je ne sais pas si cela existe...
Sinon, plutôt que LVM, peut être qu'il est possible d'avoir la liste des fichiers modifiés via lsyncd et de n'envoyer à rysnc ou rdiff-backup que cette liste histoire de gagner encore du temps ! Je ne sais pas comment se comporte lsyncd sur une grosse arborescence de millions de fichiers sur 30To par exemple...
Si je comprends bien, tu veux faire un rdiff-backup au dessus d'un rdiff-backup ! sachant que l'algo sous jacent est le même que rsync (librsync), pourquoi ne pas faire bêtement un rsync entre dépôt 1 et dépôt 2 à la fin ? Sur le dépôt 2, tu auras tout l'historique qu'il y a sur le dépôt 1...
Par simplicité, on remonte effectivement au . initial. Sur mes serveur DNS, le domaine en .42 fonctionne ! Il est très facile de nos jours de faire un paquet DNSROOT qui aurait les serveurs racines des différents pays et serait régulièrement remis à jour, un peu comme TZDATA...
Bref, si jamais les américains coupe une nom de domaine d'un pays, ce sera la fin du . sommital, et la parade pour les FAI sera très rapide à mettre en place. Je pense que le scénario est guère probable !
Et qu'est-ce que vous voulez ? Un espace sans règle ni loi ?
On vit sous le régime des états nations. Tout n'est pas idéal mais je réfère cela à celui des entreprises nations qui est une voie possible ;-)
Si on est en France, on applique le droit français et s'il est dépassé, il faut essayer de le mettre à jour. C'est difficile et long mais tout est possible... Le .fr applique le droit Français, je ne vois pas ou est le problème.
Je me souviens des débuts du web, le droit français s'appliquait déjà. Je me souviens d'une descente de la DST chez nous car un de nos étudiants nous avait piraté ! Ce couillon, s'il avait été Canadien, il n'aurait jamais été embêté car les procédures inter-état étaient (sont toujours ?) bien trop lourde.
Il ne faut pas mélanger liberté d'expression et zone de non droit... Le web peut être soumis au droit sans qu'on tombe forcément dans big brother...
Tous mes sites sont en .fr, ce domaine ne dépend pas des américains mais dépend de la loi française... Il y a aussi le .eu pour l'europe !
Il suffit de ne pas prendre les noms de domaine américain. Il y a en Europe déjà beaucoup de nom de domaine, rien n'empêche de les utiliser.
Il n'est écrit nulle part que le .com est plus intelligent que les autres. Soyez vous plus intelligent et ne donnez pas votre argent aux DNS américains ;-)
PS : mes sites web en .fr sont très bien indexé dans Google, le .com n'est pas forcément utile !
debian testing n'est pas une distrib stable. Il est normal qu'il puisse y avoir des bogues... Les corrections arrivant moins vite que dans sid, elle est même parfois plus dangereuse.
Bref, testing est la pour préparer la futur stable, c'est pas une rolling release...
Si un tel texte passe sans le support de la maison blanche, cela montre l'état de la cohabitation en ce moment et le peu de poids du président actuel !
Enfin, vu de France, c'est peu imaginable d'avoir une situation pareille...
Cependant, le passé est le passé, si on cherche à mettre à jour le passé, on finit par contrôler le présent donc le futur. Bref, on rentre dans 1984 à fond.
Ou est la limite ? Personnellement, je n'en sais rien. En informatique, ce qui a plus de quelques années, c'est plus pour les historiens qu'autre chose. Faut'il vraiment faire les mises à jour ?
A vrai dire, je n'ai aucune opinion tranché sur le sujet ;-)
On ne va pas refaire le débat BSD/GPL... Les deux visions sont intéressantes et chacun a des bons arguments.
Ce qui est plus que limite par contre, c'était (et c'est toujours) la stratégie de SUN avec ZFS. Du libre exprès incompatible avec la GPL pour être sur que ce ne soit pas intégré dans le noyau linux. C'est un peu petit joueur de leur pars, surtout depuis la rachat par Oracle - sachant que Btrfs est développé pour Linux par Oracle !
github est un truc pratique mais temporaire... Tu ne vas pas baser toutes les bibliothèques libres de ton langage sur une plateforme que tu ne maîtrises pas ! On a vu à l'automne les soucis avec berlioz (si mes souvenir sont bon...).
Je n'ai pas du avoir de chance car parmi la dizaine de paquet testé, je n'en ai pas trouvé un seul qui ne pointe pas vers un lien externe au CEAN. As tu un exemple ?
Il faut dire que TeX est un monstre du logiciel libre, bien avant la FSF (1978)... d'ailleurs cela se voit dans sa licence d'une clarté peu claire ;-)
Cependant, le CPAN a rapidement dépassé son mentor pour des raisons assez logique (début du web, langage de script...). Les autres langages "libre" ont suivis que très très lentement le mouvement.
Le couple CTAN/CPAN restera donc dans l'histoire comme les premiers, loin devant les autres. De plus, bien que le CTAN soit plus vieux, les deux sont assez indissociables. Perl/CPAN est alors à ma connaissance le premier langage communautaire.
Ceci dis, l'étape suivante me semble l'intégration d'un équivalent de github au coeur même des C*AN...
C'est une remarque que j'avais déjà faites pour OCaml, le truc très important dans le CPAN, c'est que les tar.gz sont dans le CPAN ! C'est pas juste un annuaire. La centralisation des sources assure aux utilisateurs du CPAN d'avoir toutes les versions d'un paquetage et les sources quoiqu'il advienne au projet amont. Ceci dis, on ne développe pas sous CPAN mais ailleurs et on upload sur le CPAN ses distributions, pas exemple avec dzil.
PS : Les machines debian tournent par défaut sans SELINUX à ma connaissance et sans problème particulier...
PS2 : je suppose qu'il y a 2 linux... J'installe sur le linux A grub sur la partition racine /dev/sda et sur le linux B, je met grub sur une partition bidon, par exemple /dev/sda3. Comme cela, le linux est content ;-) Jamais testé.
Idée qui me passe par la tête car cela ressemble a ce que je fais avec IPMI..
Ce qu'il y a de bien avec ifupdown, c'est que c'est une syntaxe claire, propre, concise mais facilement étendable via du script shell ! Un peu comme le Makefile. C'est pas un truc qui t'enferme mais ouvre des horizons...
Bref, je prends une voie détourné avec la commande up qui peux être multiple et est lancé après que eth0 soit monté.
auto eth0
iface eth0 inet static
address ....
netmask 255.255.255.0
broadcast ....
gateway ....
up for i in $(seq 1 241); do ip addr add 3.3.7.$i broadcast 3.3.7.255 dev eth0:$i; ip link set dev eth0:$i up; done
A tester car j'ai mis les ; et un peu tout de tête...
J'ai jamais eu à faire cela. Sur mes dom0 ZEN, j'ai une quinzaine de bridge monté sur des interfaces avec des VLAN. Je les déclare à la queue le leu. Les numéros de VLAN ne suivent en plus aucune logique ;-)
Enfin, c'est un problème intéressant, je vais voir s'il je trouve une idée. En pratique, cela sers à quoi ? Machine virtuelle ?
Le problème, c'est que firefox devient un environnement de bureau à lui tout seul ! On ne relance pas GNOME pour chaque application lancée.
Une voie me semble celle des containers. Que firefox se découpe en petits morceaux tournant dans un container global. Cela fait très HURD comme image ;-) Il y a encore du travail coté Linux à faire du coté des containers...
Ensuite, il y a aussi la voie d'Apache qui n'est pas incompatible. Un mélange de thread et de fork, avec de la précharge de thread et de fork ! Rien n'interdit d'ouvrir un thread dans un nouvel onglet/fenêtre ;-)
Bref, le modèle de firefox qui veut tout faire dans un seul processus n'est pas tenable. Une solution est de déléguer à d'autres applications une partie de l'affichage (comme la vidéo à Totem ce qu'il fait déjà). Une autre solution est de reprogrammer en interne dans firefox un OS, gestion des threads (processus), gestion de la RAM, des priorités... Au moins, ils auront 100% de contrôle sur leur code !
Il me semble clair qu'il se dirige vers cette dernière solution même si c'est pas celle que je préfère... Mais l'utilisateur sera content ;-(
Sur une ferme, tu es normalement assuré d'avoir 100% de tes CPU rien que pour toi tout seul, même en interactif ;-)
Sur ce point, je ne suis pas forcément d'accord avec les informaticiens qui m'entoure mais je ne fais pas de différence dans la gestion entre un poste utilisateur et un poste serveur. Pas de différence non plus entre une tour et un portable. Pour unifier le tout, je pars de l'hypothèse que l'ensemble du parc sont des portables, donc les portables sont gérés comme les autres, pas de règles spécifiques et tout le monde tourne sous la même distribution.
Ensuite, tout doit être simple à utiliser mais qu'est-ce que la simplicité ? Le dernier GNOME est-il plus simple que XFCE ?
La simplicité, c'est aussi de passer facilement pour les utilisateurs du serveur à son poste et que tout marche pareil dans les deux sens ;-) C'est d'ailleurs une des raisons pour installer FreeNX sur une frontale de calcul. Mais GNOME bouffe tellement de ressource que ce n'est pas possible de laisser les utilisateurs se connecter avec cela ! Mais attention, ici pas question d'éteindre la frontale à la fermeture de session alors que pour le portable, oui.
Je suis toujours ahurit du millions de cycle CPU que doit faire le processeur à chaque fois qu'on réalise le moindre clique. C'est vertigineux que ça marche encore !
Les variables globales consomment moins de RAM que les variables locales. Mais au delà d'une certaine taille, un vieux code en Fortran 77 devient imbitable... Je suis pour laisser à l'OS et au gestionnaire de fenêtre leur boulot.
Je suis sous Linux quasiment à 100% depuis des années. Il y a des trucs mieux qu'avant mais non, je ne suis pas fanatique de la monoligne - monoapplication, monovisuel, monotoolkit ;-) Je suis pour la diversité ! Il est vrai que j'ai quitté depuis des années GNOME et KDE parce que c'était tout simplement insupportable. J'y reviens de temps en temps mais jamais très longtemps... Effectivement, je ne dois pas me rendre compte de ce que certaines choses ont apporté (notamment les application en mode serveur, parce que je vois bien les progrès dans plein de domaine qu'on n'a pas évoqué dans ce post).
Je ne suis pas 100% contre DBUS ou policy-kit, je suis contre la pensée unique. Contrairement a ce que l'on peux penser, cela ne me dérange pas du tout de changer d'avis. Au contraire, cela signifie que j'ai appris quelque chose. Par contre, j'aime pas trop les arguments fallacieux qui me semble bidon, j'aime pas trop voir les choses converger vers un Windows NT ou un macOSX. Notre Linux, il est souple, simple, efficace et scriptable, il faut essayer de garder cela ;-)
Cela fait des années que l'on sais que sudo est limité. Il est clair qu'il n'est pas parfait. Pourquoi pas policy-kit lorsque j'aurais mieux compris son fonctionnement. Je demande le bénéfice du doute ! Il ne faut que cela devienne comme SELinux, un truc très (trop) puissant ou finalement quasiment personne ne comprends comment cela marche et ne sais le régler !
[^] # Re: Même pas peur…
Posté par Sytoka Modon (site web personnel) . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 3.
Ca tient la charge ? J'avais tenté la même chose avec LVM il y a quelques années mais c'était ingérable du fait de LVM...
Un point important serait lors des backup de ne sauver que les block qui ont été modifié depuis le dernier backup... Comment avoir cette liste des block modifié sur le serveur de base, via un snapshot LVM :
http://serverfault.com/questions/27397/sync-lvm-snapshots-to-backup-server
http://theshed.hezmatt.org/lvmsync/
lvmsync semble intéressant ! J'ai pas encore testé. Il y a juste un truc qui me chiffonne, il faut faire un snapshot LVM sur la source juste pour avoir la liste des block modifié... LVM fait bien plus que cela donc ralentis... Il serait intéressant d'avoir un snapshot LVM qui liste juste les block modifié sans dupliqué ces block. On n'aurait alors aucune perte et performance quasiment. Je ne sais pas si cela existe...
Sinon, plutôt que LVM, peut être qu'il est possible d'avoir la liste des fichiers modifiés via lsyncd et de n'envoyer à rysnc ou rdiff-backup que cette liste histoire de gagner encore du temps ! Je ne sais pas comment se comporte lsyncd sur une grosse arborescence de millions de fichiers sur 30To par exemple...
# tcp sur tcp
Posté par Sytoka Modon (site web personnel) . En réponse au journal Synchroniser deux répertoires rdiff-backup. Évalué à 3.
Si je comprends bien, tu veux faire un rdiff-backup au dessus d'un rdiff-backup ! sachant que l'algo sous jacent est le même que rsync (librsync), pourquoi ne pas faire bêtement un rsync entre dépôt 1 et dépôt 2 à la fin ? Sur le dépôt 2, tu auras tout l'historique qu'il y a sur le dépôt 1...
[^] # Re: La décentralisation est déjà effective
Posté par Sytoka Modon (site web personnel) . En réponse au journal De la possibilité de décentralisation de la gestion des noms de domaine. Évalué à 3.
Par simplicité, on remonte effectivement au . initial. Sur mes serveur DNS, le domaine en .42 fonctionne ! Il est très facile de nos jours de faire un paquet DNSROOT qui aurait les serveurs racines des différents pays et serait régulièrement remis à jour, un peu comme TZDATA...
Bref, si jamais les américains coupe une nom de domaine d'un pays, ce sera la fin du . sommital, et la parade pour les FAI sera très rapide à mettre en place. Je pense que le scénario est guère probable !
[^] # Re: La décentralisation est déjà effective
Posté par Sytoka Modon (site web personnel) . En réponse au journal De la possibilité de décentralisation de la gestion des noms de domaine. Évalué à 5.
Et qu'est-ce que vous voulez ? Un espace sans règle ni loi ?
On vit sous le régime des états nations. Tout n'est pas idéal mais je réfère cela à celui des entreprises nations qui est une voie possible ;-)
Si on est en France, on applique le droit français et s'il est dépassé, il faut essayer de le mettre à jour. C'est difficile et long mais tout est possible... Le .fr applique le droit Français, je ne vois pas ou est le problème.
Je me souviens des débuts du web, le droit français s'appliquait déjà. Je me souviens d'une descente de la DST chez nous car un de nos étudiants nous avait piraté ! Ce couillon, s'il avait été Canadien, il n'aurait jamais été embêté car les procédures inter-état étaient (sont toujours ?) bien trop lourde.
Il ne faut pas mélanger liberté d'expression et zone de non droit... Le web peut être soumis au droit sans qu'on tombe forcément dans big brother...
# La décentralisation est déjà effective
Posté par Sytoka Modon (site web personnel) . En réponse au journal De la possibilité de décentralisation de la gestion des noms de domaine. Évalué à 6.
Il n'y a pas que le .com dans la vie !
Tous mes sites sont en .fr, ce domaine ne dépend pas des américains mais dépend de la loi française... Il y a aussi le .eu pour l'europe !
Il suffit de ne pas prendre les noms de domaine américain. Il y a en Europe déjà beaucoup de nom de domaine, rien n'empêche de les utiliser.
Il n'est écrit nulle part que le .com est plus intelligent que les autres. Soyez vous plus intelligent et ne donnez pas votre argent aux DNS américains ;-)
PS : mes sites web en .fr sont très bien indexé dans Google, le .com n'est pas forcément utile !
[^] # Re: Ça ne touche que la version de dév ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Faille Xorg > 1.11. Évalué à 3.
debian testing n'est pas une distrib stable. Il est normal qu'il puisse y avoir des bogues... Les corrections arrivant moins vite que dans sid, elle est même parfois plus dangereuse.
Bref, testing est la pour préparer la futur stable, c'est pas une rolling release...
# Etat du système américain
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche SOPA opera. Évalué à 4.
Si un tel texte passe sans le support de la maison blanche, cela montre l'état de la cohabitation en ce moment et le peu de poids du président actuel !
Enfin, vu de France, c'est peu imaginable d'avoir une situation pareille...
[^] # Re: 1984
Posté par Sytoka Modon (site web personnel) . En réponse au message Modifier des vieux journaux/dépêches/commentaires. Évalué à 3.
Tu as raison, j'étais déjà dans mon raisonnement 1984 que je n'ai pas été très cohérent tout du long ;-)
# 1984
Posté par Sytoka Modon (site web personnel) . En réponse au message Modifier des vieux journaux/dépêches/commentaires. Évalué à 8.
Personnellement, cette demande est légitime.
Cependant, le passé est le passé, si on cherche à mettre à jour le passé, on finit par contrôler le présent donc le futur. Bref, on rentre dans 1984 à fond.
Ou est la limite ? Personnellement, je n'en sais rien. En informatique, ce qui a plus de quelques années, c'est plus pour les historiens qu'autre chose. Faut'il vraiment faire les mises à jour ?
A vrai dire, je n'ai aucune opinion tranché sur le sujet ;-)
[^] # Re: Je ne comprends pas
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 9.0 est disponible. Évalué à 3.
On ne va pas refaire le débat BSD/GPL... Les deux visions sont intéressantes et chacun a des bons arguments.
Ce qui est plus que limite par contre, c'était (et c'est toujours) la stratégie de SUN avec ZFS. Du libre exprès incompatible avec la GPL pour être sur que ce ne soit pas intégré dans le noyau linux. C'est un peu petit joueur de leur pars, surtout depuis la rachat par Oracle - sachant que Btrfs est développé pour Linux par Oracle !
[^] # Re: capabilities
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeBSD 9.0 est disponible. Évalué à 5.
Ca prouve que les patch que font le distrib ont globalement du bien ;-)
# Première page web
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Silverpeas 5.8 est disponible. Évalué à 7.
Faut changer cela, ça va pas du tout ! On n'est pas du tout dans l'esprit du libre à mettre autant en évidence ces mots...
Sinon, pour ce qui ont la flemme d'aller voir, c'est un truc en Java sur JBOSS avec PostgreSQL. Je n'ai pas été beaucoup plus loin.
[^] # Re: Pas tout à fait un CPAN
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche CEAN 2.0. Évalué à 2.
Enfin, mnesia et yaws sont intégrés dans Erlang, c'est pas des bibliothèques externes...
[^] # Re: Rendons à César...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche CEAN 2.0. Évalué à 3.
github ne sera JAMAIS un C*AN !
github est un truc pratique mais temporaire... Tu ne vas pas baser toutes les bibliothèques libres de ton langage sur une plateforme que tu ne maîtrises pas ! On a vu à l'automne les soucis avec berlioz (si mes souvenir sont bon...).
[^] # Re: Pas tout à fait un CPAN
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche CEAN 2.0. Évalué à 2.
Je n'ai pas du avoir de chance car parmi la dizaine de paquet testé, je n'en ai pas trouvé un seul qui ne pointe pas vers un lien externe au CEAN. As tu un exemple ?
[^] # Re: Rendons à César...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche CEAN 2.0. Évalué à 3.
Il faut dire que TeX est un monstre du logiciel libre, bien avant la FSF (1978)... d'ailleurs cela se voit dans sa licence d'une clarté peu claire ;-)
Cependant, le CPAN a rapidement dépassé son mentor pour des raisons assez logique (début du web, langage de script...). Les autres langages "libre" ont suivis que très très lentement le mouvement.
Le couple CTAN/CPAN restera donc dans l'histoire comme les premiers, loin devant les autres. De plus, bien que le CTAN soit plus vieux, les deux sont assez indissociables. Perl/CPAN est alors à ma connaissance le premier langage communautaire.
Ceci dis, l'étape suivante me semble l'intégration d'un équivalent de github au coeur même des C*AN...
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 2.
Je ne dirais qu'un mot : Fuck ! Euh non désolé, c'était FAI que je voulais dire ;-)
Enfin, ton post m'a bien fait rire, merci.
# Pas tout à fait un CPAN
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche CEAN 2.0. Évalué à 4.
C'est une remarque que j'avais déjà faites pour OCaml, le truc très important dans le CPAN, c'est que les tar.gz sont dans le CPAN ! C'est pas juste un annuaire. La centralisation des sources assure aux utilisateurs du CPAN d'avoir toutes les versions d'un paquetage et les sources quoiqu'il advienne au projet amont. Ceci dis, on ne développe pas sous CPAN mais ailleurs et on upload sur le CPAN ses distributions, pas exemple avec dzil.
http://search.cpan.org/~rjbs/Dist-Zilla-4.300006/
Sauf erreur de ma part, j'ai pas vu de source dans le CEAN.
On est donc pour moi encore très loin d'un vrai CPAN...
# PS
Posté par Sytoka Modon (site web personnel) . En réponse au message Concilier Nilfs et SELinux [F16]. Évalué à 3.
PS : Les machines debian tournent par défaut sans SELINUX à ma connaissance et sans problème particulier...
PS2 : je suppose qu'il y a 2 linux... J'installe sur le linux A grub sur la partition racine /dev/sda et sur le linux B, je met grub sur une partition bidon, par exemple /dev/sda3. Comme cela, le linux est content ;-) Jamais testé.
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 2.
Idée qui me passe par la tête car cela ressemble a ce que je fais avec IPMI..
Ce qu'il y a de bien avec ifupdown, c'est que c'est une syntaxe claire, propre, concise mais facilement étendable via du script shell ! Un peu comme le Makefile. C'est pas un truc qui t'enferme mais ouvre des horizons...
Bref, je prends une voie détourné avec la commande up qui peux être multiple et est lancé après que eth0 soit monté.
A tester car j'ai mis les ; et un peu tout de tête...
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 2.
Je ne sais pas, je suis collé ;-)
J'ai jamais eu à faire cela. Sur mes dom0 ZEN, j'ai une quinzaine de bridge monté sur des interfaces avec des VLAN. Je les déclare à la queue le leu. Les numéros de VLAN ne suivent en plus aucune logique ;-)
Enfin, c'est un problème intéressant, je vais voir s'il je trouve une idée. En pratique, cela sers à quoi ? Machine virtuelle ?
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 2.
libpolkit fait la glue si j'ai bien compris et transmet cela au serveur polkitd mais derrière, celui-ci lance quoi et c'est définit ou ?
Ca doit être écrit dans la doc quelque part... Je chercherait demain !
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 3.
Le problème, c'est que firefox devient un environnement de bureau à lui tout seul ! On ne relance pas GNOME pour chaque application lancée.
Une voie me semble celle des containers. Que firefox se découpe en petits morceaux tournant dans un container global. Cela fait très HURD comme image ;-) Il y a encore du travail coté Linux à faire du coté des containers...
Ensuite, il y a aussi la voie d'Apache qui n'est pas incompatible. Un mélange de thread et de fork, avec de la précharge de thread et de fork ! Rien n'interdit d'ouvrir un thread dans un nouvel onglet/fenêtre ;-)
Bref, le modèle de firefox qui veut tout faire dans un seul processus n'est pas tenable. Une solution est de déléguer à d'autres applications une partie de l'affichage (comme la vidéo à Totem ce qu'il fait déjà). Une autre solution est de reprogrammer en interne dans firefox un OS, gestion des threads (processus), gestion de la RAM, des priorités... Au moins, ils auront 100% de contrôle sur leur code !
Il me semble clair qu'il se dirige vers cette dernière solution même si c'est pas celle que je préfère... Mais l'utilisateur sera content ;-(
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 3.
Sur une ferme, tu es normalement assuré d'avoir 100% de tes CPU rien que pour toi tout seul, même en interactif ;-)
Sur ce point, je ne suis pas forcément d'accord avec les informaticiens qui m'entoure mais je ne fais pas de différence dans la gestion entre un poste utilisateur et un poste serveur. Pas de différence non plus entre une tour et un portable. Pour unifier le tout, je pars de l'hypothèse que l'ensemble du parc sont des portables, donc les portables sont gérés comme les autres, pas de règles spécifiques et tout le monde tourne sous la même distribution.
Ensuite, tout doit être simple à utiliser mais qu'est-ce que la simplicité ? Le dernier GNOME est-il plus simple que XFCE ?
La simplicité, c'est aussi de passer facilement pour les utilisateurs du serveur à son poste et que tout marche pareil dans les deux sens ;-) C'est d'ailleurs une des raisons pour installer FreeNX sur une frontale de calcul. Mais GNOME bouffe tellement de ressource que ce n'est pas possible de laisser les utilisateurs se connecter avec cela ! Mais attention, ici pas question d'éteindre la frontale à la fermeture de session alors que pour le portable, oui.
Je suis toujours ahurit du millions de cycle CPU que doit faire le processeur à chaque fois qu'on réalise le moindre clique. C'est vertigineux que ça marche encore !
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 2.
Les variables globales consomment moins de RAM que les variables locales. Mais au delà d'une certaine taille, un vieux code en Fortran 77 devient imbitable... Je suis pour laisser à l'OS et au gestionnaire de fenêtre leur boulot.
Je suis sous Linux quasiment à 100% depuis des années. Il y a des trucs mieux qu'avant mais non, je ne suis pas fanatique de la monoligne - monoapplication, monovisuel, monotoolkit ;-) Je suis pour la diversité ! Il est vrai que j'ai quitté depuis des années GNOME et KDE parce que c'était tout simplement insupportable. J'y reviens de temps en temps mais jamais très longtemps... Effectivement, je ne dois pas me rendre compte de ce que certaines choses ont apporté (notamment les application en mode serveur, parce que je vois bien les progrès dans plein de domaine qu'on n'a pas évoqué dans ce post).
Je ne suis pas 100% contre DBUS ou policy-kit, je suis contre la pensée unique. Contrairement a ce que l'on peux penser, cela ne me dérange pas du tout de changer d'avis. Au contraire, cela signifie que j'ai appris quelque chose. Par contre, j'aime pas trop les arguments fallacieux qui me semble bidon, j'aime pas trop voir les choses converger vers un Windows NT ou un macOSX. Notre Linux, il est souple, simple, efficace et scriptable, il faut essayer de garder cela ;-)
Cela fait des années que l'on sais que sudo est limité. Il est clair qu'il n'est pas parfait. Pourquoi pas policy-kit lorsque j'aurais mieux compris son fonctionnement. Je demande le bénéfice du doute ! Il ne faut que cela devienne comme SELinux, un truc très (trop) puissant ou finalement quasiment personne ne comprends comment cela marche et ne sais le régler !