ckyl a écrit 3877 commentaires

Informatiques, licence/master. Infos vennant de MCF, et un peu croiser avec ce qu'on voit passer en sortie de cursus.

Rougir non, il me semble même que j'ai dit le contraire. Maintenant j'ai dit que ca semblait baisser sérieusement ces dernières années et préférant laisser sortir des gens qui n'ont pas le niveau plutôt que de les sortir du cursus. Après je ne prétend pas être en mesure de généraliser ni de prouver quoi que ce soit.

Cela dit, si t'ajustes avec le taux de reussite, ca revient probablement au meme, grosso modo.

Vu que les écoles d'ingé appliquent les mêmes techniques que le bac pour ne pas se tirer une balle dans le pied avec un mauvais taux de réussite tu m'étonnes qu'ils ont de meilleur taux !

C'est particulièrement flagrant quand certains courts sont partagés entre univ/ingé. D'un côté une mauvaise note c'est 10 de l'autre c'est 4 pour grosso modo le même niveau (qui ne vaut pas 10)…

Bon cela dit d'après les échos que j'ai eu le niveau des facs s'est écroulé ces dernières années avec en plus consigne de faire l'école des fans donc on va peut être arriver à la même chose au final.

Personnellement contrairement au sport national ici de tout savoir sur tout, je ne me juge pas apte à juger de si c'est légal ou non. Par contre je sais que ca passe le juridique, qui met son veto sur d'autres choses dans le même domaine qui subjectivement me semblent vachement plus aller et dans le sens du service et de l'utilisateur.

Après reste les subtilités de chaque pays.

Et surtout Virgin à déjà fourni ce fichier à 36 autres acteurs du marché quand le marketing a voulu consolider ses données…

Ca se fait juste toujours les jours. Tout le monde croise avec tout le monde, je jeux étant être celui qui reçoit les données plutôt que celui qui les offres (par ce que l'un des deux fini par faire une jointure).

Bienvenue IRL.

Donc tu ne vas et viens pas entre X et TTY. Tu utilises les TTY par ce que c'est la seule interaction avec le système à ce moment là.

Le commentaire en dessous dit utiliser les TTY pour faire les mises à jour alors qu'il continue d'utiliser tout le reste comme de rien n'était et fait des vas et viens. Là je cherche encore la logique par contre…

unset DISPLAY

Sérieusement, c'est complétement con comme argument. Si tu ne veux pas utiliser de programme graphique il suffit de ne pas en utiliser… Si l'envie est si forte que ca, de toute facon tu vas rebasculer vu que tu sembles incapable de t'asteindre à quoi que ce soit.

Dommage que tu utilise un temps condescendant comme ça mais bon.

Ce n'était pas mon intention. J'espère que depuis le temps, tu sais que si je parle de quelque chose c'est que je pense que l'échange est intéressant.

Dans ton script je ne sais pas ce que font la méthode get_fname par exemple.

Je l'ai volontairement omis. C'est une méthode qui se débrouille pour m'extraire ce dont j'ai besoin (ou rien) d'une ligne. Typiquement en shell tu ferais ca extrayant le dernier champs (awk) et tu traiterait ce champ pour virer un prefix et quelques autres règle métier pourries (plus chiant en shell ca).

C'est nettement moins concis, alors que je trouve qu'en shell avec pipe, tu as tes traitements qui sont découpés et tu lis ton algo.

Je ne considère plus la concision comme une bonne métrique, surtout pas en ce basant sur du code "facile". La facilité, lisibilité, la maintenance et la sécurité sont pour moi bien plus important.

Tu retrouves avec les pipes les mêmes problème que quand tu joues en fonctionnel sur des collections. C'est itératif à développer, c'est plaisant mais tu as vite fait de faire des trucs imbitables à postériori. Il faut être vigilant

Pour la typo sur les noms de variables c'est bizarre d'en parler et d'expliquer que python c'est mieux parce qu'en effet c'est un peu mieux, mais si tu te rate uniquement sur une écriture intermédiaire dans ta variable tu est tout aussi mal

Je ne milite absolument pas pour Python et j'aimerai laisser de côté cela, je m'en suis servi comme exemple. L'idée c'est que tu as des langages mieux designé que le shell, avec des environnements de dev beaucoup mieux fourni et évolués. Pourquoi ne pas chercher à leur permettre de faire élégamment ce que tu fais avec des scripts shell. Il y a tout a y gagner. Tu gardes les mêmes fonctionnalité en te libérant de beaucoup de contraintes.

Pour ton point précis, l'interpréteur Python sera beaucoup moins tolérant aux erreurs, et l'environnement t'apporte une plus grand sureté (IDE qui t'insulte, facilité à écrire des tests etc.). Mais comme j'ai dit, ce n'est qu'un exemple. J'aurais pu l'écrire avec autre chose, chaque choix à ses faiblesses.

