karteum59 a écrit 868 commentaires

Qui a lu dans son intégralité

Vu que le noyau des OS modernes fait qq millions de lignes de code, je dirais: personne…

-si la NSA t'en veut personnellement, alors elle lira tes données, chiffrement ou pas.

Ah, ben va falloir arreter d'utiliser Linux aussi alors, parce que nombre des contributeurs sont americains la aussi, notamment Redhat.

Ton argument aurait été plus fort avec SELinux :)

Et qu'on ne vienne pas me sortir l'anerie de la disponibilite des sources, plein de non-americains (dont moi…) ont acces a toutes les sources de Windows (et peuvent les recompiler, …). Avoir les sources ne va pas permettre de trouver toutes les petites backdoors que quelqu'un voudrait inserer en les faisant passer pour des bugs.

Sauf que

• les sources auxquelles tu as accès ont pu être amputées de toute backdoor
• "plein de gens", ça reste une minorité, donc moins de paires d'yeux et de cerveaux pour trouver les éventuelles backdoors, et une proportion très faible de la population capable de faire tourner un windows recompilé à partir des sources (potentiellement sans backdoor, cf. point précédent)

Ouais enfin bon, dans la vraie vie les gens utilisent/s'échangent des fichiers .doc(x), et LibO s'en sort malheureusement très mal puisque

• il pète la mise en forme - notamment lors de la modification / enregistrement d'un fichier. Je l'ai déjà dit de nombreuses fois ici: s'il se contentait de mal afficher et d'enregistrer les données ajoutées sous forme de nouveaux noeuds dans l'arbre XML, tout irait bien, mais en l'occurrence il parse/transforme dans sa représentation à lui (qui pète la mise en forme) et reparse/retransforme dans la représentation .docx lors de l'enregistrement, ce qui induit une perte de données irréversible. En conséquence, LibO n'est pas adapté à un travail collaboratif avec des utilisateurs de MS Office
• il ne sait pas ouvrir les fichiers liés en OLE
• … et j'en passe !

(N.B. moi non plus je n'aime pas MS Office et j'aimerais pouvoir bosser uniquement avec une suite office libre !)

Peut-être que l'existence de serveurs différents tels que PA et Jack se justifie car répondant à des contraintes différentes (faible latence vs consommation & transparence réseau), mais au moins n'auraient-ils pas pu essayer de se mettre d'accord sur une API commune ? (dit autrement et PA étant né après: n'aurait-il pas pu reprendre l'API de Jack… ?)

Il y a encore une fois qu'un seul port gigabit ce qui la rend inutilisable pour faire un routeur. J'ai juste ?

Si c'est que ça

• on trouve des adaptateurs USB-ethernet pour 1€ en Chine (ou 8 € en France)
• on trouve des switchs manageables (avec VLAN) 8 ports GbE pour 20 € en Chine + FDP en France (or tu peux te faire un trunk entre ta carte et un port de ton switch et artificiellement augmenter ton nb de ports eth de cette manière)

Pour l'avoir essayé (de même que ses concurrents): c'est marrant 5 minutes mais on ne joue clairement pas dans la même cour qu'Android ou Ubuntu (après, va savoir si ça vient du hardware bas de gamme ou de l'OS…).
Et du reste, il y a de bonnes raisons de penser que les applis web ne sont peut-être pas la meilleure approche pour les terminaux mobiles avec peu de RAM

Quelqu'un a un retour d'expérience sur tinyldap ?

je ne suis plus maître de mon serveur. (…) l'hébergeur peut changer ses conditions commerciales ou techniques à tout moment

Tu as l'accès root, et (j'espère) un backup de tes données qui te permet de lancer un autre VPS ou serveur ailleurs

pour garder un prix raisonnable, il faut vraiment se limiter en espace disque et mémoire.

3€/mois pour un VPS KVM avec 512Mo de RAM, 15Go d'espace disque et 2000To de bande passante, c'est vraiment limitant pour de l'auto-hébergement ? (surtout comparé à une Raspberry Pi derrière une ligne ADSL !)

