YBoy360 a écrit 674 commentaires

j'ai aussi un avis assez faiblement tranché.

Ma faible conviction est que le porno est utile à la société, comme la morale dans une certaine mesure, qui sont 2 moyens d'exister à ceux en faisant la pratique respective (les uns permettent aux autres d'exister en plus.).

J'ai été moralement et psychiquement détruit par mon travail. Et j'avais un clavier entre les mains, il n'y avait rien d'illégale. Si j'avais fait du porno, ça n'aurait sans doute pas été pire, et peut-être même bien mieux!

coreboot payload efi & Fedora) pour remplacer mon vénérable et légendaire Chromebook C720P

J'espère que tu partageras ton expérience (ou des liens, je n'avais pas eu de chance il y a quelques temps..). J'ai quelques Chromebook, j'apprécie ces machines (pas chère, minimaliste, sans prise de tête), mais je n'ai jamais remplacé ChromeOS, juste installer le conteneur Linux et Discover (qui marche mieux que ce que les autres en dise ..).

Je ne veux rien lire, voir, entendre de David Louapre. Merci de m'en préserver ici. On le voit assez (su moins mes centres d'intérêt le met en avant tout le temps), il ne m'intéresse pas. Si j'avais une fille, il serait sans doute le gendre parfait, seulement j'en ai pas, et c'est comme regarder Drucker, ça me gave.

Désolé pour lui, il est peut-être sympa et tout, populaire, mais j'arrive pas.

Non.

Si.

On va résoudre tous nos problèmes en légiférant, avec la bureaucratie si rassurante, conjointement associé. Vive les impôts, vive les bien-pensant vertueux choisissant pour nous ce qui est bon. Une égalité forcée, ou le gouvernement, généreux, prendra l'argent des uns pour en faire don aux autres.

Je ne sais pas laquelle de ces 2 approches est la plus juste ou souhaitable. L'argent des uns ne sert pas uniquement à prendre de la coke dans des yachts. J'aimerai être libre, de ne pas favoriser le copinage systémique de notre société d'élus.

Je pense que malgré tout, ils paient des impôts sur ces dons, donc, d'après moi, ce qu'il fait est totalement hors de tous reproches.

Je pense que les débuts ont été bâclés, pas forcement à cause de Mir, mais parce qu'ils étaient peu nombreux, et surtout que leur énergie était focalisée sur la partie 'input'.

Tu leur reproches de ne pas avoir les moyens de leurs ambitions, je suis d'accord, sans doute, mais personne n'a les moyens pour ce genre d'évolution… Devoir prendre le temps pour convaincre : les pro Mir, les pro X, les utilisateurs qui rouspètent, les dev qui rouspètent aussi.. tout est justifié, tout doit être écouté. On savait que ça prendrait du temps.

Je pense que c'est une très bonne chose, pour l'avenir, mais un avenir plus actuel, aujourd'hui.

On a jamais été aussi proche de la ligne d'arrivée

comme disent les grands coureurs sportifs pendant l'épreuve (enfin, moi, en tout cas)..

