Jux a écrit 743 commentaires

En fait si on veut faire un parallèle entre la situation en Allemagne et un programme sous GPL, il faudrait plutôt comparer kino.to a une boîte qui se fait des couilles en or en distribuant un soft proprio qui contient des bouts sous GPL sans redistribuer les sources (donc en violant la GPL).

Il s'agit bêtement d'un non-respect de licence par kino.to dans un but clairement commercial. Le but commercial fait à mon avis toute la différence par rapport au type qui télécharge des séries parce qu'elles ne sont pas disponibles en Europe. Si on commence à autoriser des boîtes à ne pas respecter les licences et à se faire de l'argent en piratant le boulot des autres, ça va être joli, y compris pour certains logiciels libres (surtout ceux sous GPL-like, qui se base sur la licence pour obliger la redistribution des sources).

Je viens d'y jouer 30 minutes ! Génial, un grand moment de nostalgie :-)
Pour l'instant, c'est assez classique Zelda. Il faut bien tout explorer pour trouver où aller. Ca a vraiment l'air sympa.

Tout juste a-t-on quelques très brèves informations dans un encadré intitulé "Où va votre don ?" à peine visible dans tout ce texte. Et le premier point parle… des serveurs de Wikipedia évidemment.

Ca frise la désinformation là, les 2, 3 et 4ème points sont :
- Conférences, ateliers et presse
- Partenariats
- Soutien à la communauté

C'est effectivement la même chose pour moi qui ai donné de l'argent à Wikimedia CH. Ceci dit, ils spécifient dans leur rapport d'activité qu'ils reversent la moitié de l'argent à Wikimedia US. D'après le blog de Bastien Guerry, c'est la même chose pour Wikimedia FR.
J'imagine que pour monter une section régionale de Wikimedia, l'accord stipule que 50% des levées de fonds sont reversés à l'organisation mère.

Ceci dit, sur le fond, je ne me sens pas plus floué que ça, même s'ils pourraient donner un peu plus d'informations. Le rapport d'activité de Wikimedia CH montre qu'ils font plein d'activités pour ajouter du contenu à Wikipedia (utiliser les archives fédérales, ajouter des biographies de personnalités suisses, etc...). Donc au final, je pense que cette décentralisation des associations vise à faire avancer Wikipedia dans toutes les langues/cultures plutôt que uniquement en anglais.

Oui mais on ne parle plus latin et le français a eu quelques siècles d'usage pour changer.
Bref, c'est bon, tu nous as exposé ta culture, on peut passer à autre chose.

Sors les popcorns

la perennité des données de l'utilisateur dans le temps (relisez vos clufs!);
la possibilité de manipuler les données produites par le logiciel de son choix;

Un logiciel proprio qui utilise un format de données standard permet la même chose.

Mince, avec la fin de flash et l'avènement de la sobriété en webdesign "2.0", je me disais qu'on avait définitivement passé l'ère des années 1995-2000 avec des sites en flash horriblement chargés en animation.
Mais apparemment non, les webdesigners semblent heureux de pouvoir abuser de HTML5 et de tous les effets kikoolol... Ca promet pour le futur.

