Je permets de corriger une erreur de grammaire qui ne semble pas fortuite puisque tu l'as commise 2 fois
je ne doute pas que vous saur~~ais~~ez me le faire savoir et que vous aur~~ait~~ez pleins de remarques
Sinon sur le fond:
Pour les données, il y a un aspect que ton analyse ne couvre pas, c'est le crowdsourcing.
Récupérer tes données n'enlèvera pas le fait qu'une partie de la valeur de celles-ci peut aussi provenir du fait qu'elles sont enrichies par le croisement de tes données avec celle des autres (exemple suggestions de tag sur delicious).
L'autre aspect le relie aux logiciels libre car l'ouverture des données doit venir en sus.
Un service ouvert outre tes données se doit aussi de fournir l'infrastructure logicielle qui permet d'héberger tes données sous une forme "libre" (type AGPL par exemple)
C'est le niveau 4
Selon "ma" conception (et elle n'engage que moi), un service ouvert idéal, le niveau 5, serait un service qui peut être distribué (données réparties ou répliquées) et hébergé sur plateforme libre
3 composantes donc:
Données accessibles + LL + collaboratif
Yacy en serait un bon exemple: http://yacy.net/fr/
Ceci représente une vraie liberté:
Celle de ne pas dépendre d'un fournisseur de service unique
Ok, vu le succès rencontré, l'exemple n'est peut-être pas le bon mais l'idée est bien là.
Y'aurait moyen de ne pas rendre les liens vers des sites fermés non cliquables (voir de ne pas les citer).
Sinon ceci s'apparente à du publi-reportage et devrait donc figurer dans les journaux.
Ou alors toutes les boîtes qui utilisent git ont le droit de faire leur pub ici ?
Atom, mieux que que tous les sites online, avec le surlignage et complètement interactif.
Bon ça ne supporte que les regex JS mais c'est sudffisant pour las usages courants et ok ça n'affiche pas les groups.
Et autant sur des sujets consensuels qui sont au coeur de "encyclopédies" classiques, Wikipédia n'a visiblement rien à redire (encore que ceux qui se prévalent desdites études sont les premiers à dire qu'une seule n'en fait pas une "souce fiable") autant sur des sujets plus pointus ça pêche parfois. Même si l'on comprend que les autres encyclopédies ne couvrent même pas ces sujets, parfois on aimerait un peu plus de densité et de confiance.
A l'occasion j'y jetterai un coup d'oeil. Je me souviens de ce projet d'encyclopédie lancé par Google et basé sur la "méritocratie" (un seul auteur, approuvé par ses relecteurs) et non sur la rédaction collective et la modération. Quelqu'un se souvient du nom ?
Ce fut un cuisant échec, mais les idées n'étaient toutes mauvaises quand on voit les querelles de chapelles qu'on trouve sur Wikipédia.
C'est codé en objective C ? Vraiment ?
Dans mes souvenirs c'était du python.
Vous passez bientôt à Swift ? Ok je sors.
(Au passage un petit bug: Dans le calendrier on doit pouvoir modifier la plage d'un rdv puisque le curseur change d'aspect, mais ça le déplace au lieu de ça. Chrome sous Windows)
Ma réflexion ne portait pas sur le fait que git communique ou non avec les autres dépôts qu'au travers des synchronisations. Je sais que les commandes dont tu parles existent mais elles n'ont pas la même finalité.
Ma remarque portait plutôt sur le fait que certains pensent que le hg incoming est un plus par rapport à Git alors qu'en fait cette commande vient juste pour rendre cohérente la conception de Hg.
Hg n'intègre pas de part sa conception, le fait de séparer la synchronisation des dépôts de l'intégration avec son code (merge).
Ceci à l'avantage de la simplicité dans certains cas mais peut s'avérer plus contraignants dans d'autres. Du coup cette commande pour inspecter les commits du dépôt distant est indispensable pour le bon fonctionnement de hg alors qu'elle ne l'est pas pour Git.
A l'inverse, le modèle de git est plus complexe à maîtriser. Combien de nouveaux venus sur Git qui ne comprennent pas la différence entre un git pull et un git fetch merge|rebase réclament cette commande ou sont rassurés de pouvoir browser le serveur avant de se synchroniser.
Avec git, tu fetches sa branche et tu utilises tous les outils à ta disposition pour faire ta comparaison, checkout y compris (build, …). et tu n'intègres que si tu le souhaites avant de pusher sur le "serveur". Tu peux laisser le soin de l'intégration à un autre et tu peux vérifier et communiquer sur vos changements respectifs (CI) sans pollution.
Avec hg, soit tu en passes par ta technique, comme un palliatif pour communiquer. Soit tu pulles et tu te retrouves avec 2 heads à résoudre, forcé à intégrer, si le serveur oblige à n'avoir qu'une seule head pour pouvoir lancer la CI.
C'est pour ça que beaucoup finissent par utiliser les plugins qui adoptent le comportement à la git, je pense.
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'est qu'avec hg cette possibilité est indispensable car dès que l'on pull en récupère immanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark). Une branche hg est plutôt un "flux" de développement qui à un moment donné, fait qu'on a plusieurs version concurrentes (plusieurs têtes en même temps) du même flux. un dépôt git, n'a qu'une référence pour une branche à tout moment (d'où les précautions avec le -force qui peut déplacer une tête et perdre de l'historique).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'ets qu'avec hg cette posdibilité est indispensable car dès que l'on pull en récupère inmmanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
C'est çà 3 mois sans bouffer quand tu es u ouvrier au SMIC et tout au bon vouloir de l'administration. L'arbitraire complet.
Et on ne parlera même pas du montant de l'indemnité.
CQFD.
Et je maintiens: tu dis de la merde et je le formulerais autrement si tu étais plus respectueux de tes contradicteurs.
Le constat est le suivant: si je décide de démissionner alors que j'ai cotisé 10 ans, je ne touche absolument rien sauf
à ce que mon patron soit d'accord pour une rupture à l'amiable ou que je rentre dans les clauses dérogatoires que tu cites (lisez-les pour vous marrer un peu).
Je n'ai donc aucune liberté de choisir et comme l'assurance chômage est obligatoire et n'est pas soumise à la concurrence, je ne peux pas en contracter une autre plus favorable à la place (sauf à ce que j'en prenne une en plus si j'ai les moyens).
Comme toi, je souhaite que ceci soit privatisé pour laisser la liberté à chacun de choisir l"assurance qui le représentera et là, un équilibre se rétablirait.
Le patronnat sait très bien que ceci est un moyen de pression et les affaires de rupture pour faute grave (lorsque ta clause de mobilité entre en jeu à l'autre bout de la France ou en Roumanie pour te faire craquer) sont légions. A l'inverse un employeur qui veut se faire la belle a intérêt à avoir un plan de rechange et bien souvent faire confiance au futur employeur qu'il ne le plante pas pendant le préavis.
Au fait tu lui reproches quoi au CDI exactement ?
Parce que des possibilité pour licencier un CDI il y en a pléthore.
Le jour ou celui qui choisira de démissionner sans l'accord de son patron ne sera pas tenu de crever de faim sans toucher le chômage alors qu'il a cotisé comme les autres. Bizarrement cette flexibilité là, le patron n'en veut pas.
Par contre, il voudrait bien pouvoir se délester sans contrainte et continuer de se gaver de subventions.
Et là le licenciement économique et là pour éviter les abus mais il existe bel et bien.
S'il devait y avoir un contrat unique pourquoi s'aligner sur le CDD et pas le CDI ?
On verrait si les artisans (le premier employeur de France parait-il) delocalisent …
Entre soulager un bourgeois d'une partie de sa fortune qu'il ne doit qu'à ses rentes ou à l'héritage colonial du passé et rétablir la ségrégation raciale …
Quand les libéraux mettent sur le même pied les 2 extrêmes, ils ne sont juste pas crédibles.
Posté par El Titi .
En réponse à la dépêche Fim 1.1.0.
Évalué à 3.
J'ai déjà eu l'occasion de tester ce soft pour mon propre cas d'utilisation que je décris :
Gérer un catalogue de fichiers qui garde une trace des fichiers que j'ai déjà utilisés et volontairement effacés.
Par exemple, si j'ai déjà visionné un podcast que j'ai mis de coté et que je le récupère à nouveau, je veux que le produit me le signale. S'il est nouveau, je veux qu'il l'insère et si c'est un doublon qu'il le ne rajoute pas au catalogue.
De part sa conception qui s'appuie sur l'historique, il permet de visualiser chaque différence mais ne permet pas de comparer de manière agrégée au catalogue entier (englobant les déjà vu), je n'y suis pas parvenu. Je n'ai pas besoins des états intermédiaire mais bien de pouvoir compare à tout mon catalogue présent et passé.
Du coup j'ai du mal à saisir l'intérêt.
Pour checker l'intégrité de fichier Ok (encore que pas besoin d'historique) mais
si c'est pour pouvoir gérer des gros fichiers avec Git, il vaut mieux se tourner vers un projet qui est soutenu par des grands du domaine (Github et Atlassian), qui ont uni leur force pour initier le projet suivant https://github.com/github/git-lfs
Au moins ça reste compatible de base avec Git et on bénficie de toute la tuyauterie associée, non ?
Du coup, il faut rajouter la ligne suivante dans la procédure d'install:
brew install coreutils
et editer le shell fim en remplaçant par greadline.
Il doit y avoir une autre solution plus propre (fournir une autre shell pour mac ou jouer avec le path et un symlink, …) mais je ne suis pas assez fortiche pour faire des recommandations.
J'ai testé sur un de mes dirs et ça marche nickel.
# Coincidence
Posté par El Titi . En réponse au journal Un service ouvert ?. Évalué à 3. Dernière modification le 18 février 2016 à 00:38.
Amusant que tu postes ce journal après ta réponse à une remarque:
http://linuxfr.org/news/weboob-une-version-1-1-pour-son-sixieme-anniversaire#comment-1644006.
Je permets de corriger une erreur de grammaire qui ne semble pas fortuite puisque tu l'as commise 2 fois
je ne doute pas que vous saur~~ais~~ez me le faire savoir
et que vous aur~~ait~~ez pleins de remarques
Sinon sur le fond:
Pour les données, il y a un aspect que ton analyse ne couvre pas, c'est le crowdsourcing.
Récupérer tes données n'enlèvera pas le fait qu'une partie de la valeur de celles-ci peut aussi provenir du fait qu'elles sont enrichies par le croisement de tes données avec celle des autres (exemple suggestions de tag sur delicious).
L'autre aspect le relie aux logiciels libre car l'ouverture des données doit venir en sus.
Un service ouvert outre tes données se doit aussi de fournir l'infrastructure logicielle qui permet d'héberger tes données sous une forme "libre" (type AGPL par exemple)
C'est le niveau 4
Selon "ma" conception (et elle n'engage que moi), un service ouvert idéal, le niveau 5, serait un service qui peut être distribué (données réparties ou répliquées) et hébergé sur plateforme libre
3 composantes donc:
Données accessibles + LL + collaboratif
Yacy en serait un bon exemple:
http://yacy.net/fr/
Ceci représente une vraie liberté:
Celle de ne pas dépendre d'un fournisseur de service unique
Ok, vu le succès rencontré, l'exemple n'est peut-être pas le bon mais l'idée est bien là.
# Pub déguisée
Posté par El Titi . En réponse à la dépêche Weboob : une version 1.1 pour son sixième anniversaire. Évalué à -10.
Y'aurait moyen de ne pas rendre les liens vers des sites fermés non cliquables (voir de ne pas les citer).
Sinon ceci s'apparente à du publi-reportage et devrait donc figurer dans les journaux.
Ou alors toutes les boîtes qui utilisent git ont le droit de faire leur pub ici ?
Merci !
[^] # Re: ack, Unicode
Posté par El Titi . En réponse à la dépêche Travailler avec des expressions rationnelles. Évalué à 4.
Merci !
J'avais presque oublié ce langage et en relisant ton post, auquel je n'ai presque rien compris …mais qui m'inspire un total respect, je me suis souvenu:
http://www.fastcompany.com/3026446/the-fall-of-perl-the-webs-most-promising-language
[^] # Re: Outils de coloration?
Posté par El Titi . En réponse à la dépêche Travailler avec des expressions rationnelles. Évalué à 2.
Atom, mieux que que tous les sites online, avec le surlignage et complètement interactif.
Bon ça ne supporte que les regex JS mais c'est sudffisant pour las usages courants et ok ça n'affiche pas les groups.
Mais quand même !
[^] # Re: Ça fait 15 ans que les vraies encyclopédies sont décédées
Posté par El Titi . En réponse à la dépêche Wikipédia a soufflé ses 15 bougies. Évalué à 2.
Merci,
Ca m'a permis de découvrir Citizendium qui a vocation rendre le contenu "spécialisé" plus fiable https://fr.wikipedia.org/wiki/Citizendium.
Et autant sur des sujets consensuels qui sont au coeur de "encyclopédies" classiques, Wikipédia n'a visiblement rien à redire (encore que ceux qui se prévalent desdites études sont les premiers à dire qu'une seule n'en fait pas une "souce fiable") autant sur des sujets plus pointus ça pêche parfois. Même si l'on comprend que les autres encyclopédies ne couvrent même pas ces sujets, parfois on aimerait un peu plus de densité et de confiance.
A l'occasion j'y jetterai un coup d'oeil. Je me souviens de ce projet d'encyclopédie lancé par Google et basé sur la "méritocratie" (un seul auteur, approuvé par ses relecteurs) et non sur la rédaction collective et la modération. Quelqu'un se souvient du nom ?
Ce fut un cuisant échec, mais les idées n'étaient toutes mauvaises quand on voit les querelles de chapelles qu'on trouve sur Wikipédia.
# Langage
Posté par El Titi . En réponse à la dépêche Sortie de la version 3 de SOGo. Évalué à 1. Dernière modification le 01 février 2016 à 18:38.
C'est codé en objective C ? Vraiment ?
Dans mes souvenirs c'était du python.
Vous passez bientôt à Swift ? Ok je sors.
(Au passage un petit bug: Dans le calendrier on doit pouvoir modifier la plage d'un rdv puisque le curseur change d'aspect, mais ça le déplace au lieu de ça. Chrome sous Windows)
[^] # Re: typescript ?
Posté par El Titi . En réponse à la dépêche Superpowers sort en libre/opensource. Évalué à 3.
Et accessoirement, la version 2 du framework à la mode de Google, Angular, s'appuie dessus.
[^] # Re: C'est le codage en virgule flottante
Posté par El Titi . En réponse au message Euh… comment dire… C'est bizarre.. Évalué à 2.
Ou plutôt elle arrondit.
Peut-être en effet.
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 3.
Merci pour ces éclaircissements.
Ma réflexion ne portait pas sur le fait que git communique ou non avec les autres dépôts qu'au travers des synchronisations. Je sais que les commandes dont tu parles existent mais elles n'ont pas la même finalité.
Ma remarque portait plutôt sur le fait que certains pensent que le hg incoming est un plus par rapport à Git alors qu'en fait cette commande vient juste pour rendre cohérente la conception de Hg.
Hg n'intègre pas de part sa conception, le fait de séparer la synchronisation des dépôts de l'intégration avec son code (merge).
Ceci à l'avantage de la simplicité dans certains cas mais peut s'avérer plus contraignants dans d'autres. Du coup cette commande pour inspecter les commits du dépôt distant est indispensable pour le bon fonctionnement de hg alors qu'elle ne l'est pas pour Git.
A l'inverse, le modèle de git est plus complexe à maîtriser. Combien de nouveaux venus sur Git qui ne comprennent pas la différence entre un git pull et un git fetch merge|rebase réclament cette commande ou sont rassurés de pouvoir browser le serveur avant de se synchroniser.
Une partie de la complexité de Git provient aussi du fait que ce qui est implicite pour Hg a dû faire l'objet de
beaucoup de contorsions et de balbutiements pour automatiser de manière acceptable le pull et faire le match entre l'upstream et le local alors que pour Hg … c'est juste la même branche.
En témoigne par exemple les évolutions successives sur les set-upstream, la config des refspecs et plein d'autres paramètres qu'il faut bien souvent tuner. Ou comment les git users se transforment en bookmarkeurs de Stackoverflow compulsifs:
http://stackoverflow.com/questions/6089294/why-do-i-need-to-do-set-upstream-all-the-time
http://stackoverflow.com/questions/10002239/difference-between-git-checkout-track-origin-branch-and-git-checkout-b-branch
…
[^] # Re: C'est le codage en virgule flottante
Posté par El Titi . En réponse au message Euh… comment dire… C'est bizarre.. Évalué à 3.
Mais pourquoi la calculatrice windows donne le bon résultat dans ce cas ?
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 6.
Ca montre bien les limites du modèle.
Avec git, tu fetches sa branche et tu utilises tous les outils à ta disposition pour faire ta comparaison, checkout y compris (build, …). et tu n'intègres que si tu le souhaites avant de pusher sur le "serveur". Tu peux laisser le soin de l'intégration à un autre et tu peux vérifier et communiquer sur vos changements respectifs (CI) sans pollution.
Avec hg, soit tu en passes par ta technique, comme un palliatif pour communiquer. Soit tu pulles et tu te retrouves avec 2 heads à résoudre, forcé à intégrer, si le serveur oblige à n'avoir qu'une seule head pour pouvoir lancer la CI.
C'est pour ça que beaucoup finissent par utiliser les plugins qui adoptent le comportement à la git, je pense.
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 3.
Je reposte puisque je ne peux pas "passer":
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'est qu'avec hg cette possibilité est indispensable car dès que l'on pull en récupère immanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark). Une branche hg est plutôt un "flux" de développement qui à un moment donné, fait qu'on a plusieurs version concurrentes (plusieurs têtes en même temps) du même flux. un dépôt git, n'a qu'une référence pour une branche à tout moment (d'où les précautions avec le -force qui peut déplacer une tête et perdre de l'historique).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 3.
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'ets qu'avec hg cette posdibilité est indispensable car dès que l'on pull en récupère inmmanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
[^] # Re: Dropbox
Posté par El Titi . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 2.
Ici on ne parle que de solutions basées sur des fichiers encryptés. Existe-il une appli libre comme 1Password que l'on puisse auto-héberger ?
[^] # Re: métriques
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 5. Dernière modification le 14 janvier 2016 à 11:18.
C'est çà 3 mois sans bouffer quand tu es u ouvrier au SMIC et tout au bon vouloir de l'administration. L'arbitraire complet.
Et on ne parlera même pas du montant de l'indemnité.
CQFD.
Et je maintiens: tu dis de la merde et je le formulerais autrement si tu étais plus respectueux de tes contradicteurs.
[^] # Re: métriques
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 3.
En quoi c'est faux ?
Le constat est le suivant: si je décide de démissionner alors que j'ai cotisé 10 ans, je ne touche absolument rien sauf
à ce que mon patron soit d'accord pour une rupture à l'amiable ou que je rentre dans les clauses dérogatoires que tu cites (lisez-les pour vous marrer un peu).
Je n'ai donc aucune liberté de choisir et comme l'assurance chômage est obligatoire et n'est pas soumise à la concurrence, je ne peux pas en contracter une autre plus favorable à la place (sauf à ce que j'en prenne une en plus si j'ai les moyens).
Comme toi, je souhaite que ceci soit privatisé pour laisser la liberté à chacun de choisir l"assurance qui le représentera et là, un équilibre se rétablirait.
Le patronnat sait très bien que ceci est un moyen de pression et les affaires de rupture pour faute grave (lorsque ta clause de mobilité entre en jeu à l'autre bout de la France ou en Roumanie pour te faire craquer) sont légions. A l'inverse un employeur qui veut se faire la belle a intérêt à avoir un plan de rechange et bien souvent faire confiance au futur employeur qu'il ne le plante pas pendant le préavis.
Quand au fait que ceci ne concerne pas le patronnat, c'est bizarre de constater qu'il fasse des propositions pour la réformer dans ce cas. qu'il se la boucle et laisse les salariés décider entre eux alors. Bizarre qu'ils n'en fassent pas pour privatiser.
http://www.lesechos.fr/12/02/2014/lesechos.fr/0203311492255_assurance-chomage---les-propositions-chocs-du-medef.htm
Bref tu dis de la merde et tes airs méprisants ne trompent plus personne ici. Alors retourne à la technique si ca te chante pour redorer ton blason.
# Un petit mot de la fin
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 7.
Avec ce joli débat personne n'a encore osé la faire alors je me dévoue.
La conclusion de tout ça c'est que: "Persona non grata"
Ok je connais le chemin ----> []
[^] # Re: métriques
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 6.
Très fort l'amalgame CDI/fonctionnaire.
Au fait tu lui reproches quoi au CDI exactement ?
Parce que des possibilité pour licencier un CDI il y en a pléthore.
Le jour ou celui qui choisira de démissionner sans l'accord de son patron ne sera pas tenu de crever de faim sans toucher le chômage alors qu'il a cotisé comme les autres. Bizarrement cette flexibilité là, le patron n'en veut pas.
Par contre, il voudrait bien pouvoir se délester sans contrainte et continuer de se gaver de subventions.
Et là le licenciement économique et là pour éviter les abus mais il existe bel et bien.
S'il devait y avoir un contrat unique pourquoi s'aligner sur le CDD et pas le CDI ?
On verrait si les artisans (le premier employeur de France parait-il) delocalisent …
[^] # Re: Fatigant
Posté par El Titi . En réponse au journal Notepad++ et FN ; ou quand un développeur parle d'autre chose que de développement. Évalué à 10.
Entre soulager un bourgeois d'une partie de sa fortune qu'il ne doit qu'à ses rentes ou à l'héritage colonial du passé et rétablir la ségrégation raciale …
Quand les libéraux mettent sur le même pied les 2 extrêmes, ils ne sont juste pas crédibles.
[^] # Re: This is javaaa
Posté par El Titi . En réponse à la dépêche Fim 1.1.0. Évalué à 3. Dernière modification le 04 novembre 2015 à 10:47.
Au fait, tu peux me donner un equivalent de Minecraft écrit en PHP ?
Ok Merci. CQFD
[^] # Re: This is javaaa
Posté par El Titi . En réponse à la dépêche Fim 1.1.0. Évalué à 8.
Alors,
pour Python
https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/Python-Python.html
PHP
https://www.cvedetails.com/google-search-results.php?q=php&sa=Search
Anéfé ca sent les arguments très fondés.
Bon on evitera de parler du GIL de cPython coté scalability, des features désactivées chez les hébergeurs de PHP qui sont juste des trous béants …
Quitte a faire le le troll de compet
[^] # Re: Il existe aussi Git-Annex
Posté par El Titi . En réponse à la dépêche Fim 1.1.0. Évalué à 3.
J'ai déjà eu l'occasion de tester ce soft pour mon propre cas d'utilisation que je décris :
Gérer un catalogue de fichiers qui garde une trace des fichiers que j'ai déjà utilisés et volontairement effacés.
Par exemple, si j'ai déjà visionné un podcast que j'ai mis de coté et que je le récupère à nouveau, je veux que le produit me le signale. S'il est nouveau, je veux qu'il l'insère et si c'est un doublon qu'il le ne rajoute pas au catalogue.
De part sa conception qui s'appuie sur l'historique, il permet de visualiser chaque différence mais ne permet pas de comparer de manière agrégée au catalogue entier (englobant les déjà vu), je n'y suis pas parvenu. Je n'ai pas besoins des états intermédiaire mais bien de pouvoir compare à tout mon catalogue présent et passé.
Du coup j'ai du mal à saisir l'intérêt.
Pour checker l'intégrité de fichier Ok (encore que pas besoin d'historique) mais
si c'est pour pouvoir gérer des gros fichiers avec Git, il vaut mieux se tourner vers un projet qui est soutenu par des grands du domaine (Github et Atlassian), qui ont uni leur force pour initier le projet suivant https://github.com/github/git-lfs
Au moins ça reste compatible de base avec Git et on bénficie de toute la tuyauterie associée, non ?
Plus d'info ici:
http://www.infoq.com/news/2015/04/github-large-file-storage
```
git lfs track "*.pdf"
git add file.pdf
git commit -m "Add design file"
git push origin master
[^] # Re: ouais ouais ouais
Posté par El Titi . En réponse au journal [HS] Marguerite, le film. Évalué à 2.
Pour Catherine Frot, je te laisse à ton appréciation après ne pas avoir terminé ce navet:
Imogene
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
C'est fait. Un ticket est ouvert.
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
Inutile, j'ai trouvé d'où venait le problème. Sous Mac readlink version Gnu n'est pas la version par défaut: Il faut donc installer coreutils
C'est expliqué ici:
http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac
Du coup, il faut rajouter la ligne suivante dans la procédure d'install:
et editer le shell fim en remplaçant par greadline.
Il doit y avoir une autre solution plus propre (fournir une autre shell pour mac ou jouer avec le path et un symlink, …) mais je ne suis pas assez fortiche pour faire des recommandations.
J'ai testé sur un de mes dirs et ça marche nickel.