Ces formats MS Office sont-ils documentés ?
Au fait, tu es au courant que les logiciels libres n'ouvriront JAMAIS CORRECTEMENT les documents écrits avec la version courante de la suite concurrente ? La concurrence prend les mesures techniques nécessaires pour que ça ne soit pas possible.

En ce qui me concerne, je ne jette pas la pierre à l'équipe LibO car la concurrence de MSO (qui a des développeurs payés, et impose son format de fichier fermé) est effectivement déloyale et les développeurs LibO ont fait un travail magnifique. Cependant, il faudrait tout de même prendre acte que dans le monde réel le format .docx est prépondérant, et qu'en contexte collaboratif le fait que LibO casse le document (donc le travail des autres) rend la suite inutilisable dans ces contextes. D'autres suites propriétaires concurrentes de MSO s'en sortent mieux car elles ne modifient que les noeuds nécessaires et ne touchent pas à ce qu'elles ne comprennent pas ou ne modifient pas à l'intérieur du document .docx.

Quant à la lourdeur, LO tourne vraiment partout. Il est peut-être un peu lent (enfin c'est surtout des problèmes de boutons qui mettent 30 ans à se redessiner, du moins sous GNU/Linux),

ça dépend de ton PC… (peut-être que sur un PC récent ça se tient. Sur le mien en tout cas ça rame !)

mais il ne plante jamais (depuis la série 4.X de LO j'ai pas vu un seul plantage).

OK, donc on verra quand ce sera intégré dans les distributions stables/LTS…

Ces formats MS Office sont-ils documentés ?

Question typique de geek/libriste, mais hors-sujet pour le grand public.
Oui: je suis d'accord qu'il est déloyal/injuste d'exiger de OOo le même niveau de qualité que MSO pour supporter le format interne non documenté de MSO (d'ailleurs j'ai bien dit "aussi regrettable cela soit-il"). Mais la réalité est ainsi: le monde fonctionne sous MSO, donc quand on travaille en collaboration avec d'autres personnes il faut travailler avec le format MSO. Point.
Le minimum est donc que OOo ne détruise pas la mise en page et les métadonnées de MSO (même s'il ne comprend pas tout). De nombreuses suites alternatives (e.g. sous Android) n'ont pas un support complet du .docx et s'en sortent pourtant mieux pour la modification de fichiers .docx car elles ne modifient que le nécessaire dans l'arbre du document.

Au hasard :

• parce que le monde entier utilise .doc(x) (aussi regrettable cela soit-il), et que OOo n'est pas capable d'ouvrir et imprimer correctement un tel document, et surtout de le modifier/enregistrer sans péter la mise en page et/ou la structure du document (sommaire, etc.), ce qui le rend impropre au travail collaboratif ? (N.B. accessoirement il ne sait pas ouvrir les document attachés en OLE, ce qui est très gênant dans mon quotidien)
• parce qu'il bugge/plante toutes les 5 minutes, et qu'il est bien plus lent/lourd que la concurrence (y compris MSO) ?
• parce que les thèmes par défaut sont moches ? (argument mineur pour moi mais majeur pour nombre de mes collègues)
• …

N.B. je suis un des rares irréductibles de ma boite à avoir refusé MacOS et à continuer d'utiliser OOo sous Linux quotidiennement, mais c'est un sacerdoce et je dois régulièrement lancer MSO dans une VM WinXP. J'apprécie énormément les efforts des développeurs OOo, mais je pense que c'est surtout approprié pour un usage personnel/privé et pas entreprise dans un contexte collaboratif où les autres utilisent MSO. On aura déjà fait un grand progrès le jour où OOo saura ne modifier que les noeuds nécessaires sans péter le reste lors de la modification d'un document .doc(x) ! (i.e. sans chercher à parser / interpréter / réenregistrer la totalité du document en perdant de l'information au passage)

Oui donc c'est bien ce que je disais (dans ton cas c'est juste un argument de plus !) : prétendre que du h.264 (ou h.265, ou VP8/VP9, etc.) puisse se substituer à une vraie technologie d'affichage distant (X/NX/RDP), c'est tirer un trait sur la possibilité de faire du remote desktop en bas débit/forte latence.

Totalement d'accord: tu es root, tu peux chiffrer tes données, etc.
Par contre concernant les backups: les offres VPS "pas chères" que je mentionnais n'incluent généralement pas les backups => ça ne dispense pas de faire un rsync régulier, et par ailleurs le stockage n'est "que" de 15 Go dans l'offre de base (OS inclus, ce qui me suffit bien pour ma part).

Par contre je n'ai pas regardé de près quelles étaient les machines hôtes et j'ignore combien de VM ils mettent dessus et quelles sont les "bonnes pratiques" (j'ai lu plein de fois que les offres OpenVZ avaient tendance à être davantage overbookées que les offres KVM, qui présentaient donc davantage de garanties en terme de ressources réssources réservées, mais j'aimerais avoir plus de billes). La question n'est pas "que" d'ordre technique mais aussi d'ordre environnemental: si on peut héberger décemment plus de 100 VMs sur une grosse machine, je pense que l'impact de cette machine seule est moindre que celui de 100x Raspberry Pie (consommation d'eau, de terres rares, d'énergie, durée de vie, etc.). Par contre ce n'est peut-être plus vrai si le nombre de VM est < 20…

Je doute que h.264 puisse rendre quoi que ce soit d'utilisable visuellement sur des débits de type modem 56KBits/s (alors que NX s'en accomode sans problème !). Et oui, il y a des cas d'usage (il est très courant de tomber sur des connexions internet lentes ou instables dans de nombreux pays à l'étranger…)