C'est d'autant plus cool que (pour l'instant) les technos HTML5 bouffent 10 fois plus que flash pour les mêmes animations. Intel doit sponsoriser tout ça pour vendre ses nouveaux proc. J'imagine les pubs "Visualiser vos résultats Google sans ramer avec le nouveau Core i45 à 52 coeurs".

Comme les pubs dans les résultats des recherches sont textuelles, tu les vois aussi sous links.

Et si une partie de l'explication venait simplement du fait qu'il y a déjà énormément de contenu sur Wikipedia (je l'utilise en anglais) ? Les articles sur des sujets généraux que tout le monde peut éditer sont très bien remplis. Du coup, ce qu'il reste à ajouter concerne souvent des points précis, où il faut avoir une bonne connaissance du domaine. Donc c'est plus dur pour un contributeur lambda de trouver quelque chose à ajouter.
Typiquement, si on me demandait d'ajouter un article aujourd'hui, je pense qu'il me faudrait un moment pour trouver un sujet non traité (et qui soit intéressant pour Wikipedia).

Ceci dit, l'éditeur visuel me semble une très bonne idée.

Il me semble que c'est ce vers quoi tend AMD avec "Fusion" :
http://www.amd.com/us/products/technologies/fusion/Pages/fusion.aspx

En gros, ils mettent un GPU et un CPU sur un même chip et partagent un certain nombre de composants partageables. C'est intéressant comme approche. Je me demande si Intel fait la même chose avec les cartes graphiques de ses i3/i5/i7 ?

Je trouve qu'en général, les pages man (sous GNU/Linux) manquent d'exemple. C'est bien de lister les options, mais parfois quelques exemples seraient les bienvenus. Du coup quand je me retrouve plus souvent à faire une recherche Google (en ajoutant "sample" ou "example") qu'à lire la page de man.

Pour Word et Photoshop (ou Gimp ou OpenOffice, etc..), ils ont clairement des fonctionnalités qui demandent un apprentissage. Mais l'apprentissage se fait pas mal en douceur, il y a beaucoup de fonctions qui sont "découvrables" en se baladant dans les menus, en testant un truc, etc...

C'est nettement plus interactif que le logiciel ou tu te tappes 200 pages de manuel avant de pouvoir comprendre comment le lancer.

C'est quoi une monnaie libre ?

Ouais mais j'ai l'impression que Scala pousse à ça même hors des bibliothèques spécialisés.
Typiquement, on n'est pas obligé de mettre les parenthèses quand on appelle une méthode à un argument. On n'est pas toujours obligé de mettre un point virgule à la fin d'une expression (mais parfois oui et les règles sont pas super faciles à mémoriser), etc...

Le problème c'est que ça permet d'avoir deux programmes tout deux écrits en Scala qui n'ont pas forcément du tout la même gueule. Donc on se retrouve à devoir réapprendre une partie de la syntaxe à chaque fois. C'est particulièrement vrai avec la surcharge des opérateurs qui est utilisée à tort et à travers, encore plus qu'en C++ (pour écrire des parser, pour manipuler des structures de données).

Enfin voilà, c'est un peu dommage. J'aime beaucoup les idées de Scala, mais je rêverais d'une syntaxe un brin plus standardisé pour pouvoir l'utiliser tous les jours.

Tart a l'air intéressant. En gros ça simplifie le C++ avec une syntax plus moderne et des ajouts intéressants comme les closure, les fonctions anonymes, les protocol.

J'aime aussi bien le fait que ça semble rester très lisible. J'aime aussi bien Scala, mais on peut vraiment écrire des choses incompréhensibles pour le commun des mortels, notamment en abusant le système de type. Donc j'ai toujours été intéressé par un truc entre le Java/C++ et le Scala et Tart a l'air pas mal dans cette niche.

Contrairement à ce qu'ils pensent, les "riches" ne sont pas que 1% (les banderoles "nous sommes les 99%" m'ont bien faire rire, c'est une démonstration flagrantes d'un manque de connaissance sur le patrimoine des gens et sur ce que ne veulent surtout pas les gens dans leur ensemble, pas que les 1% soit-disant privilégiés),

Je ne suis pas porte-parole du mouvement occupy, mais il ne me semble pas que la rancoeur est spécialement dirigée à la famille qui a acheté une maison pour élever ses deux gamins, mais plutôt vers les patrons de banques et autres traders, qui forment moins de 1% de la population et qui s'en mettent plein les poches.

Un petit éclairage sur la situation aux Etat-Unis (qui est probablement pire qu'en Europe au niveau inégalité) :
http://www.businessinsider.com/what-wall-street-protesters-are-so-angry-about-2011-10?op=1

Bref, on peut vouloir défendre les épargnants normaux et s'offusquer des différences qui deviennent de plus en plus criantes entre les dirigeants du CAC40 et les autres.

Ceci dit, le vrai problème dans ce débat, même si on retourne à la planche à billet sans passer par les marchés, c'est d'avoir des finances publiques à l'équilibre et réserver les emprunts aux investissements exceptionnels. Le problème est politique. Soit on baisse les dépenses et tant pis pour le social, soit on augmente les revenus.

J'ai surtout l'impression qu'on a surtout intérêt à utiliser Xfce sur on est déçu de Gnome3.
On peut assez facilement le faire ressembler méchamment à Gnome2 et probablement qu'avec quelques devs motivés, il est possible de coder des applets pour ce qui manque.

D'ailleurs, est-ce que quelqu'un sait si Xfce va passer à GTK3 ?

Ben si y'a que un type de chaque côté, il n'y a plus de pair de chaque côté, donc c'est plus du pair à pair, c'est du un à un : U2U.

Et aussi, c'est bien, mais à part le moteur en lui même, que cela apporte-t-il au monde du jeu vidéo libre ?

C'est sacrément éducatif si tu t'intéresse au rendu 3D. Carmack est un des meilleurs programmeurs de moteurs 3D et donc on y trouve en général des perles et optimisations qu'on ne trouve pas forcément ailleurs.

Je ne pense pas que le passage au C++ change grand chose, surtout que c'est du C++ assez soft (pas d'abus des templates ou autre code illisible. En gros c'est juste pour faire de l'objet plus facilement).

Par rapport à Ogre, le moteur de Doom3 est très orienté FPS alors qu'Ogre est plus généraliste. C'est probablement à la fois un avantage (si on fait un FPS) et un inconvénient (si on veut faire autre chose).

En fait il y a deux techniques : Depth fail et Depth pass . Le passage de l'une à l'autre est trivial, mais seule une des deux est breveté :
http://en.wikipedia.org/wiki/Shadow_volume

PID to kill:

Ça n'a aucune importance: chaque log doit être analysé selon l'application qui l'a généré. Quelque soit le système que tu utilises, tu ne peux pas utiliser le même outil pour analyser les logs de SUDO, de ton serveur MAIL, de ton serveur HTPP, SMTP, ou FTP, tout simplement parceque ce sont des applications complètement différentes.

Ou pas... Typiquement, si on fait un outil de monitoring de sécurité, ça peut être intéressant de pouvoir faire une analyse chronologique de ce qui se passe : ah tient, y'a ssh qui me sort 5000 attempts loupés puis sudo qui m'en sort 5000 autres et ensuite y'a un redémarrage de mon serveur HTTP.

Enfin voilà, c'est le premier exemple qui me vient à l'esprit. Je suis sûr qu'il y a plein de gens qui font du monitoring qui vont trouver intéressant le fait de pouvoir potentiellement détecter des patterns en ayant des logs un peu plus structurés.

Pour la sécurité, il dit

The message data is generally not authenticated, every local process can claim to be Apache under PID 4711, and syslog will believe that and store it on disk.

Traduction :

Les données des messages ne sont en général pas authentifiée. N'importe quel processus local peut prétendre être Apache avec le PID 4711 et syslog va le croire et stocker ça sur le disque.

En gros, le problème de syslog semble être que c'est assez facile de falsifier les logs (pour cacher une intrusion, etc...). Comme Journal authentifie lui-même le processus qui log, ça résoud ce problème.

En même temps, il me semble que Lennart a quelques bons arguments concernant l'état des logs sur les systèmes Unix. Notamment sur la sécurité (c'est juste du texte, on ne peut pas faire confiance aux pid), sur le fait que c'est le bordel à parser parce que il n'y a pas de vrai format standard, que les timezones ne sont pas forcément indiquées, qu'on a 45 fichiers de logs, etc...

Enfin voilà, à priori, avoir des logs sous une forme un peu plus structuré faciliterait grandement la tâche des admins en permettant de simplifier l'écriture d'outils de monitoring. Si l'API de journal est bien foutue, ça peut donner des choses intéressantes. Je remarque qu'ils semble aussi garder le format texte (ce qui est une bonne chose), donc un grep continuera à fonctionner.

Il met aussi en avant le fait qu'un programme qui utilise le syslog standard verra son log dupliqué : une fois dans syslog et une fois dans Journal.

Je pense que le fait de casser la compatibilité est parfois nécessaire pour faire avancer les choses.