Mr F a écrit 898 commentaires

Evidemment, à Google, ils sont un peu moins limité qu'un ingénieur de SSII qui conçoit une BDD: ils se disent: "hoooo mais ca ne sert à rien de garder un million de copies de la même chose".

C'est un point technique avéré que l'on peut lire quelquepart officiellement ou simplement un "je pense que c'est comme ça donc ça l'es surement" ?

Non, dans le cas de l'IPv6 natif, les deux protocoles circulent sur le lien PPP : IPv4 et IPv6. Il n'y a en aucun moment transformation de l'IPv6 en IPv4. Donc si tu fais de l'IPv6, tu en fais jusqu'au bout (comprendre la destination IPv6), et non pas simplement jusqu'au FAI.

Ce qui ne servira donc à rien, si ton serveur de contenu est en IPv4, tu passera directement en IPv4 et donc à quoi te servira l'IPv6 (d'un point de vue purement technique et pragmatique, bien sûr) ?

Tant que l'infrastructure n'est pas complétement en IPv6, c'est prématuré d'y passer. Tu va faire de l'IPv6 jusqu'a ton FAI puis lui te transformera en IPv4 parceque tous les sites de contenu sont en IPv4, quel en est l'intérêt ?

J'ai un Xbook sous Linux, il est arrivé sans Windows, fonctionne parfaitement sous Linux avec drivers proprio ATI et permet de faire du dual screen. C'est loin d'être un mini portable mais il est vraiment bien, rien à redire.

Euh si tu connais trois prédicats :
- ipmi
- Serveur IBM
- Debian

ça peut permettre de construire un peu plus !

Je demandais ça dans l'optique d'avoir une réponse un peu plus construite, parceque ça, je connais déjà, merci...

Euh non j'ai pas de problème à installer une Debian stable Sarge.

SIP et la VoIP peuvent fonctionner très bien avec du NAT s'il y a utilisation de proxy. Ce n'est pas un problème de protocole mais d'architecture.

Youpi. Donc tu installe en vrac et tu fait les mises à jours à la main. À moi que tu n'ait ton propre dépot ? Il reste que tu doit surveiller les paquets.

Bien sûr, je fais ça à la façon Debian, ce serait idiot de faire autrement. Il reste du travail concernant la mise à jour, bien sûr.

Non, je voulais pouvoir utiliser Konqueror pour aller sur Gmail et les filtres KMail par imap, plus la webcam.
Pareil pour selinux, ssp, Jabber2 sur amd64... ce sont des choses qui nécessitent de compiler et qui sont utiles.

Ok, je te l'accorde, il y a quelques fonctionnalités intéressantes qui necessite une version récente d'un logiciel.

D'ailleurs il ne s'agit souvent pas de minutes mais d'années avec debian stable, et de 6 mois en testing. Et ceci à cause du lien fort qui existe entre les versions des packages utilisateurs et du coeur du système, sur toutes les distributions binaires.

La volonté de Debian Stable n'a jamais été d'avoir els derniers logiciel mais d'avoir une version stable d'un ensemble de logiciel. Il ne faut pas non plus critiquer Debian sur ce point la qui justement est voulu.

En Testing, c'est généralement 14 jours, sauf cas effectivement de changements importants. Sur SID, c'est plus rapide.

Non, je ne compte que le temps d'interaction avec la machine que l'opération me coute. Et ce temps est très court sous gentoo.
Le reste ne corresponds pas à un compromis que j'aurais à faire. Que ma machine compile ou se repose, c'est son problème: elle marche et ça me suffit.

Oui, mais si tu veux installer un logiciel customisé, bien que cela te prenne a toi 16 secondes (en sachant faire) il faudra attendre la fin de la compilation. Et donc tu ne pourra utiliser le logiciel que *plus tard*. Et ça, pour des actions imédiates, c'est très pénibles.

Ça dépends, on peut avoir besoin de tel ou tel logiciel qui ne seraient pas dans la distrib en version stable (apc, eaccelerator, openoffice2.0), où de certaines fonctionalités (mpm, selinux...).

Tout à fait, mais il n'est pas necessaire d'utiliser une distro source pour cela, je le fais régulièrement sur des distro binaire.

Je le fait parce que ça m'amuse mais ce n'est pas une nécessité. Un "emerge sync && emerge -uvD world;etc-config" toutes les semaines suffirait (suffit à mon serveur en fait). J'estime le temps d'interaction avec la machine à dix minutes dans ce cas.

Tout à fait, mais en ce cas tu n'optimise et ne personnalise rien du tout, autant ne pas recompiler, finalement...


À d'autres ! J'utilise des distros sources depuis mes débuts, à peu près à la même époque que toi.

Mes début ? Basé sur quoi ? Mon inscription Linuxfr ? C'est une mauvaise base, ma première installation de Linux, certes très laborieuse, date de 1998.

D'ailleurs je connais plus de gens qui font le passage dans le sens binaire vers source que le contraire.