la gestion des ressources (la fermeture des fichiers par exemple) est gérée de base, etc

Pour les mêmes opérations c'est la même chose. Si tu veux faire un pipe ou écrire dans un fichier, aucune raison de faire autre chose. Maintenant si je veux des set, je préfère utiliser un objet plutôt que de m'emmerder à jouer avec 4 commandes par ce qu'il n'y a pas mieux. Bref le but c'est que tu ne perde "rien" mais que tu gagnes beaucoup de choses.

Tout le travail est d'exporter des API propre dans les autres langages. Par exemple en Scala

val fname = "/tmp/uname"
"uname -a" #| "sed s/Linux/Lunix/" #> new File(fname) #&& s"cat $fname" !

Si a un endroit je pense qu'il faut mieux faire un traitement moi même plutôt que le déléguer à un outil je peux le faire très facilement. Il n'est pas question de remplacer l'un par l'autre.

1. T'as oublié le sort en sortie du ssh
2. La syntaxe c'est join -v 2 file1 file2
3. Rajoute le traitement en sortie du ssh tu vas soit te retrouver avec un pipe de 10 elements et finir par te demander ce que ca fait ou comment modulariser tout ca, soit lire stdout en bash et puis tout rebalancer dans un fichier (gestion des espaces toujours cool, pas error prone partout etc.)
4. Fais une typo dans un nom de variable ou fais une connerie type PREFIX_$var_SUFFIX et tu vas debuger pendant trois plombes ou fracasser un truc (je bosse avec des fichiers de plusieurs centaines de Go la typo fait vite mal…)
5. Ton script il va continuer comme un bourrin si y'a une erreur et c'est comme ca que les drames arrivent. La gestion d'erreur c'est l'enfer en bash
6. On peut continuer longtemps comme ca

Bref tu as du code pas expressif du tout, une gestion d'erreur à chier et non triviale, vraiment pas grand chose à ta disposition sans contortions. On parle pauvre set la hein, tu vois si je script c'est pour faire des tâches.

Je vois pas l'intêret de se priver d'un environemment moins hostile combinant un langage moderne avec la puissance, la souplesse et la performance des outils UNIX + flux textes… Passer mon temps à réinventer la roue en passant par 5 commandes et 3 fichiers, intestables, pour faire des trucs triviaux j'ai franchement mieux à faire.

Après rien n'est tout rose des deux côtés. Mais on a vite fait de s'enfermer dans ce qu'on a appris sans voir les autres opportunités qui existent. Dès qu'on sort de son prompt, je trouve que ca vaut vraiment le coup de se demander si c'est vraiment du shell qu'on veut faire, en voyant à court et long terme.

C'est exactement ce qu'on appelle bidouiller comme un cochon quand tu accumules toutes les étapes (sort vers fichier x2 vers join) que tu dois faire pour un truc aussi simple ;)

Pour prendre l'exemple le plus défavorable au shell tu peux comparer avec:

from sh import ssh

def get_files(env, prefix, pattern):
  files = set()
  for line in ssh(env, "hadoop fs -ls %s/%s" % (prefix, pattern), _iter=True):
    fname = get_fname(line)
    if fname:
      files.add(fname)

  return files

src_files = get_files_on("prod", src_prefix, pattern)
dst_files = get_files_on("rec" , dst_prefix, pattern)

files_to_upload = src_files.difference(dst_files)

(je fais exprès de n'utiliser aucun idiome du langage choisi car ca ne me semble pas être le sujet)

Là on est dans le cas simple où on ne gère rien. En pratique dans get_fname t'as trois lignes de code (qui vont te demander X pipes grep/awk/sed/cut & variable substitution pour arriver au même résultat), tu vas aussi gérer que si le répertoire n'existe pas la commande se termine en erreur et faut que tu te comportes comme un set vide etc.

Tu peux très bien le faire en shell. Je sais le faire sans problème et je sais très bien reconnaitre la force des pipes textuels (je passe mes journées à analyser des gros gros fichiers textes). Maintenant regarde le temps que ca te prendre à écrire pour que ca juste marche et que ca soit relu par quelqu'un d'autre c'est vite vu. Le shell comme langage te force aux acrobaties et introduit énormément de bruit pour faire des choses simples en dehors des pipes et conditionnelles simples, bref la glue dont tu as besoin.

Si tu ajoutes à ca que les admins codent de plus en plus par le DevOps et qu'ils commencent à savoir programmer des trucs pas trop crado dans des langages modernes (ou la sélection naturelle va bien finir par s'opérer). La question de la pertinence du Shell comme langage de prog pour les scripts aujourd'hui se pose beaucoup je trouve.