Et y'a aussi OSSv4 qui juste marche…

Des hébergeurs comme Prometeus/iperweb proposent des offres VPS KVM pour moins de 3€/mois, incluant autant de RAM que sur un RPi, 2000To / mois de trafic (soit plus que ce qu'une ligne ADSL à 1MBits/s peut uploader en continu sur un mois), une vraie connectivité internet (i.e. supportant des pointes à 100MBits/s) et globalement quelque chose autrement plus fiable qu'un RPi hébergé derrière sa ligne ADSL. Bref, entre donner toute sa vie à Google et tout héberger chez soi, il y a un entre-deux…

Surtout chez la concurrence et malgré leur interface à rubans immonde, il est très facile de faire un document qui présente bien en 3 clics (thèmes/styles), alors qu'il faut à la fois être pas trop manchot et passer du temps pour avoir un truc joli sur LO, dont les thèmes par défaut semblent dater du siècle dernier…
(A mon grand dam, la branche consulting de ma boite est repassée à la MSOffice précisément pour cette raison : parce qu'avoir des livrables qui présentent bien est important pour leur activité (troll inside :) )

Je ne suis pas expert du sujet, mais vu l'approche de Wayland, je m'interroge aussi sur l'envoi de commandes graphiques en vectoriel ("trace une ligne du point A au point B") plutôt que tout le buffer bitmap (plus gourmand en bande passante). X/NX/RDP ont une approche vectorielle, et je comprends que pour faire la même chose avec Wayland (qui a une approche bitmap, comme VNC) il faudrait intercepter les appels aux autres libs en amont (e.g. pour remplacer les appels OpenGL par une sorte de RPC pour que le dessin lui-même se fasse sur le client distant). Me trompe-je ?

N.B. comme on est trolldi, je peux en profiter pour dire aussi: de toute façon l'avenir est aux applications HTML5 non ? :)

Le pire, c'est qu'il existe des gestionnaires de paquets qui savent correctement gérer les rollbacks/downgrades (e.g. Pisi dans Pardus, ou Nix dans Nixos). Sauf que là par rapport à une base Debian on se heurte à un problème de masse critique (moins d'utilisateurs, moins de paquets et paquets moins testés, moins de bug-reports et de discussions sur les forums, moins de support industriel (e.g. Steam, AOSP), etc.)

J'ai fait hier soir mon upgrade de XUbuntu 12.10 vers 13.04. Résultat: OpenGL qui ne fonctionne plus ("can't open visual". Pas de message plus explicite, et pourtant j'utilise les drivers Intel open-source et j'ai désactivé le compositing et vérifié la présence de libGL*.so), mes trayicons qui n'apparaissent plus (Pidgin, etc.), et je n'ai pas encore fouillé en détails pour vérifier quoi d'autre avait pu être cassé au passage. Bref, les upgrades c'est bien mais c'est pas toujours au point…

C'est un peu le problème de xmpp qui est trop extensible (du coup personne ne supporte le même sous ensemble de fonctionnalités).

Le fait que le protocole soit "trop souple" est un souci pour l'interopérabilité sur les fonctionnalités avancées, mais pas un souci en soi pour que Google fasse un produit fini ("aussi bien que Skype") qui marche bien avec lui-même. C'est donc que le problème est ailleurs: soit XMPP n'est pas adapté en soi (par exemple: XML trop verbeux, NAT compliqué car ports différents entre signalisation et données, etc.), soit avoir un protocole fermé faisait partie du cahier des charges comme l'évoquait Maclag.

Dans le cas de la téléphonie mobile, comme du wifi, il y a un levier pour les autorités: l'autorisation d'utiliser ou pas certaines fréquences, et dans quelles conditions. L'État peut donc imposer un standard de communication en échange de l'octroi de la licence.

En fait non, le levier est ailleurs désormais. Depuis la mise en place de l'approche WAPECS en Europe, tout nouveau spectre se doit de garantir la neutralité technologique, modulo quelques contraintes génériques telles que les block edge masks (voir le rapport CEPT 19 à ce sujet). C'est notamment le cas des bandes 3.5 GHz, 2.5 GHz et 800 MHz (e.g. personne n'est obligé de déployer du LTE dans les bandes "4G"—à ceci près qu'aucune autre technologie ne répond aujourd'hui aux contraintes définies en terme de débit, mode de duplexage FDD dans les bandes de fréquences définies, etc.). La CEPT travaille d'ailleurs aujourd'hui sur la neutralité technologiques pour les bandes 900 et 1800 MHz (afin qu'on puisse notamment y déployer du LTE/WiMAX).

La raison pour laquelle le LTE "gagne" (et pour laquelle toutes les technologies concurrentes comme le WiMAX sont mortes) est ailleurs, dans les économies d'échelles au niveau industriel: personne ne va investir des millions en coûts fixes de R&D pour une technologie qui ne draine que des petits volumes. "The winner takes it all"…

Pour reprendre un autre exemple: personne n'est obligé non plus de se restreindre au wi-fi dans la bande ISM. Pourtant, les concurrents comme HomeRF et HiperLAN sont morts et enterrés depuis longtemps, pour des raisons de volumes et d'économies d'échelles.

Le problème venait-il de XMPP en tant que protocole fondamentalement inadapté, ou de la myriade de clients XMPP qui implémentaient la moitié des fonctionnalités et la manière intrinsèquement lente de définir un standard ?
Dit autrement : qu'est-ce qui empêche Google de développer son Hangouts sur la base de XMPP + des extensions/XEP à eux ? (qu'ils rendraient publiques mais qu'ils définiraient seuls à la vitesse et de la manière qui leur convient).

(cela dit, j'avoue que pour la voix/vidéo, un protocole de signalisation du type IAX2 qui n'utilise qu'un seul port multiplexé pour la sig + les données me semble plus simple pour traverser les NATs, donc peut-être que effectivement XMPP était fondamentalement inadapté…)

OK, ça répond au point sur l'inclusion de CAcert (qui n'est pas un bug, c'est un choix)

Par contre, le comportement consistant à afficher une page blanche (plutôt que le dialogue pour ajouter le CA) dans le cas de HSTS est selon moi un bug (qui se présente avec tout certificat auto-signé, pas seulement avec cacert), d'où mes questions: est-ce spécifique à Mozilla ? (ça se comporte comment avec Chrome/Safari/IE ?)