Moi non :-)


Justement !
Un type qui upgrade sa glibc et/ou casse tout son arbre de dépendance (ce qui se passe à l'heure actuelle sous debian si tu installe kde 3.5) perds beaucoup plus de temps qu'un gars qui lance un "emerge kde-meta" avant d'aller se coucher.


Et ça prendra plus de temps que quelqu'un restant en 3.4 (ou 3.3)... Mais certe, Debian n'est pas une distribution pour avoir la toute dernière version d'un soft "dans la minute". Mais ça, c'est de l'amusement, rien d'autre.

Les miennes se portent bien, depuis quelques années déjà.

Parceque tu en prend soins :-)


Sous gentoo, virer les dépendances à gnome me prend 16 secondes, montre en main (je viens de faire le test, il inclut la phase de login).

En comptant la recompilation ?

C'est bien ce que je dis, ça sert à s'amuser, quand tu en aura marre de passer plusieurs heures par semaine à t'occuper de ton système, tu reviendra, comme beaucoup, vers un système binaire et tu upgradera ta glibc pour avoir kde 3.5 ou tu installera les librairies Gnome, parceque ça sera toujours plus simple et rapide que de customiser son système.

Crois moi, quand on passe son temps à customiser des serveurs, on a pas du tout envie de customiser sa Workstation, on veut que ça marche et c'est tout.

Et je ne suis de toute manière pas convaincu de la pérennité d'une Gentoo sur le long terme.

Moi j'en pense que recompiler ne sert à rien d'autre que s'amuser ou perdre du temps, au choix. Il n'a jamais, et il ne le sera probablement jamais, été prouvé que la recompilation pouvait optimiser des programmes. Excepté peut être les player vidéo.

Certes, mais malheureusement PHP 4 n'est pas encore parfaitement stable et est vivement déconseillé avec Apache 2. Je ne crois pas actuellement que le PHP 5 soit très stable sous Apache 2 non plus.

Et 3 mois apres rebelote. A croire que les conditions se sont drastiquement degradees ou que les thunes donnees 3 mois plus tot ne sont plus suffisantes.

Bah 0.3% d'augmentation, c'est pas énorme quand même. Et je ne sais même pas de quand date la précédente... Et hmm, tu n'a pas bien suivis l'histoire et tu semble assez peut au courant des problèmatiques syndicales du moment. Le début de la grêve n'est pas pour augmentation, et le fait d'avoir gagner une augmentation est un bon prétexte pour arrêter une grêve soit disant illimité à son départ.
Un peu d'analyse politique te ferait le plus grand bien plutôt que de systèmatiquement blamer les cheminots de "tout le temps se mettre en grêve pour rien".


Bon, sinon, ton post illustre bien le cote egoiste irresponsable sous couvert d'altruisme.

ça, c'est une jolie phrase passe partout signifiant : "J'ai raison tu as tord tais toi" ?

Ah ! Mais il n'y a pas que des TGV sur les rails... Et certaines locomotives datent des années 70...

aucun train ne peut en suivre un autre de trop près sinon il y a un frein automatique qui se déclanche

Hmm, quand on ne sait pas on se tait !
Le frein automatique c'est le conducteur et il se base non pas sur sa vision supersonic pour repérer les train loin devant mais sur les petite chose lumineuse sur le bord d'une voie ferrer que l'on appel "feu".
Si tu as ton permit, tu sais de quoi je parle !
Et oui, il faut surveiller les feu, parceque parfois c'est vert, parfois rouge et parfois c'est de la marche à vue. Et puis ils ne faut pas louper les gare parceque non, le train s'arrête pas tout seul devant, il faut freiner et surtout doser son freinage...

Bref, quand on sait pas, on se tait ! (Je le dis deux fois, parceque sur ce thread beaucoup parlent sans savoir...)

Ca devait etre pendant les greves de 95 je crois ou des cheminots se plaignaient, entre autre, du bruit de la machine...
Ben mon con, du bruit au boulot, yen a pas que dans les trains..

C'est pas parceque c'est pire ailleur que la situation doit se dégrader pour tout le monde...

Si tu trouve tes conditions de boulot pire que ceux de la SNCF (mais encore faudrait il les connaitre vraiment car ce mail dont est issue le journal est un ramassis de stupidité, et j'en sais quelque chose étant fils, petit fils et arrière petit fils de cheminot), alors bat toi pour qu'elles s'améliorent.

Mais ne vient pas reprocher à certain de vouloir mieux sous pretexte qu'ailleur c'est pire. Parceque qu'ailleur c'est toujours pire mais que ça ne justifie rien du tout. Oui je renvendique vouloir vivre mieux même si je vis bien mieux que les 3/4 de la planête et oui, je revendique aussi qu'eux vivent aussi bien que moi.

prétendre qu'ils n'ont fait que multiplier les lignes téléphoniques ca n'est fondé sur rien du tout.

C'est tout simplement fondé sur le fait que la paire de cuivre ne permet pas, pour l'instant, de tel débit. Et même si Free posséde beaucoup de compétence, je doute qu'il soit le seul à "découvrir" comment révolutionner brutalement le débit sur ligne téléphonique (avec tous les effets de bord que l'utilisation de hautes fréquences posent).
De surcroit, la démodulation de l'adsl est en dur dans les DSLAM Free. S'il n'y a donc pas de changement de DSLAM c'est que cela reste de l'ADSL2+.
Bref, tout cela est fondé sur des connaissances que je te trouve bien prompt à remettre en cause pour des raisons et des arguments non avancés...

