psychoslave__ a écrit 5873 commentaires

Ce serait sympa de voir quels projets ont utilisé VisualGST pour leur conception, ça permettrait de se faire une idée de ce qu'on peu faire avec et en combien de temps.

Microsoft est une entité virtuel, pas une personne physique capable de ressentir les sentiments dont tu parles.

Le fait est que les seuls points qui nous permettent de spéculer sur la stratégie qu'essai de mettre en place microsoft sont :
* ses actions passés;
* ses actions présentes;
* d'hypothétiques fuites internes.

En attendant demain ou une tel fuite qui serait fiable (je fait exprès de laisser s'échapper malgré moi un document qui montre que je suis un bisounours), on ne peu juger que sur les deux premiers points.

Bah ils peuvent faire une période de transition avec un gros «if» qui choisi le moteur de rendu à utiliser.

Bah non, parce que si tu veux des roues avec un pneu que tu peux facilement changer à la main, tu veux pas des roues avec chenilles de char d'assaut qui sont censés résister à tout mais qu'il faut surtout pas avoir envie de changer à la main.

Bah tu consultes l'article linuxfr et tu compares le html et le code wiki. :)

Ça ne correspond pas à ce que j'ai dit.

Si le xml c'était tellement de la balle, on aurait pas de syntax wiki, smtpd.conf[1], etc. Si il y a la moindre chance que l'utilisateur (quelque soit son niveau) ai à modifier le fichier avec un éditeur de texte, alors xml est un mauvais choix.

Ça ne veut pas dire qu'un fichier texte clef/valeur est nécessairement mieux qu'un xml bien sûr.

Qu'est ce que tu préfères avoir à éditer, honnètement :

{{à sourcer|date=octobre 2007}}

{{Infobox Site web
| nom = Linuxfr
| favicon =
| logo = Image:Linuxfr.png
| image =
| description = actualité du [[logiciel libre]]
| url = [http://linuxfr.org/ linuxfr.org]
| commercial =
| type = actualité communautaire
| langue = [[français]]
| inscription = facultative
| propriétaire = association Linuxfr
| auteur =
| date de lancement = {{Date|28|juin|1998}}
| état actuel =
| revenue =
}}
'''Linuxfr.org''' est un site francophone communautaire traitant de l'actualité informatique liée le plus souvent au [[logiciel libre]]. Il est alimenté par sa communauté d'utilisateurs en mode contributif.

Ce site est également parfois appelé '''Da Linux French Page''' ou simplement '''DLFP'''.

== Services ==
=== Dépêches ===
Des dépêches dont les sujets tournent autour du logiciel libre et de la culture libre sont publiées irrégulièrement plusieurs fois par jour en moyenne, selon l'actualité, les contributions et la charge de modération. Il existe trois « types » de dépêches : la dépêche phare qui reste épinglée en haut de page, les dépêches de « première page » affichées en pleine page qui sont jugées importantes et les dépêches de « seconde page » qui sont partiellement affichées dans la colonne de gauche.








Logo de Linuxfr





URL
linuxfr.org


Description
actualité du logiciel libre


Type de site
actualité communautaire


Langue(s)
français


Inscription
facultative


Propriétaire
association Linuxfr


Lancement
28 juin 1998


modifier 


Linuxfr.org est un site francophone communautaire traitant de l'actualité informatique liée le plus souvent au logiciel libre. Il est alimenté par sa communauté d'utilisateurs en mode contributif.
Ce site est également parfois appelé Da Linux French Page ou simplement DLFP.







[modifier] Services
[modifier] Dépêches
Des dépêches dont les sujets tournent autour du logiciel libre et de la culture libre sont publiées irrégulièrement plusieurs fois par jour en moyenne, selon l'actualité, les contributions et la charge de modération. Il existe trois « types » de dépêches : la dépêche phare qui reste épinglée en haut de page, les dépêches de « première page » affichées en pleine page qui sont jugées importantes et les dépêches de « seconde page » qui sont partiellement affichées dans la colonne de gauche.
Les auteurs de dépêches sont des contributeurs authentifiés ou anonymes. Ces dépêches sont modérées, vérifiées, amendées ou étoffées, et éventuellement publiées par une équipe dédiée.


Ah bah zut ça passe même pas les balises xml. Encore un avantage pratique d'un format non balisé!

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=smtpd.conf&(...)

Intéropérabilité : idée saugrenue qui permet au pigeon de ne pas être pieds et poings liés à une entreprise.

Je trouve intéressant ces ordinateurs de poche qu'on vend comme des dérivés de téléphone, mais je trouve qu'ils manque plus que des d'entrées/sorties :
* Un port usb, pour y brancher un clavier[1]
* Un port vidéo, pour brancher direct sur le vidéo projecteur pour vos conf ou sur l'écran pour travailler

[1] un clavier mou peu facilement se stocker dans la poche d'une veste http://www.pcinpact.com/actu/news/FlexKeyboard_un_clavier_mo(...)

http://lowendmac.com/thompson/06/0103.html


#!software=foo
#!version=1.0.0
foo=bar
bar=foo


Déjà rien n'empêche de mettre une GUI au-dessus d'un fichier de conf qui n'a pas une arborescence de profondeur qui tend vers +∞.

Ensuite, si on donnait aux gens les moyens de faire correctement le boulot qu'on leur demande de faire, on en serait pas là. Un patron qui ne préserve pas l'employabilité de ses collaborateurs est un mauvais patron (ok j'avoue, je sors d'un cours de «loto businessmanagement et gestion de l'entreprise») qui mérite d'être lapidé en place public (ok faut encore que je revois le cours pour me bourrer le mou de main invisible).

Normal, tout comme le smtpd issu de OpenBSD le format de conf à suivi un processus de maturation nourrie au KISS.

Voila des arguments pertinents.

Le fait est qu'un format en langage clef/valeur est plus pratique pour l'édition manuel et que dans le même temps l'imbrication que permet le XML est souvent complètement inutile pour un fichier de conf (ou pire incite à complexifier un fichier dont la structure pourrait rester simple !).

Donc l'idéal serait qu'on ai un format de fichier en format clef/valeur aussi bien documenté et réfléchie que le XML, et que les développeurs l'adoptent dans les situations ou il est plus pertinent que le xml.

Mais qu'attendons-nous ? :)

Tiré de http://txt2tags.sourceforge.net/sample.t2t :

%!encoding: iso-8859-1


C'est pourtant pas du xml.

Donc c'est pas vraiment un argument valable pour l'utilisation systématique de xml pour faire un fichier de conf.

Voyons pour un usage qui reste dans le cadre de la ligne de commande :
* ~/.aspell.fr.prepl
* ~/.vimrc,
* ~/.ssh/*
* ~/.bazshrc

Même sur ta machine en prod tu as le droit de configurer les outils dont tu te sers, non ?

M'enfin si toi tu préférais qu'ils soient en xml…

Y avait une complainte semblable de Denis Bodor dans l'édito de GNU/Linux Magazine N°121 :
http://www.gnulinuxmag.com/index.php/2009/10/30/edito-gnulin(...)

Euh, oui, mais c'est bien ce que je disais.

Spa klR cke jTX ′ ? :)

Zut, moi qui n'est jamais joué à pokemon, je m'attends au pire !

Sur la page officiel du pilote du constructeur on peut lire :

Linux Software

To encourage the development of Linux media player applications using our HD video decoders, Broadcom is releasing the Linux kernel driver source code under the GNU General Public License (GPL), version 2 as well as application and library source code on a royalty-free basis under the GNU Lesser General Public License (LGPL), version 2.1, as published by the Free Software Foundation.

Current driver source supporting all kernels >= 2.6.11 (12/29/2009)

* Download Crystal HD driver source

Note: The binary firmware files included in the source archive continue to be covered under Broadcom's standard software license agreement and are not distributed either under the GPL or LGPL.


Donc en résumé le pilote est GPL v2, les bibliothèques et les logiciels utilisateurs sont LGPL 2.1, le firmware sous une licence proprio. Je n'ai pas vu de lien vers la licence en question, mais ça doit être du même acabit que celles pour les cartes wifi[2]. C'est donc :

Subject to the terms and conditions of this Agreement, Broadcom grants to Licensee the non-exclusive, non-transferable, personal, revocable right to use the Software only in connection with proprietary semiconductor products of Broadcom incorporated in the equipment purchased by Licensee, and to make one (1) copy of the Software for back-up or archival purposes only. Any other use of this Software or removal of the Software from a country in which it is licensed shall automatically terminate this license.


Aucune chance de le retrouver dans les dépôts de votre distribution préféré donc, le contrat parle d'une seule copie de sauvegarde à usage privé.

[1] http://www.broadcom.com/support/crystal_hd/
[2] http://www.broadcom.com/support/ethernet_nic/driver-sla.php?(...)

Bof, c'était vrai pour les niveaux bonus de sonic, mais là j'ai pas eu mal au crâne. À mon avis c'était plutôt du aux couleurs des niveaux en question dans sonic.

En plus là tu tournes quand tu veux.

Il manque encore un peu de difficulté, par exemple des murs pleins de piques où s'empaler, mais j'imagine que ça viendra. Un chrono aussi serait pas mal.

Pour la clef, moi ça m'a pris quelques secondes seulement pour comprendre comment bouger la clef, mais bon c'est vrai que quelques instructions à ce sujet à l'intro éviterais à certain de ce demander ce qu'il faut faire.

Ouais et donc ?

Quel est le risque ici, sérieusement ?

Qui peut vouloir cracker des conversations téléphoniques ?

Pour le pékin moyen, sa vie intéressera sans doute personne. Le voisin cracker connaîtra ses histoires de fesses secrètes, wooo ! Le pire risque que je vois dans ce cas, c'est la récupération du numéro de carte de crédit quand madame michu achète sa moumoute vibrante sur M6 boutique par téléphone. Franchement pour un cracker c'est pas très rentable quand il peu avec beaucoup moins de temps et d'efforts faire son petit site de phishing qui lui en apportera des milliers.

Pour la personnalité publique qui à une image à tenir, où quelqu'un qui à des informations confidentiels à passer, c'est déjà plus problématique. Dans ce cas le mieux c'est encore de ne faire transiter aucune information sensible par un canal aussi peu fiable que le téléphone.

Enfin je vois le cas du "distendent chinois", qui à intérêt à faire preuve d'encore plus de vigilance si il ne veut pas que lui et tout son réseau de nobles résistants se fasse trucider la gueule. Bon je donne l'exemple du "gentil" résistant, mais le criminel qui veut pas que son réseau de trafic de drogue se fasse démanteler agira avec les mêmes précautions.

Bref tout ça pour dire que le téléphone à jamais été un canal très fiable du point de vue de la confidentialité, et que les portables sont d'encore plus grosses passoires pour la vie privé. Si on garde ce fait en tête et qu'on use de ces outils en connaissance de cause, cette annonce de crackage n'a pas, à mon humble avis, de quoi effrayer grand monde.

Ils doivent etre capables de lire une page web et ne pas choisir cette imprimante la alors...

C'est vraiment vouloir se placer dans une situation de soumission des desiderata des constructeurs.

Ajouter des interfaces de compatibilite avec des anciennes API, ca se fait tous les jours, c'est pas d'une difficulte insurmontable si l'API est pas ecrite avec les pieds.

Ajouter des couches dont on peu se passer, c'est ajouter inutilement des sources de bogues. Parce qu'évidemment il y a des bogues dans l'implémentation de l'API que tu reprends, mais il y en aura aussi dans ta couche de compatibilité. Sans parler du fait que le pilote lui même en contient certainement et que tu ne pourras jamais les corriger avec un blob.

À accumuler les couches de compatibilité, au final tu te retrouves avec une usine à gaz troué de partout, et dont la maintenance n'est tout simplement plus possible tellement elle réclamerait de temps.

«yaka», ouais. Et t'estimes a combien les chances de trouver quelqu'un pour le faire sur un systeme avec 100 utilisateurs max?

Avec seulement 100 utilisateurs, t'es à peu prêt certain d'avoir un public de connaisseurs, et si l'un d'eux à le périphérique et la documentation/le code pour porter/ré-implémenter ça, t'as une forte probabilité que ce sera fait. Dans un tel cas je dirait donc que les chances sont de 80-90%, la question est surtout de savoir si l'utilisateur à le temps de le faire, les compétences il les a sûrement.

Sauf que les journaux personne t'oblige à les lire et à payer ou te passer des sages conseils qu'ils prodiguent, et ce que tu connaisses déjà ces conseils ou pas.

Je suis sûr qu'il y a pas mal d'utilisateurs avancés sous slack, gentoo, arch, etc. à qui ça doit sérieusement démanger ce genre de choses.

Et si demain j'ai envie de créer un nouveau système de gestion d'imprimantes révolutionnaire ? Avec un blob, je j'ai profond.

Et si demain je veux passer à *BSD, haiku, isaac, etc. ou que sais-je, avec des specs/sources, «yaka» porter/réécrire, avec un blob, t'es bon pour du reverse autrement plus chronophage.

Etpuis les blob en guise de pilote d'imprimante, c'est foutrement ironique quand on connais l'histoire du logiciel libre. http://www.april.org/articles/divers/intro_ll.html#ToC3

Non, non et non, les blob en guise de pilotes c'est de la merde en barre.

Brother ils te fournissent des .rpm et .deb, et si t'as le malheur d'utiliser autre chose, va falloir trafiquoter plus que ce qui est soit-disant «suffisamment détaillé [en anglais] pour qu'un utilisateur lambda puisse le faire sans trop de problème».

Sans parler du fait que si tu as pas un processeur x86(_64), tu l'as bien profond ton imprimante.

HP ça fonctionne sans ce prendre le choux, parcequ'ils jouent le jeu et filent toutes les sources, pas juste un script GPL pour CUPS qui fait wrapper à un blob proprio lpr.