C'est un peu comme les regex ou l'élégance en prog fonctionnelle. Ce sont des outils puissants et la recherche de la solution est intellectuellement satisfaisante. Maintenant on veut des trucs qui marchent, qui évoluent facilement, qui se testent et qui pourront être lu et compris rapidement dans X mois. Donc on réfléchi au meilleur outil pour le job.

Tu me prends vraiment pour un con qui aurait choisi une "résolution 4/3 sur un 16/9" ?

je rappelle que tout le monde a ce genre d'écran

Encore raté. Tu veux une photo ?

Au passage en dual screen pour les dev, plus le ratio est carré plus mieux c'est.

À l'inverse, quand tu bosses sur de l'image un gros gros wide screen, c'est top.

C'est vrai qu'à une époque où tout le monde a un écran large (16/10, voire 16/9)

Ou pas.

$ xrandr | grep " connected"
Virtual1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
Virtual2 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 0mm x 0mm

>>> 16.0/10 < 1280.0/1024 < 16.0/9
False

Dis autrement si on pense le bash comme un langage apparentière et qu'on se laisse autant de temps pour l'apprendre que du C est-ce qu'on se dira vraiment que la plupart des scripts sont imbitables ?

Oui.

Autant c'est génial pour faire des trucs crados vite fait à base de pipe, autant c'est la plaie pour tout le reste que ce soit à l'écriture, à la relecture, à la maintenance ou au test.

Encore aujourd'hui j'avais un script tout con à écrire: tu récupères la sortie de hadoop fs -ls sur deux clusters, et tu transferts tous les fichiers manquant vers la destination over ssh. En gros tu fais une différence de set, et tu gères proprement si la connexion tombe, que tu ^C ou autre etc. Si tu veux on compare la facilité et la lisibilité les deux implémentations à fonctionnalité égale pour un truc aussi con. En sh tu vas bidouiller comme un cochon pour faire un bête set.difference().

Franchement y'a encore du boulot, mais peaufiner les alternatives type process en Scala, sh en python et certainement beaucoup d'autres pour amener l'élégance du shell sur les cas simples tout en ayant en vrai outil entre les mains pour gérer toute la logique autour des pipes et fork/exec franchement ca ferait du bien.

Ton destructeur balance une exception, évidemment que ça se passe mal, il ne faut jamais lancer d'exceptions dans un destructeur.

Oui c'est vachement mieux de jeter ca sous le tapis ni vu ni connu ;)

Pourquoi tu flush ton flux tout le monde s'en fou quand ca s'est mal passé ? Autant ne pas le faire.

Dans les fait j'ai un énorme doute sur le fait que tu puisses toujours gérer correctement une erreur au niveau du destructeur. C'est assez fréquent qu'il faille remonter de X niveau business pour faire ce qu'il y a faire. En général en bas niveau on peut juste remonter que ca à foiré mais l'error recovery est bien plus haut.

Je ne fais pas de C++ mais j'ai du mal à voir en quoi ca serait spécifique sur ce point.

Le problème c'est qu'on programme vite avec l'interface utilisateur et que ca devient rapidement n'importe quoi. Des mecs capables d'écrire des trucs robustes et pas imbitables en sh franchement y'en a pas des masses. Le sh est resté de la prog des années 70.

Franchement dès que tu arrêtes de faire deux trucs à l'arrache, virer le sh pour le remplacer par quelque chose de moins masochiste c'est très bien. Il y a encore du travail à faire mais des modules comme sh vont dans le bon sens. Tu réutilises ce qui fait la force d'Unix en arrêtant de faire des trucs dégueulasses.

Maintenant je suis d'accord avec toi. Les deux besoins existent et le compromis n'est pas facile à trouver. Mais en fait tu ne me semble pas critiquer powershell mais juste que ca manque de block qui font ce que tu veux.

