Xowap a écrit 71 commentaires

Pour ma part j'ai déjà fait un poster similaire avec Inkscape, et bien qu'il soit actuellement classé secret-défense pour conserver ma dignité, d'un point de vue technique ça avait été plutôt adapté.

OOo/LO Impress, en ce qui me concerne, c'est un peu de la grosse merde. Comme l'ensemble de cette suite, ça fait tout mais ça le fait mal.

Sinon en ce qui concerne l'impression à proprement parler, la dernière fois que j'ai tenté d'imprimer un truc géant pour la déco du bureau, j'ai utilisé PosteRazor qui m'a permit d'utiliser des feuilles A4 pour me faire un Linus Torvalds de 1m20 de haut.

Bon, toutes les montres citées ci dessus ont l'air un peu à la masse (une montre sous Android, lol). En particulier, je pense qu'aucune d'entre elle ne dépasse la semaine d'autonomie...

Cependant je crois qu'il manque un détail important : la MetaWatch tourne sous FreeRTOS, et accessoirement le code source est disponible dans une licence à priori libre que j'ai eu la flemme de lire, sans oublier que la montre est entièrement documentée, y compris le protocole de communication. Ce qui veut dire qu'on peut créer ses propres applications, et implémenter la communication avec la montre sur un téléphone moins propriétaire qu'un Android (les oubliés genre FreeRunner, N900, N9, ...).

Personnellement, je trouve que c'est de loin le produit le plus viable des 4 proposés. Si quelqu'un cherchait à m'offrir un truc pour noël :3

Le problème avec les journaliste c'est qu'ils ne savent pas poser les questions fun... Si Linux devient trop complexe, fallait demander si finalement les microkernels n'étaient pas une bonne idée :3

Ils auraient pu utiliser des technologies modernes pour faire la page... Quelqu'un pour refaire la page en flash ? :3

La reconnaissance vocale ? Qui se voit parler à son PC à longueur de journée ? Déjà que les interfaces graphiques ont tendance à être superflues, l'interface vocale j'y crois pas trop.

Quand à l'impact sur l'upload, pour mémoire les FAI proposent déjà tous des services téléphoniques qui fonctionnent par ADSL, et sans que cela s'en ressente sur le surf, donc à priori pas de problèmes de débit montant pour la voix.

Si tu peux faire ça, l'IPv6 gère très bien le fait d'avoir plusieurs adresses par interface. Par contre y'a des FAI qui risquent de pas aimer...

IPv9 plutôt si ma mémoire est bonne :3

Tu sais, le jour où le gouvernent décrétera que tout flux chiffré non autorisé équivaut à se faire couper Internet pendant 1 an, tu feras moins le malin. Le gouvernement a toujours le dernier mot je te signale.

Si tu tiens à la liberté c'est pas en lutant contre le gouvernent que tu l'aura, c'est en mettant en place un gouvernement qui la défend. Si tu a de l'énergie à revendre, ne la passe pas à mettre en place des chiffrements stéganographiés dans tous les sens, va plutôt militer pour un parti politique qui défend tes idéaux.

La confidentialité de tes communications est garantie par la loi, et ton FAI n'a absolument pas le droit d'en regarder le contenu de ce que tu envoies. Les seuls éléments à craindre étant donc les pirates et le gouvernement. Gouvernement qui d'ailleurs peut très bien te demander ta clef privée et ton mot de passe, et là tu ne peux plus faire grand chose.

Quand aux pirates, comment dire... Tu transmets de temps en temps des données sensibles et tu veux les noyer dans un flux d'autres données ? Ah bon ? Comme ton cookie gmail ou ton numéro de carte bancaire ? C'est bien de vouloir les cacher hein, mais si quelqu'un veut te piquer ta carte bleue il aura plus vite fait de te casser la gueule dans la rue et de vider ton compte au distributeur le plus près que de casser ta connexion SSL. Remarque, il peut aussi faire ça numériquement, en faisant du phishing ou en installant un malware, mais ton chiffrement ne va pas t'aider là.

Maintenant soyons réaliste 2 secondes et attaquons nous à des problèmes réels, c'est à dire pas des problème de geek parano qui veut tout cacher ce qu'il fait du méchant gouvernement. Imaginons : tu es short sur la connexion internet du bâtiment que tu administre, et tu veux optimiser ça avec un proxy cache. Les gens utilisent tous du SSL ? Oh ben t'es baisé. Tu veux que les gens puissent télécharger comme des gorets mais jouer en ligne avec un ping correct. Les gens font tout passer dans un tunnel SSH ? Oh ben t'es baisé.

