ckyl a écrit 3877 commentaires

Dans le même temps, les informaticiens qui sortent de l’enseignement supérieur public peinent à trouver un emploi. Leurs compétences techniques et leur intégrabilité au monde professionnel après 3, 5 ou 7 années d’études sont contestées par les recruteurs qui leur préfèrent des étudiants mieux formés en parfois trois années seulement dans l’enseignement privé.

Mouhahahahaa

Les cours ? Quels cours ? À 42, pas de cours magistraux, mais des projets à l’occasion desquels vous apprendrez bien plus et bien plus vite.

Mouhahahahaa

Autrement j'en dis qu'ils sont pas foutu de faire une site web qui gère correctement les sessions pour des gens derrière un proxy…

Ca me ferait un peu peur que quelqu'un utilise /dev/urandom pour des besoins cryptographiques. Je viens de regarder le code d'OpenSSH:

Pour OpenSSH, il utilise arc4random et donc /dev/arandom.

Pour OpenSSH portable il repose sur /dev/random. Il existe une possibilité d'utiliser PRNGd si il n'y a pas de /dev/random ou si on le choisi.

Loin de moi l'idée de dénigrer le python comme langage mais la "simplicité" apparente du langage n'entrainerait-elle pas les élèves à penser la programmation de façon plus simpliste qu'elle ne l'est réellement.

On s'en balance un peu non ? Et ceci pour deux raisons:

Premièrement par ce que quelque soit le premier langage que l'on apprend il y aura toujours de la magie noir. C'est pas grave, on te dit de faire ca, tu fais ca. Contrairement aux discussions du dessus, penser qu'on peut démarrer avec quelque chose ou on comprend tout et peut tout expliqué me semble voué à l'échec.

Deuxièmement par ce que quelque soit le langage que tu vas choisir, les élèves vont penser de facon simpliste. La seule facon de prendre un peu de recul et de compétences est de manger au moins trois langages complémentaires fonctionnel / C / langage de l'industrie (Python / Java) et de combiner ca aux disciplines qui vont autours. Ca vient avec le temps, pas du langage.