Solr permet de contrôler la manière dont est créé l'index, et de traiter la requête de la même façon. On peut le faire en Postgres, il n'est pas nécessaire d'utiliser unaccent, il suffit d'ajouter une colonne et de mettre une copie sans accents, c'est d'ailleurs ce qui est pratiqué avec Solr. Pour cet usage précis, Solr permet de créer automatiquement les copies (tu pourrais aussi le faire avec une procédure stockée à Postgres… Bref, c'est juste pas pratique).

Finalement, on pourrait aussi tout faire en C (ou en C++ ou en Rust.. mais pas en Python, pitié, ni en JS/TypeScript…) … Avec des indexes aux petits oignons, en fonction du type de chaîne de caractères (référence produit, argot, adresse postale, adresse mail), c'est juste que Solr a pensé a tous les cas d'usage, et que c'est pas trop long a maîtriser, comme l’auto-complétion et le faceting.

Un exemple de configuration pour comprendre la manière dont sont traitées les chaînes de caractères avec Solr pour les textes anglais :

  <fieldType name="text_en" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
      <tokenizer class="solr.StandardTokenizerFactory"/>
      <filter class="solr.StopFilterFactory" words="lang/stopwords_en.txt" ignoreCase="true"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EnglishPossessiveFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
    </analyzer>
    <analyzer type="query">
      <tokenizer class="solr.StandardTokenizerFactory"/>
      <filter class="solr.SynonymGraphFilterFactory" expand="true" ignoreCase="true" synonyms="synonyms.txt"/>
      <filter class="solr.StopFilterFactory" words="lang/stopwords_en.txt" ignoreCase="true"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EnglishPossessiveFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
    </analyzer>
  </fieldType>

On voit la partie index et query, ça fait bien plus que unaccent, juste pour ce cas simple.

P.S.: J'ai lu plus bas qu'ElasticSearch n'était pas OpenSource, je n'utilise que Solr sur nos instances (voir le site de taack.org et taper JDBC par exemple dans le moteur de recherche..).

Dans les beaucoup, il y a le faceting aussi.. à lui seul, ça justifie l'usage de solr.

Car solr et elastic search permettent d'ordonner précisément les résultats, peuvent fonctionner très simplement sur des clusters (pas de relations), de faire de la recherche approximative (par exemple sans accents, avec des fautes), permet d'optimiser la recherche lorsqu'il y a plusieurs termes, et encore beaucoup, beaucoup, beaucoup d'autres choses.

Le truc chiant de se baser sur l'année calendaire, c'est que ça ne fonctionne pas forcément sur toutes les planètes de la même manière.. Je comprends ta réticence du coup.

Pour ceux ne pouvant voir la vidéo, je vais expliquer le point qui m'a interpellé : le formatage des disquettes 5 pouces 1/4 dépendait du lecteur de disquette… Les disquettes sont physiquement identiques, mais l'OS les formatait différemment pour gagné un peu performance en fonction du lecteur..

Le contrôleur de disquette étant intégré à la machine, et non au lecteur, c'est totalement délirant car il n'influence pas le temps de lecture. Il aurait fallu certifier les lecteurs et imposer un formatage unique.

Comme quoi, parfois, c’était pas top avant ! (mais c’était comme même mieux !!)

Regarder à partir de la minute 27, je n'aurai jamais cru cela possible.. cette machine est hallucinante au passage.

Oui, mais alors si ça se répète, c'est itératif, et non récursif..

C'est paradoxal !

David Louapre, j'ai vraiment beaucoup de mal avec lui…

Perso, j'en ai entendu parlé en 1992, sérieusement, lors d'une discussion avec une amie voulant travailler dans l'étude du climat. Rien d'inconnu effectivement.

Ce qui est choquant, c'est que 99 % de ceux qui en parle n'ont jamais fait de physique statistique, aucun ne sais ce qu'est l'effet de serre, personne ne fait de corrélation avec l'activité solaire (à ma connaissance).

Les scientifiques fonctionnent par silo, et je ne conteste pas le réchauffement climatique, juste les compétences des portes paroles.

C'est une vraie brute. Si il cherche un taff..

Mince, je voulais répondre au thread "Mouai", Ooops.

Normalement, si on réécrit, c'est que les techno permettent de gagner un temps important en dev, et en sûreté. On peut aussi le faire pour des raisons de gestion de dépendance.

Je suis persuadé que les techniques très récentes sont réellement inefficaces par rapport aux anciennes techniques, en terme de temps de dev. Les React, Angular, et autres, très à la mode, les IDE comme à la mode sont des régressions.

C'est très beau techniquement de faire du MVVC, mais c'est jeter l'argent par les fenêtres, et bousiller la vie de millions de dev pour rien. Je trouve cela dramatique, car tous est orienté pour subdiviser, spécialiser, augmenter les coûts et les barrières, mais sans raisons, au contraire, en augmentant la complexité, et la possibilité de résoudre des problèmes autrefois simple, proprement.

La seule chose qui compte, c'est l'UI, le thème.. En aucun cas le coût de dév. On veut utiliser du JS partout, c'est juste la pire chose à faire. Continuons, j'ai envie de dire : Merci Mozilla.. Tant pis pour le moinssage.

Excuse-moi pour le ton. Je dois travailler la forme de mes propos.

Je suis tout à fait d'accord: mort aux packages Java de 2000 lignes qui ne font que retranscrire un modèle de données, et aux ORM!

Pfff tu peux expliquer ?

Perso, j'utilise GORM (Grails ORM) depuis 10 bonnes années, et oui, j'ai fait 12 ans de SQL avant, sans compter beaucoup, beaucoup de code natif, d'optimisation CPU bien au delà de ce que la littérature d'aujourd'hui pourrait apporter, de l'optimisation GPU, je me suis occupé d'Heisenbug de compilateur pendant plusieurs années de ma vie, à une époque ou je n'avais pas d'accès internet à mon bureau …

Bref, j'en apprends tous les jours malgré tout, mais j'en ai ma claque des gars qui critiquent systématiquement ce qui vient de Java, sans aucun argument, qui prouvent surtout leur incompétence et leur susceptibilité, proposant des solutions qui refont la même chose systématiquement moins bien.

Ce n'est pas le cas de SQLPage, mais les ORM, n'ont rien à voir avec le sujet…

Les icônes sont des tâches, tellement plus malin…

Faudrait le même pour la fusion froide, même si ça semble un peu passé de mode.. C'était le bon temps.

Si il le dit … C'est vrai, un stagiaire de 16 ans, rien de mieux.

Et les autres PC ? S'en sortent t-ils mieux ?

Je ne trouve pas ce journal HS, au contraire. Il s'agit d'analyse numérique. Ce n'est plus traité, ni auprès des ingénieurs, ni auprès des universitaires.

Un normalien en méca aujourd'hui fera du Catia, mais plus d'analyse numérique.

Le 64-bit est coûteux en mémoire, et sur arm, moins de gains que sur du x86…

Si les consultant sont réellement incompétents par rapport à des personnes connaissant un métier au préalable, ils ne peuvent pas être autre chose… Même en étant très très brillant.

L'intérêt de faire appel à eux, c'est d'avoir un regard externe. Pas forcément juste, mais un regard qui peut apporter des idées et remettre en cause certains acquis.