Comment c'est fait ? Je veux dire Est-ce que c'est une simple application Java qu'il faut lancer régulièrement via cron ? Ou est-ce que c'est autonome et ça se lance comme un deamon ?
Est-ce qu'il y a quelque chose pour le superviser (connaître la quantité de données transféré) ?
Est-ce qu'il est possible (ou envisageable via un peu de développement) d'avoir un fichier de ldif en sortie plutôt qu'une connexion direct à un annuaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'était je crois l'argument de Linus pour ne pas utiliser mercurial et plutôt développer git. Récupérer l'existant est en effet très important (même d'un point de vu non technique juste pour l'histoire d'informatique que ça représente). Je ne pensais pas que ça posait tant de problème (notamment parce que le noyau linux l'a lui même fait), mais c'est vrai que depuis cvs ce n'est pas forcément très simple (d'autant qu'il faut, je présume, prévoir un temps en double phase avec les 2 gestionnaires, le temps de tester).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ce que je ne saisi pas c'est que soit tu es capable de faire ça et il n'y a pas de problème de merge (ce dont tu parlais au départ) soit (comme tu le dis à un moment) il y a un couplage fort entre ce que tu fais et ce que les autres font et ça me semble difficile d'être systématiquement capable d'avoir un code testable et qui ne casse rien en un temps court.
Le pire dans tout ça c'est que dans tous les cas j'ai l'impression qu'un DCVS va de toute manière t'apporter un gain.
Si tu es capable d'avoir ce genre de petits commits, tu peut très bien garder tes commits locaux, les faire à la fréquence qui te convient et faire des rebase quotidiens. Tu poussera ton code une fois que ta fonctionnalité est terminé. Ça ne gêne en rien le fait de faire du développement agile. au contraire ça te permet d'ajouter ou de retirer ta fonctionnalité de manière très simple. Pour pouvoir faire une démonstration au client et qu'il puisse dire que finalement ça ne l'intéresse pas sans que ça représente du travail en plus de retirer ton code (comme tu as soit un commit soit une série de commits qui se suivent tu pourra sans effort garder ces patchs sous le coude pour historiques par exemple). De plus si tu fais de l'agile en principe tu as un paquet de test et si tu n'a pas de politique de test à chaque commit ou push parce que les tests prennent trop de temps tu as le bisect qui va te rendre de bons services.
Je comprends bien que tout le monde ne se mettent pas aux DCVS. C'est vraiment compliqué et je vois déjà suffisament de monde qui ont du mal avec subversion (difficulté de gestion des merges, commits sans message ou avec message inutile, difficulté de gestion des branches ou des tag,…) pour ne pas les accablés un peu plus encore avec un DCVS. Mais d'un point de vu fonctionnel, je ne vois vraiment pas ce que tu perds avec un DCVS (l'argument des développeurs OpenBSD étant qu'avec les DCVS gérer les merges est trop simple…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu veux dire que tu arrive à avoir quelque chose de testable (de testé et qui ne casse pas les autres tests) dans du code qui a un fort couplage avec d'autres développement en 2 jours (et à le maintenir ça tous les 2 jours) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu trouve que tout le monde qui envoie des commit dans un même dépôt très fréquemment ça scale ? Si tu le fait avec quelques développeurs ça peut marcher, si vous êtes plus ça ne me semble pas réaliste. Ton dépôt central devient un amas de travail en cours divers et de qualité assez faible, ton historique est inutilisable,…
En quoi c'est un problème ?
Ben tu gêne tout le monde. Si tu veux lancer une analyse statique du code tu as des faux positifs, potentiellement ton code à moitié fini a des effets de bords que tu n'a pas encore imaginés ou pris en compte,… Tu augmente la charge globale de tous le monde pour prendre en compte ton travail, alors que si c'est ton travail, ce serait logique que ce soit à toi que reviens la charge d'intégrer proprement ton code. Tu gagne un historique propre. Pour gérer les gros merge, d'une part tu va naturellement avoir tendance à écrire du code moins invasif, tu ça va te pousser à communiquer avec les développeurs qui travaillent sur la même portion de code que toi (et ça c'est bien parce que c'est pas parce qu'il n'y a pas de conflit détecté par ton VCS qu'il n'y a pas de conflit entre vos travaux) et ça pousse à écrire des tests. Bref oui c'est pas forcément simple, mais ça pousse de bonnes pratiques.
Tu n'es pas obligé d'activer l'option dans le système de compilation.
Si tu as un couplage tellement fort que tu dois passer ton temps à faire des merges je doute que tu puisse le faire proprement.
D'ailleurs rien ne t'interdit de faire 300 rebase par jour pour que le jour où tu pousse tes modif' tu n'ai pas de gros merge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne comprends pas ce que tu dis.
Soit ça signifie que tu commit du code non fini soit que pour toi tout développement prends moins de 2 jours. Sinon le problème est identique c'est juste que tu as le problème au moment de chaque fois que tu push et pas quand tu merge.
Après entre faire un rebase quotidiens et en faire un de temps en temps (juste avant le push) c'est à mon avis dépendant du projet et de la tâche que tu as à faire. Si vous êtes plusieurs à travailler sur des bouts du programme fortement couplés, c'est à mon avis une bonne idée de discuter, si ce sont des modules indépendants, ça ne pose pas de problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Non j'essaie d'être clair. D'un coté on se demande pourquoi est-ce qu'ils utilisent un outil de l'autre on est horripilé parce que tel logiciel n'est plus libre. D'un coté c'est technique et on ne fait pas du chantage à l'utilisation, de l'autre on se pose juste une question technique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne crois pas avoir dis à quelqu'un qu'il ne devrait pas critiquer Mozilla, mais plutôt qu'il pourrait plus influer sur le projet en s'impliquant. Ici personnellement je me tamponne de savoir ce qu'ils utilisent, ils pourraient écrire le code avec wordpad et versionner avec cpold, ça ne touche pas ce que je fais, ni ce que je fais de leur logiciel, alors que souvent les critiques envers Mozilla sont plus politiques, on entend souvent dire qu'il faut quitter Firefox, parce qu'il n'est plus libre ou à la traîne. Je sais pas si c'est très clair, mais d'un coté c'est une plainte et on dit qu'il ne faut plus utiliser les logiciel final, alors que là c'est plus une remarque sans faire le moindre commentaire sur la qualité du logiciel fourni finalement.
Ici pour moi, il est plus question de discuter d'un choix technique fais par des gens compétents et qui semble à première vu dépassé (bien sûr on peut en discuter avec eux, mais pourquoi ne pas en parler entre membre de DLFP ? Je présume qu'ici aussi il y a des gens qui utilisent ou qui ont utiliser cvs et qui peuvent faire remonter des anecdotes sympa ou des commentaires pertinents). Autant dire que le C est vieux est un troll et encore beaucoup de projets de divers horizons, même nouveaux se font en C (et il y a tellement de troll là dessus que les raisons de sa longévité sont connus). Pour cvs, c'est plus surprenant, les BSD sont à ma connaissances les derniers à les utiliser, il existe pas ou peu d'hébergement cvs, il y a eu 2 vagues successives qui ont marqués leur époque svn et les dcvs (git puis hg en tête). Bref il semble qu'il n'y a plus grand chose pour défendre cet outil, c'est donc pas tout à fait idiot ou malsain de se demander pourquoi ce projet en particulier (et peut être les autres BSD) continuent à travailler avec ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je suis bien content que les devs OpenBSD se soient lancés dans une méga-chirurgie parce que c'est le seul moyen pour sauver le patient.
Moi je suis content que tout ça a :
donné une nouvelle impulsion aux bibliothèques SSL/TLS, il y a des chances qu'une concurrence se mette en place entre OpenSSL, LibreSSL et peut être d'autres comme GnuTLS ou ice ;
montré que le COTS avec du logiciel libre n'est pas tout à fait gratuit et qu'il est important de s'intéresser à la qualité et la pérennité de ce que l'on utilise.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est idiot. Ça veut dire qu'il s'oppose à toutes lois et toutes règles parce que leur existence représente l'abolition de la liberté pour l'ensemble du monde humain, mais dans le même texte, il indique les règles de cette liberté. C'est une oxymore :
« Si quelqu'un ou quelque chose te dis ce que tu as le droit de faire ou non, tu n'es pas libre », « moi je te dis que ton devoir c'est de respecter la liberté de ton prochain ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Procès d'intention ? ÀMHA ils ont plutôt des problèmes techniques pour arriver à avoir ce qu'ils veulent avec XMPP, sinon ils auraient fait comme ils l'ont déjà fait en poussant jingle (d'ailleurs à l'époque ça n'avait pas plus parce que tout le monde en parlait depuis des années et que eux sans perdre leur temps à discuter des titres et des sous-titre de chaque XEP avaient implémentés le bouzin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
hum, ne pas réinventer la roue? au premier accès concurrent, c'est des heures de perdues à comprendre ce qu'il s'est passé, à reproduire, fixer et tester.
Si tu modélise mal Si ton modèle de données deviens bloquant, tu va passer des heures à faire ta migration de données et tu souffrira lorsque ce sera utilisé par d'autres. Il n'y a pas que les accès concurrents qui posent problèmes. D'autant que là, on est dans un cas où il n'y en a pas.
C'est pas un problème, mais pendant ce temps là, le fork de microbe aura ajouté les nouvelles fonctionnalités que les utilisateurs voulaient.
C'est de la supputation et c'est à mon avis là le problème. On ajoute une couche parce que peut être qu'un jour on en aura besoin. Pourquoi ne pas faire tout ça dans un bundle OSGi/JavaEE comme ça si tu veux ajouter un module de supervision des paquets qui transitent sur le réseau, il te suffira d'écrire un nouveau bundle OSGi et de le déployer à chaud ?
Bien sûr sqlite ce n'est pas felix, mais l'idée c'est de faire ses choix sans trop imaginer le future parce que ça n'est pas souvent très utile. Après savoir où mettre le curseur est un choix comme un autre.
Et donc, pourquoi les dépendances suivantes?
Parce que ça lui plaît ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc tu as le choix : utiliser LibreSSL, un CVS « daté », mais actif, avec des gens qui cherchent à faire les choses bien; ou utiliser le git utilisé par le projet OpenSSL, mais qui se traîne des bugs et des archaïsmes désormais connus de tous.
Oh ! C'est pas manichéen ça au moins. Aujourd'hui OpenSSL a le soutien de Core Infrastructure Initiative et depuis la fameuse faille est bien plus actif.
Donc on est face de 2 projets qui ont la même base de code au moment où le second a était créé, qui sont tous deux actifs, l'un qui utilise git l'autre cvs et 2 visions un peu différentes : chez LibreSSL, on retire des fonctionnalités pour tenter de réduire la surface d'attaque on se concentre sur une base plus petite qu'on souhaite plus sûr, de l'autre il n'est pas question de supprimer des fonctionnalités et on audite le code pour améliorer sa fiabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ouai m'enfin dire que cvs c'est pas trop mal parce qu'il n'empêche pas d'utiliser git, c'est pas vraiment un argument pour rester avec cvs. C'est simple pour le moment personne n'a dégainé un argument expliquant en quoi cvs c'est bien, juste des arguments pour dire que c'est pas trop mal (on peut l'interfacer avec git, avec une bonne gymnastique on peut avoir un semblant de comit, on peut utiliser un autre outil pour signer les commits (avec un commit par fichier !),…).
Je pense sincèrement qu'un débat sur les outils peut être intéressant. Ce serait intéressant de savoir pourquoi ils le gardent est-ce vraiment parce qu'ils n'ont pas encore trouvé d'intérêt aux DCVS (j'en doute vu qu'apparement certains travaillent avec git), qu'ils ont un usage particulier pas couverts par les DCVS, une question de performance ou de compatibilité,…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
L'art de raler dans toute sa splendeur. Laisse les utiliser les outils qu'ils veulent si ils font le boulot.
Tu veux dire qu'il faut attendre le prochain heartbleed ou la corruption des sources par un attaquant ? Comme ça on aura le droit de dire que CVS ça a 20 ans de retard sans s'entendre dire qu'on est un raleur, mais du coup tu pourra dire que c'est facile à dire après coup.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Firefox ne fait pas le poids face à Games of Thrones
Qui montre que le bras de fer n'est pas entre Firefox et Chrome/Safari/IE, mais entre Firefox et les contenus encapsulés ceux qui sont plébiscités par beaucoup y compris par des gens qui se disent contre les DRM. C'est ce plébiscite qui pousse Mozilla à implémenter des DRM.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Pourquoi ne pas prendre une capture d'écran du jeu et lui appliquer un effet de flou suffisant pour garder le menu visible (quitte à mettre un repère plus important autour des boutons) ? Tu peux même en prendre quelques unes et les changer aléatoirement ou un choisir un par écran de menu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Bref la technique implique que je fasse confiance à des tiers et comme le disait RMS, dans un autre contexte, un tiers de confiance est quelqu'un qui est susceptible de trahir notre confiance.
En fait il faut distribuer la confiance pour supprimer le single point of faillure. Ça peut se faire au sein d'une équipe avec des revus de code (comme c'est fait avec linux (pas forcément pour la sécurité)) ou à d'autres niveau (la linux fondation à veut faire de la relecture d'OpenSSL je crois avec Google, MS et d'autres qui financent) ça peut aussi être les distributions qui augmentent leur processus de vérifications (comme le projet débile pour lancer de l'analyse statique de code sur les paquets Debian ou litian qui augmente ses vérifications).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Un fork de openssl est, compte-tenu du contexte une bonne chose, mais ce logiciel va-t'il être implanté sur les serveurs? Dans les navigateurs? Quand?
Il est fort probable qu'ils ne cassent pas la compatibilité avec OpenSSL ou s'ils le font qu'ils le fassent le moins possible, ils ont eux aussi du code qui utilisent OpenSSL et qu'ils doivent maintenir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Architecture
Posté par barmic . En réponse à la dépêche Sortie de LDAP Synchronization Connector 2.1.0. Évalué à 5.
Comment c'est fait ? Je veux dire Est-ce que c'est une simple application Java qu'il faut lancer régulièrement via cron ? Ou est-ce que c'est autonome et ça se lance comme un deamon ?
Est-ce qu'il y a quelque chose pour le superviser (connaître la quantité de données transféré) ?
Est-ce qu'il est possible (ou envisageable via un peu de développement) d'avoir un fichier de ldif en sortie plutôt qu'une connexion direct à un annuaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 4.
C'était je crois l'argument de Linus pour ne pas utiliser mercurial et plutôt développer git. Récupérer l'existant est en effet très important (même d'un point de vu non technique juste pour l'histoire d'informatique que ça représente). Je ne pensais pas que ça posait tant de problème (notamment parce que le noyau linux l'a lui même fait), mais c'est vrai que depuis cvs ce n'est pas forcément très simple (d'autant qu'il faut, je présume, prévoir un temps en double phase avec les 2 gestionnaires, le temps de tester).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 4.
Ce que je ne saisi pas c'est que soit tu es capable de faire ça et il n'y a pas de problème de merge (ce dont tu parlais au départ) soit (comme tu le dis à un moment) il y a un couplage fort entre ce que tu fais et ce que les autres font et ça me semble difficile d'être systématiquement capable d'avoir un code testable et qui ne casse rien en un temps court.
Le pire dans tout ça c'est que dans tous les cas j'ai l'impression qu'un DCVS va de toute manière t'apporter un gain.
Si tu es capable d'avoir ce genre de petits commits, tu peut très bien garder tes commits locaux, les faire à la fréquence qui te convient et faire des rebase quotidiens. Tu poussera ton code une fois que ta fonctionnalité est terminé. Ça ne gêne en rien le fait de faire du développement agile. au contraire ça te permet d'ajouter ou de retirer ta fonctionnalité de manière très simple. Pour pouvoir faire une démonstration au client et qu'il puisse dire que finalement ça ne l'intéresse pas sans que ça représente du travail en plus de retirer ton code (comme tu as soit un commit soit une série de commits qui se suivent tu pourra sans effort garder ces patchs sous le coude pour historiques par exemple). De plus si tu fais de l'agile en principe tu as un paquet de test et si tu n'a pas de politique de test à chaque commit ou push parce que les tests prennent trop de temps tu as le bisect qui va te rendre de bons services.
Je comprends bien que tout le monde ne se mettent pas aux DCVS. C'est vraiment compliqué et je vois déjà suffisament de monde qui ont du mal avec subversion (difficulté de gestion des merges, commits sans message ou avec message inutile, difficulté de gestion des branches ou des tag,…) pour ne pas les accablés un peu plus encore avec un DCVS. Mais d'un point de vu fonctionnel, je ne vois vraiment pas ce que tu perds avec un DCVS (l'argument des développeurs OpenBSD étant qu'avec les DCVS gérer les merges est trop simple…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 4.
Tu veux dire que tu arrive à avoir quelque chose de testable (de testé et qui ne casse pas les autres tests) dans du code qui a un fort couplage avec d'autres développement en 2 jours (et à le maintenir ça tous les 2 jours) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 4.
Tu trouve que tout le monde qui envoie des commit dans un même dépôt très fréquemment ça scale ? Si tu le fait avec quelques développeurs ça peut marcher, si vous êtes plus ça ne me semble pas réaliste. Ton dépôt central devient un amas de travail en cours divers et de qualité assez faible, ton historique est inutilisable,…
Ben tu gêne tout le monde. Si tu veux lancer une analyse statique du code tu as des faux positifs, potentiellement ton code à moitié fini a des effets de bords que tu n'a pas encore imaginés ou pris en compte,… Tu augmente la charge globale de tous le monde pour prendre en compte ton travail, alors que si c'est ton travail, ce serait logique que ce soit à toi que reviens la charge d'intégrer proprement ton code. Tu gagne un historique propre. Pour gérer les gros merge, d'une part tu va naturellement avoir tendance à écrire du code moins invasif, tu ça va te pousser à communiquer avec les développeurs qui travaillent sur la même portion de code que toi (et ça c'est bien parce que c'est pas parce qu'il n'y a pas de conflit détecté par ton VCS qu'il n'y a pas de conflit entre vos travaux) et ça pousse à écrire des tests. Bref oui c'est pas forcément simple, mais ça pousse de bonnes pratiques.
Si tu as un couplage tellement fort que tu dois passer ton temps à faire des merges je doute que tu puisse le faire proprement.
D'ailleurs rien ne t'interdit de faire 300 rebase par jour pour que le jour où tu pousse tes modif' tu n'ai pas de gros merge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 5.
Je ne comprends pas ce que tu dis.
Soit ça signifie que tu commit du code non fini soit que pour toi tout développement prends moins de 2 jours. Sinon le problème est identique c'est juste que tu as le problème au moment de chaque fois que tu push et pas quand tu merge.
Après entre faire un rebase quotidiens et en faire un de temps en temps (juste avant le push) c'est à mon avis dépendant du projet et de la tâche que tu as à faire. Si vous êtes plusieurs à travailler sur des bouts du programme fortement couplés, c'est à mon avis une bonne idée de discuter, si ce sont des modules indépendants, ça ne pose pas de problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mais encore
Posté par barmic . En réponse au journal CodeLauncher: un petit serveur maison pour exécuter rapidement du code C ou Python. Évalué à 8.
Tu n'a probablement pas de tablette.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mais encore
Posté par barmic . En réponse au journal CodeLauncher: un petit serveur maison pour exécuter rapidement du code C ou Python. Évalué à 4.
De toute manière c'est c'est pas rm qui le fait tu écris le programme C qui le fait, ou tu écris un programme C qui fait une fork bomb ou …
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 2.
Non j'essaie d'être clair. D'un coté on se demande pourquoi est-ce qu'ils utilisent un outil de l'autre on est horripilé parce que tel logiciel n'est plus libre. D'un coté c'est technique et on ne fait pas du chantage à l'utilisation, de l'autre on se pose juste une question technique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 2.
Je ne crois pas avoir dis à quelqu'un qu'il ne devrait pas critiquer Mozilla, mais plutôt qu'il pourrait plus influer sur le projet en s'impliquant. Ici personnellement je me tamponne de savoir ce qu'ils utilisent, ils pourraient écrire le code avec wordpad et versionner avec cpold, ça ne touche pas ce que je fais, ni ce que je fais de leur logiciel, alors que souvent les critiques envers Mozilla sont plus politiques, on entend souvent dire qu'il faut quitter Firefox, parce qu'il n'est plus libre ou à la traîne. Je sais pas si c'est très clair, mais d'un coté c'est une plainte et on dit qu'il ne faut plus utiliser les logiciel final, alors que là c'est plus une remarque sans faire le moindre commentaire sur la qualité du logiciel fourni finalement.
Ici pour moi, il est plus question de discuter d'un choix technique fais par des gens compétents et qui semble à première vu dépassé (bien sûr on peut en discuter avec eux, mais pourquoi ne pas en parler entre membre de DLFP ? Je présume qu'ici aussi il y a des gens qui utilisent ou qui ont utiliser cvs et qui peuvent faire remonter des anecdotes sympa ou des commentaires pertinents). Autant dire que le C est vieux est un troll et encore beaucoup de projets de divers horizons, même nouveaux se font en C (et il y a tellement de troll là dessus que les raisons de sa longévité sont connus). Pour cvs, c'est plus surprenant, les BSD sont à ma connaissances les derniers à les utiliser, il existe pas ou peu d'hébergement cvs, il y a eu 2 vagues successives qui ont marqués leur époque svn et les dcvs (git puis hg en tête). Bref il semble qu'il n'y a plus grand chose pour défendre cet outil, c'est donc pas tout à fait idiot ou malsain de se demander pourquoi ce projet en particulier (et peut être les autres BSD) continuent à travailler avec ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 4.
Moi je suis content que tout ça a :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Que de mauvaises intentions
Posté par barmic . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 3.
C'est idiot. Ça veut dire qu'il s'oppose à toutes lois et toutes règles parce que leur existence représente l'abolition de la liberté pour l'ensemble du monde humain, mais dans le même texte, il indique les règles de cette liberté. C'est une oxymore :
« Si quelqu'un ou quelque chose te dis ce que tu as le droit de faire ou non, tu n'es pas libre », « moi je te dis que ton devoir c'est de respecter la liberté de ton prochain ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Google
Posté par barmic . En réponse au journal Le chiffrement, c'est maintenant. Évalué à 2. Dernière modification le 20 mai 2014 à 09:33.
Procès d'intention ? ÀMHA ils ont plutôt des problèmes techniques pour arriver à avoir ce qu'ils veulent avec XMPP, sinon ils auraient fait comme ils l'ont déjà fait en poussant jingle (d'ailleurs à l'époque ça n'avait pas plus parce que tout le monde en parlait depuis des années et que eux sans perdre leur temps à discuter des titres et des sous-titre de chaque XEP avaient implémentés le bouzin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Premier retour
Posté par barmic . En réponse au journal Microbe : Un moteur de blog simple en Python. Évalué à 3.
Si tu modélise malSi ton modèle de données deviens bloquant, tu va passer des heures à faire ta migration de données et tu souffrira lorsque ce sera utilisé par d'autres. Il n'y a pas que les accès concurrents qui posent problèmes. D'autant que là, on est dans un cas où il n'y en a pas.C'est de la supputation et c'est à mon avis là le problème. On ajoute une couche parce que peut être qu'un jour on en aura besoin. Pourquoi ne pas faire tout ça dans un bundle OSGi/JavaEE comme ça si tu veux ajouter un module de supervision des paquets qui transitent sur le réseau, il te suffira d'écrire un nouveau bundle OSGi et de le déployer à chaud ?
Bien sûr sqlite ce n'est pas felix, mais l'idée c'est de faire ses choix sans trop imaginer le future parce que ça n'est pas souvent très utile. Après savoir où mettre le curseur est un choix comme un autre.
Parce que ça lui plaît ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 2.
Oh ! C'est pas manichéen ça au moins. Aujourd'hui OpenSSL a le soutien de Core Infrastructure Initiative et depuis la fameuse faille est bien plus actif.
Donc on est face de 2 projets qui ont la même base de code au moment où le second a était créé, qui sont tous deux actifs, l'un qui utilise git l'autre cvs et 2 visions un peu différentes : chez LibreSSL, on retire des fonctionnalités pour tenter de réduire la surface d'attaque on se concentre sur une base plus petite qu'on souhaite plus sûr, de l'autre il n'est pas question de supprimer des fonctionnalités et on audite le code pour améliorer sa fiabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à -1.
Waow on ne peut plus faire de remarques même un peu brutal ? Faut fermer linuxfr et aller sur Wikipedia.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 4.
Ouai m'enfin dire que cvs c'est pas trop mal parce qu'il n'empêche pas d'utiliser git, c'est pas vraiment un argument pour rester avec cvs. C'est simple pour le moment personne n'a dégainé un argument expliquant en quoi cvs c'est bien, juste des arguments pour dire que c'est pas trop mal (on peut l'interfacer avec git, avec une bonne gymnastique on peut avoir un semblant de comit, on peut utiliser un autre outil pour signer les commits (avec un commit par fichier !),…).
Je pense sincèrement qu'un débat sur les outils peut être intéressant. Ce serait intéressant de savoir pourquoi ils le gardent est-ce vraiment parce qu'ils n'ont pas encore trouvé d'intérêt aux DCVS (j'en doute vu qu'apparement certains travaillent avec git), qu'ils ont un usage particulier pas couverts par les DCVS, une question de performance ou de compatibilité,…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 2.
Bien sûr qu'on a le droit d'en dire ce qu'on veut ! Encore heureux !
Après ils ont tout à fait le droit de s'en foutre, mais ce n'est pas pour ça qu'on à pas le droit de commenter ce qu'ils font ou comment ils le font.
Donc oui rien que pour ton commentaire :
CVS ça pu, c'est un outil largement dépassé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 8.
Tu veux dire qu'il faut attendre le prochain heartbleed ou la corruption des sources par un attaquant ? Comme ça on aura le droit de dire que CVS ça a 20 ans de retard sans s'entendre dire qu'on est un raleur, mais du coup tu pourra dire que c'est facile à dire après coup.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de source
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 6.
Et subversion en apache/mit
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Tristan Nitot
Posté par barmic . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 8.
Tristant Nitot vient de poster un billet sur son blog forcément intéressant vu son degrès d'implication dans Mozilla :
http://standblog.org/blog/post/2014/05/19/Mozilla-et-les-DRM-une-autre-perspective
J'aime particulièrement le titre :
Qui montre que le bras de fer n'est pas entre Firefox et Chrome/Safari/IE, mais entre Firefox et les contenus encapsulés ceux qui sont plébiscités par beaucoup y compris par des gens qui se disent contre les DRM. C'est ce plébiscite qui pousse Mozilla à implémenter des DRM.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: soucis
Posté par barmic . En réponse au journal Newton Adventure 1.15. Évalué à 7.
Pourquoi ne pas prendre une capture d'écran du jeu et lui appliquer un effet de flou suffisant pour garder le menu visible (quitte à mettre un repère plus important autour des boutons) ? Tu peux même en prendre quelques unes et les changer aléatoirement ou un choisir un par écran de menu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: soucis
Posté par barmic . En réponse au journal Newton Adventure 1.15. Évalué à 5.
Je pense que c'est pour présenter jnuit.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mythe et mite pour ermite.
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 8.
En fait il faut distribuer la confiance pour supprimer le single point of faillure. Ça peut se faire au sein d'une équipe avec des revus de code (comme c'est fait avec linux (pas forcément pour la sécurité)) ou à d'autres niveau (la linux fondation à veut faire de la relecture d'OpenSSL je crois avec Google, MS et d'autres qui financent) ça peut aussi être les distributions qui augmentent leur processus de vérifications (comme le projet débile pour lancer de l'analyse statique de code sur les paquets Debian ou litian qui augmente ses vérifications).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mythe et mite pour ermite.
Posté par barmic . En réponse au journal Des nouvelles de LibreSSL. Évalué à 5.
Il est fort probable qu'ils ne cassent pas la compatibilité avec OpenSSL ou s'ils le font qu'ils le fassent le moins possible, ils ont eux aussi du code qui utilisent OpenSSL et qu'ils doivent maintenir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)