vu que c'est moi qui l'ait pointé du doigt, voir aussi 4 commentaires auparavant dans le thread où j'expliquais que mon incapacité à comprendre la psychologie des programmes informatiques m'avait fait passé >3h sur ce truc
Plutot que de la psychologie, fais plutot ton boulot en lisant le standard qui ne fait même pas 5 pages. Si a aucun moment la grammaire ne parle de commentaire c'est qu'il y en a pas… Comment veux tu écrire quelque chose qui n'est pas spécifié ? On va pas s'amuser à spécifier tout ce qui n'existe pas.
Posté par ckyl .
En réponse à la dépêche Présentation de Rust 0.8.
Évalué à 4.
Dernière modification le 14 octobre 2013 à 12:40.
Je te trouve bien défaitiste… Franchement, je pense que tout le système de type d'OCaml est trivial comparé au code qu'il faut produire pour faire un truc aussi fou que trier une liste en Java.
Implémenter Comparator et appeler une méthode ? Bin putain c' est pas de la rocket science hein faudrait se poser quelques questions…
C'est vrai que ça peut paraître plus facile dans d'autre langages, mais cette facilité à un coût :
- La prédictibilité des performances pour les langages full GC comme Java, Go, …
Tu as tout à fait raison.
Juste pour que ce soit dit, souvent quand le GC fait chier en Java, on l'évite tout simplement en sortant de la heap pour les structures de données ou ca fait un sens. C'est dégueux mais ca fait la moitié du job (l'autre moitié étant le garbage à courte vie créé un peu partout qui reste en young generation et qui rend les perfs en low latency dégueux même en faisant gaffe…).
L'approche de Rust est meilleure il n'y a pas photo. Si tu peux garder la facilité d'un GC et son adéquation avec des programmes parallèles, tout en réduisant de quelques centaines de MB/s ce que tu balances inutillement dans la face du GC c'est top.
Mais alors, si Debian par défaut reste finalement fidèle à GNOME et n'installe plus adblock-plus, que nous reste t-il pour animer nos vendredi ? Je vous le demande.
T'inquiète pas pour ca.
[ 5880.786156] traps: systemd[1] general protection ip:b74c2390 sp:bff79e2c error:0
[ 5880.786178] in libc-2.18.so[b74ab000+1a9000]
[ 5880.787844] Core dump to |/usr/lib/systemd/systemd-coredump 1977 0 0 11 1381391926 systemd pipe failed
C'est idiot. Si tu envoies un patch pour la présentation, c'est que tu as déjà fait le boulot fastidieux. Le dev devrait être content, non ?
Ca dépend. Sur un petit projet oui. Sur un gros projet distribué où ca va faire des conflits pour 100 dev et péter tout les patchs soumis et en attente il faut vraiment vraiment que ca vaille le coup…
Si le code initial n'était pas lisible alors c'est qu'il y a un problème quelque part dans le process. Si il était lisible, alors est ce que le netoyage vaut le cout par rapport au bruit et a la maintenance qu'il ajoute ?
Quand j'ai décidé (mieux vaut tard que jamais) de me passer d'eux (en contactant directement les entreprises via LinkedIn), j'en ai trouvé plein.
Désolé, les gens qui ont conçu Pôle Emploi sont des gros nuls. Le système est tellement pourri que les salariés à la base qui ne demanderaient qu'à aider (il y en a) ne peuvent rien faire pour vous.
Un mec capable de pondre des tartines d'analyses de très très haute volée comme tu veux le faire a mis 3x4 mois de chomage pour comprendre que:
Aucune agence au monde ne peut comprendre les métiers et les besoins de tout les secteurs d'activité/métiers. Si tu veux des offres et des candidats pertinants, il faut se tourner des vers des gens qui comprennent ton domaine. Vouloir donner ce job de mise en relation à PE est forcément un échec. Même les SSII n'arrivent pas à comprendre 1/4 de leurs métiers, tu penses bien que si tu généralises à toutes les branches…
Les boites qui cherchent des gens qualifiés n'ont aucune raison rationelle de publier les annonces sur de tels supports. Beaucoup de trop de bruit par rapport à une campagne plus ciblée (même chose pour monster & co). Surtout que tu ne veux surement pas viser uniquement les chomeurs pour ton poste… Donc pourquoi utiliser PE pour trouver une offre ?
Tu es dans un secteur d'activité où si tu restes 15 jours au chomage involontairement, t'as vraiment un problème. Comment on peut être compétent et ne pas le savoir ?
C'est long, très long…
TL;DR: Pole Emploi est un non sens à la base. Ils devraient se limiter à coacher les gens qui ont besoin d'être guidé avec du simple bon sens. Le seul truc utile qu'ils auraient pu faire c'est te dire de te sortir les doigts en allant chercher les offres qui grouillent plutôt d'attendre gentilement que quelqu'un publie sur PE…
Évidement si tu veux créer plusieurs graphes tu vas stocker en local les données plutôt que de déglinguer le serveur à chaque fois. Après tu peux décliner les graphes de stats à l'infini c'est pas plus compliqué.
Je me suis toujours dit que si j'avais du temps à perdre un jour, je ferais une petite démo des aglos de data mining & machine learning avec les journaux :)
Tu oserais remettre en cause la pertinence et l'exactitude de mon analyse ? Voir tu irais jusqu'à émettre l'hypothèse d'une certaine ironie dans celle-ci ? ;)
Attention hein, autrement je balance tes stats et l'analyse de haut vol qui va avec. Genre que t'es un gros trolleur du Vendredi matin avant d'aller à la cantoche ou que tu as 1h+ de trajet en sortant du taf après 18h.
Posté par ckyl .
En réponse au journal Travail dominical.
Évalué à 4.
Dernière modification le 08 octobre 2013 à 23:30.
Vu sa productivité en lâchage de coms, il ne doit travailler ni le dimanche, ni les jours qui finissent en di :-)
Je sens que je vais décevoir beaucoup de gens mais je viens de faire rapidement ses stats en punchcard depuis le début et depuis 2013 et voila les résultats:
Je me garderais bien de faire un analyse. Enfin je pense quand même que ca confirme bien qu'il kif bosser le samedi/dimanche (puisque peu de contributions), que le soir c'est nickel pour avoir une vie sociale (puisque moins de contributions que le jour) et que la journée il en branle pas une (plus d'un commentaire par 'business hour' depuis le 1er Janvier)
Bon c'est un peu grossier hein, mais j'avais que 10 minutes…
Posté par ckyl .
En réponse au journal Backups pas dans le cloud.
Évalué à 2.
Dernière modification le 08 octobre 2013 à 11:48.
Si on part sur du 64ko/s sur 24h, tu fais 5,5Go. Moi, cela me va, mon taux de remplissage de disque est bien inférieur à ça et si, on ne compte que les données qui sont intéressantes à backuper (Pas les programmes, pas ce que je peux retrouver facilement sur le net), ben, ma production de donnée doit être de quelques mo par jour.
En meme temps si on est dans ton cas on a pas besoin de 1 ou 4To ;) Je suis parfaitement d'accord avec toi. Dans ton cas un service tel que tarsnap est parfait. Ca coute pas grand chose, c'est simple, un snapshot differentiel tout les jour est rapide et basta. Faut pas s'embeter.
Maintenant si tu cherches a avoir > 500Go de backup c'est que tu produits des donnees a archiver et qu'il va falloir les envoyer. Typiquement je suis photographe, quand je vide une CF d'une grosse journee c'est 8,16,32Go a envoyer soit… 3+ jours et pendant ce temps la, la connexion est foireuse. Bref bien reflechir en fonction de son usage… C'est cool d'avoir 4To dans le Cloud pour 200 euros par an, mais encore faut il pouvoir s'en servir et que ca reponde a son besoin de backup.
Posté par ckyl .
En réponse au journal Backups pas dans le cloud.
Évalué à 5.
Dernière modification le 07 octobre 2013 à 23:52.
Deux petites remarques.
L’intérêt du RAID-1 dans ce genre de cas est souvent limité. A prix similaire tu es souvent gagnant à faire deux disques indépendants, un disque chaud et un disque froid dans une armoire par exemple. Le RAID-1 ça coûte cher pour ne prévenir uniquement que de la mort d'un disque et éviter l’interruption de service. Séparer les disques, ça prévient de la mort d'un disque mais aussi d'un NAS qui brûle, du contrôleur pourri, de l'erreur de manip sur le NAS, de la corruption lente mais non détectée etc. Le but c'est de minimiser le risque de perte de donnée, pas d'assurer un accès continu aux données.
Après sauf pour ceux qui ont la fibre des deux côtés il faut aussi réfléchir à la relation entre le volume de l’envoi initial et des incrément et le débit de sa connexion. Si ça met trois jours à synchroniser à chaque fois que tu vides une carte mémoire, il vaut peut être mieux bouger les disques que les données, surtout quand on part sur des disques de 4To. Si je voulais basculer chez un service en ligne pour le backup avec ma connexion ADSL il me faudrait plus d'un mois pour uploader le tout et 24h à chaque fois que je vide une carte CF et je suis loin de remplir 1To.
Ou alors, tu m'interesses à m'offrir si gracieusement l'assistance technique
En l’occurrence on parle d'un service qui a une pauvre home page, mono-page, qui link vers un compte twitter vide, dont le nom est introuvable ailleurs. Terme du contrat introuvable. Service introuvable. Archi introuvable. Je te laisse te renseigner pour trouver les infos des mecs qui y bosse et sur la société.
Si le service et la durabilité t'intéresse, c'est pas là que j'irai signer quand à côté des mecs qui n'ont plus rien a prouver signe du 99.999999+% pour moins cher (mais pas les mêmes fonctionnalités non plus).
Et si tu te balances du service mais cherche juste la durabilité. Vu l'usage de pas mal de gens de backup pour particulier " très peu de données chaudes modifiées souvent ET sensibles, potentiellement gros volume de données photo/video read-only qui grossissent petit à petit qu'on ne veut pas perdre à long terme" acheter un disque d'1To tout les 6 mois, dumper ses données et l'envoyer quelque part pour stockage coûte le même prix pour beaucoup plus de robustesse au cas ou toutes les autres copies disparaissent. On peut compléter ça par autre chose pour ce qui le nécessite.
Ça ne correspond clairement pas à tout et il existe beaucoup de cas d'utilisation. Mais il faut bien voir qu'entre rien et claquer 200€/an, il existe plein de solutions surtout quand le but est uniquement de minimiser les pertes quand toutes les copies locales meurent.
Posté par ckyl .
En réponse au journal Backups pas dans le cloud.
Évalué à 3.
Dernière modification le 07 octobre 2013 à 21:25.
Euh… Ca tourne à 2 centime le Go, c'est pas si cher que ça!
Ne coupe pas ma phrase. Sur 1To, si le service n'est rien d'autre que foutre tes données dans un RAID-6 distant et basta c'est cher pour ce que ça t'apporte par rapport à d'autres alternatives pour un particulier. En faisant du RAID 1 comme un grand dans une machine quelconque ou deux copies indépendantes avec des disques externes tu es gagnant en 6 à 12 mois ! Pour prendre un exemple concret, un NAS acheté en 2010 avec 1.5To en RAID-1 ça revient à moins de 5 euros TTC/mois et il va continuer à s'amortir. C'est sous cet angle là qu'il faut y réfléchir.
Le ratio Go/mois est peut être bon si tu es prêt d'un seuil tarifaire, mais c'est le service et son adéquation au besoin qui décide si c'est intéressant ou non. On parle de stockage et donc de coût à long terme. Ça vaut le coup d'y réfléchir à deux fois et même plus loin que centimes/Go/mois. Certains cherchant à stocker 950Go, sans autre alternative, sans besoin de durabilité et avec le goût du risque trouveront peut être l'offre intéressante. Ou ceux ayant besoin de monter très rapidement/ponctuellement en volume.
Il n'y a surtout pas d'info sur la securite des donnes. Il est marque RAID6 ca veut dire que si la machine, la baie ou le DC meurt j'ai plus de donnees ? Qualite de service ?
Non par ce que ~14 euros/mois pour 1To c'est tres cher si tu compares a deux disque dur d'1To (~60 euros piece) que tu timbrales ou que tu poses quelque part. Et ca n'offre pas plus de garantie voir moins. En 8 mois de service tu paies tes disques sauf que eux vont normalement durer quelques annees.
Il faut donc bien evaluer le besoin que l'on a:
- Avoir un backup toujours tres frais et pas de la semaine derniere ou du mois dernier ?
- Viser uniquement la resilience a long terme ?
- Variation importante de besoin de volume ? Racheter des disques plus gros c'est cher et chiant
- Etc.
Il n'y a pas de bonne reponse universelle. Mais une offre comme ca, ca me fait tres peur et j'en resterais loin sans plus d'info. C'est cher et techniquement ca semble tres leger. Contrairement a tarsnap par exemple.
Pas forcement. Le besoin est il me semble ennonce comme ca:
" Alors, je me dit que faire un second backup quelque part dans les internets ce serait pratique en cas d'incendie/chute de météorite/inondation/etc d'avoir ça ailleurs. "
Ce que tu cites c'est sa premiere approche du probleme. Rien ne dit quelle soit bonne ou la meilleure. Si il veut uniquement mettre a l'abris ses donnees pour le pire cas (la source et les backups locaux sont KO) alors un service comme glacier peut etre interessante. Tout comme peuvent l'etre deux disques dur que l'on deplace.
Savoir si c'est la meilleure approche pour lui dependra de beaucoup de criteres que l'on ne peut connaitre:
- volumetrie
- duree de retention, frequence update
- mutualisation des couts pour d'autres besoins (possible avec un VPS ou dedie mais pas avec un service specifique)
- outillage existant
- Choix personnels
Maintenant, pour faire du backup oui la comparaison de cout entre S3 et glacier est pertinante. Et tu ne peux pas un coup dire qu'il cherche absolument un dedie et l'autre dire qu'en fait la baseline de cout c'est S3…
Non bon calcul. Ce qu'il semble vouloir c'est quelque chose comme glacier. On s'en balance que tarsnap utilise S3 ou des pigeons et des disquettes. Si je peux avoir quelque chose qui fait juste ce que je veux et qui est 10x moins cher, alors c'est ma baseline. Pas l'autre service.
Si tu n'as pas de volume alors le prix tu t'en balances, ca ne sera jamais cher. Si tu as un peu de volume, un facteur 30 ca passe tout de suite de "pas grand chose" à "grand chose". D'ailleurs souvent un (des) bon vieux disque qu'on balade permettra de belles économies contre une petite fenetre de vulnerabilité au pire cas (toutes les autres copies ont été détruites) qui est très souvent très acceptable. Sans parler du temps de restauration qui peut être extrement long sans fibre quand on à >500Go à restaurer.
Le problème c'est que tu racontes n'importe quoi. 40k€ enfin 35K€ c'est la scolarité entière… La vérité c'est ~10K€ par an (moins stage et césure). Gratos ou -50% si t'es boursier.
Bon bref, je m'arrête là, mais tout ça pour vous dire, que quand on vous dit d'aller vite et qu'il faut que ça sorte, battez vous pour obtenir du rabe si vous êtes limite et au pire, un délai après la sortie pour bien ré-architecturer et bien documenter ce que vous avez dégueulé en une demi journée.
Pas totalement d'accord sur l'approche de gratter du temps. Pour un projet il existe quatre variable d'ajustement: l'ensemble de fonctionnalités, la date de sortie, la vélocité, la qualité.
En général un produit est créé pour répondre à un besoin et il est totalement stupide d'utiliser la qualité comme variable d'ajustement. C'est assez facile à expliquer dans tout contexte qui n'est pas borné au court terme (coût du support, vélocité après quelque années, perte de clients, évolutions). Bref si on arrive pas à faire immédiatement oublier cette variable, il faut soit se remettre en question, soit partir direct. Attention on ne parle pas de faire quelque chose de parfait, mais quelque chose de viable dans le temps. Sortir un produit qui marche et qu'on pourra maintenir.
La vélocité étant assez difficile à maîtriser et à faire évoluer. C'est un objectif à long terme mais certainement pas une variable pour un produit. On cherche à la maximiser, et on l'ajuste pour la vision à long terme mais on ne s'en sert pas pour du court terme.
Il reste donc deux variables possibles et cohérentes: la date mais surtout les fonctionnalités.
Bien souvent il est plus facile et raisonnable de négocier les fonctionnalités qu'une date. On peut facilement expliquer ce qui coûte, pourquoi, comment on pourrait faire moins cher et laisser les gens choisir. On maintient la qualité constante, et on fait au mieux pour une date fixe. On pourra toujours compléter en gardant la même vitesse. Réussir à calculer une date pour une large ensemble de fonctionnalités contractuelle est beaucoup beaucoup plus difficile et plus mauvais pour le produit: obligé d'utiliser la qualité comme variable, ou prévoir des marges énormes. Mais dans ce cas, ça coûte très cher pour rien…
Il existe des cas ou ce n'est pas possible et où on va devoir fixer les fonctionnalités: Première livraison du sous ensemble de fonctionnalité minimum par exemple, contrat pourri etc. De mon expérience, c'est souvent douloureux pour toutes les parties. Ça marche vachement moins bien que l'autre sens.
Bref impliquer toutes les parties concernés par le produit pour construire l'histoire au mieux avec eux pour un coût donné me semble souvent une meilleure idée que de jouer à perpétuellement gratter du temps et donc utiliser le coût comme variable d'ajustement. Ceux qui payent ont une raison de le faire et ne sont généralement pas stupides. Si ils sont content de ce qui est livré, ils remettront du pognon pour ce qui est à rajouter. Il vaut souvent mieux livrer une ou deux fonctionnalité tout les mois, que toutes dans 2 ans (ou 4, ou 6 mois, ou 3 mois mais ca marche pas…).
En tout cas nulle part sur le site de free je n'ai pu lire cette restriction idiote.
Elle est pas forcément idiote pour dimensionner les différents serveurs. En forçant à utiliser les serveurs SQL ils s'assurent que les fronts ne font pas d'IO dès que c'est dans le cache et peuvent donc alléger la facture.
Après Free c'est un service de merde à la Free, rien de nouveau depuis 10 ans pourquoi s'en surprendre maintenant ? Et j'arriverais jamais à comprendre les gens qui disent avoir des exigences mais choisissent ce genre de truc plutôt que de dépenser une à trois pizza par an pour avoir quelque chose de carré, pro et correct. Le discours me semble un peu contradictoire.
Les thesards sont a peine plus que le smic ce qui fait qu'ils sont imposables et ce qui fait que a la fin du mois ils ont moins qu'un smic (les 1450 euros/ mois sont eux aussi brut).
Heu tu paies des impôts sur la tranche qui dépasse… Tu peux m'expliquer comment tu peux gagner moins ?
Au passage il me semble que depuis un certain nombre d'années tu es imposable au smic (~150€). De toute façon je vois pas pourquoi on parle de thésards. C'est un pourcentage ridicule du marché, tu choisis volontairement d'y aller, et pour coller à la discussion niveau matos les labos sont souvent très loin devant l'industrie et correctement doté.
parce qu'elle est 24 fois plus puissante que nos desktop pourquoi (bon pas pour les accès disques)
Ca fait rêver la où tu bosses ! Si ton desktop est 24 fois moins puissant alors tu as une config moisie d'il y a 10 ans…
Maintenant vu la config, j'ai un gros doute que ca soit une solution efficace:
RAM pourrie par utilisateur. Sur un serveur de travail/compile les utilisateurs passent leur temps à pourrir le cache VFS, ca implique plus d'IO et des perfs un ordre de grandeur plus lent qu'une station avec 50-100€ de RAM.
Les IO sont partagés et je pense pas que t'ais investi dans de l'IO fusion pour compenser. Du coup bin quand tu as X utilisateurs c'est juste ~X fois plus lent qu'un desktop. T'as intêret que les IO de chaque utilisateur soient vachement séquentielles.
Le CPU permet de gérer un poil plus les pics si encore une fois les demandes sont très séquentielles. Mais si c'est pour faire du time-sharing c'est pas le pérou non plus.
Quand tu vois l'investissement ridicule que représente un poste de travail de dev par rapport à de nombreux métiers et à l'écart de productivité que ca représente, ca vaut le coup de réfléchir à deux fois. 16Go de RAM ca ne coute même pas 1/2 journée d'un gars. Si il attend 10min de moins chaque jour, c'est rentabilisé en deux semaines. En vrai, si ton desktop est inadapté c'est plutot 30mn à 1h par jour que tu perds, sans parler de ce qui n'est tout simplement pas possible et qui baisse la qualité (bonjour VM de test, tests dans divers env, bidouillage de déploiement etc.)
Bref ca peut être un bon choix dans certain cas. Mais ce que tu présentes, me semble juste un gros setup complétement dépassé; ce qui n'est pas un problème et peut repondre a votre besoin mais il faut juste être honnete. A ~20% prêt c'est mon poste de travail sauf que tu le partages en 10. Le cout de ce dit poste de travail est grosso modo entre 0.25% et 1% du coût chargé sur 3 ans, pour être très très très large.
Je compatis avec tous ceux qui se retrouvent bloqués (c'es le moment de faire jouer le time tracking en sa faveur…) mais ce genre d'approche à gratter 1€ pour en perdre 5 reste une decision stupide.
Je m'en sert tous les jours pour me connecter sur une grosse machine (24 coeurs, 25Go ram), c'est là qu'on compile et exécute le projet, on est généralement entre 5 et 10 personnes connectés dessus
Tain nous en 2013 on appele ca une workstation ;)
C'est quoi l'intêret de foutre 10 gus sur une machine maxi 3 à 4x plus puissance qu'un desktop ?
Nous avons des volumes relativement conséquents (5-10 Go) de données à charger/mettre à jour tous les mois et nous devons pouvoir y accéder ensuite rapidement en lecture.
5 à 10 Go par mois conséquent en 2013 ?
J'ai envie de dire que n'importe quoi de sérieux fait l'affaire. Tu ne verras pas de différence entre un truc ou l'autre par ce que tu es très très loin des limites quelque soit la technos. Après c'est en cache ou c'est pas en cache, mais ça dépend du hard.
La différence fonctionnelle ou de perf devient notable quand un RDBMS sur une grosse machine ne peut pas suivre en volume, en lecture, en écriture ou pour des besoins spécifique. Là ca commence être intéressant de réfléchir à ses besoins et aux choix qu'on va faire pour que ca réponde à nos besoins en terme de perfs / facilité de dev / maintenance. On peut choisir autre chose qu'un RDBMS avant si c'est plus pratique, mais c'est généralement moins mur et moins de compétences dispo, donc sauf besoin précis pas forcément un bon choix.
[^] # Re: Encore un standard que personne utilisera
Posté par ckyl . En réponse au journal JSON : Data Interchange Format not found.... Évalué à 5.
Plutot que de la psychologie, fais plutot ton boulot en lisant le standard qui ne fait même pas 5 pages. Si a aucun moment la grammaire ne parle de commentaire c'est qu'il y en a pas… Comment veux tu écrire quelque chose qui n'est pas spécifié ? On va pas s'amuser à spécifier tout ce qui n'existe pas.
[^] # Re: dev français ?
Posté par ckyl . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 4. Dernière modification le 14 octobre 2013 à 12:40.
Implémenter Comparator et appeler une méthode ? Bin putain c' est pas de la rocket science hein faudrait se poser quelques questions…
[^] # Re: Et go ?
Posté par ckyl . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 4.
Tu as tout à fait raison.
Juste pour que ce soit dit, souvent quand le GC fait chier en Java, on l'évite tout simplement en sortant de la heap pour les structures de données ou ca fait un sens. C'est dégueux mais ca fait la moitié du job (l'autre moitié étant le garbage à courte vie créé un peu partout qui reste en young generation et qui rend les perfs en low latency dégueux même en faisant gaffe…).
L'approche de Rust est meilleure il n'y a pas photo. Si tu peux garder la facilité d'un GC et son adéquation avec des programmes parallèles, tout en réduisant de quelques centaines de MB/s ce que tu balances inutillement dans la face du GC c'est top.
[^] # Re: Systemd pardi !
Posté par ckyl . En réponse au journal Ayé (plus) : Adblock Plus n'est plus installé par défaut dans Debian. Évalué à 3.
Clair !
En fait il a raison le monsieur, même les gros trolls pourris sur systemd ne marchent plus. Triste époque…
# Systemd pardi !
Posté par ckyl . En réponse au journal Ayé (plus) : Adblock Plus n'est plus installé par défaut dans Debian. Évalué à 3.
T'inquiète pas pour ca.
Je pense que c'est un bon départ ;)
[^] # Re: Libre
Posté par ckyl . En réponse au journal MailPile, le prochain diaspora? Ou pas…. Évalué à 7.
Ca dépend. Sur un petit projet oui. Sur un gros projet distribué où ca va faire des conflits pour 100 dev et péter tout les patchs soumis et en attente il faut vraiment vraiment que ca vaille le coup…
Si le code initial n'était pas lisible alors c'est qu'il y a un problème quelque part dans le process. Si il était lisible, alors est ce que le netoyage vaut le cout par rapport au bruit et a la maintenance qu'il ajoute ?
[^] # Re: Pole emploi
Posté par ckyl . En réponse au journal Droite et gauche unies pour défendre la FNAC face à Amazon. Évalué à 3.
Un mec capable de pondre des tartines d'analyses de très très haute volée comme tu veux le faire a mis 3x4 mois de chomage pour comprendre que:
C'est long, très long…
TL;DR: Pole Emploi est un non sens à la base. Ils devraient se limiter à coacher les gens qui ont besoin d'être guidé avec du simple bon sens. Le seul truc utile qu'ils auraient pu faire c'est te dire de te sortir les doigts en allant chercher les offres qui grouillent plutôt d'attendre gentilement que quelqu'un publie sur PE…
[^] # Re: travail hebdomadaire
Posté par ckyl . En réponse au journal Travail dominical. Évalué à 3.
C'est un gros script moche écrit sur un coin de table.
Évidement si tu veux créer plusieurs graphes tu vas stocker en local les données plutôt que de déglinguer le serveur à chaque fois. Après tu peux décliner les graphes de stats à l'infini c'est pas plus compliqué.
Je me suis toujours dit que si j'avais du temps à perdre un jour, je ferais une petite démo des aglos de data mining & machine learning avec les journaux :)
[^] # Re: travail hebdomadaire
Posté par ckyl . En réponse au journal Travail dominical. Évalué à 4.
Tu oserais remettre en cause la pertinence et l'exactitude de mon analyse ? Voir tu irais jusqu'à émettre l'hypothèse d'une certaine ironie dans celle-ci ? ;)
Attention hein, autrement je balance tes stats et l'analyse de haut vol qui va avec. Genre que t'es un gros trolleur du Vendredi matin avant d'aller à la cantoche ou que tu as 1h+ de trajet en sortant du taf après 18h.
[^] # Re: travail hebdomadaire
Posté par ckyl . En réponse au journal Travail dominical. Évalué à 4. Dernière modification le 08 octobre 2013 à 23:30.
Je sens que je vais décevoir beaucoup de gens mais je viens de faire rapidement ses stats en punchcard depuis le début et depuis 2013 et voila les résultats:
Je me garderais bien de faire un analyse. Enfin je pense quand même que ca confirme bien qu'il kif bosser le samedi/dimanche (puisque peu de contributions), que le soir c'est nickel pour avoir une vie sociale (puisque moins de contributions que le jour) et que la journée il en branle pas une (plus d'un commentaire par 'business hour' depuis le 1er Janvier)
Bon c'est un peu grossier hein, mais j'avais que 10 minutes…
[^] # Re: 2 nas reseaux qui se synchronisent entre eux
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 2. Dernière modification le 08 octobre 2013 à 11:48.
En meme temps si on est dans ton cas on a pas besoin de 1 ou 4To ;) Je suis parfaitement d'accord avec toi. Dans ton cas un service tel que tarsnap est parfait. Ca coute pas grand chose, c'est simple, un snapshot differentiel tout les jour est rapide et basta. Faut pas s'embeter.
Maintenant si tu cherches a avoir > 500Go de backup c'est que tu produits des donnees a archiver et qu'il va falloir les envoyer. Typiquement je suis photographe, quand je vide une CF d'une grosse journee c'est 8,16,32Go a envoyer soit… 3+ jours et pendant ce temps la, la connexion est foireuse. Bref bien reflechir en fonction de son usage… C'est cool d'avoir 4To dans le Cloud pour 200 euros par an, mais encore faut il pouvoir s'en servir et que ca reponde a son besoin de backup.
[^] # Re: 2 nas reseaux qui se synchronisent entre eux
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 5. Dernière modification le 07 octobre 2013 à 23:52.
Deux petites remarques.
L’intérêt du RAID-1 dans ce genre de cas est souvent limité. A prix similaire tu es souvent gagnant à faire deux disques indépendants, un disque chaud et un disque froid dans une armoire par exemple. Le RAID-1 ça coûte cher pour ne prévenir uniquement que de la mort d'un disque et éviter l’interruption de service. Séparer les disques, ça prévient de la mort d'un disque mais aussi d'un NAS qui brûle, du contrôleur pourri, de l'erreur de manip sur le NAS, de la corruption lente mais non détectée etc. Le but c'est de minimiser le risque de perte de donnée, pas d'assurer un accès continu aux données.
Après sauf pour ceux qui ont la fibre des deux côtés il faut aussi réfléchir à la relation entre le volume de l’envoi initial et des incrément et le débit de sa connexion. Si ça met trois jours à synchroniser à chaque fois que tu vides une carte mémoire, il vaut peut être mieux bouger les disques que les données, surtout quand on part sur des disques de 4To. Si je voulais basculer chez un service en ligne pour le backup avec ma connexion ADSL il me faudrait plus d'un mois pour uploader le tout et 24h à chaque fois que je vide une carte CF et je suis loin de remplir 1To.
[^] # Re: GreenHDD
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 4.
En l’occurrence on parle d'un service qui a une pauvre home page, mono-page, qui link vers un compte twitter vide, dont le nom est introuvable ailleurs. Terme du contrat introuvable. Service introuvable. Archi introuvable. Je te laisse te renseigner pour trouver les infos des mecs qui y bosse et sur la société.
Si le service et la durabilité t'intéresse, c'est pas là que j'irai signer quand à côté des mecs qui n'ont plus rien a prouver signe du 99.999999+% pour moins cher (mais pas les mêmes fonctionnalités non plus).
Et si tu te balances du service mais cherche juste la durabilité. Vu l'usage de pas mal de gens de backup pour particulier " très peu de données chaudes modifiées souvent ET sensibles, potentiellement gros volume de données photo/video read-only qui grossissent petit à petit qu'on ne veut pas perdre à long terme" acheter un disque d'1To tout les 6 mois, dumper ses données et l'envoyer quelque part pour stockage coûte le même prix pour beaucoup plus de robustesse au cas ou toutes les autres copies disparaissent. On peut compléter ça par autre chose pour ce qui le nécessite.
Ça ne correspond clairement pas à tout et il existe beaucoup de cas d'utilisation. Mais il faut bien voir qu'entre rien et claquer 200€/an, il existe plein de solutions surtout quand le but est uniquement de minimiser les pertes quand toutes les copies locales meurent.
[^] # Re: GreenHDD
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 3. Dernière modification le 07 octobre 2013 à 21:25.
Ne coupe pas ma phrase. Sur 1To, si le service n'est rien d'autre que foutre tes données dans un RAID-6 distant et basta c'est cher pour ce que ça t'apporte par rapport à d'autres alternatives pour un particulier. En faisant du RAID 1 comme un grand dans une machine quelconque ou deux copies indépendantes avec des disques externes tu es gagnant en 6 à 12 mois ! Pour prendre un exemple concret, un NAS acheté en 2010 avec 1.5To en RAID-1 ça revient à moins de 5 euros TTC/mois et il va continuer à s'amortir. C'est sous cet angle là qu'il faut y réfléchir.
Le ratio Go/mois est peut être bon si tu es prêt d'un seuil tarifaire, mais c'est le service et son adéquation au besoin qui décide si c'est intéressant ou non. On parle de stockage et donc de coût à long terme. Ça vaut le coup d'y réfléchir à deux fois et même plus loin que centimes/Go/mois. Certains cherchant à stocker 950Go, sans autre alternative, sans besoin de durabilité et avec le goût du risque trouveront peut être l'offre intéressante. Ou ceux ayant besoin de monter très rapidement/ponctuellement en volume.
[^] # Re: GreenHDD
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 4.
Il n'y a surtout pas d'info sur la securite des donnes. Il est marque RAID6 ca veut dire que si la machine, la baie ou le DC meurt j'ai plus de donnees ? Qualite de service ?
Non par ce que ~14 euros/mois pour 1To c'est tres cher si tu compares a deux disque dur d'1To (~60 euros piece) que tu timbrales ou que tu poses quelque part. Et ca n'offre pas plus de garantie voir moins. En 8 mois de service tu paies tes disques sauf que eux vont normalement durer quelques annees.
Il faut donc bien evaluer le besoin que l'on a:
- Avoir un backup toujours tres frais et pas de la semaine derniere ou du mois dernier ?
- Viser uniquement la resilience a long terme ?
- Variation importante de besoin de volume ? Racheter des disques plus gros c'est cher et chiant
- Etc.
Il n'y a pas de bonne reponse universelle. Mais une offre comme ca, ca me fait tres peur et j'en resterais loin sans plus d'info. C'est cher et techniquement ca semble tres leger. Contrairement a tarsnap par exemple.
[^] # Re: tarsnap
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 3.
Pas forcement. Le besoin est il me semble ennonce comme ca:
" Alors, je me dit que faire un second backup quelque part dans les internets ce serait pratique en cas d'incendie/chute de météorite/inondation/etc d'avoir ça ailleurs. "
Ce que tu cites c'est sa premiere approche du probleme. Rien ne dit quelle soit bonne ou la meilleure. Si il veut uniquement mettre a l'abris ses donnees pour le pire cas (la source et les backups locaux sont KO) alors un service comme glacier peut etre interessante. Tout comme peuvent l'etre deux disques dur que l'on deplace.
Savoir si c'est la meilleure approche pour lui dependra de beaucoup de criteres que l'on ne peut connaitre:
- volumetrie
- duree de retention, frequence update
- mutualisation des couts pour d'autres besoins (possible avec un VPS ou dedie mais pas avec un service specifique)
- outillage existant
- Choix personnels
Maintenant, pour faire du backup oui la comparaison de cout entre S3 et glacier est pertinante. Et tu ne peux pas un coup dire qu'il cherche absolument un dedie et l'autre dire qu'en fait la baseline de cout c'est S3…
[^] # Re: tarsnap
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 4.
Non bon calcul. Ce qu'il semble vouloir c'est quelque chose comme glacier. On s'en balance que tarsnap utilise S3 ou des pigeons et des disquettes. Si je peux avoir quelque chose qui fait juste ce que je veux et qui est 10x moins cher, alors c'est ma baseline. Pas l'autre service.
[^] # Re: tarsnap
Posté par ckyl . En réponse au journal Backups pas dans le cloud. Évalué à 5.
30x le prix d'Amazon tout de même.
Si tu n'as pas de volume alors le prix tu t'en balances, ca ne sera jamais cher. Si tu as un peu de volume, un facteur 30 ca passe tout de suite de "pas grand chose" à "grand chose". D'ailleurs souvent un (des) bon vieux disque qu'on balade permettra de belles économies contre une petite fenetre de vulnerabilité au pire cas (toutes les autres copies ont été détruites) qui est très souvent très acceptable. Sans parler du temps de restauration qui peut être extrement long sans fibre quand on à >500Go à restaurer.
[^] # Re: travail hebdomadaire
Posté par ckyl . En réponse au journal Travail dominical. Évalué à 7.
Le problème c'est que tu racontes n'importe quoi. 40k€ enfin 35K€ c'est la scolarité entière… La vérité c'est ~10K€ par an (moins stage et césure). Gratos ou -50% si t'es boursier.
[^] # Re: Leurre, moi je dis "non !"
Posté par ckyl . En réponse au journal Le libre libère la créativité. Évalué à 7.
Pas totalement d'accord sur l'approche de gratter du temps. Pour un projet il existe quatre variable d'ajustement: l'ensemble de fonctionnalités, la date de sortie, la vélocité, la qualité.
En général un produit est créé pour répondre à un besoin et il est totalement stupide d'utiliser la qualité comme variable d'ajustement. C'est assez facile à expliquer dans tout contexte qui n'est pas borné au court terme (coût du support, vélocité après quelque années, perte de clients, évolutions). Bref si on arrive pas à faire immédiatement oublier cette variable, il faut soit se remettre en question, soit partir direct. Attention on ne parle pas de faire quelque chose de parfait, mais quelque chose de viable dans le temps. Sortir un produit qui marche et qu'on pourra maintenir.
La vélocité étant assez difficile à maîtriser et à faire évoluer. C'est un objectif à long terme mais certainement pas une variable pour un produit. On cherche à la maximiser, et on l'ajuste pour la vision à long terme mais on ne s'en sert pas pour du court terme.
Il reste donc deux variables possibles et cohérentes: la date mais surtout les fonctionnalités.
Bien souvent il est plus facile et raisonnable de négocier les fonctionnalités qu'une date. On peut facilement expliquer ce qui coûte, pourquoi, comment on pourrait faire moins cher et laisser les gens choisir. On maintient la qualité constante, et on fait au mieux pour une date fixe. On pourra toujours compléter en gardant la même vitesse. Réussir à calculer une date pour une large ensemble de fonctionnalités contractuelle est beaucoup beaucoup plus difficile et plus mauvais pour le produit: obligé d'utiliser la qualité comme variable, ou prévoir des marges énormes. Mais dans ce cas, ça coûte très cher pour rien…
Il existe des cas ou ce n'est pas possible et où on va devoir fixer les fonctionnalités: Première livraison du sous ensemble de fonctionnalité minimum par exemple, contrat pourri etc. De mon expérience, c'est souvent douloureux pour toutes les parties. Ça marche vachement moins bien que l'autre sens.
Bref impliquer toutes les parties concernés par le produit pour construire l'histoire au mieux avec eux pour un coût donné me semble souvent une meilleure idée que de jouer à perpétuellement gratter du temps et donc utiliser le coût comme variable d'ajustement. Ceux qui payent ont une raison de le faire et ne sont généralement pas stupides. Si ils sont content de ce qui est livré, ils remettront du pognon pour ce qui est à rajouter. Il vaut souvent mieux livrer une ou deux fonctionnalité tout les mois, que toutes dans 2 ans (ou 4, ou 6 mois, ou 3 mois mais ca marche pas…).
[^] # Re: Wordpress
Posté par ckyl . En réponse au journal Sortir de google. Évalué à 3.
Elle est pas forcément idiote pour dimensionner les différents serveurs. En forçant à utiliser les serveurs SQL ils s'assurent que les fronts ne font pas d'IO dès que c'est dans le cache et peuvent donc alléger la facture.
Après Free c'est un service de merde à la Free, rien de nouveau depuis 10 ans pourquoi s'en surprendre maintenant ? Et j'arriverais jamais à comprendre les gens qui disent avoir des exigences mais choisissent ce genre de truc plutôt que de dépenser une à trois pizza par an pour avoir quelque chose de carré, pro et correct. Le discours me semble un peu contradictoire.
[^] # Re: OSEF
Posté par ckyl . En réponse au journal Le mythe de la transparence réseau. Évalué à 5.
Heu tu paies des impôts sur la tranche qui dépasse… Tu peux m'expliquer comment tu peux gagner moins ?
Au passage il me semble que depuis un certain nombre d'années tu es imposable au smic (~150€). De toute façon je vois pas pourquoi on parle de thésards. C'est un pourcentage ridicule du marché, tu choisis volontairement d'y aller, et pour coller à la discussion niveau matos les labos sont souvent très loin devant l'industrie et correctement doté.
[^] # Re: OSEF
Posté par ckyl . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.
Ca fait rêver la où tu bosses ! Si ton desktop est 24 fois moins puissant alors tu as une config moisie d'il y a 10 ans…
Maintenant vu la config, j'ai un gros doute que ca soit une solution efficace:
Quand tu vois l'investissement ridicule que représente un poste de travail de dev par rapport à de nombreux métiers et à l'écart de productivité que ca représente, ca vaut le coup de réfléchir à deux fois. 16Go de RAM ca ne coute même pas 1/2 journée d'un gars. Si il attend 10min de moins chaque jour, c'est rentabilisé en deux semaines. En vrai, si ton desktop est inadapté c'est plutot 30mn à 1h par jour que tu perds, sans parler de ce qui n'est tout simplement pas possible et qui baisse la qualité (bonjour VM de test, tests dans divers env, bidouillage de déploiement etc.)
Bref ca peut être un bon choix dans certain cas. Mais ce que tu présentes, me semble juste un gros setup complétement dépassé; ce qui n'est pas un problème et peut repondre a votre besoin mais il faut juste être honnete. A ~20% prêt c'est mon poste de travail sauf que tu le partages en 10. Le cout de ce dit poste de travail est grosso modo entre 0.25% et 1% du coût chargé sur 3 ans, pour être très très très large.
Je compatis avec tous ceux qui se retrouvent bloqués (c'es le moment de faire jouer le time tracking en sa faveur…) mais ce genre d'approche à gratter 1€ pour en perdre 5 reste une decision stupide.
[^] # Re: OSEF
Posté par ckyl . En réponse au journal Le mythe de la transparence réseau. Évalué à 1.
Tain nous en 2013 on appele ca une workstation ;)
C'est quoi l'intêret de foutre 10 gus sur une machine maxi 3 à 4x plus puissance qu'un desktop ?
[^] # Re: Couchbase
Posté par ckyl . En réponse au journal Symfony, AngularJS, ..... Évalué à 3.
5 à 10 Go par mois conséquent en 2013 ?
J'ai envie de dire que n'importe quoi de sérieux fait l'affaire. Tu ne verras pas de différence entre un truc ou l'autre par ce que tu es très très loin des limites quelque soit la technos. Après c'est en cache ou c'est pas en cache, mais ça dépend du hard.
La différence fonctionnelle ou de perf devient notable quand un RDBMS sur une grosse machine ne peut pas suivre en volume, en lecture, en écriture ou pour des besoins spécifique. Là ca commence être intéressant de réfléchir à ses besoins et aux choix qu'on va faire pour que ca réponde à nos besoins en terme de perfs / facilité de dev / maintenance. On peut choisir autre chose qu'un RDBMS avant si c'est plus pratique, mais c'est généralement moins mur et moins de compétences dispo, donc sauf besoin précis pas forcément un bon choix.