disponibilité d'un format de compression de textures libre de droits (ETC, offert par Ericsson)
Je ne comprend pas vraiment le sens de "libre de droit" ici. J'ai bien trouvé la licence du kit de dévelopement de ETC, qui ne ressemble pas à une licence libre, mais rien sur le format lui-même ou les brevets qui pourraient s'y appliquer.
Pourrais tu expliquer le sens de la formule fourre-tout "libre de droits" dans le cas présent?
Bon c'est vrai que le bousin n'arrive pas à la cheville d'Emacs et pas mal d'autres références déjà libres, mais bon une libération est toujours une bonne chose.
Comme tu dis il ne tourne que sur Mac OS, mais le truc doit pouvoir être porté sur GnuStep je pense, celui-ci réimplémentant l'API Cocoa.
Non c'est vrai. Pour ces choses lourdes on va soit devoir donner des liens et s'appuyer sur HTTP, ou bien faire un truc original et concocter une nouvelle XEP pour XMPP.
C'est là aussi l'avantage du protocole, il est extensible et les extension sont standardisable(?) par une entité gouvernante (la XSF).
Ça n'est pas encore possible avec Movim. Je crois que friendica propose des fonctions de formattage, mais tu devrais essayer pour savoir si c'est suffisant pour toi.
Le gros soucis de PHP avec ce genre d'application vient du fait qu'il est stateless (c'est à dire qu'il oublie complètement ce qu'il fait d'une requête à l'autre), de plus il ne tourne pas non plus entre deux requêtes. XMPP s'attend à ce que le client et serveur soient à l'écoute en permanence. Ça complique énormément les choses.
Movim est compatible avec Jappix. La différence principale vient surtout de la structure, Jappix étant presqu'intégralement en javascript, il s'agit d'un client lourd alors que Movim tente d'alléger de client le plus possible, le but étant qu'on puisse utiliser Movim à terme sur des terminaux peu puissants (comme des smartphones d'entrée de gamme).
Non ce n'est pas une question qu'on a si souvent. Intrinsèquement la différence entre Movim et Diaspora n'est pas grande (sauf qu'on n'a pas 200k$).
S'il y a bien une distinction, elle vient plutôt du protocole qu'on utilise, XMPP ayant déjà un grand nombre de serveurs et de clients, Movim est de facto déjà accessible à un grand réseau d'utilisateurs. De plus, XMPP est standard et extensible, donc ça simplifie grandement la compatibilité et interopérabilité.
Du côté de diaspora par contre, on a un protocole propriétaire qui n'est pas compatible avec l'existant[1], qui n'a qu'un réseau existant somme toute assez limité, et un seul client (à ma connaissance), qui n'est pas standard (forcément) et a une maturité et une documentation assez douteuse[2].
la protection d'un serveur, d'un ordinateur… par un parefeu correctement paramétré est une obligation.
Tu as raison et tu as bien fait d'insister sur le pare-feu, d'autant que le NAT n'a pas été conçu comme un mécanisme de protection, et qu'avec IPv6 qui arrive, il va falloir qu'un bon nombre d'admins revoient la sécurité de leur réseau.
Le alt-F2 qui propose l'autocomplétion des commandes (et programmes) est plus que bienvenue, c'était sans doute le plus gros manque d'XFCE pour mon utilisation quotidienne.
Et de plus, cette fonctionalité et rapide et sans indexation coûteuse; que demander de plus?
En l'occurence il ne s'agit que d'un membre, pas d'un actif qui travaille pour la FSF. N'importe qui peut avoir une adresse de la FSF et être assez bête pour envoyer des suggestions personelles avec.
Je ne suis pas du tout spécialiste en la matière, mais j'ai le sentiment que le circuit graphique n'a pas grand chose à voir avec le fait que le processeur soit ARM, un peu comme si nvidia faisait un processeur intel maison avec un GPU (pas libre) dans la même puce.
Enfin ces fabricants sont des spécialistes de l'embarqué ou du mobile, domaine où le libre n'est pas du tout habituel et leur manière traditionelle de faire est de tout planquer. Mais ça va venir (l'espoir c'est bon).
C'est bien que Coreboot puisse avancer comme cela. Avec un peu de chance nous pourront tous le flasher bientôt et faire un pied de nez à UEFI.
Je trouve juste un peu triste qu'il faille qu'une entreprise monstrueuse comme Google force la main d'Intel pour que les clients (d'Intel) puissent avoir les specs des chipsets qu'ils ont acheté.
Sûrement parce qu'après plusieurs années à -100 degrés ou encore moins, il y a assez peu de chance que le matos reparte. Qui plus est, ils éteignent des radiateurs dans la sonde afin de préserver l'énergie restante.
Je réponds à mon propre commentaire (we need to go deeper…), pour préciser un point par rapport aux autres commentaires que j'ai négligé.
Movim est libre de vrai. Du coup le tiers de confiance n'est pas obligatoirement un tiers proche. On peut très bien mettre Movim avec un serveur XMPP sur un gros serveur, faire accepter une EULA avec droits et devoirs pour les deux partis afin d'accéder au bestiau. Je pense que c'est une possibilité qui est souvent négligée.
Movim ne stocke en aucun cas les mots de passes. Nous gardons bien une empreinte sha1 du mot de passe, mais elle n'est pas utile telle quelle. Linuxfr fait probablement pareil d'ailleurs.
Il est vrai que les serveurs XMPP ont tendance à stocker les mots de passe en clair, ceci pour la simple (et honteuse) raison que les spécifications du protocole ne définissent pas une seule méthode de hashing lors de la connexion. Du coup la majorité des serveurs enregistrent le mot de passe en clair plutôt que générer de multiples hash (plus gérable, on ne peut pas vraiment les blamer).
Mais dans ce cas de figure, on peut parfaitement héberger sa propre instance d'XMPP/Movim et passer outre ces problèmes. Movim ne propose pas de nœud par défaut qui risquerait de devenir central, mais promeut une logique de confiance ; si on n'est incapable d'administrer une instance de Movim, on peut toujours utiliser celle d'un tiers de confiance, ami, famille, coloc etc.
Non je ne connaissais pas. Mon choix s'était porté sur mod_proxy_balancer parce qu'il fait partie d'Apache et est assez simple à configurer. Après on peut aussi le rendre "aware" du contenu du site, cookies etc. de manière à toujours envoyer la même session sur le même esclave derrière (sympa pour la consistence).
Enfin au niveau load balancer, il y a largement le choix, avec toutes les implémentations disponibles, dont certaines hardware. Ça dépend aussi de ce qu'on a derrière, dans certains cas de figure, un LB hardware qui fait un bête round-robin suffit (cookies de session en BDD par exemple).
[^] # Re: Trop gros, passera pas…
Posté par etenil . En réponse au journal Newton Adventure la soluce 1/6: la terrible jungle. Évalué à 0.
Ou bien "professeuse" tant qu'on y est…
# Libre de droits?
Posté par etenil . En réponse à la dépêche Quoi de neuf du côté d'OpenGL et Linux ?. Évalué à 4.
Je ne comprend pas vraiment le sens de "libre de droit" ici. J'ai bien trouvé la licence du kit de dévelopement de ETC, qui ne ressemble pas à une licence libre, mais rien sur le format lui-même ou les brevets qui pourraient s'y appliquer.
Pourrais tu expliquer le sens de la formule fourre-tout "libre de droits" dans le cas présent?
[^] # Re: Titanic
Posté par etenil . En réponse au journal TextMate2 placé sous GPL3. Évalué à 4.
Bon c'est vrai que le bousin n'arrive pas à la cheville d'Emacs et pas mal d'autres références déjà libres, mais bon une libération est toujours une bonne chose.
Comme tu dis il ne tourne que sur Mac OS, mais le truc doit pouvoir être porté sur GnuStep je pense, celui-ci réimplémentant l'API Cocoa.
[^] # Re: bosh?
Posté par etenil . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 5.
Non c'est vrai. Pour ces choses lourdes on va soit devoir donner des liens et s'appuyer sur HTTP, ou bien faire un truc original et concocter une nouvelle XEP pour XMPP.
C'est là aussi l'avantage du protocole, il est extensible et les extension sont standardisable(?) par une entité gouvernante (la XSF).
[^] # Re: Texte long
Posté par etenil . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 2.
Ça n'est pas encore possible avec Movim. Je crois que friendica propose des fonctions de formattage, mais tu devrais essayer pour savoir si c'est suffisant pour toi.
[^] # Re: bosh?
Posté par etenil . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 3.
C'est ce que propose XMPP. Movim n'en est qu'un client web.
[^] # Re: Utiliser Movim comme un blog ?
Posté par etenil . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 3.
Comparer dotclear à facebook/diaspora/movim?
Nonobstant le fait que ce n'est pas exhaustif, j'ai un peu l'impression de comparer des poireaux et des salades sur le coup…
[^] # Re: bosh?
Posté par etenil . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 4.
Le gros soucis de PHP avec ce genre d'application vient du fait qu'il est stateless (c'est à dire qu'il oublie complètement ce qu'il fait d'une requête à l'autre), de plus il ne tourne pas non plus entre deux requêtes. XMPP s'attend à ce que le client et serveur soient à l'écoute en permanence. Ça complique énormément les choses.
[^] # Re: Bravo !
Posté par etenil . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 5.
Movim est compatible avec Jappix. La différence principale vient surtout de la structure, Jappix étant presqu'intégralement en javascript, il s'agit d'un client lourd alors que Movim tente d'alléger de client le plus possible, le but étant qu'on puisse utiliser Movim à terme sur des terminaux peu puissants (comme des smartphones d'entrée de gamme).
[^] # Re: Bravo !
Posté par etenil . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 10.
Salut et merci.
Non ce n'est pas une question qu'on a si souvent. Intrinsèquement la différence entre Movim et Diaspora n'est pas grande (sauf qu'on n'a pas 200k$).
S'il y a bien une distinction, elle vient plutôt du protocole qu'on utilise, XMPP ayant déjà un grand nombre de serveurs et de clients, Movim est de facto déjà accessible à un grand réseau d'utilisateurs. De plus, XMPP est standard et extensible, donc ça simplifie grandement la compatibilité et interopérabilité.
Du côté de diaspora par contre, on a un protocole propriétaire qui n'est pas compatible avec l'existant[1], qui n'a qu'un réseau existant somme toute assez limité, et un seul client (à ma connaissance), qui n'est pas standard (forcément) et a une maturité et une documentation assez douteuse[2].
[1] http://dustinthe.net/2011/12/07/diaspora-et-friendica-commentaires-sur-les-protocoles/
[2] http://friendica.com/node/24
# Tu l'a dit bouffi!
Posté par etenil . En réponse au journal J'ai plein d'amis ... et je ne le savais pas ;o). Évalué à 1.
Tu as raison et tu as bien fait d'insister sur le pare-feu, d'autant que le NAT n'a pas été conçu comme un mécanisme de protection, et qu'avec IPv6 qui arrive, il va falloir qu'un bon nombre d'admins revoient la sécurité de leur réseau.
# Amélioration bien attendue
Posté par etenil . En réponse à la dépêche Xfce 4.10 est disponible !. Évalué à 2.
Le alt-F2 qui propose l'autocomplétion des commandes (et programmes) est plus que bienvenue, c'était sans doute le plus gros manque d'XFCE pour mon utilisation quotidienne.
Et de plus, cette fonctionalité et rapide et sans indexation coûteuse; que demander de plus?
[^] # Re: Euh .... on s'en fout non ?
Posté par etenil . En réponse au journal Où comment PiTiVi a failli perdre son nom…. Évalué à 3.
En l'occurence il ne s'agit que d'un membre, pas d'un actif qui travaille pour la FSF. N'importe qui peut avoir une adresse de la FSF et être assez bête pour envoyer des suggestions personelles avec.
[^] # Re: Mauvaise impression sur ARM
Posté par etenil . En réponse au journal Un peu plus de liberté sous ARM ?. Évalué à 2.
Je ne suis pas du tout spécialiste en la matière, mais j'ai le sentiment que le circuit graphique n'a pas grand chose à voir avec le fait que le processeur soit ARM, un peu comme si nvidia faisait un processeur intel maison avec un GPU (pas libre) dans la même puce.
Enfin ces fabricants sont des spécialistes de l'embarqué ou du mobile, domaine où le libre n'est pas du tout habituel et leur manière traditionelle de faire est de tout planquer. Mais ça va venir (l'espoir c'est bon).
[^] # Re: AMD
Posté par etenil . En réponse à la dépêche Intel Ivy Bridge et Linux : ça juste marche. Évalué à 3.
C'est bien que Coreboot puisse avancer comme cela. Avec un peu de chance nous pourront tous le flasher bientôt et faire un pied de nez à UEFI.
Je trouve juste un peu triste qu'il faille qu'une entreprise monstrueuse comme Google force la main d'Intel pour que les clients (d'Intel) puissent avoir les specs des chipsets qu'ils ont acheté.
[^] # Re: Pour coder
Posté par etenil . En réponse au journal Dotsies : remplacer l'alphabet !. Évalué à -1.
Vim?
Ah tu voulais dire Emacs.
[^] # Re: mouais bof
Posté par etenil . En réponse à la dépêche Pear Linux Comice OS 4 Final release disponible. Évalué à 10.
Ceci est une révolution.
[^] # Re: Désactivation des caméras
Posté par etenil . En réponse au journal VGER near to be out, stay tuned. Évalué à 2.
Sûrement parce qu'après plusieurs années à -100 degrés ou encore moins, il y a assez peu de chance que le matos reparte. Qui plus est, ils éteignent des radiateurs dans la sonde afin de préserver l'énergie restante.
# C'est long
Posté par etenil . En réponse au journal Anniversaire : Archlinux a 10 ans !. Évalué à -3.
Dommage que ce ne soit pas Vendredi…
Difficile de croire que ça fait 10 ans qu'on se tape les kikoolols repentis d'Arch linux.
(Moinssez-moi!)
[^] # Re: Sacré ploum !
Posté par etenil . En réponse au journal Vos retours sur Friendika et les réseaux sociaux décentralisés ?. Évalué à 1.
Je réponds à mon propre commentaire (we need to go deeper…), pour préciser un point par rapport aux autres commentaires que j'ai négligé.
Movim est libre de vrai. Du coup le tiers de confiance n'est pas obligatoirement un tiers proche. On peut très bien mettre Movim avec un serveur XMPP sur un gros serveur, faire accepter une EULA avec droits et devoirs pour les deux partis afin d'accéder au bestiau. Je pense que c'est une possibilité qui est souvent négligée.
[^] # Re: Sacré ploum !
Posté par etenil . En réponse au journal Vos retours sur Friendika et les réseaux sociaux décentralisés ?. Évalué à 1.
Movim ne stocke en aucun cas les mots de passes. Nous gardons bien une empreinte sha1 du mot de passe, mais elle n'est pas utile telle quelle. Linuxfr fait probablement pareil d'ailleurs.
Il est vrai que les serveurs XMPP ont tendance à stocker les mots de passe en clair, ceci pour la simple (et honteuse) raison que les spécifications du protocole ne définissent pas une seule méthode de hashing lors de la connexion. Du coup la majorité des serveurs enregistrent le mot de passe en clair plutôt que générer de multiples hash (plus gérable, on ne peut pas vraiment les blamer).
Mais dans ce cas de figure, on peut parfaitement héberger sa propre instance d'XMPP/Movim et passer outre ces problèmes. Movim ne propose pas de nœud par défaut qui risquerait de devenir central, mais promeut une logique de confiance ; si on n'est incapable d'administrer une instance de Movim, on peut toujours utiliser celle d'un tiers de confiance, ami, famille, coloc etc.
[^] # Re: mod_sed en 2012
Posté par etenil . En réponse à la dépêche Apache passe en version 2.4. Évalué à 1.
Ça peut aussi servir pour des remplir des templates et les servir facilement.
[^] # Re: Sources
Posté par etenil . En réponse à la dépêche Sortie d'Anvil. Évalué à 6.
Heu, est-ce de ça que tu parle?
http://bzr.ath.cx/anvil-forge/branch/0.01/file/anvil.py-20110819183743-2v7mwdiky03278br-1
# Passe donc nous voir.
Posté par etenil . En réponse au message Movim 0.4. Évalué à 3.
Salut,
Movim n'a pas de forum. Néanmoins, je t'encourage à passer nous voir sur le salon jabber movim@muc.jappix.com.
[^] # Re: HA avec Apache
Posté par etenil . En réponse au journal Quelles solutions adopter pour améliorer un parc existant ? La suite !. Évalué à 1.
Non je ne connaissais pas. Mon choix s'était porté sur mod_proxy_balancer parce qu'il fait partie d'Apache et est assez simple à configurer. Après on peut aussi le rendre "aware" du contenu du site, cookies etc. de manière à toujours envoyer la même session sur le même esclave derrière (sympa pour la consistence).
Enfin au niveau load balancer, il y a largement le choix, avec toutes les implémentations disponibles, dont certaines hardware. Ça dépend aussi de ce qu'on a derrière, dans certains cas de figure, un LB hardware qui fait un bête round-robin suffit (cookies de session en BDD par exemple).