De toutes façon, c'est pas grave. Moi je m'en fiche, j'habite en ville et je roule avec un gros 4x4. Ça dégage bien plus de CO2 qu'il n'en faudrait, ça empêche les gens de respirer de l'air de bonne qualité, ça prend de la place sur les parkings, et en plus c'est absolument indispensable si jamais je dois passer une flaque d'eau. Mais les gens ils vont se faire foutre, par ce que je paie mon carburant et c'est pas leur problème ! En plus, avec un 4x4 comme ça, les gens ils vont penser que j'ai un gros pénis.

Non franchement, Internet est une ressource limitée, c'est pas la peine de lui chier dessus au nom de la lute contre les méchants gouvernements. Surtout en France. Les méchants gouvernements, fallait pas les élire à la base...

Là c'est un usage légitime je conteste pas !

Par contre chiffrer toutes ses communications c'est débile...

« Why? Let's consider the (realistic) possibilities. A likely one is that you are a clueless spoiled American adolescent (or a European equivalent of one) with liberal views, believing that it is vital to prevent the government from snooping on his political views, as expressed in various circle-jerk online forums. Another possibility is that you are an adult American neocon nutjob who likes to buy guns and memorize their technical specifications, and frequently masturbates to the absurd idea that it will be a rabble of people like him, and not the military elite, who might one day overthrow the evil centralized government. Yet another possibility is that you simply like to view nude pictures of little kids — which, depending on your jurisdiction and the hypocritic prurience of your surroundings, might as well include 20-year-old nubile females. »

[source: http://dee.su/liberte-motivation ]

Un outil comme Tor a un coût énorme en terme de performances, qu'il s'agisse de l'utilisateur, des relais, ou des divers opérateurs traversés une ou plusieurs fois pour le même paquet. Sans oublier l'impossibilité de faire de la QoS, par exemple.

En gros, le geek capricieux qui décide de chiffrer toutes ses communications prends la décision de saturer le réseau mondial ¹, tout en marchant sur la gueule de autres utilisateurs ², en augmentant les émissions de CO2 ³, rendant au passage le réseau incontrôlable ⁴ et tuant au passage des bébés phoques en masse.

Chiffrer ses communications par ce qu'on transporte des données sensibles oui, mais communiquer en IPsec + Tor avec Facebook, faut pas se foutre de la gueule du monde non plus...

________
¹) Un paquet qui transite dans Tor passe par au moins 3 nœuds à priori, donc engendre au moins 3 fois plus de trafic.
²) Pas de QoS veut dire que tous les flux seront traités à égalité, ce qui n'est pas bon dans certains cas, et ce même sans porter de jugement de valeur. Exemple, la VoIP demande une faible latence mais un faible débit, alors qu'un transfert de fichier se fiche de la latence, mais demande du débit.
³) Et oui le chiffrement à tous les étages ça mange du CPU et donc du courant électrique.
⁴) Oui c'est le but de ces outils, et non je n'ai aucune envie de voir un réseau anarchique qui échappe à toutes règles.

Pour moi IPsec c'est bien, mais pas top. 2 principaux arguments :

* Configurer IPsec fait le même effet que de se mettre le cerveau au congélateur puis de le manger à la petite cuillère

* Chiffrer l'ensemble des communications empêche le fonctionnement de trucs relativement importants, du genre le firewalling ou la QoS.

Finalement, c'est à n'utiliser qu'en cas de nécessité...

Bah, les nazis ont fait de bonnes choses, les autoroutes par exemple. Là c'est pareil, il a fait le format maildir. Après le reste...

C'est une légende ça...

En fait, qmail est tellement secure qu'il se torche le cul avec les conventions de placement de fichiers, et met tout dans /var/qmail. Tu peux pas le changer, c'est hardcodé (sinon ça serait pas secure).

Ensuite, le principal facteur de sécurité est le gros manque de fonctions, c'est à dire qu'un qmail brut n'est capable que de délivrer les mails dans les répertoires perso des utilisateurs système. Il n'y a pas de configuration possible, ça serait pas secure. (les seuls fichiers de "configuration" sont quelques détails qui contiennent uniquement la liste des utilisateurs ou les domaines à relayer).

