flan a écrit 1830 commentaires

Visuellement, peut-être, mais les différences entre OS X et Linux se n'arrêtent pas à un simple thème graphique ou à une interface « épurée » (ou minimaliste, selon les goûts), loin de là. On pourrait citer beaucoup d'autres différences, plus ou moins profondes, et qui peuvent plus ou moins changer le confort au quotidien ; bien sûr, tout dépend des goûts et des façons d'utiliser son ordi.

On ne risque pas de savoir si c'est un OIV ou non : la liste est tenue secrète.

Pourquoi y aurait-il UNE bonne stratégie ?

Il y a plein d'entreprise différentes, avec plein de stratégies différentes pour gagner de l'argent, et que chacun considérera plus ou moins morales.
En l'occurrence, je ne trouve pas celle-ci choquante et elle me convient plutôt pas mal (même si elle pourrait encore plus me convenir s'ils mettaient en libre toutes les fonctionnalités de la pro).

Oui, mais ça permettrait d'avoir plus facilement les fonctions Enterprise. Après, tu peux rajouter un certain nombre de fonctions de façon détournée avec les webhooks, même si c'est loin d'avoir la souplesse de vrais plugins.

Je suis d'accord avec toi sur le fond, ça serait 'achement mieux avec des plugins, mais je trouve déjà pas mal ce que l'on a déjà =)

Oui, ça ne te choquerait pas si en gros tu pouvais avoir le beurre et l'argent du beurre (vu que le but est clairement d'avoir les fonctionnalités de la version entreprise sans son prix).

Il faut plutôt voir l'autre aspect : ils auraient pu le garder totalement propriétaire comme Github, et ils ont quand même fait une version libre (même si légèrement incomplète).

