Mon commentaire se place dans le contexte de la discussion, qui est des gens qui se plaignent qu'on ne les paie pas à leur juste valeur par ce qu'ils ne savent pas se vendre (mais qui ne veulent pas être payé plus non plus par soucis d'honnêteté intellectuelle…).
Donc ca suppose que:
- Ils sont informaticiens
- Ils sont effectivement bons
Sortir mon commentaire de son contexte n'a pas de sens. Si tu gardes le contexte ma réponse est très cohérente.
Justifier que tu te sens mal à l'aise de négocier ton salaire par ce qu'un ouvrier sur un chaîne de montage gagne 5x moins c'est risible. Au pire si tu penses être trop payé, négocie ton salaire et donnes le à une asso plutôt que de le laisser aux actionnaires. On ne sauve pas le monde avec le couplet "Je ne travail pas pour l'argent" bien au contraire.
Dire que certains métiers gagnent trop, c'est enfoncer des portes ouvertes. Ma remarque n'est pas si conne qu'elle en à l'air. Quand le ratio facilité / paie est trop déséquilibrés beaucoup de gens s'y engagent et à moyen terme ça se régule. Regarde l'informatique depuis 15 ans. Il existe bien sur des exceptions. Mais au final quelle solution ? Je doute qu'on puisse juger objectivement de la valeur d'un travail et qu'on puisse l'encadrer. Suffit de voir les discussions sur la pénibilité du travail ou en fait chaque branche essaie de sauver son cul.
Avoir des bouchers non ce n'est pas normal. Maintenant dans notre domaine on a le luxe de choisir. Si tu ne trouves pas ça normal pourquoi tu signes chez eux ? Tu sais exactement pourquoi tu signes et comment ça fonctionne quand tu donnes ton accord. Il faut assumer les choix qu'on fait à un moment. Si tu veux être payer en fonction du contrat avec le client faut faire freelance.
Effectivement y'a des branches entières ou tu n'as plus le choix. Alors permets moi au moins de rappeler la réalité de notre métier. On a le choix, alors les assumer ca ne fait pas de mal.
Tu oublies que ça peut aussi être du à une profonde honnêteté intellectuelle et qu'il peut être difficile de réclamer plus de 5 fois le smic
J'ai du mal à suivre l'argument là. Le problème c'était pas que le méchant patron essayait de t'entuber à la négociation ? Et maintenant tu n'oses pas négocier ton salaire par profonde honnêteté intellectuelle mais si le mec te l'offre ça te pose pas de soucis ?
Ou alors parce que tu discutes avec quelqu'un qui touche deux fois ton salaire juste parce qu'il a un carnet d'adresse, et qu'un plus il vends des trucs complétement délirant te forçant à faire un paquet d'heure sup
C'est un autre problème qui n'a rien a voir. Y'a des métiers qui payent plus ou moins; tu peux pas comparer des choux avec des carottes. Maintenant si l'herbe est beaucoup plus verte ailleurs, tu peux aller la brouter. Mais je vois pas le rapport avec la discussion.
il vends des trucs complètement délirant te forçant à faire un paquet d'heure sup. à l’œil
Arrêtes de bosser pour des bouchers. Au passage tu as un contrat, tu es juste tenu de faire tes heures. Tes deux seules variables d'ajustement sont donc:
- Livrer de la merde qui marche pas
- Faire du boulot correct. Donc refuser le travail qui ne peut pas être fait
Et savoir faire ça, ca fait justement parti du boulot d'ingé.
Ou alors parce que le montant du contrat passé avec le client t'est complètement inconnu et que tu n'as aucune idée du coût facturé.
La encore je vois pas le rapport. Ce n'est pas ton problème, le seul truc qui t'intéresse c'est ce qui va dans ta poche. Une SSII c'est fait pour faire du fric sur ton dos. Si t'es pas d'accord avec ca, ne bosse pas pour une SSII.
La différence c'est surtout que l'un t'embauche pour résoudre ses problèmes et que l'autre t'embauche pour te revendre à différent clients. Du coup en SSII j'ai jamais vu un entretient technique potable, tout se fait au pipo les mecs que tu as en face de toi ne comprennent rien. Chez les éditeurs qui cherchent des mecs compétents c'est pas vraiment la même, et c'est même l'excès inverse: on te juge sur ce que tu sais faire en entretient à un instant T en se foutant de ce que tu as pu faire les 10 dernières années ou de ce que tu peux raconter.
Du coup ca m'étonne un peu de voir des gens se plaindre du côté pipo, alors qu'ils vont bosser dans un endroit où le pipo est roi…
Et donc t'attends qu'on te prenne par la main et te disant: tiens tu vaux ca ? Désolé mais le prix que tu vaux ça n'existe pas. Et même avec une fourchette, si t'es si mauvais que ça, tu te retrouverais systématiquement en bas de la fourchette voir en dessous. Cf. la technique des SSII qui t'annoncent un prix, puis qui font rentrer tout et n'importe quoi dedans, puis qui retirent 1/2K par point qu'il te manque par rapport à l'annonce qui en comporte 50. T'avais une fourchette n'empêche que tu t'es fait baiser…
C'est une compétence qui s'acquière comme toutes les autres. Tu dois pouvoir trouver une SSII par jour pour te faire la main. Et si tu penses que quelqu'un est prêt à t'offrir plus, suffit de chercher un nouveau poste.
En fait c'est plus le salaire mini que la fourchette qui est intéressante.
Pour avoir une compétence il faut payer un prix minimum, et ce prix t'indique si il cherche un prix, un mec qui à un minimum de compétence, ou un bon. À partir de là, c'est effectivement de la négo et tu sais si ca vaut le coup d'aller se vendre ou pas. Le problème est souvent d'identifier les annonces correspondant aux deux premières catégories. La troisième est plus facile à repérer.
Posté par ckyl .
En réponse au journal Go 1.
Évalué à 8.
Je te suis complètement la dessus. Je mets toujours les parenthèses même quand elles pourraient être absentes. Du code c'est fait pour être lu et pour être facile à débugger. C'est tellement plus rapide de comprendre une ligne quand le découpage est déjà fait, et ça évite les bugs cons en forçant le développeur à expliciter ce qu'il a en tête.
Bref c'est pas par ce qu'on peut s'en passer qu'il faut s'en passer. Du coup les règles de précédence on s'en tape un peu non ?
Oui enfin d'un côté t'as un binaire ou une fois qu'il est publié tu peux plus faire grand chose. Il suffit qu'un mec le crack (et il sera forcément cracké) c'est free food pour tout le monde jusqu'à la fin des temps.
De l'autre un service que tu gères, que tu peux monitorer et modifier à ta guise quand tu veux. Détecter les comptes aux comportements anormaux, je crois que c'est pas vraiment la fouille de données la plus difficile à faire. Et même si 5 ou 10% de tes utilisateurs passaient entre les mailles, le reste assure tes revenus. Tu ne pourras jamais arriver dans la situation du binaire qui correspondrait au fait que tu ais UN compte payant.
Sisi ca se fait malheureusement encore les boites pilotés. Par exemple le sensodrive chez Citroen sur les C2/C3. C'est lent, ça fait parfois nawak et ça pète rapidement, bref j'aurais honte de vendre ca…
Tu as des études chiffrées en condition réelle pour la consommation ?
Je ne confonds pas mais quelles voitures de catégorie B ou C avec un moteur Européen offrent une BVA ? J'ai pas de nom qui me vient perso. Même les ricains mettent du robotisé sur leurs "petites" voitures, doit bien y avoir une raison…
Tu ne penses pas que ça se fasse encore les boites robotisés à double embrayage ? C'est une blague ? Les DSG de VW, les PDK de Porsche, les powershift de Ford, et la plupart des bagnoles de sports ont été retirées du catalogue ?
Le plus dur étant les acquis. Un exemple bête: les voitures automatiques sont, de nos jours, plus confortables et plus écologiques que les manuelles.
Plus écologiques ? Étant donné qu'en France les bagnoles font majoritairement de la ville et qu'une boite auto en ville ça surconsomme nettement il faudra m'expliquer comment. De même regarde les segments et la provenance des voitures vendues en France. Majoritairement des petites voitures sur lesquels il y très peu de boite auto potables. Souvent c'est des boites de merde voir le plus souvent des robotisés mal faites qui explosent dans les 100.000 bornes…
Plus confortable, quand c'est bien fait oui carrément. Mais un boite DSG c'est facturé entre 1.5 et 3K€ plus dans les 250 euros pour les palettes. Un petit frein à la diffusion non ?
Posté par ckyl .
En réponse au journal HUBIC online.
Évalué à 2.
Quand tu copies une architecture connue oui, quand tu mets en place un nouveau service non.
Bien sur que si. C'est le principe de toute méthodologie agile pour faire dans le buzzword. Livrer de petits incréments 100% fonctionnels pour avoir très tôt et de manière continue du retour des utilisateurs. Ca te permet d'évoluer très facilement et plutôt que de bourriner bêtement, en se disant qu'on verra plus tard. Au passage ce que tu livres et qui est en prod est toujours carré, fonctionnel, documenté, testé. Le plus fantastique c'est que ca coute moins cher de procéder correctement et tout le monde est gagnant.
Quand au bout de quelque mois tu compares les résultats de deux équipes dans la même boîte qui fonctionnent différemment les résultats sont édifiants.
Regarde les commentaires, 80% du thread compare le service à DropBox, alors que bon il n'y a pas vraiment de rapport entre les deux.
Je me fiche des autres threads. Par contre quand j'utilise un service je veux qu'il fournisse exactement ce qui est documenté, avec la qualité de service associé. Et ma remarque soulignait que certains sont les champions du vite fait, mal fait, jamais fixé.
Ils ont une excellente maitris des outils et des techno "cloud", notamment une bonne maitrise des outils VMWare et ils sont plutôt bien placés sur le marché quand on regarde le rapport qualité/prix.
Le rapport avec ce dont je parle ?
Faire de l'hosting c'est une autre problématique. Donc je continue d'affirmer que pour le soft et les services un certain nombres de boites Françaises sont des cowboys. Mais elles n'en ont pas l'exclusivité hein.
Posté par ckyl .
En réponse au journal HUBIC online.
Évalué à 0.
On parle de service et de dev là. Faire les choses de manière carrée, pro et lancer un service qui marche, quitte a fournir des features de façon incrémentales ca coute pas plus cher c'est même l'inverse. Faire les trucs à l'arrache n'importe comment c'est un choix, quelque soit tes moyens.
Une boite qui n'est pas capable de gérer son dev correctement, perso je lui confie ni mes données ni mon site web. Et c'est triste qu'en 2012 on en soit encore là.
J'ai déjà posté un bon lien plus haut et plus généralement tu peux lire le blog d'un des affreux crétins qui n'aime pas Unix et ne comprend rien aux logs: http://blog.gerhards.net/
Ce crétin c'est aussi le mec qui écrit les specs de syslog et écrit le démon utilisé par défaut dans Debian/Fedora/Suse.
Quand tu arrêtes d'extrapoler sur 2 fichiers d'exemple donnés sans aucun contexte et que tu te renseignes sur ce qu'ils sont en train d'essayer de faire; ca devient d'un seul coup plus clair et plus logique. C'est très rationel et ils ne cherchent pas à tout péter. Je suis un peu biaisé par ce que je connais très bien syslog et ses subtilités, mais je pense que les propos de Rainer sont accessibles à tout le monde.
Tout ce que je demande c'est d'essayer de comprendre de quoi on parle avant de donner son avis ou d'asséner que les mecs qui bossent sont de sombres crétins alors que nous on a tout compris.
Le schéma définit le champ comme étant de type xs:dateTime, qui permet justement de préciser avec la syntaxe ISO dont tu parles. Donc on peut sans problème spécifier explicitement le fuseau horaire (et j'espère qu'en pratique, ça sera le cas), et si c'est pas précisé, je pense que ça doit être l'heure locale.
C'est pas comme si les timezones manquantes étaient un problème depuis toujours dans syslog et qui avait déjà été adressé dans la RFC 5424.
Les veilles implémentations sont capables d'envoyer des message sans timezone, ce qui est une énorme connerie mais qu'il faut prendre en compte. Pour tout ce qui est nouveau la timezone doit être spécifiée on peut faire sans. Dans syslog comme partout l'heure locale ca n'existe pas et c'est toujours une connerie de ne pas mettre de timezone dans une date. Toujours.
J'ai vraiment l'impression que vous prenez les mecs qui bossent là dessus pour des lapins de 3 jours.
Je pense que la dépêche est très mal rédigée pour que 99% des commentaires soient complétement à côté de la plaque et montre l'incompréhension totale de ce qui existe et de ce qui est proposé.
On constate juste des réponses basées sur le fantasme impliqué par le mot XML, et un mépris complet des gens bossant sur ce projet. C'est d'autant plus ironique que dans ces gens, y'en a quelques uns qui ont fait les RFC syslog et les démons qui sont encensés ici même. Ils ne sont pas devenus soudainement schizophrènes et proposent des améliorations backward compatibles de ce que vous aimez tant, pas de tout exploser.
Bref un peu trop de réaction primaires à mon gout…
Ce sur quoi ils bossent est un complément de la RFC 5424. Ils essaient d'étendre ce qu'il y a autour:
- API userland
- Payload des messages plus évoluée et structurée
- Comment on stock tout ca intelligemment
La RFC 5424 c'est très cheap sur la payload mais ca marche bien comme protocole de transport. Ce qu'il manque c'est des données structurées. Alors on garde le même transport mais on standardise la payload pour y inclure des données structurées plutôt qu'une bête string. Ce qui fonctionnait marche encore, et il suffit de proposer des API alternatives pour générer une jolie payload structurée plutôt qu'une string.
Après le deuxième problème c'est comment stocker ces données. Si tu ne changes rien au stockage actuel te retrouves avec une payload json par ligne, c'est deja mieux que rien. Tu peux toujours grepper comme avant, et les outils d'analyse peuvent enfin faire des trucs moins con que regexper au petit bonheur la chance. Mais il y a surement à réfléchir pour trouver des stockages plus adaptés à l'exploitation des données structurées.
Bref ce qui est bien avec les mecs qui font; c'est qu'ils ne vivent pas dans l'idéalisme du passé et qu'ils comprennent ce qui existe. Pour les meilleurs, ils arrivent à reconnaitre les limites actuelles, et des fois ils tentent d'améliorer les choses sans tout péter. C'est le cas ici.
XPath nécessite de monter le document en mémoire par ce tu as des accesseurs qui peuvent revenir en arrière dans le document.
Maintenant si tu regardes ce que les admins font avec grep/cut/awk/sed, je pense que si tu le traduis en XPath on peut parier qu'ils ne se servirait que d'un ensemble de XPath avec des accesseurs vers les noeuds suivants uniquement. Avec un tel sous ensemble tu peux très bien ne pas monter le document en mémoire mais bosser sur un flux Sax/Stax. Tu peux aussi faire comme VTD-XML qui permet déjà d'aller chatouiller des grosses volumétries.
Le gros problème de XML, c'est le manque de bon outil spécialisés en CLI et la méconnaissance du XML et des outils associés par les personnes devant le manipuler. Et aussi d'être souvent utilisé à très mauvais escient :p
J'espère que ca marche mieux que leurs précédant outils.
Pour avoir eu à faire avec eux il y a quelque temps; leurs outils sortaient des résultats bien douteux. Encore pire ils n'ont jamais pu nous expliquer le rationnel en dehors d'un discours "C'est une analyse qualitative blahblahblah" permettant d'éviter toute réponse précise même quand on leur donnait des exemples précis d'incohérences flagrantes.
Faut pas hésiter a être agressif sur les environnements de build. Ca coute rien de vérifier sur bien plus de cibles que ce qui est supporté par la release et permet de chopper les problèmes en avance lors du dev plutôt que deux ans après quand tu changes d'environnement cible et que tout casse en même temps et que ca devient indébuggable. Au pire même si tu fixes pas tout pour certains cas spécifiques, tu as déjà identifier depuis longtemps les parties de code qui vont poser problème.
Pour ce qui est des branches. C'est l'ennemie de l'intégration continue. Il faut soit adopter des cycles de branche très court et intégrer agressivement dans le trunk (version agile, tes branches c'est 2 à 15 jours de boulot max, quand tu merges tout doit être vert). Soit avoir très peu de branches et des cycles très longs avec un build branché sur chaque branche. Le cout de QA par branche n'est pas nul, donc souvent opter pour la première version est une bonne idée.
Mais il y des solutions pour forcer en douceur les gens à faire le travail.
C'est la limite des distros et de la compilation de projet tiers en général. Tout ce qui a trait aux tests unitaires / fonctionnels / intégration n'est pas standardisé et nécessite au mieux la configuration d'environnements complexes. Ca c'est dans le meilleur des cas. Dans la vraie vie je prend le pari que plus de 60% des projets empaquetés n'ont pas la moindre suite de test valable.
Bref c'est l'usage courant dans le libre et dans les distros depuis toujours. ./configure && make install et ca devrait marcher. Tu t'es déjà posé la question de savoir si un logiciel que tu as compilé marchait correctement ? Tu penses que les maintainers font plus que regarder si ca a l'air de marcher ? Les distribs sources font-elles passer les tests ? La réponse est toujours non. Ils ne font ni mieux ni pire que tout le monde. Les utilisateurs remonteront les bug reports au besoin.
[^] # Re: Non monsieur,
Posté par ckyl . En réponse au journal Des emplois dans le libre en France et en Suisse.. Évalué à 3. Dernière modification le 04 avril 2012 à 19:48.
Mon commentaire se place dans le contexte de la discussion, qui est des gens qui se plaignent qu'on ne les paie pas à leur juste valeur par ce qu'ils ne savent pas se vendre (mais qui ne veulent pas être payé plus non plus par soucis d'honnêteté intellectuelle…).
Donc ca suppose que:
- Ils sont informaticiens
- Ils sont effectivement bons
Sortir mon commentaire de son contexte n'a pas de sens. Si tu gardes le contexte ma réponse est très cohérente.
Justifier que tu te sens mal à l'aise de négocier ton salaire par ce qu'un ouvrier sur un chaîne de montage gagne 5x moins c'est risible. Au pire si tu penses être trop payé, négocie ton salaire et donnes le à une asso plutôt que de le laisser aux actionnaires. On ne sauve pas le monde avec le couplet "Je ne travail pas pour l'argent" bien au contraire.
Dire que certains métiers gagnent trop, c'est enfoncer des portes ouvertes. Ma remarque n'est pas si conne qu'elle en à l'air. Quand le ratio facilité / paie est trop déséquilibrés beaucoup de gens s'y engagent et à moyen terme ça se régule. Regarde l'informatique depuis 15 ans. Il existe bien sur des exceptions. Mais au final quelle solution ? Je doute qu'on puisse juger objectivement de la valeur d'un travail et qu'on puisse l'encadrer. Suffit de voir les discussions sur la pénibilité du travail ou en fait chaque branche essaie de sauver son cul.
Avoir des bouchers non ce n'est pas normal. Maintenant dans notre domaine on a le luxe de choisir. Si tu ne trouves pas ça normal pourquoi tu signes chez eux ? Tu sais exactement pourquoi tu signes et comment ça fonctionne quand tu donnes ton accord. Il faut assumer les choix qu'on fait à un moment. Si tu veux être payer en fonction du contrat avec le client faut faire freelance.
Effectivement y'a des branches entières ou tu n'as plus le choix. Alors permets moi au moins de rappeler la réalité de notre métier. On a le choix, alors les assumer ca ne fait pas de mal.
[^] # Re: Non monsieur,
Posté par ckyl . En réponse au journal Des emplois dans le libre en France et en Suisse.. Évalué à 3.
J'ai du mal à suivre l'argument là. Le problème c'était pas que le méchant patron essayait de t'entuber à la négociation ? Et maintenant tu n'oses pas négocier ton salaire par profonde honnêteté intellectuelle mais si le mec te l'offre ça te pose pas de soucis ?
C'est un autre problème qui n'a rien a voir. Y'a des métiers qui payent plus ou moins; tu peux pas comparer des choux avec des carottes. Maintenant si l'herbe est beaucoup plus verte ailleurs, tu peux aller la brouter. Mais je vois pas le rapport avec la discussion.
Arrêtes de bosser pour des bouchers. Au passage tu as un contrat, tu es juste tenu de faire tes heures. Tes deux seules variables d'ajustement sont donc:
- Livrer de la merde qui marche pas
- Faire du boulot correct. Donc refuser le travail qui ne peut pas être fait
Et savoir faire ça, ca fait justement parti du boulot d'ingé.
La encore je vois pas le rapport. Ce n'est pas ton problème, le seul truc qui t'intéresse c'est ce qui va dans ta poche. Une SSII c'est fait pour faire du fric sur ton dos. Si t'es pas d'accord avec ca, ne bosse pas pour une SSII.
[^] # Re: Non monsieur,
Posté par ckyl . En réponse au journal Des emplois dans le libre en France et en Suisse.. Évalué à 3.
La différence c'est surtout que l'un t'embauche pour résoudre ses problèmes et que l'autre t'embauche pour te revendre à différent clients. Du coup en SSII j'ai jamais vu un entretient technique potable, tout se fait au pipo les mecs que tu as en face de toi ne comprennent rien. Chez les éditeurs qui cherchent des mecs compétents c'est pas vraiment la même, et c'est même l'excès inverse: on te juge sur ce que tu sais faire en entretient à un instant T en se foutant de ce que tu as pu faire les 10 dernières années ou de ce que tu peux raconter.
Du coup ca m'étonne un peu de voir des gens se plaindre du côté pipo, alors qu'ils vont bosser dans un endroit où le pipo est roi…
[^] # Re: Non monsieur,
Posté par ckyl . En réponse au journal Des emplois dans le libre en France et en Suisse.. Évalué à 2.
Et donc t'attends qu'on te prenne par la main et te disant: tiens tu vaux ca ? Désolé mais le prix que tu vaux ça n'existe pas. Et même avec une fourchette, si t'es si mauvais que ça, tu te retrouverais systématiquement en bas de la fourchette voir en dessous. Cf. la technique des SSII qui t'annoncent un prix, puis qui font rentrer tout et n'importe quoi dedans, puis qui retirent 1/2K par point qu'il te manque par rapport à l'annonce qui en comporte 50. T'avais une fourchette n'empêche que tu t'es fait baiser…
C'est une compétence qui s'acquière comme toutes les autres. Tu dois pouvoir trouver une SSII par jour pour te faire la main. Et si tu penses que quelqu'un est prêt à t'offrir plus, suffit de chercher un nouveau poste.
[^] # Re: Non monsieur,
Posté par ckyl . En réponse au journal Des emplois dans le libre en France et en Suisse.. Évalué à 8. Dernière modification le 02 avril 2012 à 12:28.
En fait c'est plus le salaire mini que la fourchette qui est intéressante.
Pour avoir une compétence il faut payer un prix minimum, et ce prix t'indique si il cherche un prix, un mec qui à un minimum de compétence, ou un bon. À partir de là, c'est effectivement de la négo et tu sais si ca vaut le coup d'aller se vendre ou pas. Le problème est souvent d'identifier les annonces correspondant aux deux premières catégories. La troisième est plus facile à repérer.
[^] # Re: Quel avenir?
Posté par ckyl . En réponse au journal Go 1. Évalué à 8.
Je te suis complètement la dessus. Je mets toujours les parenthèses même quand elles pourraient être absentes. Du code c'est fait pour être lu et pour être facile à débugger. C'est tellement plus rapide de comprendre une ligne quand le découpage est déjà fait, et ça évite les bugs cons en forçant le développeur à expliciter ce qu'il a en tête.
Bref c'est pas par ce qu'on peut s'en passer qu'il faut s'en passer. Du coup les règles de précédence on s'en tape un peu non ?
[^] # Re: hum...
Posté par ckyl . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 1.
Oui enfin d'un côté t'as un binaire ou une fois qu'il est publié tu peux plus faire grand chose. Il suffit qu'un mec le crack (et il sera forcément cracké) c'est free food pour tout le monde jusqu'à la fin des temps.
De l'autre un service que tu gères, que tu peux monitorer et modifier à ta guise quand tu veux. Détecter les comptes aux comportements anormaux, je crois que c'est pas vraiment la fouille de données la plus difficile à faire. Et même si 5 ou 10% de tes utilisateurs passaient entre les mailles, le reste assure tes revenus. Tu ne pourras jamais arriver dans la situation du binaire qui correspondrait au fait que tu ais UN compte payant.
[^] # Re: Noms des applications
Posté par ckyl . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 3.
Nos commentaires se sont croisés.
Sisi ca se fait malheureusement encore les boites pilotés. Par exemple le sensodrive chez Citroen sur les C2/C3. C'est lent, ça fait parfois nawak et ça pète rapidement, bref j'aurais honte de vendre ca…
[^] # Re: Noms des applications
Posté par ckyl . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 2.
Tu as des études chiffrées en condition réelle pour la consommation ?
Je ne confonds pas mais quelles voitures de catégorie B ou C avec un moteur Européen offrent une BVA ? J'ai pas de nom qui me vient perso. Même les ricains mettent du robotisé sur leurs "petites" voitures, doit bien y avoir une raison…
Tu ne penses pas que ça se fasse encore les boites robotisés à double embrayage ? C'est une blague ? Les DSG de VW, les PDK de Porsche, les powershift de Ford, et la plupart des bagnoles de sports ont été retirées du catalogue ?
[^] # Re: Noms des applications
Posté par ckyl . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 4.
Plus écologiques ? Étant donné qu'en France les bagnoles font majoritairement de la ville et qu'une boite auto en ville ça surconsomme nettement il faudra m'expliquer comment. De même regarde les segments et la provenance des voitures vendues en France. Majoritairement des petites voitures sur lesquels il y très peu de boite auto potables. Souvent c'est des boites de merde voir le plus souvent des robotisés mal faites qui explosent dans les 100.000 bornes…
Plus confortable, quand c'est bien fait oui carrément. Mais un boite DSG c'est facturé entre 1.5 et 3K€ plus dans les 250 euros pour les palettes. Un petit frein à la diffusion non ?
[^] # Re: Noms des applications
Posté par ckyl . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 4.
[^] # Re: C'est récurrent
Posté par ckyl . En réponse au journal Un bug de uClibc bloque le passage à l’heure d’été des box ADSL de Free et Orange. Évalué à 4.
T'es sérieux là ? Tu veux dire que Free pourrait communiquer sur un truc ou de valider les trucs qu'ils poussent ? Rassures moi t'as pas de Freebox ?
[^] # Re: Pas de parcours sur le web, pas de readme dans le tarball linux !
Posté par ckyl . En réponse au journal HUBIC online. Évalué à 2.
Bien sur que si. C'est le principe de toute méthodologie agile pour faire dans le buzzword. Livrer de petits incréments 100% fonctionnels pour avoir très tôt et de manière continue du retour des utilisateurs. Ca te permet d'évoluer très facilement et plutôt que de bourriner bêtement, en se disant qu'on verra plus tard. Au passage ce que tu livres et qui est en prod est toujours carré, fonctionnel, documenté, testé. Le plus fantastique c'est que ca coute moins cher de procéder correctement et tout le monde est gagnant.
Quand au bout de quelque mois tu compares les résultats de deux équipes dans la même boîte qui fonctionnent différemment les résultats sont édifiants.
Je me fiche des autres threads. Par contre quand j'utilise un service je veux qu'il fournisse exactement ce qui est documenté, avec la qualité de service associé. Et ma remarque soulignait que certains sont les champions du vite fait, mal fait, jamais fixé.
Le rapport avec ce dont je parle ?
Faire de l'hosting c'est une autre problématique. Donc je continue d'affirmer que pour le soft et les services un certain nombres de boites Françaises sont des cowboys. Mais elles n'en ont pas l'exclusivité hein.
[^] # Re: Pas de parcours sur le web, pas de readme dans le tarball linux !
Posté par ckyl . En réponse au journal HUBIC online. Évalué à 0.
On parle de service et de dev là. Faire les choses de manière carrée, pro et lancer un service qui marche, quitte a fournir des features de façon incrémentales ca coute pas plus cher c'est même l'inverse. Faire les trucs à l'arrache n'importe comment c'est un choix, quelque soit tes moyens.
Une boite qui n'est pas capable de gérer son dev correctement, perso je lui confie ni mes données ni mon site web. Et c'est triste qu'en 2012 on en soit encore là.
[^] # Re: Pas de parcours sur le web, pas de readme dans le tarball linux !
Posté par ckyl . En réponse au journal HUBIC online. Évalué à 7.
Mince il me semblait que c'était "on commence à l'arrache et on fera un nouveau truc à l'arrache dans quelque mois"
# Karma
Posté par ckyl . En réponse au journal Rédaction coopérative et karma. Évalué à 10.
Par ce qu'il existe au moins une personne n'a pas passé le stade de la bonne image à l'école et qui attache la moindre importance au karma ?
[^] # Re: Du XML ?
Posté par ckyl . En réponse à la dépêche Projet Lumberjack. Évalué à 4.
Je crois qu'ils sont au courant puisque William Heinbockel (CEE Technical Lead) participe à lumberjack et que CEE est utilisé comme idée de base ;)
[^] # Re: Wahou
Posté par ckyl . En réponse à la dépêche Projet Lumberjack. Évalué à 2.
J'ai déjà posté un bon lien plus haut et plus généralement tu peux lire le blog d'un des affreux crétins qui n'aime pas Unix et ne comprend rien aux logs: http://blog.gerhards.net/
Ce crétin c'est aussi le mec qui écrit les specs de syslog et écrit le démon utilisé par défaut dans Debian/Fedora/Suse.
Quand tu arrêtes d'extrapoler sur 2 fichiers d'exemple donnés sans aucun contexte et que tu te renseignes sur ce qu'ils sont en train d'essayer de faire; ca devient d'un seul coup plus clair et plus logique. C'est très rationel et ils ne cherchent pas à tout péter. Je suis un peu biaisé par ce que je connais très bien syslog et ses subtilités, mais je pense que les propos de Rainer sont accessibles à tout le monde.
Tout ce que je demande c'est d'essayer de comprendre de quoi on parle avant de donner son avis ou d'asséner que les mecs qui bossent sont de sombres crétins alors que nous on a tout compris.
[^] # Re: Intérêt ?
Posté par ckyl . En réponse à la dépêche Projet Lumberjack. Évalué à 1.
C'est pas comme si les timezones manquantes étaient un problème depuis toujours dans syslog et qui avait déjà été adressé dans la RFC 5424.
Les veilles implémentations sont capables d'envoyer des message sans timezone, ce qui est une énorme connerie mais qu'il faut prendre en compte. Pour tout ce qui est nouveau la timezone doit être spécifiée on peut faire sans. Dans syslog comme partout l'heure locale ca n'existe pas et c'est toujours une connerie de ne pas mettre de timezone dans une date. Toujours.
J'ai vraiment l'impression que vous prenez les mecs qui bossent là dessus pour des lapins de 3 jours.
# Wahou
Posté par ckyl . En réponse à la dépêche Projet Lumberjack. Évalué à 9.
Je pense que la dépêche est très mal rédigée pour que 99% des commentaires soient complétement à côté de la plaque et montre l'incompréhension totale de ce qui existe et de ce qui est proposé.
On constate juste des réponses basées sur le fantasme impliqué par le mot XML, et un mépris complet des gens bossant sur ce projet. C'est d'autant plus ironique que dans ces gens, y'en a quelques uns qui ont fait les RFC syslog et les démons qui sont encensés ici même. Ils ne sont pas devenus soudainement schizophrènes et proposent des améliorations backward compatibles de ce que vous aimez tant, pas de tout exploser.
Bref un peu trop de réaction primaires à mon gout…
[^] # Re: Du XML ?
Posté par ckyl . En réponse à la dépêche Projet Lumberjack. Évalué à 10.
http://blog.gerhards.net/2012/02/announcing-project-lumberjack.html
Ce sur quoi ils bossent est un complément de la RFC 5424. Ils essaient d'étendre ce qu'il y a autour:
- API userland
- Payload des messages plus évoluée et structurée
- Comment on stock tout ca intelligemment
La RFC 5424 c'est très cheap sur la payload mais ca marche bien comme protocole de transport. Ce qu'il manque c'est des données structurées. Alors on garde le même transport mais on standardise la payload pour y inclure des données structurées plutôt qu'une bête string. Ce qui fonctionnait marche encore, et il suffit de proposer des API alternatives pour générer une jolie payload structurée plutôt qu'une string.
Après le deuxième problème c'est comment stocker ces données. Si tu ne changes rien au stockage actuel te retrouves avec une payload json par ligne, c'est deja mieux que rien. Tu peux toujours grepper comme avant, et les outils d'analyse peuvent enfin faire des trucs moins con que regexper au petit bonheur la chance. Mais il y a surement à réfléchir pour trouver des stockages plus adaptés à l'exploitation des données structurées.
Bref ce qui est bien avec les mecs qui font; c'est qu'ils ne vivent pas dans l'idéalisme du passé et qu'ils comprennent ce qui existe. Pour les meilleurs, ils arrivent à reconnaitre les limites actuelles, et des fois ils tentent d'améliorer les choses sans tout péter. C'est le cas ici.
[^] # Re: But
Posté par ckyl . En réponse à la dépêche Projet Lumberjack. Évalué à 6.
XPath nécessite de monter le document en mémoire par ce tu as des accesseurs qui peuvent revenir en arrière dans le document.
Maintenant si tu regardes ce que les admins font avec grep/cut/awk/sed, je pense que si tu le traduis en XPath on peut parier qu'ils ne se servirait que d'un ensemble de XPath avec des accesseurs vers les noeuds suivants uniquement. Avec un tel sous ensemble tu peux très bien ne pas monter le document en mémoire mais bosser sur un flux Sax/Stax. Tu peux aussi faire comme VTD-XML qui permet déjà d'aller chatouiller des grosses volumétries.
Le gros problème de XML, c'est le manque de bon outil spécialisés en CLI et la méconnaissance du XML et des outils associés par les personnes devant le manipuler. Et aussi d'être souvent utilisé à très mauvais escient :p
# Antelink
Posté par ckyl . En réponse à la dépêche Antepedia, base de données des projets Open Source. Évalué à 4.
J'espère que ca marche mieux que leurs précédant outils.
Pour avoir eu à faire avec eux il y a quelque temps; leurs outils sortaient des résultats bien douteux. Encore pire ils n'ont jamais pu nous expliquer le rationnel en dehors d'un discours "C'est une analyse qualitative blahblahblah" permettant d'éviter toute réponse précise même quand on leur donnait des exemples précis d'incohérences flagrantes.
[^] # Re: Ca fait du bien...
Posté par ckyl . En réponse au journal Debian recompilée avec Clang/LLVM. Évalué à 2.
Faut pas hésiter a être agressif sur les environnements de build. Ca coute rien de vérifier sur bien plus de cibles que ce qui est supporté par la release et permet de chopper les problèmes en avance lors du dev plutôt que deux ans après quand tu changes d'environnement cible et que tout casse en même temps et que ca devient indébuggable. Au pire même si tu fixes pas tout pour certains cas spécifiques, tu as déjà identifier depuis longtemps les parties de code qui vont poser problème.
Pour ce qui est des branches. C'est l'ennemie de l'intégration continue. Il faut soit adopter des cycles de branche très court et intégrer agressivement dans le trunk (version agile, tes branches c'est 2 à 15 jours de boulot max, quand tu merges tout doit être vert). Soit avoir très peu de branches et des cycles très longs avec un build branché sur chaque branche. Le cout de QA par branche n'est pas nul, donc souvent opter pour la première version est une bonne idée.
Mais il y des solutions pour forcer en douceur les gens à faire le travail.
[^] # Re: compil only
Posté par ckyl . En réponse au journal Debian recompilée avec Clang/LLVM. Évalué à 3.
C'est la limite des distros et de la compilation de projet tiers en général. Tout ce qui a trait aux tests unitaires / fonctionnels / intégration n'est pas standardisé et nécessite au mieux la configuration d'environnements complexes. Ca c'est dans le meilleur des cas. Dans la vraie vie je prend le pari que plus de 60% des projets empaquetés n'ont pas la moindre suite de test valable.
Bref c'est l'usage courant dans le libre et dans les distros depuis toujours. ./configure && make install et ca devrait marcher. Tu t'es déjà posé la question de savoir si un logiciel que tu as compilé marchait correctement ? Tu penses que les maintainers font plus que regarder si ca a l'air de marcher ? Les distribs sources font-elles passer les tests ? La réponse est toujours non. Ils ne font ni mieux ni pire que tout le monde. Les utilisateurs remonteront les bug reports au besoin.