Sytoka Modon a écrit 4565 commentaires

On est déjà limite vis à vis de la loi sur pas mal de point mais c'est difficilement pénalisable car c'est pour le bien de l'état et il n'y a jamais d'enrichissement personnel (les rapports du parlement l'ont signalé à chaque fois : c'est limite mais au vu de ce qu'on attribue aux universités et du résultat, c'est plus que bien !).

Après, il y a des limites que j'espère n'avoir pas franchis. La surfacturation en fait partie ;-)

De toute manière, on fuck les ricains ;-)

Quand tu travailles dans le public, ce n'est pas aussi facile que cela de financer le libre… On a les services comptables sur le dos et je n'ai pas encore trouvé la bonne solution !

Une architecture micro noyau rend le développement beaucoup plus difficile (algorithmes distribues, débogage infernal, etc.), et potentiellement désastreux pour les performances si l’implémentation n'est pas correcte. Certes la sécurité est accrue, mais dans notre monde actuel, la sécurité passe après les fonctionnalités, perfs, etc.

Je ne suis pas sur que la sécurité soit accrue alors que le développement devient beaucoup plus difficile (algorithmes distribues, débogage infernal…). Il est donc probable qu'il y ait un bogue dans ton raisonnement !

s/déployé/déployer/

Sinon, je n'y connais pas grand chose en RHEL…

Je fais pas mal de fote d'ortografe mais là, il faut quasiment déchiffrer un mot sur deux…

Un container ne sécurise pas une application codé comme les pieds ;-) Les containers et la virtualisation, c'est bien pour les serveurs mais au niveau applicatif, ce n'est pas forcément toujours une bonne idée. C'est une dérive de type Windows de faire du développement en variable globale pour moi…

Capsicum, c'est un peu la généralisation que ce qui se fait avec Postfix par exemple. Chaque application diminue ces droits sur certaines parties en fonction de ce qu'elle a besoin. La réduction des droits se fait à la source par un choix du développeur. Cela me semble une approche personnellement plein d'avenir pour les applications critiques.

Personnellement, j'évite toutes les extensions "américaine" .com, .net, .org…. tant que celles-ci ne sont pas clairement sous juridiction internationale.

Le dépôt "deb-multimedia" pose pas mal de soucis depuis un certain temps.. notament de dialogue entre les personnes mais on a aussi plus de soucis qu'avant (il faut installer les paquets dans un certain ordre et ne pas mettre "deb-multimedia" trop tôt !

La solution est à mon avis de refaire comme avant un dépôt officiel non-US, basé en Europe et dépendant de Debian Europe ou Debian France… On met dedans les paquets qui donnent des boutons aux USA et basta.

C'est fatiguant à force cette loi américaine qu'on s'impose de nous même jusque sur notre territoire.

Et OVH avait dis merde à Sarkosi dans l'affaire wikileaks. Bref, ils font gaffes et c'est bien.

C'est faux.

La grenouille Rackable faisait du cloud, SGI du HPC. C'est différent et complémentaire. D'ailleurs, les machines UV (UltraViolet) de SGI sont toujours uniques et magnifiques (même si beaucoup trop cher). La techno derrière UV ne provient pas de la grenouille…

Surtout que j'ai déjà eu de la Suse SGI entre les mains. La machine SGI est (était) très bien mais la Suse est (était) pour moi une daube. Je trouve yast tout pourris…

Enfin, je n'empêche pas ceux qui aime d'y aller !

J'ai été voir sur le green500 puisqu'on parle de machine 'propre'…

http://www.green500.org/lists/green201406

Pas de SGI dans les 10 premiers et il y a du Xeon sur chaque ligne. On ne voit pas non plus IBM pour les fanatiques du Power…

Alors tous à vos claviers pour faire exploser la salle d'attente sous notre nombre ;-)

-décider de respecter l'auteur qui n'a sciemment pas mis à dispo les binaires gratuitement et le laisser faire son beurre

