rakoo a écrit 925 commentaires

elle n'a simplement pas fait attention aux clauses du contrat d'édition

Et bien tant pis pour elle. Elle a signé un contrat, elle a donc accepté tout ce qui est écrit dessus. Qu'elle l'ait lu ou pas, c'est a dire qu'elle ait une confiance aveugle en son éditeur ou pas ne regarde qu'elle.

Bon sang, on croirait qu'un contrat n'a plus aucune valeur.

Merci pour le retour.

ça utilise le scripting lua de redis, or la version de redis qui tourne actuellement sur LinuxFr.org ne prend pas en charge cette fonctionnalité ;

C'est "prévu" : le script tente d'utiliser le code lua, et passe par le code ruby si ce n'est pas possible. C'est possible grâce au bloc begin, qui va tomber dans le cas rescue si la commande eval n'existe pas sur le serveur. Le jour où le serveur évoluera, le script marchera.

D'ailleurs, le site officiel de Redis dit qu'il ne serait pas impossible que les transactions deviennent un jour obsolètes, en faveur des scripts lua. Je me prépare à l'avenir =]

ça passe par le hub de google, alors que l'on essaye d'éviter les services centralisés,

Judicieuse remarque, mais :

• On ne perd strictement aucune fonctionnalité, et il n'y a aucune dépendance. Si le hub tombe, l'aggrégateur RSS peut toujours poller le flux directement chez LinuxFr.org
• On peut définir autant de hubs que l'on veut (solution partielle, mais potentiellement gratuite : SuperFeedr et Ayup! fournissent un service de publication qui ne coûte rien)
• LinuxFr.org peut avoir son propre hub (ça demanderait quand même du développement et des ressources à l'utilisation, certes)

tout particulièrement ceux de grosses sociétés pas très respectueuses de la vie privée de ses utilisateurs.

Il s'agit là de flux publiquement accessibles à n'importe quel passant, la vie privée de personne n'est en jeu. Et puis, si Google peut indexer les flux concernés quand on lui dit qu'il y a du nouveau contenu au lieu de poller constamment le site, ça peut être intéressant. Mais je comprends tout à fait le fond du message et suis d'accord.

À vrai dire, il y a un petit quelque chose qui m'embête vraiment :

error = begin
         Redis::CommandError
       rescue NameError
         RuntimeError # Dirty dirty hack for redis gem before 3.0
       end

Il s'agit de l'erreur que l'on doit matcher dans le rescue dont on parle plus haut. Catcher une RuntimeError me déplait au plus haut point, parce que c'est une erreur qui peut arriver de n'importe quoi. Ce qu'il faudrait c'est upgrader la gem redis à au moins 3.0.0, qui introduit Redis::CommandError et qui me plaît largement plus, parce que c'est exactement ce que l'on veut.

Ou alors enlever carrément toute la partie script et la remettre le jour où on aura une version plus récente de Redis ?

Sinon, c'est sympa d'avoir proposé un patch

Ça ne paiera pas la bande passante dont j'ai abusé, mais ça me fait plaisir =]

Ah! Je ne savais même pas que cette solution existait. Il semble donc que j'aie posté au mauvais endroit. Merci !

Ce serait effectivement un moyen très sympathique. Le problème est qu'il faudrait adapter l'usage des suiveurs qui n'utilisent pas un MUA pour lire leurs flux Atom. PubSubHubBub a l'avantage d'être rétro-compatible avec le système existant.

Aaaah. Ce codec annonce de grande choses sympathiques pour la diffusion temps-réel, et, top cool, quelques entreprises ont pensé à nous :

Un codec libre est difficile à obtenir, surtout vu le nombre de brevets, la plupart futiles, qui encombrent ce domaine.

Bien, donc si on veut implémenter dans notre coin, il va nous falloir demander l'avis de ces dépositaires pour diffuser. Super.

Plus simple : utilise ta branche master comme base commune entre toutes tes machines, et une branche par machine. Lorsque tu veux ajouter un fichier à toutes les configs, tu le commit dans master et tu merge master dans chaque branche.

Le vrai changement serait de séparer le fond et la forme et de permettre aux utilisateurs de se focaliser vraiment sur le fond et laisser la forme à l'ordinateur.

Dans l'absolu c'est ce que fait déjà Latex. Mais pour aller plus loin, on obtient des résultats vraiment intéressants avec txt2tags. Il y a sûrement d'autres langages de balisage pour faire la même chose, mais celui-là est vraiment bien fait.

M'est avis qu'il y aura toujours le sentiment de sécurité basé sur l'obfuscation. "Si les pirates chinois du FBI ne peuvent pas voir le code, alors ils ne pourront pas le cracker."

Je vois mal une institution administrative comprendre que cette sécurité est toute relative.

Il y a peut-être aussi la liberté de pouvoir coder sans se soucier de la qualité, puisque personne ne pourra le voir.

Il y aura peut-être également la possibilité d'utiliser des briques logicielles propriétaires, non compatibles avec d’éventuelles briques GPL.

C'est pas a ça que sert le vala? Simplifier le développement ?

Tiens, j'aimerais savoir: il m'a l'air d'avoir un sacré caractère ce monsieur, donc est-ce que RH lui dit ce qu'il doit coder, ou est-ce qu'il fait plutôt ce qu'il veut (et pense être bon) et est force de proposition chez RH ?

Par exemple, Linus a un contrat avec la Linux Foundation qui dit qu'il a le droit de faire ce qu'il veut. Donc il "bosse" pour eux, mais fait ce qu'il veut.

La BnF a également un rôle de conservation des écrits. Et j'imagine qu'ils ont plus confiance en leur propre capacité de conservation d'un tel ouvrage par rapport à un particulier. Pour le coup, je suis d'accord pour que le livre soit conservé par elle.

L'histoire de distribution du contenu est tout autre.

Sa position, si je la résume, m'a l'air de tout à fait tenir :

"Si vous voulez rendre systemd compatible avec d'autres noyaux, ça va créer un machin horrible à maintenir, je ne veux pas le faire. Mais quiconque veut le faire peut"

Autrement dit : le systemd de Lennart ne sera pas compatible avec autre chose que Linux, mais rien n'empêche JohnDoe de créer JDsystemd qui sera compatible avec tous les noyaux, et qui peut même être accepté partout.

C'est incroyable ça. Le type fait le logiciel comme il l'entend, il le rend dispo à tout le monde, mais on trouve le moyen de se plaindre de lui parce qu'il ne veut pas bosser à l'oeil pour son propre noyau.

Bon sang, systemd est même sous LGPL, qui contient quand même ce bout en ALL CAPS :

COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

Si ça ne fait pas ce que tu veux, dommage pour toi, Lennart et les contributeurs ne te doivent rien. Forke donc !

Le débat NC vs DP est un troll qui n'intéresse que les mouchophiles d'ici… […] alors que toute personne normale aurait besoin de 3h d'explications pour saisir la différence.

Ça tombe "bien", les gens qui décident de la licence de ces œuvres sont des gens dont la préoccupation est la diffusion de la culture, pas de simples gens normaux qui veulent juste consommer. Et ce qui est grave c'est que malgré leur rôle primordial, ils privilégient les intérêts privés de la BnF (oui, ça a l'air d'exister) aux intérêts publics.

Ça c'est sûr, les MACistes adorent !

Réussir une attaque DOS se résume à trouver un objet assez lourd pour maintenir la touche F5 enfoncée.

Vérifié en pratique

Juste pour te contredire, je tape en aveugle, donc je n'en ai pas besoin. Mais si tu peux y trouver des usages, tant mieux pour toi =]

$ emacs --help
[…]

Run M-x info RET m emacs RET m emacs invocation RET inside Emacs to
read the main documentation for these command-line arguments.

Justement, Nvidia dépend du noyau linux et de X. Autrement dit, peu de choses qui font une distribution; c'est assez dépendant. C'est du coup beaucoup plus facile de le porter vers d'autre distributions. À l'opposé, regarde les dépendances de Firefox, et dis-toi que chacune de ces dépendances doit être remplie pour faire marcher Firefox sur une autre distribution que l'originale.

Je parlais du cas ou les librairies de rendu PDF n’étaient pas communes/stable, ce qui aurait demande un gros travail de maintenance. J'avoue ne pas connaitre le domaine. Il semble qu'il y ait tout de même pas mal de librairies, dont poppler qui a l'air assez utilisée donc stable, je suppose. Vu comme ca, oui, il aurait été plus malin de s'en servir.

et il faut un serveur pour afficher un PDF.

Pourquoi un serveur ? Tu parles du moteur Javascript ?

Soit c'est libre et non commercial et si le soft est intéressant les distributions feront le package. Soit c'est commercial et je pense que c'est toi fournisseur d'un logiciel que tu vends qui fait le support pour les 3 ou 4 grosses distribs.

Les autres entreprises le font pour Mac et Windows, si le marché y était sur linux, elles le feraient aussi, c'est juste un problème économique.

Je crois que tu viens exactement de demontrer en quoi il avait raison :

• Sous Windows/Mac OS, l'editeur fait un logiciel, il marchera sur toutes les versions de Windows/Mac OS.

• Sous linux, il ne marchera que pour les quelques distributions que tu as choisies. Il y a du travail supplémentaire a faire de la part de l'editeur et du packager pour faire tourner ton machin sur sa distrib si tu ne l'as pas visee directement.

Soit tu fais un logiciel pour Linux le noyau, et la tu as des chances que ça marche facilement un peu partout. Soit tu fais un logiciel pour certains GNU/Linux en particulier, et dans ce cas la tu dois t'adapter a chacune d'entre elles. Ton but en tant que developpeur commercial, est de viser le plus de machines possibles pour un cout minimal. L’écosystème Linux est a l'exact oppose de ça, alors que les deux autres sont adaptes pour.

Non, linux/desktop est une plateforme en perte de vitesse

Ah ! Linux rejoint donc le clan des *** is dying. Les BSD se sentiront moins seuls !

PS : après, que ce soit un Javascript, c'est une autre histoire… Peut-être pas la meilleure idée qu'ils aient eu. Et oui, pour les linux, ça aurait pu reposer sur une libpdf, mais existe-t-elle?

Quitte a avoir une libpdf qui sera dépendante de l’hôte donc de l'OS, de l'architecture, et peut-être encore d'autres paramètres, autant avoir une appli faite pour l'OS, c'est-a-dire la situation actuelle.

Dans le nouveau cas, a partir du moment ou tu as Firefox, tu as un interpréteur de Javascript. Peu importe l'OS, l'archi, et tout le reste, tu sais que tu peux exécuter du javascript sans réfléchir. Ça a donc du sens de se baser dessus. C'est pas forcement le meilleur langage/le meilleur interpréteur, mais au moins on sait qu'il est la en même temps que Firefox et qu'il marche. Maintenir un nouveau langage ou même une lib, ça demande autrement plus d'efforts, que la Fondation n'a pas forcement.

Je comprends mieux l'offre d'Amazon, Glacier, qui offre des capacités énormes de stockage a condition d'attendre un peu pour pouvoir les lire.

C'est en tout cas une excellente nouvelle pour le stockage a long terme. On pourrait imaginer, demain, un espace de stockage qui se régénère lorsqu'il est blessé, comme un être vivant classique.

Je ne pratique pas le C parce que les soucis de gestion bas niveau ne m'avaient pas l'air intéressants. Mais avec ce journal et le dernier, agrémentés de petits commentaires qui font vivre le code et nous donnent des explications sur le pourquoi, ça donne envie. J'aime beaucoup l'approche linéaire qui suit le raisonnement qu'aurait un développeur.

J'ai hâte de lire la suite !

En un mot : Merci !

sûrement à opposer au viol… consentant?!?

Plutôt legitimate rape. J'ai peur de traduire ça par viol légitime, ça voudrait presque dire "Elle l'a demandé". M'enfin, avec les histoires de viol aux Etats-Unis et leur appréciation par ces chers républicains, ça m’étonnerait pas qu'il ait pense ça.

Hop, on dévie doucement vers de la politique. J'ai bon pour le troll-sans-fin ?