flan a écrit 1865 commentaires

Oui, c'est vrai aujourd'hui. On le voit bien avec les Américains qui se vantaient lors de leur premier raid en Syrie d'avoir détruit un mortier et une dizaine de pickups (bref, quelques dizaines de milliers de dollars de dégâts) avec un raid qui a couté plusieurs (dizaines de ?) millions de dollars.
Accessoirement, des drones se feraient descendre assez facilement en Syrie. Les Syriens ont perdus des dizaines d'avions de chasse), alors qu'ils vont bien plus vite, sont un peu blindés et mieux équipés.

Mais qu'en sera-t-il dans 10 ans ? Tous les pays du monde (sauf l'Europe) sont en train de se réarmer de façon importante. De plus en plus de pays veulent construire leurs propres armements, y compris leurs avions de combat.
Maintenant, sachant qu'un avion de combat demande en gros une quinzaine d'années entre les premiers travaux et l'entrée en service, est-il raisonnable de faire l'impasse dessus et de ne croire qu'il n'y en aura plus jamais besoin ?
Ce n'est pas parce qu'il n'y a pas eu de conflit en Europe de l'Ouest pendant 70 ans que le reste du monde se porte mieux.

Dans le domaine militaire, quand on fait une erreur de ce type, la sanction peut être très dure et se chiffrer en dizaine de milliers de vies.

Je pense comprendre l'intérêt des hardlinks (ne pas avoir plusieurs fois les mêmes données, j'imagine), mais je trouve ça particulièrement dangereux pour de la sauvegarde/archivage/redondance.
En effet, si je modifie une seule sauvegarde (avec un simple >> , par exemple), toutes les copies précédentes sont également corrompues.
Personnellement, quitte à garder tout l'historique, j'aurais pris du Subversion ou du Git. Au moins, pas de problème de hardlinks, avec tout l'historique et aucun problème de duplication (ou au moins pas plus qu'avec les hardlinks).

Time Capsule est le nom d'un NAS qui peut servir pour TimeMachine.
TimeMachine utilise bien des hardlinks… mais des hardlinks sur les dossiers ! Le système de fichiers (HFS+) a été modifié pour ça. Forcément, ça change tout ;)

Les russes ( ni les indiens ) n'ont pas encore de chasseur de 5eme génération en service. Au mieux ils ont le SU-35 un 4++ plus proche de l'enclume volante ( quand il ne se crache pas ) le tout sur un design des années 60

Le Su-27 date des années 70 (premier vol en mai 1977, avec une grosse refonte des premiers prototypes au début des années 80) et non des années 60. Accessoirement, ces histoires de génération n'ont strictement aucun sens, elles ont été lancées par le service marketing de Lockheed et de l'USAF, en prenant uniquement les caractéristiques qui avantageaient le F-22.
Avant le F-22, personne n'avait jamais parlé de génération 2, 3, 4… de chasseurs. D'ailleurs, on se demande bien quelles seraient les générations précédentes :

• 4ème : 2000/F-16/F-15/Su-27/MiG-29/F-18 (quid du Mirage F1 ?),
• 3ème : la vague des géométries variables, avec F-14 (successeur du F-111B), MiG-23, Tornado, Mirage G,
• 2ème : du P-86 au F-4, ou du MiG-9 au MiG-21 ? on peut distinguer au moins 3 générations là-dedans,
• 1ère : Me-262 et Meteor, essentiellement, voire le P-59.

Bref, ça ne correspond à absolument rien. Le seul intérêt est de pouvoir dire que le F-22 est le seul avion de 5ème génération et que les autres sont pourris (bouhhhh ! à peine du 4++++ !). Alors, oui, le F-22 est sûrement bien meilleur que le Su-35 en air-air, mais c'est simplement absurde de qualifier le Su-35 d'enclume volante. Le Su-35 vole bien, très bien même, avec une capacité d'emport qui est bien plus importante que celle du F-22. 14 points d'emports, 8 t d'armement, avec notamment des armes air-sol bien utiles en ce moment.
Le Su-35 (et tout le reste de la famille, bien nombreuse) vole, et surtout a l'avantage par rapport au F-22 et au F-35 d'être à la fois utile et utilisé. Ce n'est pas rien :)

