flan a écrit 1830 commentaires

Ou alors tout simplement ne pas passer par des clefs, mais par un système comme Kerberos (qui permet l'authentification à deux facteurs) couplé à des netgroups stockés dans du LDAP. Ça permet de faire de la gestion de droits assez fine, tout en étant centralisée et modifiable via une interface web unique.

Et c'est dans ces moments-là qu'on voit les limites de VIM.
Dans mon IDE favori, quand je change un raccourci clavier, il m'indique immédiatement la présence de conflits, dès que j'entre le nouveau raccourci clavier.

Au final, j'ai beau avoir passé de longues heures à configurer un VIM pour faire du Python, il n'arrive toujours pas à la cheville de mon IDE brut de fonderie. Oui, on peut peut-être tout faire avec VIM, mais à quel prix…

C'est à mes yeux la meilleure interface pour VIM, et de (très) loin, surtout quand on la compare à VIM dans un terminal ou à GVIM/Linux ou GVIM/Windows.

Pour moi, la grosse différence entre les deux, c'est qu'un éditeur de texte concerne un fichier, alors que l'IDE va s'occuper de projets.

Avec un éditeur de texte, tu peux ouvrir n'importe quel fichier de façon unitaire, sans te soucier de l'endroit où tu es (il n'y a pas de contexte). L'IDE possède un contexte (par exemple les bibliothèques externes, la version du langage utilisée, du compilateur, où sont situés les tests, les réglages choisis pour les warning, etc.), ce qui change tout en termes de productivité.

Je vois deux gros problèmes :

• on ne peut pas réutiliser le mot methods
• ça veut dire que les méthodes sont des choses un peu à part, différentes des autres attributs.

En Python, ça me semble plus cohérent pour deux raisons :
* les méthodes sont des attributs au même titre que les autres. Et comme tout en Python, ce sont des objets comme les autres. La différence, c'est qu'ils ont une méthode (ou un attribut) __ call __.
* toutes les méthodes s'appellent mon_objet.ma_methode. Il n'y a pas d'attributs avec des noms particuliers comme >>, & ou encore [].

As-tu des exemples en particulier ?

Manifestement, avec tika utilisé par ElasticSearch, ça fonctionne plutôt pas mal :) Et ça permet de prendre en compte autre chose que le pdf (docx, odt, etc.).

Au passage, les systèmes d'indexation ne correspondaient pas à ce que je voulais faire, même si mon ordi en utilise un depuis début 2005 :)

Je n'avais pas spécialement envie d'utiliser un programme externe, à vrai dire. La solution proposée par ElasticSearch me convient tout à fait, même si elle doit consommer un peu plus d'espace disque (mais vu les volumes considérés, ce n'est pas grave).

Ah oui, en effet.

Malheureusement, ça m'a l'air compliqué d'extraire le contenu des PDF en Python 3.3, je risque de passer outre (en partant du principe que je n'aurais pas trop de fichiers), en attendant de trouver une meilleure solution. Merci pour l'info, en tout cas !

je bosse sur un petit site pour stocker mes documentations (notamment celles de langages ou de bibliothèques que j'utilise), et j'aimerais ajouter le support des PDF avec une indexation avec ElasticSearch.

J'ai l'impression que c'est possible ( http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-attachment-type.html ). Si je comprends bien, j'envoie simplement à ElasticSearch une requête POST qui contient ce message JSON (avec mon PDF en base64), et il sera indexé proprement. Me trompé-je ?
Et si je lui passe une archive ZIP avec plein de HTML dedans, fonctionnera-t-il aussi bien ?

Ça m'enlèverait une bonne épine du pied !

Quand on regarde sur un an, ça ne bouge quand même plus beaucoup : https://github.com/ArchipelProject/Archipel/graphs/commit-activity

C'est dommage, j'aimais bien l'idée

Ça m'a l'air un peu loin de Gitlab, malheureusement :( Enfin, je regarderai quand même le moment venu, merci :)

En effet :) pour le coup, ça fait quelques années qu'OS X est passé à launchd et personne ne s'en plaint ; je ne vois pas pourquoi on se plaindrait davantage sur Linux avec systemd (en termes de complexité et de fonctions, ils sont grosso-modo équivalents).

De mémoire, le passage à été progressif sur OS X, par exemple crond est resté pendant une ou deux versions.

Perso, j'aurais plutôt parlé d'OS X, qui doit avoir 6 ou 7 fois plus de présence que Linux (sur les ordis classiques, en tout cas). C'est aussi un vrai UNIX (avec la certification notamment).

Ce n'est pas si évident.
Imaginons en plus qu'une boîte se mette volontairement en déficit à force de proposer des prix extrêmement bas pour couler la concurrence, avant de pouvoir remonter tranquillement ses prix une fois que la concurrence est éliminée. Non, je ne pense absolument pas à Amazon.

Si on limite l'amende proportionnellement au bénéfice, alors celle-ci sera ridicule, bien que si elle pratiquait des prix « normaux », elle pourrait être largement bénéficiaire, et donc payer une amende bien plus forte.

S'il n'y avait que ça comme affreux anglicisme : on voit quand même de plus en plus assumer une supposition, adresser puis fixer un problème, être confortable, demander une question, un raisonnement consistant, etc.

Je ne connaissais pas du tout gitlab, et ça paraît plutôt pas mal.

Je sais que dans quelque temps je vais refaire ma forge perso (actuellement basée sur du svn + redmine, avec du github pour des projets publics), et gitlab me paraît un bon candidat. C'est simplement dommage à mes yeux que ça soit en Ruby, va falloir que j'apprenne à faire avec… (ce n'est pas une critique de Ruby, c'est qu'autant je maîtrise le déploiement des sites en Python, autant je ne connais rien en Ruby)

Accessoirement, Archipel a l'air plus ou moins mort :(

Juste par curiosité, où sont les problèmes entre clang et le kernel ? Parce que s'il ne compile pas à cause d'options spécifiques à GCC et qui ne sont pas dans le standard, le chemin à faire n'est pas forcément pour clang.

Je ne vois pas trop où tu veux en venir, à vrai dire. Montrer qu'Apple fait son beurre avec du logiciel propriétaire, qui lui permet de vendre le matériel associé avec des marges confortables ? Ce n'est pas non plus une grande nouvelle, ça. J'imagine que tu avais un message un peu plus subtil à faire passer…

Que ne comprends-tu pas dans « Apple distribue le code (avec les modifs) des projects BSD qu'ils utilisent sur opensource.apple.com. » ?

Bin a priori oui. mais bon, manifestement, ton opinion est toute faite, je ne suis pas sûr que ça vaille la peine de discuter.

Je ne vois pas le rapport avec le fait d'avoir les serveurs du projet chez soi. Ou alors peut-être fait-il ses tests sur l'environnement de prod ??? Je n'espère pas, ça ruinerait toute la réputation de sérieux du projet.

On peut déjà utiliser les modules R depuis Python (donc depuis Pandas) avec rpy2 :)

J'avais déjà entendu parler de Pandas, mais je n'ai pas eu l'occasion de m'en servir pour l'instant.

Mais que veux-tu dire exactement par gros volumes de données ? Pour moi, un gros volume de données, ça se compte en Po ou au moins en To, mais je ne pense pas que Pandas soit réellement adapté à de tels volumes.