S'ajoute à cela la licence jusqu'à récemment non libre, qui fait qu'on ne pouvais pas redistribuer le code source modifié. Résultat, il n'y a pas eu de fork pour ajouter des fonctionalités *. Donc si tu te retrouves avec des vrais besoins (gérer plusieurs domaines, avoir des utilisateurs non système, ...), t'es obligé d'y aller avec une mixture de logiciels externes (vpopmail, qmailadmin par exemple) + de patchs trouvés au hasard sur des mailing lists * (patchs étant incompatibles entre eux, il faut bien entendu faire l'adaptation soi même).

Finalement, ça fait une masse d'ajouts de provenance plus ou moins douteuse, dont on n'a pas de visibilité sur les bugs, et encore moins sur les failles de sécurité. Sans oublier le fait qu'à cause de licence et de la maltraitance des conventions unix, qmail n'est pas packagé dans les distributions majeures. Et comme tout le monde le sait, ne pas installer un logiciel en utilisant le système de paquets revient à s'exposer à de nombreux ennuis...

En bref, qmail lui même n'a pas de problèmes de sécurité, mais si tu veux l'utiliser en production tu va devoir choisir entre la sécurité et les fonctionnalités. Et en fait, sauf à mettre en place un relais pour spammeur, tu n'a pas le choix. Donc qmail est complètement impossible à maintenir, en plus de t'obliger à y rajouter des failles de sécurité et des bugs échapants à la loi de Torvalds, au prix d'une grosse prise de tête.

Moralité : fuyez :)

* Ces dernières années on a vu un fork majeur et des compilations de patchs se former, mais qmail n'est plus à ses heures de gloire, ces éléments sont maintenus en pointillets si maintenu, et l'origine des modifications reste toujours aussi douteuse.

Et alors, bash + m4 + make ça fait 3 langages en plus, alors que si tu fais tout en python ça ne fait qu'un langage en plus...

« Daniel J. Bernstein, l'auteur de qmail et djbdns, a proposé une alternative à Make qu'il a appelée redo, mais celle-ci se présente sous forme de notes et non pas de code. »

AAAAAAAAAAAH

Fuyez ! Fuyez ! Tant que vous le pouvez encore fuyez !

Ceux qui ont un jour utilisé qmail me comprendront...

Pour ma part j'ai testé le patch hier, il fonctionne parfaitement bien sur ma machine :)
À savoir que ça n'est pas une bête de courses, et qu'en temps normal elle lit du 1080p mais pas à l'aise. Bah là j'ai pu faire un make -j64 du kernel et regarder ma vidéo en même temps, en gardant une interface réactive.

À noter quand même que j'ai dû faire la compilation en ramfs, l'I/O du disque était saturée sinon...

Donc voilà, regarder du 1080p avec une charge de 66 sur le PC, ça fait plaisir. Et le changement est net, à partir du moment où on désactive l'option le PC devient totalement inutilisable.

Après l'intérêt avec un usage normal, j'ai pas encore trouvé. J'ai pas constaté de ralentissement, mais pas forcément d'améliorations non plus.

Personnellement j'aurais largement préféré un vrai langage/framework, comme du Python/Django par exemple, m'enfin tant qu'on me fait pas manger du code je dis rien...

Ça confirme que Facebook s'en mord les doigts non ? Être obligé de devoir écrire un compilateur de PHP vers C++ pour s'en sortir...

Et ça ne règle pas les problèmes de conception, ça n'est qu'un palliatif pour pouvoir afficher plus de pages à la seconde.

C'est un langage complètement à la rache super simple à utiliser : on ne se pose pas de questions, c'est intuitif... Très bien pour les petits sites dynamiques à l'époque où ça a été créé. Et face à des monstres du genre JSP, on comprend pourquoi les gens ont préféré faire leurs sites en PHP !

Le problème, c'est que de fil en aiguille, des fonctions ont été ajoutées au langage (la POO par exemple) pour permettre des projets plus gros. Sauf que comme les développeurs PHP sont principalement des amateurs à la base, qui ne se posent pas trop de questions, on a gardé les mauvaises pratiques (combien de serveurs encore aujourd'hui ont les magic quotes et les register globals activées, par nécessité ?). Et le langage est resté très permissif à ce sujet là...