La maniabilité n' as plus aucun interêt que faire joli lors des meeting aérien. Ca fait 20 ans ou plus que les dogfights ça sert a rien. Un chasseur moderne se doit de faire du BVR , et sur ce plan les US sont largement en avance

Largement en avance, sans avoir de missile digne de ce nom ? Le AIM-120 a quand même les pattes un peu courtes (dans les 80 km) par rapport aux missiles qui apparaissent (Meteor, R-77M) qui tapent plutôt dans les 150 km. C'est physique : un statoréacteur porte plus loin qu'un simple moteur à poudre. Au passage, les ÉU ont beaucoup sacrifié pour la furtivité, un concept de 40 ans qui risque de ne plus valoir grand-chose en pratique : beaucoup de pays travaillent depuis des années pour contrecarrer ça, les solutions théoriques sont connues depuis longtemps si elles ne sont pas déjà existantes en pratique. Ça avait un sens au début du F-22 (les années 90), mais ça fait dans les 30 ans maintenant.
Accessoirement, ils n'ont que 187 F-22, avec une disponibilité qui a priori laisse encore à désirer. Les guerres ont souvent montré qu'il valait mieux beaucoup d'armes avec une bonne disponibilité que peu d'armes high-tech qui fonctionnent une fois sur deux.
Accessoirement, tu as l'air de mieux connaître le sujet que Lockheed et le Pentagone : la maniabilité extrême faisait partie du cahier des charges du F-22. Dommage qu'ils ne sachent pas que ça ne sert plus à rien ! :)

et Le F35, bin il est pas encore admis en service actif.

Et bien si, justement. L'IOC a été déclarée pour le F-35B il y a un an et il est officiellement prêt au combat. Bon, apparemment, pas au point d'y aller en vrai, à croire que ça ne va pas si bien que ça…

De mon côté, j'utilise PyCharm avec des annotations pour l'aider encore plus à détecter les types. J'utilise parfois la souplesse du typage dynamique, mais de façon très ponctuelle (parfois ça aide bien !). Au final, je ne vois pas tellement de différences entre un langage fortement typé et du Python, et le refactoring se passe très bien.
Je préférerais avoir un vrai système de typage fort, mais ça ne me gêne pas plus que ça.

1) tous les gros frameworks Python (comme Django, par exemple) fonctionnent avec des serveurs d'applications multithreadés ou multiprocess (comme tu veux), sachant qu'il y a plusieurs serveurs d'applications existants (comme uwsgi, gunicorn).
2) les perfs ne sont pas forcément un problème :
- pas mal de sites (notamment sur intranet) n'ont pas forcément beaucoup de clients simultanés
- il faudrait mettre en rapport au temps de dev. si tu dois mettre un dev en plus pendant un an sur un projet parce que faire un projet en Java peut prendre plus de temps, ça coûte 70k€ (en comptant avec une très grosse louche deux fois le salaire pour les charges). Combien coûte un second serveur si un seul ne suffit pas ?
3) vu le niveau des dév. purement Java que j'ai rencontrés, je ne sais pas si c'est un défaut ou une qualité :D
4) on pourrait dire ça de Java ; les défauts de Python ne sont pas dus au hasard, simplement à la base Python n'a pas les mêmes buts que Java
5) on en revient au problème de perfs

On reconnaitrait bien l'esprit de solidarité de l'UE !
mais en effet, c'est peu le discours de certains politiques… et ça soulève quand même pas mal de questions, je trouve.
Tout faire pour couler un pays s'apparente plus ou moins à un acte de guerre, ça reste très très loin du soi-disant esprit de solidarité régnant au sein de l'Europe, ça revient à fouler aux pieds le droit des peuples à disposer d'eux-mêmes (autre valeur de l'Europe), … et ça donnerait surtout l'impression d'une prison européenne, qu'on ne pourrait pas quitter sans se faire matraquer :/

