Sytoka Modon a écrit 4551 commentaires

Mais non, depuis Fukushima, les japonais dégazent plus, c'est bien connu.

C'est sur que cela ressemble quand même fortement à cela !

gaby

Ces puissances sont purement virtuelles car à la connaissance, aucun programme n'utilise 100% de la machine en pratique. C'est un peu comme si additionnait toutes les machines de GRID 5000 (j'exagère exprès).

A mon sens, il est temps de faire un autre classement avec des critères plus significatif. Celui-là ne signifiant plus grand chose. Ce sont des clouds de calcul plus que des machines de calculs.

Les grosses sont incapable d'innovation. Si tu innoves est que cela marche, on t'en veux, si tu innoves et que cela ne marche pas, t'en prends à vie ! Les grosses boites ont externalisées l'innovation en rachetant des startup...

Dans les mesures à prendre, on peux supprimer les brevets de toute sorte qui ne permette au final qu'aux grosses boites de se maintenir. Évidement, on ne peux pas faire cela du jour au lendemain...

Sinon, le système français a des inconvénients en cas de fort développement mais en cas de crise, vu qu'une bonne partie de l'économie est nationale, les crises sont bien moins violentes qu'ailleurs. Par exemple, dans mon laboratoire, on investi de la même manière que l'année dernière, on n'est pas réellement soumis à la crise à court terme, les PME qui travaillent avec nous sont bien content ! L'état français est un sacré volant d'inertie qui fonctionne tant à l'accélération qu'au ralentissement.

Une étude faite au CNRS a montré que la moindre facture a un coût minimum de 80E. Du coup, pour les factures inférieurs à 50E, ils sont beaucoup plus souple depuis quelques temps je chose, en tout cas dans mon laboratoire.

A mes souvenirs, sous IRIS (SGI), les homes étaient sous /usr/people... mais tout cela est vieux !

Et puis, autoriser cela remettrais cause les principes d'UNIX d'héritage père fils ou un fils n'influe pas sur le père (pas de variable globale). C'est une des raisons de la solidité du modèle UNIX et de sa robustesse face au virus et autres cochonneries. C'est pour cela que je ne suis pas toujours fanatique de système de GUI moderne qui oublie un peu tout cela - bus global pour faire des espèces de variable globale (avec plus de gestion de la notion de groupe principale et d'autres choses amusantes).

Dans les anciens gestionnaire de fenêtre, on faisait un restart ou un reload pour avoir une prise en compte. Par parfait mais on ne faisait pas des modifications tous les jours. Maintenant, on met du dbus partout mais un jour, un ver va se propager la dedans et on devra avoir un firewall dbus !

avahi est une daube en entreprise... C'est encore un protocole à la Apple conçu pour le familial ou la PME.

Avahi ne me dérange pas en soi tant qu'il ne devient pas une dépendance nécessaire à l'environnement de bureau...

which lsof
/usr/bin/lsof

Chez debian, ip et lsof sont utilisables par les utilisateurs. Pas ifconfig car je l'ai déjà dis, ifconfig est obsolète...

C'est pas incompatible ;-)

Je remonte un sentiment sur un forum. Je ne suis pas là pour faire tous les test sur tous les navigateurs sur toutes les plateformes...

Déjà, je précise que j'ai fais en vrai les tests sous iceweasel...

Tant mieux si d'autres font le même test ailleurs et le disent. C'est le but du débat.

A priori, ca fait cela depuis des années et je ne le découvre que maintenant et je ne suis pas le seul. Objectif du post atteint ;-)

Je viens de faire une recherche, lorsque la souris passe sur un lien des résultats Google, Firefox affiche l'URL finale mais si on fais copier le lien, alors Firefox affiche le lien passant par Google (à vrai dire j'utilise Iceweasel... j'ai pas fait le test sous l'original Firefox).

Cela signifie que Firefox n'affiche pas en bas à droite le vrai lien mais un truc dont on ne peux pas avoir confiance... C'est pas bon ça pour le phishing car si Google le fait, d'autres peuvent aussi le faire. j'utilisais cette fonctionnalité pour toujours vérifier les liens un peu louche.