Combien de développeurs web pros ont appris le PHP sur le site du zéro et l'utilisent quotidiennement comme référence ? Ou alors prenons le code de Prestashop (solution de e-commerce open source majeure), qui de ce que j'en ai vu utilise les classes comme sucre syntaxique pour remplacer les namespaces (toutes les méthodes sont statiques). Bref, un langage dont la culture est l'amateurisme et qui permet de faire des choses à pas cher au prix d'immondices techniques (comprendre : problèmes de performances, sécurité et mise à l'échelle).

Ça, et les défauts de conception dont je parlais avait, bien sûr... Finalement c'est le même schéma que Windows : du quick & dirty à la base, maintenant bloqué dans son évolution à cause de ses utilisateurs.

Ayons une petite pensée émue pour les plus gros sites du monde codés en PHP (Wikipedia, Facebook) qui s'en mordent aujourd'hui les doigts :)

Non sérieusement... Le PHP (Personal Home Page) est une bricole depuis toujours et restera une bricole. Comment un langage qui n'a résolu aucun de ses gros défauts peut-il être considéré comme mature ?

Je ne ferais même pas l'affront de parler de la gestion de l'Unicode, mais déjà prenons simplement le concept de base du PHP : chaque fichier est parsé à chaque page vue. Prenons au pif une page blanche générée par Symfony, ça demande environ 130 fichiers, qui doivent donc tous être lu et interprétés. Au final, 0.4 secondes pour afficher ma page blanche, c'est long. Et pourtant, PHP continue de fonctionner en tant que tel, même si *tous* les frameworks/guides de bonne pratique/applications "sérieuses" (enfin si c'était vraiment sérieux ça ne serait pas codé en PHP) font au moins utiliser des fichiers de template séparés.

Ajoutons à ça le typage faible garanti 100% non secure, l'API bordélique, tout un tas de trucs pour garder la compatibilité avec les anciennes versions (ça me rappelle la raison pour laquelle un certain OS a du mal à évoluer tiens...), des comportements étranges (une méthode static significativement plus rapide qu'une methode pas static ? sérieusement...), et j'en passe. Un langage mature ? Vraiment ?

Après y'a aussi des questions/résponses complètement insensées assez marrantes dans l'article. Par exemple, Rasmus questionné sur la sécurité qui incrimine le Javascript à cause du XSS. Il est marrant, mais totalement à côté de la plaque : côté utilisateur le gros de la menace vient des plugins privateurs (Flash "par exemple"), et côté serveur la plus grosse source de piratage vient de ... Ô surprise, PHP. Bah oui, avec toutes les mauvaise pratiques que les développeurs du dimanche on pu prendre pendant toutes ces années, c'est pas par ce que maintenant on a des moyens moins sales de faire les choses (PDO, filter input par exemple) que les développeurs les utilisent. Résultat, c'est incroyable le nombre de serveurs zombifiés à cause d'un site PHP avec une faille béante. Et pas la peine de parler de PhpMyAdmin (source de faille garantie sur 95% des serveurs web)...

Et puis il n'y aura jamais d'alternative propriétaire à PHP, pas comme ASP par exemple. Zut fallait pas le dire :)

Donc bon, la maturité de PHP, peut être pour la version 7 ?

J'ai la mémoire courte, quelqu'un peut me rappeler les précédentes tentatives d'avoir un tel outil qui se sont soldées par un flop ?

Oui bah j'ai cité l'exemple plus haut (enfin j'ai oublié de parler du DHCPv6, mais je sais qu'il fonctionne aussi). Le problème c'est que c'est dans NetworkManager, si tu veux pas de cette bouze ou si tu administre un serveur, tu l'a dans le cul...

On reste LOIN du DHCP classique dans l'intégration au système.

IPSec est surtout obligatoire dans une implémentation IPv6. Donc tous les clients IPv6 gèrent IPSec nativement, ce qui présente quand même un certain avantage, pour ne pas dire un avantage certain...

C'est ce que j'ai cru comprendre, d'où le fait que j'ai abandonné très vite...

Mais donc y'a vraiment aucun espoir de pouvoir l'utiliser sur une carte CF ?

Sans oublier le montage des partitions en noatime et l'usage d'ext2 (ou YAFFS pour les courageux) pour éviter la journalisation.