Ils sont bien obligé de causer des ces conneries par que ceux qui s'intéressent au sujet sont assez décu des informations du Design Document.

Genre pour revenir à la question initiale, rien de sérieux techniquement à se mettre sous la dent sur le sujet de congestion. C'est super vague et ils ne disent rien de ce qu'ils veulent/ont expérimenter.

Y'a quelqu'un qui a eu le temps de regarder en détail, et qui a réussi à trouver des pointeurs intéressants pour ceux qui s'intéressent plus au réseau qu'a la morale ? Ou alors il n'y a rien ?

J'avoue que ca me choque même plus comparé à perdre entre 2 et 3x plus de hauteur pour absolument rien. Sauf peut être le plaisir de rendre le code illisible vu que plus aucune fonction ne tient sur un écran vu qu'une pauvre boucle + if/else prendre déjàau moins 12 lignes…

Mais l'important c'est qu'au moins ca soit cohérent, les maintainer font les choix qu'ils veulent, même si ils sont mauvais ;) Si je suis pas content je fork…

Enfin dans tout les cas, si tu bosses sur des projets venant de plusieurs personnes/entités t'as toujours ce genre de conneries à gérer (+ template, + règle custom, + etc.).

Le libraire ne revend pas tes données

Ca tu n'en sais rien. Il y a des magasins physiques voir des secteurs entiers qui se sont organisés depuis des années pour collecter des données sur les clients. De même tout les programmes de promotion sont généralement basé sur les collectes de données.

De même on parle de personnalisation de service basé sur un historique et/ou des recommandation sociale ici. Ca ne demande pas de vendre les données et en pratique très peu le font. Il faut faire attention aux mots que l'on emploi, on a vite fait agiter un drapeau rouge où il n'y a pas lieu.

La où ca devient limite c'est quand on commence à faire reposer les recommandations sur des services de tracking externes, qui eux commencent à faire n'importe quoi. C'est assez opaque mais en pratique il n'y a pas trop lieu de fantasmer non plus. Note que ce n'est pas de ca dont on parle maintenant.

Après tu as la pub qui est encore différente par ce que là tu ne te base pas forcément sur les données du service lui même pour contextualiser les affichages.

C'est pour ca que j'insiste sur le fait de ne pas tout mélanger.

il m'en conseille deux fois sur trois un troisième livre et tombe juste presque tout le temps.

Le but est exactement le même. Dans l'idée, on combine des recettes basée sur:

• La demande générale
• L'historique de l'utilisateur
• Le recoupement avec les autres utilisateurs

C'est ce que tu retrouves sur les sites d'écoute de musique en ligne, les sites de vidéo, le ecommerce et partout ailleurs.

Tu vois, dans ce cas précis on ne cherche qu'à faire ce que en tant que client tu demandes. Te présenter des choses que tu aimes et que tu peux aimer.

C'est un domaine encore jeune, il reste beaucoup de progrès à faire mais c'est exactement ce qu'on fait.

Après on peut aussi faire des choses pour jouer sur les prix et faire des milliards de chose bien ou pas bien. Tu vois comme quand le mec dans les Alpes fait +500% sur le prix des chaines les jours de neige quand il y a des touristes…

Le libraire utilise un prix public qu'il peut éventuellement réduire de 5%. Le prix affiché ne l'est pas que pour moi. La seule variation qu'il peut faire c'est réduire le prix de 5%.

Le livre est un cas réglementé et très particulier. Autrement pour tout le reste du commerce les prix sont libres, et les commerçants ont toujours pratiqué la personnalisation des prix que ce soit en B2B ou B2C.

Tout comme les commerçants ont toujours cherché à comprendre leurs clients et leurs habitudes afin d'une part de maximiser leur profit en proposant des choses qu'ils sont susceptible acheter personnellement, et d'autre part de comprendre la dynamique général afin de trouver les points faibles & forts pour s'adapter.

Sur Youtube tu penses que les gens préfère avoir la video et c'est tout, ou aussi des fonctionnalités de recherche et de navigation contextuelle qui leur permet de naviguer dans le catalogue ? En dessous c'est exactement la même chose…

Certes. Mais justement, j'ai une idée assez précise de ce qui peut se faire et je suis assez bien placé pour y échapper !

Tu as surtout un discours complétement schizophrène. Si ça te répugnes tant que tu veux le dire, et que tu ne vois absolument pas pourquoi ça peut être des besoins légitimes voir même soyons fou intéressant pour l'utilisateur (après c'est comme tout tu as multitudes de façons de faire), j'ai un peu de mal à comprendre et trouver crédible ta position dépourvue de toute nuance…

