scullder a écrit 543 commentaires

D'expérience, quand on donne du vieux matos, on tombe plus sur des accumulateurs compulsifs un peu louches que sur des gens qui en ont réellement l'utilité.

Du coup j'en viens à me demander, est-ce que ce serait pas mieux de mettre ça en déchetterie et avoir la garantie que ce sera recyclé/traité correctement et que ça ne finira pas dans la nature ?

C'est un gachi de ressources hallucinant, tant à l'installation (bande passante &co, même si npm gère un cache), qu'à l'exécution.

Je pense pas que le fait d'utiliser 50Mo de ram en plus soit un argument recevable de nos jours.
Le problème est plutôt "est-ce que ça passe à l'échelle ou pas ? jusqu'à combien d'utilisateurs en parallèle ? combien ça coûte en temps de développement / admin sys d'optimiser ? pour quel bénéfice ?".

Si tu passes du temps à optimiser des dépendances pour augmenter les performances de 2% pour un cas particulier, je pense sincèrement que c'est inutile (enfin c'est intéressant pour moi mais je vais pas prendre le risque de casser des applis au travail pour ça).
Si tu passes du temps pour monter d'un ordre de grandeur dans le passage à l'échelle, oui c'est intéressant si tu en as l'utilité…

Les distributions linux n'arrivent pas à suivre le dependency hell de beaucoup de projets qui utilisent extensivement rubygems, PyPI, npm, etc.

Par exemple, sous archlinux, on ne peut pas installer plusieurs versions d'un même paquet.
Donc on doit créer un paquet différent par version pour le même module.
Comme beaucoup de modules ont des cycles de développement pas très carrés et ultra rapides et cassent régulièrement leur rétro-compatibilité, ça devient vite compliqué et contre productif de repackager 10 versions différentes de chaque gems de rubygems… A mon avis, ça demande énormément de travail de packaging pour des avantages relativement faibles…

Au final, tout le monde utilise des hacks comme rvm et installent tout dans leur homedir car c'est impossible d'utiliser ruby sans cloisoner chaque projet ruby dans un gemset indépendant…

Après si on ne se pose plus la question de la pérénité des dépendances, j'ai envie de dire qu'on l'a bien cherché… Peut-être qu'on ne devrait pas dépendre sur des dizaines de modules aléatoires publiés par des inconnus qui n'ont aucune intention de les maintenir à long terme…

edit: en fait, j'ai mal compris la question et je n'y réponds pas exactement…

Ils peuvent se racheter une image, ça suffira pas à devenir une alternative crédible. Comment on fait une pull request sur sourceforge déjà ? Ah oui, on poste un diff dans le bug tracker, ahah.

J'utilise cet excellent soft très souvent, une seule remarque, je déteste le thème graphique, je voudrais que ce soit intégré avec mon thème gtk/qt/kde… :(

Au pire, tu gardes une bécane avec un Microsoft Office juste pour faire la conversion en pdf ou alors tu prends un compte office 365 pour convertir?

Perso, j'essaye 2/3 méthodes de conversion (calligra, openoffice, google doc, etc), si ça ne passe pas, je demande de renvoyer en pdf ou opendocument.
Normalement, les gens sont plutôt conciliants du moment que tu n'intercales pas un délai de 2 semaines entre chacun de tes mail.

Aère ton texte, passe des lignes !
Là c'est condensé, ça rend la lecture difficile.

"Reiter complained of having to wait weeks for an external mail server to be set up just so that he could get mail on his smartphone" Bon, si c'est vrai, il faut changer les informaticiens d'urgence, mon smartphone fait du courrier avec un serveur Debian et ça m'a pris une heure…

Il y a une différence entre bidouiller un serveur de mail pour un utilisateur et administrer un serveur pour x*1000 employés, et s'assurer de la fiabilité, de la maintenance et de la disponibilité du service pour les x années suivantes.

Est-ce que le délai aurait été plus court dans un environnement microsoft avec un problème similaire ?
Est-ce que ça a du sens d'avoir son propre serveur de mail plutôt que de le mutualiser avec d'autres municipalités/région/etc, voire même de l'externaliser ?

A noter le très drôle package sl de debian, qui affiche une locomotive à vapeur dans le terminal pendant quelques secondes et est impossible à killer avec ctrl+c.

Premier effet: taper sl au lieu de ls est une faute de frappe récurrente
Deuxième effet: ajouter un alias ls=sl :)

Oui. D'ailleurs, tu es déjà terroriste à l'insu de ton plein gré, à cause de la fonction de préchargement de ton browser.

Je chiffre rarement mes messages, simplement parce que peu de mes contacts ont une paire de clefs.

Je ne chiffre pas pour une autre raison, dans beaucoup de clients mails, la recherche ne fonctionne pas sur les mails chiffrés, les mails chiffrés ne sont pas indexé (mac mail?).
Donc je ne chiffre que quand c'est nécessaire (échange de passwords, coordonnées, etc), mais je signe tous mes mails automatiquement.

Je faisais ça pour git.
Puis un jour, j'ai pushé des commit signés sur un dépot qui était mouliné avec grit, les commit signés n'étaient pas gérés, et j'ai tout pété :)

