Ce qui ne t'apporte absolument rien en soit. Du code pourri avec un format, qui change tout les ans, et qui n'a pas été concu pour être (ré)utiliser, t'as rien gagné en tant qu'utilisateur. Et c'est bien là ou se situe la nuance.
Si on suit la logique bête et méchante "Format ouvert = Je pourrais toujours le relire" alors tu t'en fou de pas pouvoir forker le logiciel original. Tu as ton document dans un format ouvert alors yapluka...
Cela dit je prendrais quand même personnellement quelques pincettes. Je suis prêt a mettre quelque billets sur un truc très simple. Je sauvegarde mes XCF et mes PSD aujourd'hui et on regarde en pratique lesquels peuvent être ouvert avec le moins de pertes dans 5/10/15/20 ans. Car je pense que c'est toute la différence entre la théorie et la pratique. Supporter de vieux formats, même ouvert, est un gros travail. Porter un logiciel mort est rapidement un boulot monstrueux. Et que le format soit ouvert ou non, si il n'y a pas la masse critique d'utilisateur, ou financière, pour inciter ce travail alors il ne sera pas fait.
Ce que je dis, c’est qu’avec ma Corsa je roule à couple max, je consomme moins et je tire plus qu’une bagnole à 150 cv (pas parce que j’ai plus de puissance mais parce que, les gens ne savent pas passer les vitesses).
Non ca que tu dis c'est que tu conduis d'une certaine facon. Les voitures n'ont rien avoir là dedans.
Tu souffres donc du syndrome "Je conduis mieux que tout le monde" doublé de ce qui semble être d'une incompréhension crasse du fonctionement d'une voiture moderne essence ou diesel.
L’avantage, c’est qu’avec une Corsa de 2000, 1200 cm² de 60 cv, je laisse sur place les nouvelles BMW Série 1 :)
Arrêtes de rêver t'as déjà eu d'autres voitures ? C'est juste que les mecs n'appuies pas. Une corsa 1.2 16v 75cv ca fait dans les 13s au 0-100. Une pauvre 116d toute moisie te mets déjà 3s. Et une vraie voiture type 125i ou 123d te laisse sur place en dessous en étant < 7s.
T'es content d'avoir gratté un mec au démarrage sur un 0-60km/h. Par contre lui était mieux installé que dans ton salon (quoi que les series 1) et si tu veux vraiment jouer, à la première courbe ou à la première accélération au dessus de 50km/h si il conduit pareil tu le vois plus. Les séries 1 c'est des vrais jouets.
Pour avoir conduit de l'express & panda 1 jusqu'à des beaux joujoux, tu te fais des films. Après je suis d'accord sur route tu t'amuses beaucoup plus avec une panda qu'avec un truc qui tient le pavé ;)
Les motards ne demandent pas d'avoir un monde rempli de véhicules au rapport poids/puissance équivalent à celui d'une Porsche (d'ailleurs ma prochaine moto devrait probablement avoir au moins 20% de puissance en moins que l'actuelle) mais juste que les motos ne soient pas bridées.
On est donc d'accord. Demander le débridage, c'est demander à ce que soit homologué des motos qui pour les moins puissantes sont largement équivalentes aux bagnoles les plus hyper sport. Ce n'est pas un avis personnel pour savoir si souhaitable ou non, ni savoir c'est dangereux ou pas, c'est une constatation. Il faut appeler un chat un chat.
Pour dire le contraire il faudrait être d'une mauvaise fois absolue. Suffit de regarder regarder les specs sur le 0-100, 0-200, 80-140 ou simplement de voir en vrai. Pour avoir expérimenté RS4 contre street triple bridée à 100cv, dès que y'a de la place pour essorer la moto passe. Etrange...
En dessous de 100ch ca sert a rien de discuter t'es pas concerné par le bridage. Ta moto traine con de 120ch (donc bridage léger) et 200 kilos elle est à 1.66kg/ch. Grosso modo c'est une Z750 quoi. Une Porsche GT2RS qui est la spec homologuée route la plus brutale et très loin d'être un modèle rependu c'est 620ch pour 1370kg soit 2.2kg/ch. Un modèle sportif rependu comme une 4S c'est 385ch pour 1555kg donc 4kg/ch.
Donc oui même l'ultra sportive de chez Porsche est assez loin de n'importe quelle brêle... Si tu rajoutes le CX, et le contact au sol ca va pas rattraper les caisseux. D'ailleurs ca correspond avec la réalité, t'as interet à ce que le motard puisse pas essorer la poignée pour le tenir.
J'en vois beaucoup, mais par contre je sais encore faire des calculs poids/puissance pour ne pas dire qu'une porsche homologuée route est comparable à n'importe quelle bécanne un peu puissante. Y'a une raison pour que seule une Hennessey Venom (1200ch pour 1200kg) se rapproche un tant soit peu des specs d'une moto...
L’enchaînement de "Je ne parle évidement pas de chercher comment on fait une boucle en D ou savoir déclarer une fonction en ksh." et ton exemple me fait largement sourire. C'est juste utiliser de l'API bête et méchante utilisant des designs ultra classiques.
Tu auras peut être, sûrement même, besoin de survoler 10/20/50 pages pour arriver à cerner le problème. Par contre garder tout ça ouvert ça ne te sert à rien. La plupart de ce que tu as lu tu l'as synthétisé, et tu pourras le retrouver très très vite au besoin. En dehors de garder une ref sur la doc et l'exemple pertinent que tu as isolé je vois pas à quoi vont te servir les 13 autres pages.
De même t'as pas besoin de te farcir tout les détails des deux approches. La vue globale suffit largement pour faire un choix raisonnable: handler VS contexte injecté ça s'arrête là. T'as perdu ton temps à te farcir tout les détails d'une solution que tu n'utiliseras pas pour pouvoir isoler les références vraiment pertinentes. La plus value de ce travail est de toute façon discutable, c'est pas en faisant 8 howto que tu feras à coup sur le bon choix. Et si tu n'as pas fait ce travail approfondi alors les 15 liens que tu laisses ouverts ont sûrement la même valeur que les 15 premiers résultats de google. Pas d’intérêt.
C'est typiquement une attitude que tu rencontres dans un contexte de spike en scrum. Il faut savoir se cadrer pour ne faire que ce qui est utile dans un contexte d'exploration/décision. Et une fois que ton spike est fini, tu passes rapidement au vrai job ou tu n'as pas besoin de surfer tout l'internet et tu te concentres sur une chose à la fois.
Je fais des choses ni plus simples ni plus compliquées que n'importe quel dev R&D qui à un peu d'XP et ne pense pas avoir inventé l'eau tiède...
Je ferais bien le parallèle entre les gens qui font 200 choses à la fois en virevoltant et les développements menés à l'arrache avec une deadline dans 6 mois et 10 features et on y va avec son couteau. Se forcer à structurer sa façon de travailler à de bonnes chances d'apporter le même gain de productivité que de mettre en place une bonne méthodologie dans une équipe.
Tu décris justement un processus itératif qui se structure très bien. Si tes 50 liens sont intéressants pour ta tache courante pourquoi les garder pour les lires plus tard ? Si tu n'as pas besoin d'une deuxième itération tu as perdu du temps à ouvrir des tabs, décider qu'elles seraient intéressantes plus tard, les retrouver puis les fermer. Si tu as besoin d'une deuxième itération ce que tu as appris lors de la première te donnera un bien meilleur point de départ que ce que tu as laissé ouvert et qui n'était pas assez intéressant pour être lu tout de suite.
Ou alors au lieu de glander en passant d'un sujet à l'autre, tu t'occupes de trouver ce que tu cherchais. Ca peut demander quelques onglets temporaires qui vont avoir un durée de vie courte par ce que soit ca contient pas ce que tu cherchais soit tu as trouvé ce dont tu avais besoin et tu peux tout fermer. Si par hasard tu tombes sur quelque chose qui demande à investiguer plus tard, tu notes le sujet dans ton inbox (ou n'importe quoi que tu utilises pour gérer ton taff) et tu passeras du temps sur ce sujet là quand tu décideras de t'y atteler, pas besoin d'avoir 50 tabs intermédiaires. Soit ca à un interet pour ta tache courante, soit c'est une tache future en soit et tu n'as pas besoin de polluer ta tache courante, soit c'est perdre du temps.
Passer son temps à virevolter d'un sujet à l'autre sans focus c'est pas efficace comme façon de travailler. Je suis pas sur de la pertinence de chercher à optimiser ce workflow.
Chercher à gagner une petite minute sur le redémarrage de Firefox quand on à 150 onglets ouverts c'est assez marrant je trouve. Organise ton travail, arrête de faire 150 trucs à la foi ou de glander sur 20 sujets et tu gagneras 10x plus de temps...
J'ai pas regardé en détail les propositions de journald et j'ai laché le draft de la 5424 depuis 2005; donc je pense pas avoir un avis très pertinent. Par contre beaucoup me semblent méconnaitre l'histoire de syslog, et m'ont l'air d'idéaliser un peu le truc (et le fait de mélanger sous le même nom API, protocole réseau et démon n'arrange rien). Le constat c'est qu'en dix ans on a à peine réussi à faire implémenter un protocole simplissime qui nettoie le bordel minimaliste existant. Donc ca ne m'étonne que moyennement que quelqu'un arrive avec ses gros sabots pour tout péter.
L'article de Gerhards Rainer cité plus haut me semble très juste. Comme lui, je préférerais que ca soit fait avec un peu de subtilité pour ne changer que ce qui est nécéssaire mais le monde syslog à peut être aussi cherché son sort en gardant la confusion sur le mot "syslog" et en restant sur quelques dizaines d'années d'historiques sans trop chercher à avancer.
Rainer Gerhards n'est pas le développeur de syslog mais de rsyslog. Mais plus important qu'être le dev d'un des démon syslog; c'est surtout l'auteur des RFC 5424, 5674 et 6012. Et un des contributeurs aux RFC 5425 et 5426. Bref il a passé beaucoup de temps à essayer de sortir un peu syslog de la vase dans laquelle il baignait. Sachant qu'il a fallut plus de 6 ans pour qu'un tout petit incrément comme la 5424 soit publié (et AFAIK pas encore implémenté partout), faut être armé de patience...
J'ai rien dit sur le niveau réel du truc, vu que j'ai même pas regardé le porblème. Par contre j'ai dit que quand sur la page des résultats t'as un lien vers des offres d'emplois qui te proposent un salaire entre 25 et 30k£, t'as pas interet à faire un truc trop difficile. Autrement il se pourrait que les mecs qui le passe ne soient pas très intéressés.
En même temps d'après leur page de recrutement, vaut mieux pas qu'ils visent trop haut sur les compétences des candidats au vu des salaires proposés...
En lisant un peu sur le net et en recueillant des avis à gauche et à droite, c'est : "les logiciels libres, c'est de la merde face à Lightroom". Mmmmmh, vachement objectif (hohoho), surtout dans le milieu de la photographie.
Tu as un avis plus pertinant et constructif que ceux que tu critiques ?
Lightroom à deux énormes avantages:
- Une UI/UX penséee pour les photographes. C'est le seul logiciel à proposer toutes les fonctionalités utiles (allant du DAM à l'export), intégrées correctement et de manière souple. Même si il a quelques points faibles, il entère vraiment tout ses concurrents sur ce point. Tu peux te construire un workflow à ton gout et très efficace. Avec les autres logiciel t'es obligé de bricoler sur un point ou un autre.
- Pérénité des éditions. Adobe garde une compatibilité ascendante (le moteur de lightroom 2 est intégré dans ligthroom 3) ce qui te donne plus de chance de pouvoir reprendre tes éditions dans le future. Et lightroom occupe une telle part de marché que tu peux raisonablement penser que si Adobe se met à deconner quelqu'un proposera des solutions d'export. Avec darktable ou Bibble dans 6 mois, il te reste deja pas grand chose en compat...
Après on peut passer à la liste feature par feature mais c'est plus subjectif. Il y a de très bonnes choses dans la plupart des logiciels et lightroom est battu sur pas mal de points précis. Le problème c'est le résultat global et dans quoi tu as envie d'investir du temps.
Pour Bibble c'était une bonne alternative il y a quelques temps. Aujourd'hui, perso, je n'investirais pas de temps ni d'argent dedans. Le projet s'essouffle, ils n'arrivent jamais à shipper à temps, ca n'avance plus trop et les utilisateurs qui toléraient l'état plus digne de betas que de releases depuis des années commence à en avoir marre. Cependant ca reste pour moi la solution la plus crédible sous Linux. J'ai utilisé Bibble avec plaisir et succès pendant quelques années. En attendant en vain qu'un logiciel libre devienne convaincant.
Pour le prix, tu peux attendre une promo ou te dire que ca va d'un pauvre filtre pola à un petit flash...
Après avoir été un utilisateur fidèle de Bibble. Après avoir douter de la pérénité de Bibble à cause de la fuite des developpeurs historiques. Après avoir testé darktable. J'ai basculé sous ligthroom et réinstallé mon premier Windows depuis Windows 98...
C'est triste à dire mais avec le déclin de Bibble, il n'y à plus de solution de développement de raw convaincante sous Linux. LigthZone est mort, digikam fait tout mais pas ce qu'un photographe lui demande, darktable a de supers modules mais n'a rien compris à l'UI/UX, n'a pas de DAM et ne donne pas confiance vis à vis de la compatibilité. Rawtherapee n'en fini pas de sortir, faudra que je test la release à l'occase.
C'est donc avec tristesse que j'ai basculé sous Windows/ligthroom cet été pour enfin avoir quelque chose de convaincant tant au niveau UX, que performance, que perénité... J'attends qu'une solution prouve enfin son savoir faire sous Linux et donne suffisament confiance pour remigrer
Le boulot de clarifier un peu le merdier de syslog (le protocole) a déjà été fait il y a un peu plus de 5 ans. Le but était d'arrêter le délire des 10 implémentations existantes mais incompatibles qui donnait des trucs imparsable alors qu'il y a trois pauvres champs (cf la RFC 3164 qui dressait un état de l'art). Ca a donné la RFC 5424... qui n'a été nul part. Pourtant c'était pas ambitieux mais pratique. Au passage toutes les RFC annexes pour la secu & sont parties aussi à la poubelle. Bref ceux qui s'importe du sort de syslog ne peuvent s'en prendre qu'a eux même. C'est un bordel dégeulasse que personne n'a jamais voulu fixer.
Bin si, c'est Sytoka Modon. On pourrait presque faire un générateur de commentaire assez facile: si ce n'est pas en Perl et qu'il ne l'utilise pas personellement dans son labo qui est le centre du monde c'est nul. Mais la où ca bloquerait c'est les énormités qu'il sort à chaque fois qu'il parle d'un truc qui touche au dev...
Comme dit plus haut. Ca dépend de ce que tu veux faire... Décider qu'une archi est meilleure qu'une autre abstraitement ca me parait assez léger.
Pour de l'HPC je ne vois pas de cas ou ca pourrait se justifier effectivement. Pour des serveurs là ca se discute. Je ne dis pas que c'est toujours une bonne solution, car ce n'est pas le cas. Si c'est pour écrire un serveur HTTP qui livre du contenu statique ca semble pas la meilleure option effectivement. Par contre je dis qu'il existe des cas où une architecture comme cela fait sens.
Il y a des très gros à priori sur les perfs de ce modele alors que les bench montrent que quand c'est adapté ca marche plutot bien tant niveau perf que scalabilité (je me souviens de http://www.mailinator.com/tymaPaulMultithreaded.pdf).
Le problème du multithreadé c'est que derrière de bonnes intentions ca reste assez facile de fracasser ces perfs théoriques sur des erreurs. Il y a très peu de gens capable designer et d'implémenter quelque chose de performant de bout en bout. Et tu te retrouves effectivement à faire des bêtes thread pools, avec gavé de structure partagées, ou t'auras quand même gras de context switchs et de perte d'affinitée proc, sans pouvoir gérer les pics de charge, et tu supposes que ton résultat est plus performant et plus scalable que l'autre solution. Pas dit... Je vais pas trop détailler mais si ca t'intéresse y'a de très bons articles sur l'implémentation correcte d'un producteur/consommateur là: http://mechanical-sympathy.blogspot.com/ . Et encore une fois une telle archi ne s'adapte pas à tout les problèmes, ni tout les protocoles.
[^] # Re: Cherche successeur à Fedora 14
Posté par ckyl . En réponse au journal Vendredi \o/ Gnome-Shell forked. Évalué à 7.
En gros tu demandes une distrib avec des logiciels à jour (Gnome 3) mais avec Gnome 2 ?
[^] # Re: Vive le libre
Posté par ckyl . En réponse au journal Arte - Apple la Tyrannie du cool. Évalué à 2.
Ce qui ne t'apporte absolument rien en soit. Du code pourri avec un format, qui change tout les ans, et qui n'a pas été concu pour être (ré)utiliser, t'as rien gagné en tant qu'utilisateur. Et c'est bien là ou se situe la nuance.
[^] # Re: Vive le libre
Posté par ckyl . En réponse au journal Arte - Apple la Tyrannie du cool. Évalué à 2.
Si on suit la logique bête et méchante "Format ouvert = Je pourrais toujours le relire" alors tu t'en fou de pas pouvoir forker le logiciel original. Tu as ton document dans un format ouvert alors yapluka...
Cela dit je prendrais quand même personnellement quelques pincettes. Je suis prêt a mettre quelque billets sur un truc très simple. Je sauvegarde mes XCF et mes PSD aujourd'hui et on regarde en pratique lesquels peuvent être ouvert avec le moins de pertes dans 5/10/15/20 ans. Car je pense que c'est toute la différence entre la théorie et la pratique. Supporter de vieux formats, même ouvert, est un gros travail. Porter un logiciel mort est rapidement un boulot monstrueux. Et que le format soit ouvert ou non, si il n'y a pas la masse critique d'utilisateur, ou financière, pour inciter ce travail alors il ne sera pas fait.
[^] # Re: Troll Circuit
Posté par ckyl . En réponse au journal La nouvelle Ducati 1199 est décembre. Évalué à 3.
Non ca que tu dis c'est que tu conduis d'une certaine facon. Les voitures n'ont rien avoir là dedans.
Tu souffres donc du syndrome "Je conduis mieux que tout le monde" doublé de ce qui semble être d'une incompréhension crasse du fonctionement d'une voiture moderne essence ou diesel.
[^] # Re: Troll Circuit
Posté par ckyl . En réponse au journal La nouvelle Ducati 1199 est décembre. Évalué à 3.
Arrêtes de rêver t'as déjà eu d'autres voitures ? C'est juste que les mecs n'appuies pas. Une corsa 1.2 16v 75cv ca fait dans les 13s au 0-100. Une pauvre 116d toute moisie te mets déjà 3s. Et une vraie voiture type 125i ou 123d te laisse sur place en dessous en étant < 7s.
T'es content d'avoir gratté un mec au démarrage sur un 0-60km/h. Par contre lui était mieux installé que dans ton salon (quoi que les series 1) et si tu veux vraiment jouer, à la première courbe ou à la première accélération au dessus de 50km/h si il conduit pareil tu le vois plus. Les séries 1 c'est des vrais jouets.
Pour avoir conduit de l'express & panda 1 jusqu'à des beaux joujoux, tu te fais des films. Après je suis d'accord sur route tu t'amuses beaucoup plus avec une panda qu'avec un truc qui tient le pavé ;)
[^] # Re: Troll Circuit
Posté par ckyl . En réponse au journal La nouvelle Ducati 1199 est décembre. Évalué à 3.
Moi je repondais à ca:
On est donc d'accord. Demander le débridage, c'est demander à ce que soit homologué des motos qui pour les moins puissantes sont largement équivalentes aux bagnoles les plus hyper sport. Ce n'est pas un avis personnel pour savoir si souhaitable ou non, ni savoir c'est dangereux ou pas, c'est une constatation. Il faut appeler un chat un chat.
Pour dire le contraire il faudrait être d'une mauvaise fois absolue. Suffit de regarder regarder les specs sur le 0-100, 0-200, 80-140 ou simplement de voir en vrai. Pour avoir expérimenté RS4 contre street triple bridée à 100cv, dès que y'a de la place pour essorer la moto passe. Etrange...
[^] # Re: Troll Circuit
Posté par ckyl . En réponse au journal La nouvelle Ducati 1199 est décembre. Évalué à 2.
Justement je sais calculer...
En dessous de 100ch ca sert a rien de discuter t'es pas concerné par le bridage. Ta moto traine con de 120ch (donc bridage léger) et 200 kilos elle est à 1.66kg/ch. Grosso modo c'est une Z750 quoi. Une Porsche GT2RS qui est la spec homologuée route la plus brutale et très loin d'être un modèle rependu c'est 620ch pour 1370kg soit 2.2kg/ch. Un modèle sportif rependu comme une 4S c'est 385ch pour 1555kg donc 4kg/ch.
Donc oui même l'ultra sportive de chez Porsche est assez loin de n'importe quelle brêle... Si tu rajoutes le CX, et le contact au sol ca va pas rattraper les caisseux. D'ailleurs ca correspond avec la réalité, t'as interet à ce que le motard puisse pas essorer la poignée pour le tenir.
[^] # Re: Troll Circuit
Posté par ckyl . En réponse au journal La nouvelle Ducati 1199 est décembre. Évalué à 3.
J'en vois beaucoup, mais par contre je sais encore faire des calculs poids/puissance pour ne pas dire qu'une porsche homologuée route est comparable à n'importe quelle bécanne un peu puissante. Y'a une raison pour que seule une Hennessey Venom (1200ch pour 1200kg) se rapproche un tant soit peu des specs d'une moto...
[^] # Re: We need to talk about tabs.
Posté par ckyl . En réponse au journal Plus besoin de quitter Firefox. Évalué à 1.
L’enchaînement de "Je ne parle évidement pas de chercher comment on fait une boucle en D ou savoir déclarer une fonction en ksh." et ton exemple me fait largement sourire. C'est juste utiliser de l'API bête et méchante utilisant des designs ultra classiques.
Tu auras peut être, sûrement même, besoin de survoler 10/20/50 pages pour arriver à cerner le problème. Par contre garder tout ça ouvert ça ne te sert à rien. La plupart de ce que tu as lu tu l'as synthétisé, et tu pourras le retrouver très très vite au besoin. En dehors de garder une ref sur la doc et l'exemple pertinent que tu as isolé je vois pas à quoi vont te servir les 13 autres pages.
De même t'as pas besoin de te farcir tout les détails des deux approches. La vue globale suffit largement pour faire un choix raisonnable: handler VS contexte injecté ça s'arrête là. T'as perdu ton temps à te farcir tout les détails d'une solution que tu n'utiliseras pas pour pouvoir isoler les références vraiment pertinentes. La plus value de ce travail est de toute façon discutable, c'est pas en faisant 8 howto que tu feras à coup sur le bon choix. Et si tu n'as pas fait ce travail approfondi alors les 15 liens que tu laisses ouverts ont sûrement la même valeur que les 15 premiers résultats de google. Pas d’intérêt.
C'est typiquement une attitude que tu rencontres dans un contexte de spike en scrum. Il faut savoir se cadrer pour ne faire que ce qui est utile dans un contexte d'exploration/décision. Et une fois que ton spike est fini, tu passes rapidement au vrai job ou tu n'as pas besoin de surfer tout l'internet et tu te concentres sur une chose à la fois.
[^] # Re: We need to talk about tabs.
Posté par ckyl . En réponse au journal Plus besoin de quitter Firefox. Évalué à 1.
Je fais des choses ni plus simples ni plus compliquées que n'importe quel dev R&D qui à un peu d'XP et ne pense pas avoir inventé l'eau tiède...
Je ferais bien le parallèle entre les gens qui font 200 choses à la fois en virevoltant et les développements menés à l'arrache avec une deadline dans 6 mois et 10 features et on y va avec son couteau. Se forcer à structurer sa façon de travailler à de bonnes chances d'apporter le même gain de productivité que de mettre en place une bonne méthodologie dans une équipe.
Tu décris justement un processus itératif qui se structure très bien. Si tes 50 liens sont intéressants pour ta tache courante pourquoi les garder pour les lires plus tard ? Si tu n'as pas besoin d'une deuxième itération tu as perdu du temps à ouvrir des tabs, décider qu'elles seraient intéressantes plus tard, les retrouver puis les fermer. Si tu as besoin d'une deuxième itération ce que tu as appris lors de la première te donnera un bien meilleur point de départ que ce que tu as laissé ouvert et qui n'était pas assez intéressant pour être lu tout de suite.
[^] # Re: We need to talk about tabs.
Posté par ckyl . En réponse au journal Plus besoin de quitter Firefox. Évalué à 2.
Ou alors au lieu de glander en passant d'un sujet à l'autre, tu t'occupes de trouver ce que tu cherchais. Ca peut demander quelques onglets temporaires qui vont avoir un durée de vie courte par ce que soit ca contient pas ce que tu cherchais soit tu as trouvé ce dont tu avais besoin et tu peux tout fermer. Si par hasard tu tombes sur quelque chose qui demande à investiguer plus tard, tu notes le sujet dans ton inbox (ou n'importe quoi que tu utilises pour gérer ton taff) et tu passeras du temps sur ce sujet là quand tu décideras de t'y atteler, pas besoin d'avoir 50 tabs intermédiaires. Soit ca à un interet pour ta tache courante, soit c'est une tache future en soit et tu n'as pas besoin de polluer ta tache courante, soit c'est perdre du temps.
Passer son temps à virevolter d'un sujet à l'autre sans focus c'est pas efficace comme façon de travailler. Je suis pas sur de la pertinence de chercher à optimiser ce workflow.
# Organisation
Posté par ckyl . En réponse au journal Plus besoin de quitter Firefox. Évalué à 8.
Chercher à gagner une petite minute sur le redémarrage de Firefox quand on à 150 onglets ouverts c'est assez marrant je trouve. Organise ton travail, arrête de faire 150 trucs à la foi ou de glander sur 20 sujets et tu gagneras 10x plus de temps...
# Merci
Posté par ckyl . En réponse à la dépêche La colorimétrie sous Linux, un pas de plus. Évalué à 4.
Comme toujours quand on parle de colorimetrie sous Linux: Merci richard hughes !
Ca serait intéressant d'avoir un test qualitatif/comparatif de la sonde pour voir.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ckyl . En réponse au journal Que faut-il penser de Lennart qui casse tout ?. Évalué à 6.
J'ai pas regardé en détail les propositions de journald et j'ai laché le draft de la 5424 depuis 2005; donc je pense pas avoir un avis très pertinent. Par contre beaucoup me semblent méconnaitre l'histoire de syslog, et m'ont l'air d'idéaliser un peu le truc (et le fait de mélanger sous le même nom API, protocole réseau et démon n'arrange rien). Le constat c'est qu'en dix ans on a à peine réussi à faire implémenter un protocole simplissime qui nettoie le bordel minimaliste existant. Donc ca ne m'étonne que moyennement que quelqu'un arrive avec ses gros sabots pour tout péter.
L'article de Gerhards Rainer cité plus haut me semble très juste. Comme lui, je préférerais que ca soit fait avec un peu de subtilité pour ne changer que ce qui est nécéssaire mais le monde syslog à peut être aussi cherché son sort en gardant la confusion sur le mot "syslog" et en restant sur quelques dizaines d'années d'historiques sans trop chercher à avancer.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ckyl . En réponse au journal Que faut-il penser de Lennart qui casse tout ?. Évalué à 8.
Rainer Gerhards n'est pas le développeur de syslog mais de rsyslog. Mais plus important qu'être le dev d'un des démon syslog; c'est surtout l'auteur des RFC 5424, 5674 et 6012. Et un des contributeurs aux RFC 5425 et 5426. Bref il a passé beaucoup de temps à essayer de sortir un peu syslog de la vase dans laquelle il baignait. Sachant qu'il a fallut plus de 6 ans pour qu'un tout petit incrément comme la 5424 soit publié (et AFAIK pas encore implémenté partout), faut être armé de patience...
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ckyl . En réponse au journal Que faut-il penser de Lennart qui casse tout ?. Évalué à 3.
Donc fais mieux encore et va bosser chez RedHat...
[^] # Re: Interdire le mail ?
Posté par ckyl . En réponse au journal Athos interdit les mails en interne. Évalué à 5.
Non c'est que la solution la plus adaptée au vrai monde du travail est déployée: Notes ;)
[^] # Re: Beuh, facile !
Posté par ckyl . En réponse au journal Qui veut entrer au MI6 ?. Évalué à 2.
J'ai rien dit sur le niveau réel du truc, vu que j'ai même pas regardé le porblème. Par contre j'ai dit que quand sur la page des résultats t'as un lien vers des offres d'emplois qui te proposent un salaire entre 25 et 30k£, t'as pas interet à faire un truc trop difficile. Autrement il se pourrait que les mecs qui le passe ne soient pas très intéressés.
[^] # Re: Beuh, facile !
Posté par ckyl . En réponse au journal Qui veut entrer au MI6 ?. Évalué à 5.
En même temps d'après leur page de recrutement, vaut mieux pas qu'ils visent trop haut sur les compétences des candidats au vu des salaires proposés...
[^] # Re: du côté des rentiers / LEAP....
Posté par ckyl . En réponse au journal L'Europe est en récession.. Évalué à 4.
L'informatique pour rester dans le thème de ce site...
[^] # Re: Un workflow, mais pour quoi faire ?
Posté par ckyl . En réponse au journal Logiciels de développement des fichiers RAW sous Linux. Évalué à 5.
Tu as un avis plus pertinant et constructif que ceux que tu critiques ?
Lightroom à deux énormes avantages:
- Une UI/UX penséee pour les photographes. C'est le seul logiciel à proposer toutes les fonctionalités utiles (allant du DAM à l'export), intégrées correctement et de manière souple. Même si il a quelques points faibles, il entère vraiment tout ses concurrents sur ce point. Tu peux te construire un workflow à ton gout et très efficace. Avec les autres logiciel t'es obligé de bricoler sur un point ou un autre.
- Pérénité des éditions. Adobe garde une compatibilité ascendante (le moteur de lightroom 2 est intégré dans ligthroom 3) ce qui te donne plus de chance de pouvoir reprendre tes éditions dans le future. Et lightroom occupe une telle part de marché que tu peux raisonablement penser que si Adobe se met à deconner quelqu'un proposera des solutions d'export. Avec darktable ou Bibble dans 6 mois, il te reste deja pas grand chose en compat...
Après on peut passer à la liste feature par feature mais c'est plus subjectif. Il y a de très bonnes choses dans la plupart des logiciels et lightroom est battu sur pas mal de points précis. Le problème c'est le résultat global et dans quoi tu as envie d'investir du temps.
Pour Bibble c'était une bonne alternative il y a quelques temps. Aujourd'hui, perso, je n'investirais pas de temps ni d'argent dedans. Le projet s'essouffle, ils n'arrivent jamais à shipper à temps, ca n'avance plus trop et les utilisateurs qui toléraient l'état plus digne de betas que de releases depuis des années commence à en avoir marre. Cependant ca reste pour moi la solution la plus crédible sous Linux. J'ai utilisé Bibble avec plaisir et succès pendant quelques années. En attendant en vain qu'un logiciel libre devienne convaincant.
Pour le prix, tu peux attendre une promo ou te dire que ca va d'un pauvre filtre pola à un petit flash...
# lightroom...
Posté par ckyl . En réponse au journal Logiciels de développement des fichiers RAW sous Linux. Évalué à 8.
Après avoir été un utilisateur fidèle de Bibble. Après avoir douter de la pérénité de Bibble à cause de la fuite des developpeurs historiques. Après avoir testé darktable. J'ai basculé sous ligthroom et réinstallé mon premier Windows depuis Windows 98...
C'est triste à dire mais avec le déclin de Bibble, il n'y à plus de solution de développement de raw convaincante sous Linux. LigthZone est mort, digikam fait tout mais pas ce qu'un photographe lui demande, darktable a de supers modules mais n'a rien compris à l'UI/UX, n'a pas de DAM et ne donne pas confiance vis à vis de la compatibilité. Rawtherapee n'en fini pas de sortir, faudra que je test la release à l'occase.
C'est donc avec tristesse que j'ai basculé sous Windows/ligthroom cet été pour enfin avoir quelque chose de convaincant tant au niveau UX, que performance, que perénité... J'attends qu'une solution prouve enfin son savoir faire sous Linux et donne suffisament confiance pour remigrer
[^] # Re: Problèmes de Syslog
Posté par ckyl . En réponse au journal Lennart casse les logs!. Évalué à 6.
Le boulot de clarifier un peu le merdier de syslog (le protocole) a déjà été fait il y a un peu plus de 5 ans. Le but était d'arrêter le délire des 10 implémentations existantes mais incompatibles qui donnait des trucs imparsable alors qu'il y a trois pauvres champs (cf la RFC 3164 qui dressait un état de l'art). Ca a donné la RFC 5424... qui n'a été nul part. Pourtant c'était pas ambitieux mais pratique. Au passage toutes les RFC annexes pour la secu & sont parties aussi à la poubelle. Bref ceux qui s'importe du sort de syslog ne peuvent s'en prendre qu'a eux même. C'est un bordel dégeulasse que personne n'a jamais voulu fixer.
[^] # Re: Problèmes de Syslog
Posté par ckyl . En réponse au journal Lennart casse les logs!. Évalué à -2.
Bin si, c'est Sytoka Modon. On pourrait presque faire un générateur de commentaire assez facile: si ce n'est pas en Perl et qu'il ne l'utilise pas personellement dans son labo qui est le centre du monde c'est nul. Mais la où ca bloquerait c'est les énormités qu'il sort à chaque fois qu'il parle d'un truc qui touche au dev...
[^] # Re: En clair
Posté par ckyl . En réponse au journal Vente liée : comment se tirer soi-même une balle dans le pied. Évalué à 4.
Comme dit plus haut. Ca dépend de ce que tu veux faire... Décider qu'une archi est meilleure qu'une autre abstraitement ca me parait assez léger.
Pour de l'HPC je ne vois pas de cas ou ca pourrait se justifier effectivement. Pour des serveurs là ca se discute. Je ne dis pas que c'est toujours une bonne solution, car ce n'est pas le cas. Si c'est pour écrire un serveur HTTP qui livre du contenu statique ca semble pas la meilleure option effectivement. Par contre je dis qu'il existe des cas où une architecture comme cela fait sens.
Il y a des très gros à priori sur les perfs de ce modele alors que les bench montrent que quand c'est adapté ca marche plutot bien tant niveau perf que scalabilité (je me souviens de http://www.mailinator.com/tymaPaulMultithreaded.pdf).
Le problème du multithreadé c'est que derrière de bonnes intentions ca reste assez facile de fracasser ces perfs théoriques sur des erreurs. Il y a très peu de gens capable designer et d'implémenter quelque chose de performant de bout en bout. Et tu te retrouves effectivement à faire des bêtes thread pools, avec gavé de structure partagées, ou t'auras quand même gras de context switchs et de perte d'affinitée proc, sans pouvoir gérer les pics de charge, et tu supposes que ton résultat est plus performant et plus scalable que l'autre solution. Pas dit... Je vais pas trop détailler mais si ca t'intéresse y'a de très bons articles sur l'implémentation correcte d'un producteur/consommateur là: http://mechanical-sympathy.blogspot.com/ . Et encore une fois une telle archi ne s'adapte pas à tout les problèmes, ni tout les protocoles.