Pour y échapper, il me semble tu n'es ni plus ni moins bien loti que n'importe quel utilisateur. Tu es juste un peu moins naïf et un peu mieux au courant de certaines choses. Mais en pratique en tant qu'utilisateur ça change pas grand chose. Je connais maintenant très bien le monde de la pub et du tracking, mais en tant qu'utilisateur ça n'a rien changé comparé à avant. Au contraire tu arrêtes un peu de fantasmer sur comment sont utilisées les données et tu déprimes pour d'autres raisons.

Ça je le gère via checkstyle.

Je ne te parle pas de vérifier, je te parle que l'IDE te produise par défaut du code répondant aux specs du projet. Tu ne vas pas t'amuser à réindenter pour le plaisir à chaque insertion. Genre j'ai un projet upstream où les gus aiment le old school illisible avec un Allman style en Java… Ou alors des mecs qui violent l'ordre des modifiers.

Après si tu commences à maintenir beaucoup de code, tu vas vite arriver à avoir des templates, des refactoring et des analyses un poil différentes.

Ça devrait être dans le pom.xml ou au moins automatisé mais surtout pas lié à l'IDE.

Ca dépend. Évidement que tu n'écris rien de spécifique à l'IDE pour exécuter ou déployer des tests. Maintenant quand tu passes ton temps à aller attacher des debugers sur des clusters distants dans des conditions à la con c'est pas ton build qui le fait, c'est pas son job. Selon ce sur quoi tu bosses tu as plus ou moins de glue dans l'IDE pour te permettre d'utiliser ce qui a été déployé.

Trop longtemps que je n'utilise plus ce genre de choses, mais ça venait des différences de configuration entre les développeurs d'un même projet. On se retrouvait souvent à se passer des bouts de conf' à la main

Effectivement gettho style, mauvais dev changer dev !

Je suis entièrement d'accord avec toi qu'un projet doit être IDE agnostic. Maintenant en tant que dev, si tu veux tirer parti de pas mal de fonctionalités, tu vas configurer tes environnements par projet pour t'aider au fur et à mesure à faire mieux, plus facilement, plus vite. Tu le retire ca n'a aucun impact sauf pour le dev.

Eclipse ne m'a jamais fait de misère (j'utilise au choix eclipse/netbeans/intellij selon l'environnement et les besoins) mais je me demande si tout le monde est d'accord sur ce qu'est un "fichier projet".

Par ce que si tu utilises ton IDE sérieusement, ce n'est pas par ce que tu as un build propre que tu n'as pas une terachiée de conf par projet dans ton IDE. En vrac:

• Tout ce qui est coding style, error reporting, refactoring auto, templates (entre les projets internes, les upstreams, les open sourcés j'ai au moins 5 confs très différentes) etc.
  
• Tout ce qui de la conf ou pré-conf pour le lancement des tests dans l'IDE, remote debugging etc.
• Déploiement pour ceux qui aiment (moi pas)

Bref c'est quoi qui pète. .projet, .classpath, .settings ?

Ils vont bien évidement inclure la gestion de congestion dans le protocole. Et puisqu'ils sont pas con, ils vont faire que ca marche de manière équitable avec TCP.

UDP doesn’t have congestion control, so won’t QUIC cause Internet collapse if widely adopted?

QUIC employs congestion controls, just as it employs automatic retransmission to support reliable transport. QUIC will attempt to be fair with competing TCP traffic. For instance, when conveying Q multiplexed flows, and sharing bandwidth with T concurrent TCP flows, we will try to use resources in the range of Q / (Q+T) bandwidth (i.e., “a fair share” for Q additional flows).

Je préfère donc m'abstenir d'acheter afin de rester en accord avec ma conscience morale.

Tu ne bosses pas chez neolane ? Par ce que bon tes tirades de ce genre… lol quoi

À tout mélanger on a vite fait de dire vite n'importe quoi.

De plus attention ici on parle d'un acteur qui surveille l'utilisation de son service afin de maximiser sa pertinence et son efficacité. C'est la base de n'importe quel commerce.

C'est assez différent du tracking publicitaire à plus large échelle. Tant techniquement que moralement.

Ouai ils ont fait exprès de faire une release avec des régressions sur les perfs pour le fun. Et vu qu'android est leur seul marché, après s'être bien poilé ils ont fait une release sérieuse.