Au final, c'est pas un usage très courant et potentiellement mal géré, donc je ne signe plus mes commit pour éviter de casser les mauvais scripts qui moulinent/parsent les historiques de commit. Eventuellement, on peut signer les tags uniquement.

Il faut lancer le démon gpg-agent au démarrage de KDE, ça permet de ne taper qu'une seule fois la phrase de passe par session (ou pour une période donnée, il y a une bonne granularité à la configuration).

C'est le défaut sur certaine distribution non? (comme ssh-agent)

Facile, si tu veux quitter SAP, tu dois t'en sortir en payant autant que tu as payé initialement pour passer à SAP.

De mon expérience récente, sous centos 5 et 6, si tu as un crash violent qui t'empêches de démonter proprement ton fs XFS, il faut absolument faire un xfs_repair avant de remettre en prod :)

Et pour faire un xfs_repair, il te faut une quantité de mémoire suffisante (je suis monté autour de 50Go de mémoire utilisé pour xfs_repair sur un volume de 170To) et ça prend plusieurs heures.

A noter:
* l'entretien n'est pas trop cher quand la voiture est neuve (dans les 60 000 premiers km)
* les contrats d'entretien sont prévu pour des kilométrages très bas du genre 15 000 km / an

Maintenant, quand tu roules suffisamment pour ne plus pouvoir te débrouiller en bus, Renault ne te propose plus le contrat d'entretien à 50€ / mois :o

Et pour ta ford d'occasion, c'est pas cher à l'achat, ça ne va peut-être même pas être cher à réparer du moment que tu le fais toi même mais ça ne va pas se réparer tout seul…

@fearan, en même temps, dacia ou pas, quand tu t'approches d'un certain kilométrage, autour de 40 000km / an, une voiture neuve est un consommable, la décote est énorme, ta mise initiale est intégralement perdue en 5 ans, et tu peux ajouter ~ 150€ d'entretien / mois si tu veux suivre les préconisations constructeurs et garder ta garantie…

Sinon tu achètes une voiture en occasion à 4000€ et tu fais tout l'entretien toi même, je l'ai fait, c'est encore plus économique qu'une dacia neuve mais ça prend du temps…

Donc je te laisser juger de ce qui est jeter de l'argent par les fenêtres et de ce qui ne l'est pas, une voiture est très rarement rentable. Mais une voiture plaisir comme une audi tts à 35 000€ a l'avantage d'être revendable…

Parce que Linux Desktop nous a déçu ?

Pas moi (de rien).

Perso j'ai préféré tester pubkeyfs [1] pour éviter de patcher openssh, c'est un fs fuse, qui se bind sur ldap. On peut ensuite utiliser normalement la directive AuthorizedKeysFile (qui peut prendre plusieurs paramètres depuis openssh 5.9 [2])

[1] https://github.com/kelseyhightower/pubkeyfs
[2] http://www.openssh.com/txt/release-5.9

J'ai d'ailleurs un module puppet non publié pour pubkeyfs…

Et avec une durée de vie suffisante car j'ai pas envie de gérer trop de serveurs, j'ai assez à faire en dehors."

Et c'est pour ça que je prends des vm pour mes besoins persos, je ne veux pas m'occuper du hardware, risquer de subir une panne et devoir réinstaller. J'ai trop peu de temps à y consacrer (ce qui a d'ailleurs dicté mon choix d'os, à savoir celui que je maîtrise le mieux, debian, directement en wheezy)…

Pour l'ipv6, je conseille ovh et beaucoup moins online. J'ai switché de online à ovh exactement pour ça.
J'avais une dedibox avec du lxc, et je voulais une ipv6 par conteneur, sauf que je n'avais qu'un /128…

Donc j'ai râlé un peu, et on m'a dit que si je voulais de l'ipv6, il fallait aller voir "en face" (parce qu'on s'en fout un peu de nos besoins de geeks avec l'ipv6 là).

Et finalement, j'ai switché vers l'offre virtual kimsufi. D'ailleurs le morceau d'amd opteron alloué à ma machine virtuelle me semble plus véloce en général que le via nano d'une dedibox de base (ça mérite benchmark).

Je viens d'adopter le paquet yabause sur arch pour le mettre à jour, je te dis ça ce week end :p

A chaque release (et surtout à chaque nouvelle génération de processeur), je réessaye radiant silvergun en espérant que ce soit jouable et ça commence à devenir impressionnant.
J'avais un prob de synchro de son avec la version précédente de yabause.

Bontmia : http://folk.uio.no/johnen/bontmia/
750 lignes de Bash, ça c'est KISS. :D

Et perso, j'utilise backupninja, et j'ai codé les plugins qui me manquaient (snapshot lvm pour backupper les domU xen)
Backupninja : https://labs.riseup.net/code/projects/backupninja

J'avais traduit ce plasmoid quand il était encore distribué sur kde-apps.org. Puis le plasmoid a été intégré à kde et ma traduction a été remplacée par une traduction incomplète…

; <<>> DiG 9.9.1 <<>> -tAAAA linuxfr.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35942
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;linuxfr.org.                   IN      AAAA

;; Query time: 5 msec
;; SERVER: 192.168.0.254#53(192.168.0.254)
;; WHEN: Thu Jun  7 23:22:18 2012
;; MSG SIZE  rcvd: 29

D'où ma question, à quand linuxfr en ipv6 ? :D