Il me semble que pour gcompris, ça faisait chier les auteurs de faire et de maintenir le paquet PE32 et c'est pas aussi trivial que cela. La somme modique était plus destiné, de mon point de vu, à faire réfléchir l'acheteur que d'arrondir leur fin de mois.

A mon avis, c'est du stockage qui passe de baie de disque à du stockage en masse sur bande. Le centre de calcul IDRIS fais cela aussi. Du coup, il faut du temps pour faire un simple "ls".

Le noyal il a été lancé en 90. Je ne pas suis sûr qu'un noyau sous GPL prendrait aujourd'hui (en supposant que des bonnes alternatives existent bien entendu).

C'est sur qu'à force de tout refaire sous licence BSD plutôt que d'améliorer ou de produire sous GPL, on affaibli petit à petit la GPL ;-)

C'est un problème avec Python ces licences… Avec Perl, tu colles la licence GPL + Perl Artistic et tu upload le tout sur le CPAN comme tout le monde, sans te poser de question ;-)

ou par un mécanisme de partage de fichiers standard (NFS, CIFS)

Attention, NFS en mode noyau ne marche pas dans les containers à l'heure actuelle (sauf s'il y a eu un changement dans le noyau mais j'en doute). Il faut utiliser NFS en mode utilisateur qui n'est plus par exemple dans la Debian par défaut.

Je pense comme toi. Le foot est hyper-chiant globalement. Il ne se passe rien… comme au foot américain ou au base-ball. Les résumés des journée de championnat ne sont pas du tout significatif et on ne voit que la ou les deux actions des 90 min ! Mais la grande partie des gens aime.

Le basket, la hand-ball, le hockey, le rugby… sont bien plus passionnant. Les match ne sont pas verrouillés au premier but ni ne finissent à la loterie aussi souvent ;-)

Et alors, si la Belgique perds demain, il est possible de faire le même journal a un mot près.

Les meilleurs spécialistes se sont penchés sur RSA et AES. Il y a des concurrents afin de n'être pas trop dépendant si un jour quelqu'un les casses.

Si la NSA avait une clef pour lire, elle lirait. Mais si elle lit et le garde que pour elle et n'en fait jamais rien car il ne faut pas qu'elle dise qu'elle sais lire, cela ne sers à rien…

A moins de garder cela comme une arme ultime au même titre que la bombe atomique, ça n'a pas d'intérêt et surtout, elle ne peux pas l'utiliser…

Donc personnellement, au terme de ce raisonnement, je pense que c'est peu probable.

Dans le deuxieme, les variables d'environments sont une plutot mauvaise solution, c'est un gros bordel, et super facile a peter avec un simple unset.

Les variables environnements sont attachés à chaque processus. C'est une espèce de mini base de registre héritable de père en fils mais non l'inverse. Si tu la pète via un unset, tu pètes pas le père. C'est très robuste.

Ta base de registre globale, si tu fais un unset, t'es marron aussi et en plus, tu auras tout pété ;-)

Une machine d'entreprise partagee par plusieurs personnes.

Chez moi, chacun a son profil… En plus sur Renater, l'anonymat est interdit.

Un developeur qui est assigne a un bug qui n'arrive que dans une locale donnee.

LANG=en_US.ISO-8859-15 geany -i
Si c'est l'environnement de bureau que tu testes, tu peux ouvrir un xnest ou un x2go sur localhost…

Tu penses tellement en variable globale que tu ne te rends pas compte qu'il y a une autre voie qu'UNIX a utilisé pendant des années et qui fonctionne très dans 99% des cas. Enfin, j'espère que tu te rends compte des inconvénients des variables globales et de leur danger. A mettre en face à face avec leurs apparentes simplicitées.

C'est pour cela que tout programme qui dépend d'un service, comme dbus par exemple, doit pouvoir être configuré sur sa ligne de commande, ou via des variables d'environnement, afin de pouvoir utiliser un autre service dbus.

Parce que tu mets une ACL différente pour chaque clef de registre ? Faut arrêter avec cette histoire d'ACL, c'est de la mauvaise fois totale.