Sur un autre registre, cette technologie pourrait permettre de mutualiser le débit Internet d'un immeuble, ce qui pourrait être interessant.

Du Tera sur de la fibre, c'est pas encore pour demain non plus, a moins d'installer du DWDM à la maison (et encore), mais ça a quand même un certain cout :)
Il ne faut pas croire que la fibre peut tout faire passer...

Très simple :
Free parle dans son communiquer de l'utilisation de la technologie ADSL2+, hors cette technologie ne permet pas de faire plus de 20Mb. C'est comme l'ADSL qui ne permet pas de faire plus de 8 Mb. L'idée de Free est d'utiliser plusieurs paires de cuivre et de les coupler afin d'augmenter le débit. L'appelation de cette technique est, d'après Free, le F-ADSL. Il faut donc bien une dixaine de ligne FT, environs, pour atteindre ce débit.

Il semblerait même qu'il s'agisse d'un problème de surchauffe de la carte graphique, peut être une mauvaise ventilation/dissipation de chaleur...

de plus il me semble que la pluspart des routeurs et autres sont en IPv6

Absolument pas.

Avoir plusieurs softs, chacun avec un role et une fonction définie c'est bien. Les gros trucs monolithyques qui font le café c'est inmaintenable assez vite.


Sans allez a l'extrème, il s'agit simplement d'une fonctionnalité lié de façon très proche avec PHP.


Il le tient pourtant à plein d'endroits. Ca doit être le wrapper le plus utilisé pour ça. Pourquoi ne pourrait-il pas convenir d'après toi ?

Parcequ'il n'éxècute pas de binaire en ce basant sur le uid du fichier lancé, mais en ce basant sur l'url (la partie ~user). De plus il ne supporte pas les virtual uid.
Donc non, il ne convient pas, et non, ce n'est pas le plus utilisé dans le domaine de l'hébergement (et c'est un domain que je connais bien).

Tu rajoutes bien apache, tu rajoutes l'OS, tu rajoutes les libs, tu rajoutes tes comptes utilisateur ... PHP ne contient pas tout et n'est pas fait pour ça. Pourquoi vouloir intégrer suexec et pas directement le serveur Web par exemple ?
C'est un langage de programmation, pas un serveur d'application, et encore moins une plate-forme complète.


Il s'agit justement de fixer la bonne limite entre une fonctionnalité pouvant être incorporé et "le reste du monde".
Et en l'occurence, c'est une fonctionnalité qui pourrait être implémenté directement dans PHP, sans que cela le transforme en usine à café brésilien, et qui permettrait de supprimer une couche non necessaire.

Mais bref, nos point de vue diverges, autant arrêter là.

Ca n'est pas son rôle et ce n'est pas forcément réalisable.


C'est une vue de l'esprit.


Installé en CGI il y a déjà plein de wrapper de ce type.

Justement, d'ou l'idée de ne pas s'encombrer d'un wrapper supplémentaire.


Suexec est fourni avec Apache mais il en existe d'autres moins couplés au serveur Web

Suexec ne permet absolument pas de remplir ce rôle. Et s'il en existe d'autres, il n'en existe pas tant que ça non plus.


Quel serait l'avantage pour PHP d'implémenter ça en interne ?


De permettre d'avoir un système sécurisé sans devoir rajouter quoi que ce soit d'autre.
Je serais plutôt tenter de demander : En quoi est ce génant que php incorpore directement ce type de code, activable a souhait, permettant de supprimer les wrappers divers et varié ?

Ils ne proposent pas de retirer open_basedir, c'est même limite l'inverse. Ils veulent retirer le safe_mode qui est dûr à maintenir et pose plein de problèmes pour les hébergeurs mutualisés (alors que c'est justement la cible) pour imposer plutot l'utilisation de open_basedir (qui n'agit pas sur les même choses mais qui répond assez bien au principal de la problématique).

Très peu d'hébergeur mutualisé utilisent actuellement le safe_mode, il est bien trop restrictif par rapport au cahier des charges necessaire pour être compétitif en therme de fonctionnalités.

C'est effectivement d'avantage une solution à base d'open_basedir et de forbiden_fonctions qui est utilisé par les hébergeurs. Si PHP6 pouvait intégrer en plus directement un équivalent à suexec, ce serait parfait.