Après, tu as toujours la possibilité de le forker (et de maintenir le fork, ce qui n'est sûrement pas évident), voire tout simplement de ne pas l'utiliser.

Et pourtant, je suis affecté par ce comportement (vu que j'avais dû patcher la version libre pour avoir une authentification Kerberos et ça m'arrangerait bien qu'elle soit prise en compte directement).

Mais d'un autre côté, il faut se mettre à leur place. Ils gagnent de l'argent en vendant leur licence entreprise, et il faut bien qu'elle garde des avantages par rapport à la version gratuite.

Personnellement, ça ne me choque pas, même si j'aimerais bien avoir la version entreprise gratuitement. Ils auraient très bien pu rester en 100% propriétaire.

L'ancien système reposait sur beaucoup de comptables, qui ne sont plus là. Pas évident de les réembaucher du jour au lendemain.

Pour ce prix, ce n'est pas un nouveau logiciel, mais une adaptation d'un logiciel existant (du SAP)…

Non, il dit « il y a vraiment peu de raisons d'utiliser un stockage texte quand il y a une meilleure option disponible »

Traduction : quand le binaire est meilleur, il ne voit pas de raison d'utiliser du texte.

Question bête pour la structuration des données.

Est-ce qu'une bête base de données SQL classique (sqlite quand on est en local, ou pgsql/mysql si on veut faire plus compliqué) ne pourrait pas convenir ? Quel est l'intérêt d'un format binaire spécifique alors que du SQlite dispose déjà de milliards d'outils ?

Gitlab utilise une base de données classique (postgres ou mysql). J'ai donc fait un petit script (avec l'ORM de Django vu que je maîtrise un minimum) qui écrit directement les utilisateurs et les groupes dans la base de données de Gitlab.

s%fichier large%gros fichier%
(enfin, je pense)

On ne parle pas spécialement d'utilisateur, on parle de filtrage des communications entre l'intranet et l'internet. Ces communications peuvent être faites par les utilisateurs, ou par des spywares qui vont communiquer en HTTPS pour se noyer justement dans le flux licite.

Après, pour le digne de confiance, il faut bien distinguer deux niveaux : les utilisateurs malveillants (concrètement, on ne doit pas pouvoir faire grand-chose contre eux à mon avis), et les utilisateurs négligents (là, fliquer peut aider pas mal, mais il faut qu'ils soient prévenus).

Bien sûr, tout dépend du niveau de sécurité demandé, mais c'est parfois nécessaire. Ça ne me choquerait pas qu'il y ait pas mal de mesures de sécurité pour des ministères comme Bercy.

mais l'Allemagne cherche à récupérer toute la partie intéressante (ils ont notamment essayé de déménager les bureaux de conception d'Airbus de Toulouse à Hambourg). De notre côté, on se laisse plutôt faire…

Parfois, la sécurité informatique prime, c'est normal de devoir surveiller ce qui sort de ton réseau local quand il y a potentiellement des informations un peu sensibles (je pense à Bercy, par exemple).

Tout le monde ne suit pas cette logique : par exemple, Windows 10 (prévu pour la mi-2015) a les mêmes prérequis matériels que Windows Vista (sorti en 2007, soit 8 ans avant).
Pourtant, il y a pas mal de nouveautés en termes d'interface qui arrivent avec cette version (qu'on aime ou pas, c'est un autre débat).

Je ne sais pas comment je fais, mais ça ne m'est jamais arrivé de rajouter des bugs comme ça. Peut-être que mon IDE y est pour beaucoup, mais ça ne m'a jamais dérangé.

Il suffit de faire comme tout le monde et de suivre la PEP008 (qui décrit une norme de code à suivre), et tu n'as alors aucun problème.
Globalement, la PEP008 est très suivie, la plupart des codes Python que j'ai pu relire s'y conforment. Du coup, on a un écosystème assez homogène à ce niveau là et il est facile de se plonger dans le code d'un autre.

D'une part parce que je ne connaissais pas ( :D ), d'autre part c'est plus lourd à utiliser que DjangoFloor :

• pas de classe à définir
• possibilité de réutiliser les variables au sein de variable (par exemple je définis LOCAL_PATH, puis je redéfinis les autres valeurs avec : STATIC_ROOT = '{LOCAL_PATH}/static' )
• tu peux te passer des --configuration ou de export DJANGO_CONFIGURATION en utilisant un fichier nommé monprojet-manage (à la place de manage.py)
• il va chercher un fichier de conf' local (qui ne sera pas donc versionné, important quand il y a des mots de passe).

DjangoFloor est un module Python (et une app Django), donc tu peux le mettre à jour facilement.
Pas de merge à faire, vu que ses fichiers restent séparés de ceux du projet (et également séparés du fichier de conf local).

Normalement, les settings Django font partie du code « maison ». Avec DjangoFloor, les settings n'est plus dans le code maison, il se contente d'aller piocher dans le code maison les paramètres qui changent (puis dans la conf locale les paramètres spécifiques).

Mais MrBob rajoute un outil supplémentaire. Là, on utilise uniquement easy_install/pip (pour rester en mode Python) ou apt/yum (si on a pris la peine de les packager avec les setuptools), deux types d'outils bien intégrés avec les outils classiques de déploiement (Ansible, Puppet, Salt, etc.). On déploie un paquet (dont on ne touche pas les fichiers) et on écrit un fichier de conf, et c'est tout.

Pour moi, cookiecutter permettait de créer un début de code pour un nouveau projet, pas d'en déployer un existant.
L'inconvénient d'un template super complet, c'est que s'il est modernisé, alors tu dois modifier les projets existants à la main.

uwsgi -> un serveur applicatif, un peu l'équivalent de Tomcat pour Python (et quelques autres langages). En l'occurrence, je ne l'ai pas mis en dépendance explicite
bootstrap3 (django-bootstrap3 et django-admin-bootstrapped) -> une feuille CSS généraliste pour avoir un site web qui ressemble à quelque chose par défaut
font-awesome -> une feuille CSS avec des icônes sous forme de caractères d'une police faite sur mesure
CSS et JS (django-pipeline, jsmin et rcssmin) -> fusionne et minimise les feuilles CSS et fichiers JS
gestion de tâches (celery via Redis) ->
cache, websockets et sessions (django-websocket-redis, django-redis-sessions-fork, django-redis-cache) -> les websockets sont un moyen de faire des communications bi-directionnelles sur une page web, en gardant une connexion active
django-debug-toolbar
gunicorn -> un serveur applicatif 100% Python

Il y a uniquement gunicorn en dépendance, pour des raisons de simplicité (pas de module C à compiler…). En revanche, le script pour utiliser uwsgi est fourni (qui se contente d'importer le bon module, au final).

La place à l'intérieur du sac n'est pas extensible, tout simplement, et je me pose souvent comme contrainte de ne partir qu'avec ce sac.

Ou alors on accepte de rajouter trois millimètres d'épaisseur à la machine, ce n'est pas la mort non plus… En pratique, le poids et les dimensions (largeur x longueur) me paraissent beaucoup plus importants au quotidien que l'épaisseur.

Ça dépend beaucoup des gens. Pour moi, largeur et longueur ont peu d'importance tant que ça tient dans mon sac. Par contre, je préfère avoir l'ordi le plus fin possible, et les 3 mm comptent à ce niveau-là.