Je n'ai pas eu de temps à consacrer à la préparation du sondage (donc dur de critiquer), mais je suis partiellement d'accord avec toi : le sondage est très orienté « que faites-vous avec Git ? » (qui est super important pour les développeurs) mais très peu sur les difficultés d'apprentissages (qui le seraient aussi).
Ceci dit, il ne faut pas en conclure qu'il n'y a pas d'effort pour rendre le logiciel plus facile à prendre en main. Si tu regardes l'évolution de l'outil, il y a des tas de petites choses qui ont été changées pour aider les débutants, et ça continue. Je donne des cours sur Git à des débutants complets, et les points sur lesquels j'avais toujours les mêmes questions il y a quelques années ont à peu près tous été réglés (ça n'est pas une coïncidence, en général c'est moi qui ai envoyé les patchs ;-) ). Y'a encore du boulot, mais ça avance.
Emacs fait aussi ça assez bien : M-x ansi-term RET ou M-x shell RET pour avoir un terminal, découpage de l'écran via C-x 2 / C-x 3 / …, et possibilité de se connecter à distance à un emacs existant (ssh machine-distante.example.com 'emacsclient -t' par exemple).
Première chose : évites absolument le WebDAV. C'est un hack intéressant quand tu ne peux pas héberger de CGI (rien de spécifique à Git sur le serveur, juste un serveur webdav et ça suffit), mais c'est beaucoup plus lent que git-http-backend et c'est aussi plus buggé (lent => peu d'utilisateurs => peu de volontaires pour corriger les bugs).
Et pour git-http-backend, il faut utiliser deux AliasMatch et un ScriptAliasMatch et se baser sur une détection immonde du paramètre git-receive-pack dans QUERY_STRING ou REQUEST_URI…
Si tu veux héberger un dépôt Git utilisable par un client git et du gitweb utilisable par un navigateur web sur la même URL, tu vas bien être obligé de dire quelque part « ça, c'est pour git-http-backend et ça c'est pour gitweb ».
Sans oublier un git config http.receivepack true sur tous les dépôts…
Tout ça pour juste autoriser l'accès en lecture seule…
Si tu dois positionner la même variable sur tous les dépôts, utilises ~/.gitconfig ou /etc/gitconfig.
Je ne peux que te conseiller de suivre à la lettre la doc de git-http-backend et de rapporter les éventuels bugs sur la mailing-list (mais si c'est juste pour râler que c'est trop dur sans poser de vraie question, tu auras peu de chance d'avoir de l'aide …).
Il n'y a pas de tab à 4 espaces, mais une indentation de l'ensemble du message de commit par 4 espaces dans l'affichage fait par git log (ce qui a toujours été le cas).
On parle bien d'une fonctionnalité codée par Torvalds, là, hein ;-).
Je connais bien la communauté Git, merci (cherches mon nom dans les logs si tu n'es pas convaincu).
Le fait que GitHub soit un gros contributeur de Git est évident. Mais la communauté Git reste une communauté décentralisée, chacun y apporte ce qu'il veut. GitHub apporte beaucoup de code, l'hébergement de git-scm.com, et Junio Hamano y pousse son code régulièrement (mais le dépôt https://github.com/git/git/ n'a rien de plus officiel que git://git.kernel.org/pub/scm/git/git.git/). Si tu cherches une définition de « Git » en temps qu'entité légale, ce qui s'en approcherait le plus serait la Software Freedom Conservancy qui héberge le compte en banque.
L'annonce la plus officielle des releases est faite par Junio Hamano, en publiant les releases notes relues et commentées par la communauté. Le blog de GitHub est un complément très appréciable, mais c'est une initiative unilatérale de GitHub, avec un texte sous leur contrôle et leur propriété.
Ça a l'air d'un détail, mais ce genre de confusion entretient une confusion bien plus embêtante entre Git et GitHub, par exemple on a chaque année des candidats en Google Summer of Code qui candidatent dans l'organisation Git et disant qu'ils veulent contribuer à GitHub, ou des gens qui postent sur la mailing-list de Git en posant des questions spécifiques à GitHub.
Le lien que tu donnes n'est pas vraiment l'annonce officielle. C'est un article sur le blog de GitHub (très bien écrit par ailleurs), et même s'il y a un lien évident entre Git et GitHub, ça reste important de ne pas confondre les deux. Un article sur Git sur le blog de GitHub n'est pas plus officiel que n'importe quel article sur Git sur n'importe quel blog.
Sinon :
La possibilité de faire de l'ASCII-art avec git describe
Ça me parait être un raccourcis un peu étrange. git describe donne maintenant une description meilleure d'un commit, et git log ne casse plus l'ascii-art qui utilise des tabs (ce qui n'est pas du tout inutile, c'était une vraie demande de Linus qui en avait marre de voir les jolis messages de commits bien alignés utilisant des tabs cassés par le préfixe à 4 espace de git log), mais ce sont deux fonctionnalités différentes .
Autant je suis tatillon sur ma vie privée, mon parcours professionnel est, pour moi, une donnée complètement publique.
LinkedIn connaît aussi des choses pas publiques du tout, par exemple : avec qui tu es connecté (pas un secret d'état, mais quand même), quels profils et offres d'emploi tu as consulté (donc indirectement : est-ce que tu cherches à quitter ton emploi actuel, est-ce que tu cherches à recruter), …
Les sous c'est une chose, mais pour que ça soit intéressant il faut aussi avoir des gens intéressés pour bosser à plein temps sur le projet, pas forcément bien payé et avec peu de visibilité sur l'avenir. Avec 30000$ par an, ça fait un salaire assez maigre (en coût total employeur).
Si des devs de Gimp veulent se faire payer pour passer plus de temps dessus, je leur donnerais volontiers un peu de sous, mais s'ils préfèrent garder ça comme loisir, on ne peut pas leur en vouloir.
L'historique immuable avec Git, c'est deux lignes dans un fichier de config (receive.denyNonFastForwards et receive.denydeletes). Si c'est tout ce qui te retient avec Subversion … ;-).
Maintenant, je rejoins Zenitram : si tu veux des contributeurs, donnes leur des bonnes conditions de travail, donc exit Subversion. Contribuer à un projet quand on n'a pas la possibilité de faire un commit, c'est vraiment pas pratique.
Et surtout : le fait qu'un service soit associatif te protège effectivement assez bien des dérives à la sourceforge, mais pas du tout de la faillite ou des interruptions de services à rallonges. On se souvient de kernel.org qui a été coupé très longtemps (je crois que le wiki a mis plus d'un an à revenir), plus récemment, l'hébergeur Olympe mettra la clé sous la porte s'ils ne trouvent pas 28000 € dans les 12 jours qui viennent. Le fait que GitHub ait un service payant et fasse autant de pognon avec est quand même une bonne garantie que ce genre de chose n'arrive pas.
Il y a des tas de bonnes raisons de ne pas choisir GitHub, mais « j'ai plus confiance dans la pérennité d'un service non-commercial » ne me parait pas être la meilleure.
CVS aussi permettait d'avoir l'ensemble des modifs d'un commit.
Justement non. En gros, un cvs commit sur tout un projet est équivalent à for f in $(find . -type f); do cvs commit $f; done. En terme de format de stockage, l'historique de chaque fichier est stocké dans un fichier (.v), mais il n'y a rien qui relie l'historique de tous ces fichiers. Chaque fichier a un ensemble de numéros de versions, mais la version 42 d'un fichier ne correspond pas à la version 42 d'un autre.
Regarde ce que sont obligés de faire des outils comme cvsps (et son option --fuzz) pour voir l'étendue des dégâts.
Une des conséquences est celle que tu donnes sur les accès concurrents, mais ça n'est pas la seule.
Un point clé est « Git/Github has all the market share. Trying to compete with that just proved to be too hard. » (Git/Github a toutes les parts de marché. Essayer de concurrencer ça est trop dur).
Ils gardent espoir de trouver un business model, mais ça ressemble un peu à une mise en open-source en guise d'enterrement :-(.
Je suis d'accord que « prix libre » est différent de « gratuit mais dons possibles ». Par exemple, le « Humble Indie Bundle » (http://linuxfr.org/news/humble-indie-bundle-5-jeux-pour-le-prix-que-vous-voulez) avait un modèle intéressant : prix libre, mais strictement supérieur à 0. Et honnêtement, une fois qu'on a mis son numéro de carte bleu dans le système de paiement, on se sentirait vraiment radin de choisir la somme 0.01 €. En pratique, le prix moyen était autour de 10 €.
Ahem, rien que ça, ça en dit long sur à quel point tu ne t'es pas renseigné sur la question. Ça fait belle lurette que Linus a passé la main sur Git, il ne suit même plus régulièrement la mailing list, il envoie un patch de temps en temps mais je peux t'assurer que le fait que Linus compile Git sous Windows ne changerait strictement rien à la santé de Git pour Windows.
Euh, c'est pas comme si il n'y avait personne qui travaillait là dessus … Y'a eu du gros développement pour le support de Git sous Visual Studio (avec contributions de Microsoft à libgit2 en open-source). Maintenant il y a un salarié Microsoft à plein temps sur « Git for Windows ».
Vu que les comptes google sont apparus avant gmail, je vois mal comment ça aurait été obligatoire à une époque d'avoir un compte gmail pour avoir un compte google …
C'est juste que les utilisateurs confondent (et que Google ne fait pas grand chose pour éviter la confusion).
il est possible de comparer différents clichés avec la touche "Z" qui affiche très rapidement en plein écran la photo sélectionnée.
On peut aussi afficher l'image en plein écran sans "Z": il suffit de régler le zoom (par exemple Control-molette) pour n'afficher qu'une image. Et éventuellement d'appuyer un coup sur Tabulation pour supprimer les barres latérales.
Oui, aussi (d'où ma conclusion sur le fait que la seule vraie solution est de changer de matériel). Je citais le noyau car c'est du logiciel au même titre que l'application qui pose problème à l'auteur du journal, apporté par la même mise à jour. Donc avoir peur de l'application et pas du noyau est particulièrement paradoxal.
Euh, tu réalises que tu as sur ton téléphone un noyau fourni par ton constructeur. Côté permission, c'est autrement pire que tout ce que tu cites, le code qui tourne dans le noyau a accès à absolument tout sur ton téléphone. Est-ce que tu as pensé à désinstaller ton noyau ?
Le système de droit, c'est fait pour te permettre d'installer des applications venant de fournisseurs en qui tu as moyennement confiance seulement. Si tu n'a pas confiance en Samsung et que tu as un téléphone Samsung, la seule option que tu as est de changer de téléphone. Tout ce que tu peux faire d'autre ne pourra que te donner l'illusion de sécurité, mais ça ne changera strictement rien à ce que Samsung peut faire sur ton téléphone.
ce que j'aimerais c'est un système de publication géré par la communauté
OK, mais c'est totalement orthogonal au système d'archives ouvertes, et au fait que les publis soient accessibles ou non. Tu peux faire du peer-reviewé ou non sur une archive ouverte, tu peux avoir un éditeur privé qui fait de l'open access, … Si on invente un super nouveau système pour décider quelle publi est acceptée ou non, ça ne changera rien au fait que la publi puisse aller sur HAL.
Il commence à y avoir des labels gérés par des universitaires qui concurrencent les éditeurs classiques. En informatique, il y a ça par exemple : https://www.dagstuhl.de/publikationen/. Là, y'a un problème qu'une loi peut difficilement résoudre : les éditeurs « prestigieux » sont ceux qui sont privés et cher. Ceux qui sont les plus proches de mon sens de l'éthique n'ont pas (encore ?) la même renommée.
[^] # Re: Rrrr Zzzz
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 8.
Je n'ai pas eu de temps à consacrer à la préparation du sondage (donc dur de critiquer), mais je suis partiellement d'accord avec toi : le sondage est très orienté « que faites-vous avec Git ? » (qui est super important pour les développeurs) mais très peu sur les difficultés d'apprentissages (qui le seraient aussi).
Ceci dit, il ne faut pas en conclure qu'il n'y a pas d'effort pour rendre le logiciel plus facile à prendre en main. Si tu regardes l'évolution de l'outil, il y a des tas de petites choses qui ont été changées pour aider les débutants, et ça continue. Je donne des cours sur Git à des débutants complets, et les points sur lesquels j'avais toujours les mêmes questions il y a quelques années ont à peu près tous été réglés (ça n'est pas une coïncidence, en général c'est moi qui ai envoyé les patchs ;-) ). Y'a encore du boulot, mais ça avance.
# Emacs
Posté par Matthieu Moy (site web personnel) . En réponse au sondage Votre multiplexeur de terminal favori. Évalué à 10.
Emacs fait aussi ça assez bien : M-x ansi-term RET ou M-x shell RET pour avoir un terminal, découpage de l'écran via C-x 2 / C-x 3 / …, et possibilité de se connecter à distance à un emacs existant (
ssh machine-distante.example.com 'emacsclient -t'par exemple).[^] # Re: Git sur https
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de git 2.9. Évalué à 7.
Première chose : évites absolument le WebDAV. C'est un hack intéressant quand tu ne peux pas héberger de CGI (rien de spécifique à Git sur le serveur, juste un serveur webdav et ça suffit), mais c'est beaucoup plus lent que
git-http-backendet c'est aussi plus buggé (lent => peu d'utilisateurs => peu de volontaires pour corriger les bugs).Si tu veux héberger un dépôt Git utilisable par un client git et du gitweb utilisable par un navigateur web sur la même URL, tu vas bien être obligé de dire quelque part « ça, c'est pour
git-http-backendet ça c'est pourgitweb».Si tu dois positionner la même variable sur tous les dépôts, utilises
~/.gitconfigou/etc/gitconfig.Je ne peux que te conseiller de suivre à la lettre la doc de git-http-backend et de rapporter les éventuels bugs sur la mailing-list (mais si c'est juste pour râler que c'est trop dur sans poser de vraie question, tu auras peu de chance d'avoir de l'aide …).
[^] # Re: Des tabs à 4 espaces
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de git 2.9. Évalué à 3.
Il n'y a pas de tab à 4 espaces, mais une indentation de l'ensemble du message de commit par 4 espaces dans l'affichage fait par
git log(ce qui a toujours été le cas).On parle bien d'une fonctionnalité codée par Torvalds, là, hein ;-).
[^] # Re: Annonce officielle
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sortie de Git 2.9. Évalué à 5.
C'est toi qui a mis en face les deux phrases que tu cites, mais le « euh non » n'était à mon avis pas en réponse à « le mainteneur officiel » …
[^] # Re: Annonce officielle
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sortie de Git 2.9. Évalué à 10.
Je connais bien la communauté Git, merci (cherches mon nom dans les logs si tu n'es pas convaincu).
Le fait que GitHub soit un gros contributeur de Git est évident. Mais la communauté Git reste une communauté décentralisée, chacun y apporte ce qu'il veut. GitHub apporte beaucoup de code, l'hébergement de git-scm.com, et Junio Hamano y pousse son code régulièrement (mais le dépôt https://github.com/git/git/ n'a rien de plus officiel que git://git.kernel.org/pub/scm/git/git.git/). Si tu cherches une définition de « Git » en temps qu'entité légale, ce qui s'en approcherait le plus serait la Software Freedom Conservancy qui héberge le compte en banque.
L'annonce la plus officielle des releases est faite par Junio Hamano, en publiant les releases notes relues et commentées par la communauté. Le blog de GitHub est un complément très appréciable, mais c'est une initiative unilatérale de GitHub, avec un texte sous leur contrôle et leur propriété.
Ça a l'air d'un détail, mais ce genre de confusion entretient une confusion bien plus embêtante entre Git et GitHub, par exemple on a chaque année des candidats en Google Summer of Code qui candidatent dans l'organisation Git et disant qu'ils veulent contribuer à GitHub, ou des gens qui postent sur la mailing-list de Git en posant des questions spécifiques à GitHub.
# Annonce officielle
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sortie de Git 2.9. Évalué à 9.
Le lien que tu donnes n'est pas vraiment l'annonce officielle. C'est un article sur le blog de GitHub (très bien écrit par ailleurs), et même s'il y a un lien évident entre Git et GitHub, ça reste important de ne pas confondre les deux. Un article sur Git sur le blog de GitHub n'est pas plus officiel que n'importe quel article sur Git sur n'importe quel blog.
Sinon :
Ça me parait être un raccourcis un peu étrange.
git describedonne maintenant une description meilleure d'un commit, etgit logne casse plus l'ascii-art qui utilise des tabs (ce qui n'est pas du tout inutile, c'était une vraie demande de Linus qui en avait marre de voir les jolis messages de commits bien alignés utilisant des tabs cassés par le préfixe à 4 espace degit log), mais ce sont deux fonctionnalités différentes .[^] # Re: Pérennité des données
Posté par Matthieu Moy (site web personnel) . En réponse au journal Rachat de LinkedIn par Microsoft pour 26 milliards de dollars. Évalué à 3.
LinkedIn connaît aussi des choses pas publiques du tout, par exemple : avec qui tu es connecté (pas un secret d'état, mais quand même), quels profils et offres d'emploi tu as consulté (donc indirectement : est-ce que tu cherches à quitter ton emploi actuel, est-ce que tu cherches à recruter), …
[^] # Re: GIMP
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Sortie de Krita 3.0. Évalué à 7.
Les sous c'est une chose, mais pour que ça soit intéressant il faut aussi avoir des gens intéressés pour bosser à plein temps sur le projet, pas forcément bien payé et avec peu de visibilité sur l'avenir. Avec 30000$ par an, ça fait un salaire assez maigre (en coût total employeur).
Si des devs de Gimp veulent se faire payer pour passer plus de temps dessus, je leur donnerais volontiers un peu de sous, mais s'ils préfèrent garder ça comme loisir, on ne peut pas leur en vouloir.
[^] # Re: Git
Posté par Matthieu Moy (site web personnel) . En réponse au journal Migration d'un projet de SourceForge vers TuxFamily. Évalué à 7.
L'historique immuable avec Git, c'est deux lignes dans un fichier de config (receive.denyNonFastForwards et receive.denydeletes). Si c'est tout ce qui te retient avec Subversion … ;-).
Maintenant, je rejoins Zenitram : si tu veux des contributeurs, donnes leur des bonnes conditions de travail, donc exit Subversion. Contribuer à un projet quand on n'a pas la possibilité de faire un commit, c'est vraiment pas pratique.
[^] # Re: GitHub
Posté par Matthieu Moy (site web personnel) . En réponse au journal Migration d'un projet de SourceForge vers TuxFamily. Évalué à 3.
Et surtout : le fait qu'un service soit associatif te protège effectivement assez bien des dérives à la sourceforge, mais pas du tout de la faillite ou des interruptions de services à rallonges. On se souvient de kernel.org qui a été coupé très longtemps (je crois que le wiki a mis plus d'un an à revenir), plus récemment, l'hébergeur Olympe mettra la clé sous la porte s'ils ne trouvent pas 28000 € dans les 12 jours qui viennent. Le fait que GitHub ait un service payant et fasse autant de pognon avec est quand même une bonne garantie que ce genre de chose n'arrive pas.
Il y a des tas de bonnes raisons de ne pas choisir GitHub, mais « j'ai plus confiance dans la pérennité d'un service non-commercial » ne me parait pas être la meilleure.
[^] # Re: Incroyable
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Bitkeeper essaye de rattraper l'histoire en passant Open Source. Évalué à 10.
Justement non. En gros, un
cvs commitsur tout un projet est équivalent àfor f in $(find . -type f); do cvs commit $f; done. En terme de format de stockage, l'historique de chaque fichier est stocké dans un fichier (.v), mais il n'y a rien qui relie l'historique de tous ces fichiers. Chaque fichier a un ensemble de numéros de versions, mais la version 42 d'un fichier ne correspond pas à la version 42 d'un autre.Regarde ce que sont obligés de faire des outils comme cvsps (et son option
--fuzz) pour voir l'étendue des dégâts.Une des conséquences est celle que tu donnes sur les accès concurrents, mais ça n'est pas la seule.
# Bazaar maintenu ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Bitkeeper essaye de rattraper l'histoire en passant Open Source. Évalué à 7.
Il y a eu une cinquantaine de commits sur les 4 dernières années (cf. aussi openhub) de développement de Bazaar. « Maintenu » est un bien grand mot, c'est un projet essentiellement à l'abandon.
# Quelques explications sur la raison du passage en open-source
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Bitkeeper essaye de rattraper l'histoire en passant Open Source. Évalué à 10.
Quelques explications supplémentaires :
https://news.ycombinator.com/item?id=11667494 (les commentaires de Larry McVoy sont fait avec le pseudo luckydude).
https://lwn.net/Articles/686896/
Un point clé est « Git/Github has all the market share. Trying to compete with that just proved to be too hard. » (Git/Github a toutes les parts de marché. Essayer de concurrencer ça est trop dur).
Ils gardent espoir de trouver un business model, mais ça ressemble un peu à une mise en open-source en guise d'enterrement :-(.
[^] # Re: Juste une question ...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Olympe, hébergeur gratuit et sans publicités, mène une campagne de financement participatif. Évalué à 5.
Je suis d'accord que « prix libre » est différent de « gratuit mais dons possibles ». Par exemple, le « Humble Indie Bundle » (http://linuxfr.org/news/humble-indie-bundle-5-jeux-pour-le-prix-que-vous-voulez) avait un modèle intéressant : prix libre, mais strictement supérieur à 0. Et honnêtement, une fois qu'on a mis son numéro de carte bleu dans le système de paiement, on se sentirait vraiment radin de choisir la somme 0.01 €. En pratique, le prix moyen était autour de 10 €.
[^] # Re: Expérience enrichissante
Posté par Matthieu Moy (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 4.
Ahem, rien que ça, ça en dit long sur à quel point tu ne t'es pas renseigné sur la question. Ça fait belle lurette que Linus a passé la main sur Git, il ne suit même plus régulièrement la mailing list, il envoie un patch de temps en temps mais je peux t'assurer que le fait que Linus compile Git sous Windows ne changerait strictement rien à la santé de Git pour Windows.
[^] # Re: Expérience enrichissante
Posté par Matthieu Moy (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 3.
Euh, c'est pas comme si il n'y avait personne qui travaillait là dessus … Y'a eu du gros développement pour le support de Git sous Visual Studio (avec contributions de Microsoft à libgit2 en open-source). Maintenant il y a un salarié Microsoft à plein temps sur « Git for Windows ».
[^] # Re: gmail
Posté par Matthieu Moy (site web personnel) . En réponse au journal Google passe devant Apple et annonce 1 milliard de comptes Gmail.... Évalué à 2.
Vu que les comptes google sont apparus avant gmail, je vois mal comment ça aurait été obligatoire à une époque d'avoir un compte gmail pour avoir un compte google …
C'est juste que les utilisateurs confondent (et que Google ne fait pas grand chose pour éviter la confusion).
# Après X, voici Y
Posté par Matthieu Moy (site web personnel) . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 6.
Il y a déjà eu une tentative qui ressemble à ça :
http://linuxfr.org/news/apr%C3%A8s-x-voici-y
Le moins qu'on puisse dire, c'est que ça n'a pas l'air très vivant ;-).
[^] # Re: Comparaison côte à côte de deux photos ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Darktable 2.0 : traitement et gestion de photographies. Évalué à 2.
On peut aussi afficher l'image en plein écran sans "Z": il suffit de régler le zoom (par exemple Control-molette) pour n'afficher qu'une image. Et éventuellement d'appuyer un coup sur Tabulation pour supprimer les barres latérales.
# Manuel utilisateur en français
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Darktable 2.0 : traitement et gestion de photographies. Évalué à 5.
Le manuel traduit est maintenant disponible ici :
https://github.com/darktable-org/darktable/releases/download/release-2.0.0/darktable-usermanual-fr.pdf
(si un modérateur passe par là, ça serait cool de l'ajouter aux liens dans la dépêche)
[^] # Re: Encore un super billet!
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Darktable 2.0 : traitement et gestion de photographies. Évalué à 3.
Et un grand merci à toi pour tes vidéos :-) !
[^] # Re: Mauvaises permissions
Posté par Matthieu Moy (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 3.
Oui, aussi (d'où ma conclusion sur le fait que la seule vraie solution est de changer de matériel). Je citais le noyau car c'est du logiciel au même titre que l'application qui pose problème à l'auteur du journal, apporté par la même mise à jour. Donc avoir peur de l'application et pas du noyau est particulièrement paradoxal.
[^] # Re: Mauvaises permissions
Posté par Matthieu Moy (site web personnel) . En réponse au journal Mise à jour Samsung S5, Smart Manager de votre vie privée.. Évalué à 5.
Euh, tu réalises que tu as sur ton téléphone un noyau fourni par ton constructeur. Côté permission, c'est autrement pire que tout ce que tu cites, le code qui tourne dans le noyau a accès à absolument tout sur ton téléphone. Est-ce que tu as pensé à désinstaller ton noyau ?
Le système de droit, c'est fait pour te permettre d'installer des applications venant de fournisseurs en qui tu as moyennement confiance seulement. Si tu n'a pas confiance en Samsung et que tu as un téléphone Samsung, la seule option que tu as est de changer de téléphone. Tout ce que tu peux faire d'autre ne pourra que te donner l'illusion de sécurité, mais ça ne changera strictement rien à ce que Samsung peut faire sur ton téléphone.
[^] # Re: Archive ouverte vs peer review
Posté par Matthieu Moy (site web personnel) . En réponse au journal PLRN Article 9 - "Libre" accès aux publications scientifiques de la recherche publique. Évalué à 2.
OK, mais c'est totalement orthogonal au système d'archives ouvertes, et au fait que les publis soient accessibles ou non. Tu peux faire du peer-reviewé ou non sur une archive ouverte, tu peux avoir un éditeur privé qui fait de l'open access, … Si on invente un super nouveau système pour décider quelle publi est acceptée ou non, ça ne changera rien au fait que la publi puisse aller sur HAL.
Il commence à y avoir des labels gérés par des universitaires qui concurrencent les éditeurs classiques. En informatique, il y a ça par exemple : https://www.dagstuhl.de/publikationen/. Là, y'a un problème qu'une loi peut difficilement résoudre : les éditeurs « prestigieux » sont ceux qui sont privés et cher. Ceux qui sont les plus proches de mon sens de l'éthique n'ont pas (encore ?) la même renommée.