Alors se palucher sur le langage à choisir et les possibles implications sur les élèves ca me semble un peu discuter dans le vide. Java, Python, Scheme, Pascal & co font tous de très bons langages pour apprendre en terminal (ce genre d'option existait déjà à mon époque, on faisait du turbo pascal) l'important n'est pas là. Il s'agit de démarrer la machine et donné un appercu de la chose. Après quand tu as passé les premières bases et écrit tes premiers trucs, direction le C et un lisp-like pour s'y mettre sérieusement et lancer la machine.

Non mais il génère des bits aléatoires, qui eux servent à SSH pour générer les clés. Et c'est bien la le problème. man 4 random

A quand les devs noyau se mettront au TDD plutôt qu'à code hero ? ;)

Si tu vas par là, en combinant un inotifywait ou watchmedo avec un rsync --link-dest tu as la même solution en 4 lignes sauf que ca juste marche exactement comme tu le veux et en local…

Créer des mini commits toutes les cinq minutes ne sert à rien, pourrit l'historique, est beaucoup plus verbeux, etc.

À la fin ca ne pourri rien du tout. Si tes commits ne servent à rien au final, ils ne seront simplement plus là. Ils t'ont juste servi temporairement.

Maintenant l'avantage c'est que tu as une chronologie, une séparation de ton travail et une place qui centralise tout. Tu peux t'arrêter de bosser n'importe quand, et reprendre n'importe quand c'est toujours aussi clair. Les changements sont toujours répertoiriés et dissociés.

La tera-chiée de foo_${id} dans un répertoire, ca devient vite compliqué de s'y retrouver vu qu'il n'y a aucun lien logique. Pourtant tu les as bien sauvegardé pour une raison ?

Je suis pas sur qu'on était en train de chercher une solution qui ne sert à rien ;) La discussion me semblait bien plus générale: savoir sentir les cas foireux, les mauvais usages, les mauvais designs. Remplacer un eval par un python sandboxé pour faire une calculette, c'est persister dans son erreur.

Maintenant tu vas pas aller bien loin avec literal_eval qui comme son nom l'indique n'évalue que des literaux… Cool tu peux parser des int et des float. Le reste est à faire, tu vas donc basculer sur ast.walk en faisant gaffe à pas faire de conneries. Retour plus ou moins à la case départ. Mais au fait avec literal_eval; ton calculteur tu voulais vraiment lui laisser parser des dicts ?

Maintenant le mec qui veut se coder sa calculatrice. Il va définir son cahier des charges (quelles constructions sont autorisées, quels impacts niveau CPU et mémoire etc.), et il va soit utiliser un des 1000 projets qui doivent faire ca. Soit se coder son parseur en une aprèm si il veut quelque chose de très précis. Là encore soit à l'ancienne type premier projet de compil, soit en utilisant un lib de parsing comme il en existe tant. Bref on s'en fou un peu en fait.

Si. Tu peux aussi mettre le travail en cours dans une branche dédiée. C'est fait pour. Savoir maitriser son VCS est vraiment quelque chose de très important. "Ne pas vouloir créer un commit" est aberrant de nos jours. Si ca fait du sens à l'instant T de commiter en local alors il faut commiter même si on sait qu'à long terme il va disparaitre. On pourra toujours le retravailler, le supprimer, le combiner ou le déplacer si besoin.

Je n'arrive pas a voir le cas d'utilisation de quelque chose que l'on "veut garder" mais dont on se fou puisque si jamais la machine crash adieu le /tmp.

On en revient exactement à ce dont parle l'article.

Pour faire ton module calc tu as le choix entre deux options:

• Écrire, ou utiliser, un parser dédié. C'est un projet que n'importe quel étudiant à fait, et qui se boucle en quelques heures. Tu es 100% sur de la sécu, au pire il va manquer des fonctionalités que tu pourras rajouter par la suite.

• Utiliser quelque chose qui repose sur de l'éxecution de code de ton langage. Que ca soit eval que tu essais de sécuriser ou une sandbox ca revient en gros au même. Au moindre problème, faille, ou chose imprévue tu t'exposes à des catastrophe. Pour rien. La surface d'attaque est importante et les conséquences (DOS, faille, fuite d'info) sont très nombreuses.

Un poil de bouteille devrait te faire toujours rester très loin de la deuxième solution sauf excellente raison.

Ca s'applique à de nombreuses choses. Au fur et à mesure tu apprends à détecter les choses qui vont inexorablement poser problème et exploser en vol dans une semaine ou cinq ans et que des choix rationnels auraient évité.

Dans les quelques villes qui font déjà ca que j'ai traversé les axes surveillés sont indiqués.

Tiens on est revenu 15 ans en arrière ? Les bots reviennent à la mode ?

Autrement vu ton module calc l' article suivant n'a jamais été aussi vrai…

Te rappelles-tu de l'affaire du tracteur flashé à 160 sur l'autoroute

Il s'agissait d'une doublette. La seule facon de s'en apercevoir est de contrôler chaque véhicule et ses papiers. Quand un policier te balance un PV de stationnement ou tout autre infraction qui ne se termine pas par un contrôle c'est exactement la même chose.

Ca, c'est le problème des sanctions automatiques.

Qui n'a donc rien à voir avec la facon de constater l'infraction. C'est la procédure de contestation qui pose problème.

Autre point important, les sanctions automatiques remettent

Sauf que ce dont on parle là n'a rien de sanction automatique. AFAIK Paris veut faire comme les autres villes qui ont déjà mis ca en place. Une salle de visionage, où des humains & policiers surveillent un ensemble de caméra donné et ce qu'il s'y passe. Détecter une double file en marchant dans la rue, ou en mâtant une caméra ca change pas grand chose. Et contrairement à un instantané, ie. photo, tu as la dynamique de la scène pour avoir un certain discernement.