Ca va pas améliorer le web cela.

Les attributs étendus ont été inventé, c'est fait pour servir !

Pourquoi ne pas tout simplement mettre les bases de données USB et PCI dans /lib ? On a bien un /lib/modules ! D'après ce que tu dis, cela semble plus un bogue udev que systemd...

En cherchant 30s, j'ai retrouvé cela...

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538433
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html

Je crois qu'il y a des soucis avec IPv6... je ne sais plus bien. Debian pousse iproute2 qui installe la commande ip qui gère aussi les routes.

Je dois dire que 90% de mes scripts utilisent encore ifconfig... La migration va être longue ;-)

which ping
/bin/ping

Sous dedian, ping n'est pas sous sbin. C'est idiot de mettre sous /sbin un binaire suid qui a justement vocation a être utiliser par quelqu'un d'autre que root.

Il ne faut pas se leurrer, les capabilities, c'est juste découper le bit suid en petit morceau plus petit. Il ne faut pas dire qu'il n'y a pas de suid, il y a un suid limité...

Question, la commande montre les capabilities ?

which ip
/bin/ip

J'avais fais l'essais avant de le dire (je suis sous debian squeeze).

J'ai fais exprès de ne pas lire le lien pour simplement réagir sur la forme.

Ce que j'en pense est que systemd a vouloir tout gérer dès le début me semble avoir un problème de conception s'il est aussi rigide. Il me semble normal qu'une partie du système ne soient pas monté au tout début (/usr ou autre (des services sous /srv...)). Si des programmes ont besoin de /usr, soit il faut les démarrer plus tard, soit il faut déplacer les dépendances de /usr vers /, soit il faut que le service se lance en mode dégradés puis se recharge au fur et à mesure des montages.

L'ordre de montage et le lancement des services a toujours été un jeu subtil (bidouille _netdev dans fstab...). Une bonne archi doit pouvoir gérer cela. Je ne dis pas que c'est simple !

Peut être systemd avec dbus et tout le tralala est un peu gros pour être le job 1... Pourquoi pas un systemd minimal qui au fur et à mesure du boot chargerait des greffons ?

La commande ifconfig est obsolète... elles ne sont pas donc synonymes à 100%. Il me semble normal de "cacher" de l'utilisateur une commande obsolète mais de la garder un certain temps quand même pour les anciens scripts !

Ca prouve une chose si cela est vrai, c'est que systemd est beaucoup trop rigide pour tout baser dessus et il ne tiendra pas 10 ans à cette allure...

Bref, cela me fait plus penser à un problème de conception !

J'ai bien compris que tu avais compris ;-) Je complétais simplement...

Sous AIX (ou HP-UX j'ai un trous), le home du compte root était directement sous / !

J'adore les UNIX propriétaire ;-)

C'est peut être que ifconfig devrait être dans /bin mais pas forcément pour tous les programmes de /sbin.

D'ailleurs, il faut utiliser la commande ip qui EST dans /bin

ip link show

Mettre la commande ifconfig dans /sbin, c'est un moyen de la déprécier... (bien que je la trouve plus simple que ip).

Un gestionnaire de paquet ne devrait pas avoir le droit d'écrire dans /srv /opt et /usr/local

Il y a un espace pour a distrib et un espace pour l'administrateur système. J'ai une SUSE avec des paquets propriétaires qui mettent des merdes partout, c'est absolument ingérable...

parce que Debian a généralisé cela au multi-arch ou on peux faire un mix avec de l'ARM par exemple. C'est très bien expliqué par Raphaël Hertzog dans dpkg.

http://lists.debian.org/debian-devel-announce/2011/06/msg00002.html
http://wiki.debian.org/Multiarch/

La source initiale mais j'en suis pas sur...

http://raphaelhertzog.fr/2011/07/06/mes-activites-debian-en-juin-2011/

C'est la 'touch' debian ;-)