Au moins, c'est plutôt rassurant comme message ! :)

Un Allemand qui ne parle pas français a peu de chance de lire un article en… français. Et s'il le lit quand même, je doute que ça soit le titre de « Directeur Technique » qui soit le plus compliqué.

Malheureusement, non : je n'ai quasiment pas utilisé SQLAlchemy.

Concernant celui de Django : il s'est beaucoup amélioré à chaque version. Il permet de faire très facilement des requêtes simples et facilement des requêtes complexes. De plus, django debug toolbar permet de voir quelles sont les requêtes SQL effectuées, donc c'est assez facile de voir quelles sont les requêtes problématiques (et donc quelles sont les requêtes qu'on peut laisser telles quelles).

Si tu fais gaffe aux perfs, l'ORM de Django possède pas mal de subtilités qui permettent d'affiner le SQL effectué (soit en restant en pur Python, soit en aidant un peu, soit en écrivant directement le SQL). Par exemple, tu peux faire des jointures propres sans trop de souci.

Django permet depuis très longtemps d'intégrer ses propres moteurs (autrement dit un adaptateur à une base de données) à l'ORM de base, et tu peux depuis longtemps faire du LDAP ou du MongoDB.

À côté de ça, tu peux maintenant (mais c'est récent, Django 1.8 ou 1.9) changer d'ORM et utiliser un autre (par exemple SQLAlchemy). De façon générale, Django est maintenant beaucoup plus modulaire : tu peux changer son moteur de template (pour du Jinja2, au hasard) et son ORM.

En quoi sa parole serait-elle d'évangile ? il précise justement qu'il ne parle que de ses besoins personnels, et que sa situation n'est pas forcément transposable.
Si tu préfères Linux, bah grand bien t'en fasse. Que pourrait-il dire d'autre ? Il n'a jamais sous-entendu qu'OS X te serait bien mieux adapté.

En revanche, OS X n'est pas un dérivé UNIX bâtard. OS X EST un UNIX de plein droit, il est d'ailleurs certifié UNIX (contrairement à Linux ;) ).

Après, je ne comprends absolument pas ton passage sur son acceptation sociale et son statut de jouet (tous les professionnels, quels qu'ils soient, qui utilisent OS X au quotidien seront ravis d'apprendre qu'ils ne font que jouer ; heureusement que tu es là pour leur apprendre :) ).

En fait, le X correspondrait aux deux, à la fois une référence à UNIX et au « 10 » romain. D'après ce que j'ai lu (mais je ne garantis pas l'info), Mac OS 9 a été sorti uniquement pour passer à X/10 (il n'apporterait que peu de chose par rapport à Mac OS 8, il aurait très bien être une version mineure).

Ensuite, Mac OS X a été renommé en OS X (il y a 3 ou 4 ans, de mémoire), et maintenant OS X est renommé en macOS (sans majuscule).

Oui, c'est d'ailleurs pour ça que j'ai mis « x is None » ; cependant il n'est possible que parce qu'il n'y a qu'une seule instance de None.

La méthode recommandée est :
```

class Test:
… def init(self, items=None):
… self.items = [] if items is None else items
…

… def add(self, item):
… self.items.append(item)
```
None est un objet dont il existe une unique instance (comme False ou True), on peut donc indifféremment utiliser « x is None » et « x == None ».

Malheureusement, l'inférence de type n'est pas parfaite, surtout avec les bibliothèques tierce-partie qui n'aident pas toujours beaucoup (voire rarement) à ce sujet :(

Ça serait pas mal de n'avoir que les erreurs de type, mais il y a tant d'autres raisons… l'algo peut être faux, on peut oublier de vérifier certaines conditions, les cas limites (j'essaie d'utiliser hypothesis pour ça), mauvaise gestion des exceptions, …

Bon, globalement j'ai quand même bien plus de chances que ça fonctionne dès le premier lancement que l'inverse depuis que je fais les choses proprement (PyCharm + indications de type + tests + hypothesis + intégration continue).

Avant même la compilation : dès l'écriture du code. Pourquoi compiler du code alors que la compilation échouera forcément ?

Quand je code en Python, j'utilise PyCharm qui fait de l'inférence de type assez efficace (d'autant plus que je l'aide pas mal à ce sujet) et me force à respecter la PEP008. C'est maintenant rarissime que j'obtienne des erreurs de type au lancement.

En prenant un cas caricatural et en oubliant tous les autres avantages (lib standard, écosystème, absence de compilation, …), ça ne change pas grand-chose, forcément.

Merci pour ton retour. J'ai un peu l'impression que tu en parles au passé, a-t-il été abandonné, ou est-ce bien un changement de poste de ta part ?

Au final, avec Kerberos, cela fonctionnait-il bien ? Comment était possible la transmission du ticket Kerberos au smtp derrière SoGO ? Pas d'authent' en local sur le port 25 ?

Tu as trois possibilités pour les paquets Python :

• avec le système de packaging de ta distrib (apt-get install python-numpy)
• depuis le dépôt avec les sources et la recompilation qui va avec
• depuis le dépôt avec des versions précompilées (avec plusieurs choix d'archi)

par exemple : https://pypi.python.org/pypi/numpy/1.9.3

Et ces langages font souvent appel à du C pour les fonctions consommatrices de ressources. Après, je suis très content d'utiliser ces langages, il ne faut juste pas se voiler la face.

D'ailleurs, on peut faire du calcul matriciel en Python qui soit aussi performant que le code C équivalent. Ça n'a absolument rien de magique, car les bibliothèques bien écrites (comme numpy) sont codées en C, et le code Python (qui est la seule chose que le développeur voit, et qui sera facile à écrire et concis) ne sert que de ciment au code qui calcul. Du coup, on se moque que le code Python ne soit pas très performant, vu qu'on n'y passe qu'un pouillème du temps de calcul.

Ok, merci encore pour toutes ces réponses.

pour les catégories ou les flux publics, je pensais à la possibilité de mettre des flux ou des groupes de flux visibles d'autres personnes, avec une page proposant ces groupes déjà prêts à être ajoutés dans une sélection perso.

Merci pour tes réponses. Je n'ai pas encore eu le temps de m'y plonger sérieusement, mais je note pour plus tard, dans ma liste de choses à installer ^ ^

Peut-on l'utiliser en reverse proxy, plus simplement ?

Y a-t-il moyen de compiler facilement et de l'exporter sous forme de .deb ?
De plus, si je comprends bien, la conf' est écrite dans un fichier .py au milieu du code. Serait-il envisageable de l'exporter dans un .ini ?

Que se passe-t-il pour la mise à jour de la base de données si tu changes le modèle ? Je suis habitué au système de migrations de Django, mais je ne connais pas du tout Flask.

Encore une question : peut-on partager ou rendre publiques des catégories ? Je n'ai pas vu de telle option en me logguant rapidement.

Je suis également franchement intéressé. Ça me paraît pas mal du tout ! Je n'ai pas eu le temps de tester, mais je le mets sur ma liste de choses à installer.

Par pur plaisir d'être pénible, j'aurais quelques remarques, uniquement basées sur la doc et liées à mes petites manies :

• pour moi, un projet Python devrait s'installer via pip (quitte à avoir une commande pour créer la doc), ou via des paquets (type .deb ou .rpm), le tout associé à un fichier de conf' : c'est toujours plus agréable d'avoir une seule méthode pour installer tous les projets, et de pouvoir les installer sans accès internet. C'est en tout cas ainsi que je raisonne pour mes projets perso (basés sur Django), mais j'ai l'impression que ce n'est pas le cas ici.
• y a-t-il moyen d'utiliser le REMOTE_USER (ou HTTP_REMOTE_USER) pour authentifier l'utilisateur ? j'aime bien avoir mes utilisateurs authentifiés via Kerberos.

C'est un bête Mac Mini. Quant à la consommation, je ne l'ai pas fait directement, mais d'autres que moi l'ont mesurée.