Après tu peux être pour ou contre. Mais on bascule rapidement vers les anneries en mélangeant tout et n'importe quoi.

Visiblement pour verbaliser les véhicules qui commettent des infractions ça marche plutôt pas mal. Un agent avec ses caméras doit pouvoir coller plus de prunes à l'heure que s'il devait arpenter la chaussée.

Si la propagande P9 est bonne. Ca marche tellement bien que ca fait baisser la verbalisation.

Et pour les vélos qui font nawak aussi ?

Elle peut même toucher les bons pères de famille?

Bha non si tu n'as rien à te reprocher tu n'as pas a avoir peur de la verbalisation des infractions routières puisque tu n'en fais pas… L'argument est donc toujours valide.

Paris va expérimenter la verbalisation des infractions routières en utilisant son réseau de vidéosurveillance

Pendant ce temps là d'autres villes le font depuis quelques années.

Beh non, les IO sont déjà pas en problème puisque toutes les opérations IO permisses par le navigateur sont "evented

L'IO en elle même non, par contre parser la réponse et la traiter ca peut prendre un certain temps si tu as un peu de volume et ca c'est synchrone.

Peut-on avoir des exemples concrets avec lesquels un worker sert à autre chose qu'étendre un système de calcul distribué ?

Le web ce sont des pages statiques, des pages dynamiques et des applications webs. Donc réagir aux actions de l'utilisateur, faire du CPU bound sans bloquer l'UI, consulter et agréger des ressources externes, implémenter des greffons, structurer et segmenter son code ?

Sérieusement vous croyez vraiment qu'on passe son temps à utiliser votre petit CPU ? Il y a beaucoup de choses qui font plus de sens à faire client side que serveur side. Quand on avait pas le choix pour des raisons techniques, matérielles ou de base de code on trouvait une solution avec des échanges coté serveur. Maintenant il faut trouver la balance.

Il faut autant cesser de voir le web comme simplement des pages à papa qu'il faut arrêter d'utiliser des usines à gaz pour des pages vraiment à papa.

Maintenant, qu'on veuille rendre JS plus efficace, qu'on le JIT, qu'on l'optimise pour qu'il bouffe moins de cycles pour une même tâche, c'est très bien, mais il devrait être limité en vitesse d'exécution par défaut (avec un mécanisme de réglage facile pour les applis exigeantes, voire une api standard pour demander ce genre de permission) et faire des petits usleep(3) des familles pour ne pas rendre ton système rentable à exploiter.

C'est quoi ton délire de système exploités ? Qui exploite ta machine et pourquoi ? Tu peux nous donner des exemples concrets puisque ca fait plusieurs fois que tu assénes ca comme une vérité ?

Et si tu as plusieurs machines pour une utilisation donnée à la case départ.

Rigole pas, ca va être intéressant de suivre la charge du RSS sur les sites si on remplace un seul google-fetcher bien élévé à pleins de clients qui poll comme des cochons.

Tu as oublié une force de google reader. Une time-machine sur les flux, même quand tu viens de t'abonner.

cependant, je doute tres fort qu'ils le ferment dans 3 mois. ce serait une erreur.

Ca fait parti du netoyage habituel, ca sera ni le premier ni le dernier.

il ferait mieux de le monétiser.

Faut pas y compter: http://gigaom.com/2013/03/13/chris-wetherll-google-reader/

Et encore ça ce n'est qu'une de ses 150 tabs de son butineur !

L'avantage au moins d'une application native, c'est que tu n'es pas dépendant du bon vouloir d'un service qui peut être débranché unilatéralement.

Reste à voir l'impact du débranchage du service ultra-dominant sur la techno sous-jacente.

Il y a deux possibilités, soit ça va relancer l'innovation dans ce domaine qui était au point mort depuis le lancement de Google Reader. Soit ça signe la mort effective d'ici 2/3 ans du RSS qui n'avait plus trop la forme.

Il y a vraiment un coup de com, de polish et une grosse appli/service à faire autours de RSS pour ne pas le voir sombrer. Ce qui serait bien dommage.