Pour ma part, j'ai 45 minutes de plus d'autonomie que ce qui est annoncé dans les spécifications (merci cpufreq), mais je n'ai pas comparé avec Windows.
Je ne sais pas si ça peut répondre à tes attentes, mais pour ceux qui veulent la puissance de Vim et une interface plus "classique" (pour les habitués de Windows essentiellement), il y a Cream [1]. C'est assez agréable à utiliser, même si je penche plutôt côté Emacs.
Pour firefox, si tu installes "Adblock Filterset.G Updater", une liste d'expressions rationnelles à bloquer sera installée et mise à jour régulièrement, ce qui permet de bloquer automatiquement la plupart des pubs. Tu peux bien sûr rajouter tes propres règles.
Il y a un avantage immédiat à produire du C: ton langage devient automatiquement compilable sur n'importe quelle platforme qui possède un compilateur C.
Je ne sais pas quelle est la version de Lisaac à ce jour, mais ça n'a pas l'air d'être "fini". Ça n'aurait aucun sens, pendant qu'on fait de la recherche dessus, de perdre son temps à supporter plusieurs architectures de manière optimale. En compilant vers du C, tu hérites déjà de la compatibilité avec toutes les plateformes de GCC.
En plus, le C étant de plus haut niveau que le langage machine, c'est probablement plus facile à optimiser. Et donc si ça peut permettre de s'intéresser aux concepts plutôt qu'aux détails d'implémentation, c'est un choix justifié.
Ce dont tu parles, c'est peut-être à la portée du préprocesseur du C, vu que ça n'a pas l'air de nécessiter de choses trop compliquées. Peut-être qu'on peut faire un jeu de macros qui fait un gros malloc quelque part, et qui quand on appelle ALLOUE(liste de variables), s'arrange pour qu'elles soient contiguës. D'ailleurs, je me demande si ce n'est pas ce que fait la Glib avec ses fonctions g_slice_* qui sont censées accélérer l'allocation de bouts de mémoire de taille fixe.
Ça ne change rien à l'argument principal, bien sûr, le préprocesseur étant de toutes façons un compilateur pour un langage qui produit du C :)
Tous les créationnistes ne prônent pas l'interprétation littérale de la Bible comme le font certains aux USA en ce moment. Le point commun entre tous les types de créationnismes, c'est la croyance que le monde a été créé par Dieu.
L'intelligent design, lui, essaye généralement d'éviter le mot "Dieu", mais les concepts fondamentaux sont les mêmes: un certain élément est trop "beau" ou trop "parfait" pour être apparu par hasard, et on y voit la main d'une intelligence qui, au final, est un créateur.
L'intelligent design ne dit pas toujours que la science a raison. En particulier, ils ont tendance à prétendre que la sélection naturelle ne peut pas expliquer (entièrement) la vie comme nous la connaissons. Le grand jeu de certains partisans de l'ID est de choisir un caractère particulier (disons, la rétine), de mettre au défi les scientifiques de détailler le chemin évolutionnaire qui a produit ce caractère, et dès qu'ils trouvent un caractère pour lequel on n'a pas (encore) la réponse, ils s'empressent de dire que c'est une preuve que le hasard n'a pas pu le produire, et qu'un "designer" a été nécessaire.
On trouve des créationnistes qui disent que la terre a 6000 ans, on en trouve aussi qui acceptent l'idée que Dieu a créé l'univers et que c'est le hasard qui a laissé évoluer la vie. On trouve des partisans de l'ID qui disent que la Terre a bien l'âge que donnent les scientifiques, mais je ne suis pas sûr qu'on en trouve qui défendent la théorie de l'évolution. C'est un peu le contraire du principe de l'intelligent design. Au final j'ai l'impression que le créationnisme englobe l'ID, mais est plus large.
Je peux me tromper, mais il me semble que les flash mobs et les smart mobs n'ont rien à voir. Les flash mobs ("foule éclair"), c'est des rassemblements rapides, mais le concept de "smart mobs" ("foules intelligentes"), c'est tout ce qui sous entend que les nouvelles technologies et la globalisation permettent aux foules de créer du contenu. L'idée c'est qu'en foule on est con (généralement), mais que les nouvelles technologies nous permettent d'être intelligents en foule.
La confusion vient peut-être du fait que généralement, les flash mobs utilisent les NTIC pour s'organiser.
Ouais, enfin t'as pas les moyens de verifier que le binaire du pilote libre distribue par red mandribuntusian n'a pas ete corrumpu non plus.
Non, mais tu as la possibilité d'installer le driver à partir des sources. Et donc si tu suspectes un problème, ou bien si tu veux corriger un bug, ou bien si tu as besoin que ta plateforme soit supportée, tu installes les sources et tu regardes dedans.
Il serait idiot de prétendre que parce qu'un logiciel est libre, il ne contient ni bugs ni arnaques. Mais la disponibilité des sources te donne une option supplémentaire par rapport à la même situation avec un logiciel propriétaire.
Donc partant de la, la confiance que tu as dans tout binaire est celle que tu as dans l'organisation qui te fournit le binaire, que le binaire vienne d'un code libre ne change pas grand chose, voire meme strictement rien si on est rigoureux.
Si, ça change deux choses:
- L'organisation qui te fournit le binaire d'un driver libre n'est pas la même que celle qui te fournit le driver d'un logiciel propriétaire. Quand ta distrib te fournit un driver propriétaire nvidia, tu fais confiance à nvidia. Quand elle te fournit un driver libre, tu lui fais confiance à elle.
- Le fait que les sources puissent être regardées n'est pas une garantie qu'elles seront regardées, mais c'est une indication du risque de se faire chopper si tu y caches quelque chose de malfaisant. Si tu es une boîte qui veut cacher un petit bout de spyware dans ton logiciel, le risque de te faire prendre est beaucoup plus grand si tu diffuses sous forme de code et pas sous forme de binaire. Nécessairement, ça diminue le nombre d'arnaques volontaires.
(Bien sûr si tu diffuses sous forme de code ET de binaire, rien ne garantit que le binaire correspond au code diffusé...)
Je ne fais pas de catastrophisme, je dis que si tu renonces à tout contrôle sur ce qu'exécute ta machine, tu risques de le regretter la première fois qu'une boîte essayera de t'entuber. Si ça n'arrive jamais, tant mieux.
Et si en effet il y aura des DRM hard, rien ne m'empechera d'aller voir un autre constructeur, tant que c'est interoperable, je ne serais jamais pieds et poings liés avec un constructeur ou editeur.
Si ça t'amuse de racheter ton matériel tous les trois mois, moi ça ne m'amuse pas. Par conséquent, je préfère savoir que mon matériel est utilisable avec des drivers que je peux regarder/modifier.
(Concernant le troisième point, je n'ai rien compris à ce que tu écris, je crois qu'il manque des mots.)
Est-ce que par hasard, tu auras une version d'Ubtuntu qui n'est pas Breezy, ou bien une Breezy avec toutes les mises à jour de sécurité ? Parce que bon, c'est corrigé, et si tu es à jour c'est normal de ne pas avoir le problème.
1- C'est le problème du constructeur s'il a chosit de na pas supporter tel plateforme.
Ça devient ton problème à toi quand tu as envie d'utiliser une plateforme qui n'est pas supportée, ou quand ta plateforme qui était supportée avant ne l'est plus dans les nouvelles versions.
Bien sûr, tu peux répondre que dans ce cas, tu t'arrangeras pour avoir une plateforme supportée, donc une plateforme Intel. Mais dans ce cas, ce qui était "le problème du constructeur" est devenu ton problème à toi, puisque tu ne peux plus choisir la plateforme que tu veux.
2- Comme avec le libre, qui supporte encore el kernel 1.0 ?
Tu confonds matériel et logiciel. Si j'ai acheté une carte vidéo 200 euros, j'aime bien me dire qu'elle va fonctionner aussi longtemps que je voudrai m'en servir. Avec des drivers propriétaires, le jour où le constructeur décide que ce n'est plus assez rentable, ma carte vidéo n'est plus supportée. J'ai donc le choix entre rester avec une vieille version de mon système (pour laquelle le driver existe) ou racheter une nouvelle carte vidéo.
Par contre, mettre à jour le kernel, c'est gratuit. Je vais peut-être passer quelques heures à galérer si je casse un truc, mais si je veux passer à un kernel plus récent, je n'aurai en principe pas besoin de racheter de matériel. Parce que la compatibilité ascendante est bonne, les nouveaux kernels supportent le matériel qui était supporté par les précédents [si le driver est libre].
3- Pour moi, ce n'est pas trivial
Tsk tsk, c'est trivial pour tout le monde: si t'as pas le droit de regarder le code, tu n'as aucun moyen de vérifier ce qu'il fait.
Peut-être voulais-tu dire que ce n'était pas vital de savoir ce que fait le driver. Tu as tout à fait le droit de vouer une confiance illimitée au constructeur de ta carte vidéo, après tout. Tu le regretteras peut-être le jour où les cartes seront remplies de DRM, mais peut-être pas.
Oui, ma phrase était mal construite, je voulais dire "la plupart des API", et après j'ai voulu rajouter SAX, mais j'ai oublié d'enlever "la plupart" :)
Là, si tu veux que ce soit utile, les évènements doivent être plus précis, donc intégrer de la sémantique.
Par exemple "je commande un nouveau paragraphe", "je commence un tableau" (jusque là c'est facile), ou "je commence une nouvelle formule de maths" (ça se complique).
D'autre part, pour gérer ce modèle standard et énorme le plus efficacement, la structure interne devra y coller
Pas nécessairement, mais par contre on aura besoin d'un format/protocole intermédiaire. Par exemple dans le cas de la formule de maths, on ne peut pas avoir un évènement pour chaque type d'opération (puissance, fraction, ...). Mais si le parser, quand il rencontre une formule de maths, peut te donner la formule soit en MathML soit en LaTeX, alors tu es libre d'en faire ce que tu veux.
Et si tu développes un éditeur de texte qui ne sait pas éditer les formules de maths, tu peux utiliser une bibliothèque externe pour faire un rendu de la formule en image, par exemple.
Au final ce genre de filtre ressemblerait à une convertion du format d'origine vers un format intermédiaire générique, puis vers la structure de données propre au programme. Le programme étant libre, évidemment, d'ignorer une partie des informations. Si je veux faire un office-grep, je n'ai pas besoin d'incorporer dans ma structure de données les détails de mise en page, j'ai juste besoin d'y mettre le contenu en texte.
Tant qu'on n'a pas créé une intelligence artificielle qui soit plus "intelligente" qu'un humain, "théoriquement", le programmeur peut toujours faire mieux que n'importe quel compilateur.
Il vaut mieux s'intéresser à ce que peut faire le programmeur "en un temps raisonnable", et pour définir le critère "raisonnable" je propose "qui ne nécessite pas plus de X% du temps consacré au développement".
avoir une grammaire ultra-simple sans les constructions minimum n'est pas vraiment aidant question optimisation
Dans le cas particulier où la grammaire du langage L ne permet pas d'exprimer des concepts de plus haut niveau que le langage C, on est d'accord. Mais en règle générale, on n'est pas d'accord: je prétend qu'on peut faire un langage de haut niveau qui compile vers du C et qui tourne plus vite que code C saisi par un humain.
Donc on est bien d'accord :)
Moi je disais juste que c'est dommage de chercher à faire un langage de haut niveau puissant question optimisation si c'est pour produire du C au final : on va comme tu dis perdre un grand nombre de possibilités d'optimisation sur le code final, vu qu'on sera limité au sens du langage C.
Je disais le contraire... Si tu avais raison, ça ne servirait à rien (au niveau des optimisations) de coder dans un langage de haut niveau puisque de toutes façons au final on se retrouve avec du code machine qui manipule des bits.
Je ne peux pas tellement trouver d'exemples plus explicites que ceux de mon précédent message (d'autant plus que ce n'est pas mon domaine). L'idée générale, si on a la chaîne de compilation suivante:
[code en L] --(étape 1)--> [code en C] --(étape 2)--> [code en M] -> (étape 3: exécution)
Admettons qu'on a à faire un programme P, et qu'on le donne à un développeur, qui produit un programme PL en langage L, et à un autre développeur qui produit un programme PC en langage C. Appelons PLC le programme PL compilé vers du C.
Si le langage L permet de manipuler des concepts de plus haut niveau que le langage C, alors le compilateur L peut essayer durant l'étape 1 de faire des optimisations sur PL qui font que PLC compilé en M produira du code plus rapide que PC compilé en M.
Je reprend l'exemple de l'héritage. Soit L un langage objet, et soit c un objet de classe C qui hérite de B qui hérite de A. Quand j'appelle c.toto(), on doit chercher si C implémente toto(), sinon B, sinon A. Une fois qu'on a trouvé toto(), on peut décider soit de faire un appel de fonction, soit d'inliner la fonction si c'est plus efficace.
Si on peut toujours résoudre le problème de trouver la fonction à appeler à l'étape 1, alors on peut produire du code C avec des appels de fonction directs ou bien du code inliné.
Si on essaye de coder la même chose directement en C, étant donné que le C n'a pas de concept d'héritage et que son préprocesseur n'est pas assez puissant, on est obliger de chercher la fonction toto() à l'étape 3 (runtime), ce qui signifie qu'on se traine des pointeurs de fonctions, et qu'on ne peut pas inliner. Autrement dit, si tu veux gérer l'héritage, le problème "trouver toto" doit être résolu à une étape, et le C ne permet pas de le résoudre à l'étape 2. Si tu le résouds à l'étape 3, tu perds en performance. Il ne reste que l'étape 1 pour optimiser.
(Disclaimer: un programmeur peut théoriquement faire le boulot du compilateur L à l'étape 1 et produire lui-même à la main le code C correspondant. De la même manière qu'un programmeur peut théoriquement recoder n'importe quoi entièrement en assembleur. C'est simplement trop compliqué et trop long à faire dans la vraie vie.)
Pas forcément. Par exemple, pour parser le XML, la plupart des API inspirées de SAX définissent des évènements du type "je rencontre une ouverture de tag", "je rencontre une fermeture de tag", etc. et c'est au programmeur de relier ces évènements à sa structure de données. On peut imaginer quelque chose de similaire pour une API qui ouvre des documents "Office".
Evolution avait les recherches nommées (VFolders, dans le jargon d'origine) avant Gmail, pour KMail je ne sais pas. Thunderbird a aussi récupéré cette feature il y a quelques mois.
Je ne sais pas comment fonctionnent les tags de GMail, mais les recherches nommées c'est très très bien.
Enfin thoériquement un langage qui produit du C en sorti aura dû mal à être plus rapide, si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire.
Un langage de plus haut niveau que le C a un avantage énorme pour l'optimisation: le compilateur connaît plus de choses sur le "sens" des instructions que le compilateur de C. Par exemple, un compilateur de C a peu d'informations sur une boucle for quand le critère d'arrêt n'est pas une constante, et donc il lui est difficile de savoir comment dérouler la boucle de manière optimale. Un compilateur pour un langage de plus haut niveau pourrait avoir des informations supplémentaires sur la boucle, par exemple le fait qu'elle contient toujours un nombre pair d'itérations, etc. Dans ce cas, l'optimisation est souvent plus simple.
L'exemple que j'ai pris est un peu simpliste: on peut se dire que ce genre de cas peut aussi être géré en C par le développeur. Dans des cas plus compliqués, déléguer la tâche au compilateur est très appréciable. Comme les développeurs ont toujours une contrainte de temps, moins ils passent de temps à produire du code illisible mais optimisé et mieux c'est.
Pour prendre un autre exemple, les templates du C++ sont à la fois un outil qui aide à coder plus vite et un outil qui aide à optimiser. Si ça ne servait qu'à coder plus vite (au détriment de la vitesse d'exécution), l'intérêt serait beaucoup plus limité. Pourquoi est-ce que ça optimise aussi la vitesse d'exécution ? Parce que le traitement par le moteur de templates est effectué à la compilation, pas à l'exécution.
Quand le langage ne permet pas d'exprimer l'information nécessaire, le compilateur ne peut pas effectuer le travail pendant l'étape de compilation, et donc tu as le choix entre faire le travail toi même ou bien utiliser le langage pour faire le travail pendant l'exécution. Faire le travail soi même, c'est souvent long et compliqué, et faire le travail à l'exécution, ça implique souvent une perte de performance. Donc plus un langage donne d'informations au compilateur et plus il est à même de produire du code rapide si le compilateur est malin.
Dernier exemple, l'héritage: en C, tu ne peux pas exprimer l'héritage dans le langage, mais tu peux le simuler avec des pointeurs de fonctions et des casts bien placés. Par contre, le compilateur n'a aucune notion d'héritage, et donc l'héritage est forcément géré en partie pendant l'exécution. Ça veut dire que tu vas avoir des pointeurs de fonction dans tes objets, et que pour appeler une méthode d'objet, tu vas devoir accéder au pointeur de la fonction correspondante. Ça veut dire entre autres que tu ne peux pas inliner le code de ces méthodes. Ça implique une perte de performances.
Si le compilateur du langage L connaît l'héritage, alors il peut produire du code C qui évite dans la plupart des cas l'usage de pointeurs de fonctions pour simuler l'héritage, donc du code C qui sera plus facile à optimiser pour le compilateur C, et qui au final sera plus rapide. Faire la même chose pour le programmeur est théoriquement possible, mais en pratique irréalisable car trop long et trop compliqué.
Je ne connaissais pas Sather, je viens de regarder rapidement la documentation sur les itérateurs, et je trouve que ça ressemble beaucoup à ceux de ruby, donc d'emblée ça a l'air très bien. Tu aurais des détails sur pourquoi ils sont "bien plus puissants" que ceux de ruby ?
J'ai utilisé Gnome sur cette machine pendant deux ans, sans que ça raaaammme:
- Proc: Athlon-MP qui tourne à 663 MHz
- RAM: 256 Mo -32 pour la vidéo
- Swap: 128 Mo
- /usr et /var: un peu moins de 3 Go
Ensuite, j'ai monté la RAM à 512 Mo (-32 pour la vidéo toujours). Depuis, mon swap ne se remplit que quand j'ouvre de très grosses images dans Gimp.
je sais que ces propos violent pas mal de dogmes
T'en fais pas va, même si t'es mal noté pour l'instant, plus tard l'histoire reconnaîtra ton audace, et tu seras autant cité qu'Einstein, Wilde et Clémenceau réunis.
J'ai besoin de rien sur le bureau car j'utilise quasiment toute les applis en maximised, donc seul la taskbar me sert a "interagir" avec le systeme.
Connais-tu le gestionnaire de fenêtres ion ? Sinon, ça pourrait t'intéresser.
Au lieu de fenêtres, on a des cadres. Dans un cadre, on peut avoir plusieurs applications, qui sont toutes "maximisées", et accessibles par des onglets. Quand tu as un seul cadre, ça revient à avoir toutes les applis maximisées et une barre des tâches pour switcher. Mais ça devient assez intéressant quand on a plus d'un cadre à l'écran, et c'est complètement contrôlable au clavier. Évidemment, c'est aussi très économique en ressources.
Système de mises à jour bizarre (pkoi est-ce à l'appli de gérer ses mises à jours ? )
Le firefox de debian se met à jour comme le reste du système, via un package. Je ne sais pas comment ça fonctionne chez les autres distribs.
Par contre, je connais des Windowsiens qui sont capables de t'affirmer longuement à quel point c'est mieux que chaque application gère elle même son installation, ses mises à jour et sa désinstallation... La plus grosse part des utilisateurs de FF étant sous Windows, autant leur faire plaisir.
[^] # Re: Ca va faire plaisir a pas mal de personne:
Posté par Yusei (Mastodon) . En réponse au journal Noyau Linux 2.6.16. Évalué à 2.
[^] # Re: Puisqu'on cause de Gnome...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 3.
[1] http://cream.sourceforge.net/
[^] # Re: Utilisez un bureau GNOME complet...
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 3.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 5.
Je ne sais pas quelle est la version de Lisaac à ce jour, mais ça n'a pas l'air d'être "fini". Ça n'aurait aucun sens, pendant qu'on fait de la recherche dessus, de perdre son temps à supporter plusieurs architectures de manière optimale. En compilant vers du C, tu hérites déjà de la compatibilité avec toutes les plateformes de GCC.
En plus, le C étant de plus haut niveau que le langage machine, c'est probablement plus facile à optimiser. Et donc si ça peut permettre de s'intéresser aux concepts plutôt qu'aux détails d'implémentation, c'est un choix justifié.
[^] # Re: Anti-protection !
Posté par Yusei (Mastodon) . En réponse au journal Les Chrétiens anti-anti-spam ?. Évalué à 8.
En tout cas, c'est un bon début. Si tous les gens qui ont une foi commençaient par respecteur leurs semblables, le journal de 20h serait plus court.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Ça ne change rien à l'argument principal, bien sûr, le préprocesseur étant de toutes façons un compilateur pour un langage qui produit du C :)
[^] # Re: Anti-protection !
Posté par Yusei (Mastodon) . En réponse au journal Les Chrétiens anti-anti-spam ?. Évalué à 5.
L'intelligent design, lui, essaye généralement d'éviter le mot "Dieu", mais les concepts fondamentaux sont les mêmes: un certain élément est trop "beau" ou trop "parfait" pour être apparu par hasard, et on y voit la main d'une intelligence qui, au final, est un créateur.
L'intelligent design ne dit pas toujours que la science a raison. En particulier, ils ont tendance à prétendre que la sélection naturelle ne peut pas expliquer (entièrement) la vie comme nous la connaissons. Le grand jeu de certains partisans de l'ID est de choisir un caractère particulier (disons, la rétine), de mettre au défi les scientifiques de détailler le chemin évolutionnaire qui a produit ce caractère, et dès qu'ils trouvent un caractère pour lequel on n'a pas (encore) la réponse, ils s'empressent de dire que c'est une preuve que le hasard n'a pas pu le produire, et qu'un "designer" a été nécessaire.
On trouve des créationnistes qui disent que la terre a 6000 ans, on en trouve aussi qui acceptent l'idée que Dieu a créé l'univers et que c'est le hasard qui a laissé évoluer la vie. On trouve des partisans de l'ID qui disent que la Terre a bien l'âge que donnent les scientifiques, mais je ne suis pas sûr qu'on en trouve qui défendent la théorie de l'évolution. C'est un peu le contraire du principe de l'intelligent design. Au final j'ai l'impression que le créationnisme englobe l'ID, mais est plus large.
[^] # Re: Anti-protection !
Posté par Yusei (Mastodon) . En réponse au journal Les Chrétiens anti-anti-spam ?. Évalué à 8.
[^] # Re: Anti-protection !
Posté par Yusei (Mastodon) . En réponse au journal Les Chrétiens anti-anti-spam ?. Évalué à 10.
Quelle position extrêmiste...
# Définitions
Posté par Yusei (Mastodon) . En réponse au journal [mobilisation] Smart-mob "rendu de CD" mercredi 22 mars aux halles Paris. Évalué à 7.
La confusion vient peut-être du fait que généralement, les flash mobs utilisent les NTIC pour s'organiser.
[^] # Re: correction :
Posté par Yusei (Mastodon) . En réponse au journal METTEZ A JOUR VOS ZUBUNTUS !. Évalué à 2.
[^] # Re: j'ai pas bien compris
Posté par Yusei (Mastodon) . En réponse au journal Changement de licence des drivers opensource VIA. Évalué à 10.
Non, mais tu as la possibilité d'installer le driver à partir des sources. Et donc si tu suspectes un problème, ou bien si tu veux corriger un bug, ou bien si tu as besoin que ta plateforme soit supportée, tu installes les sources et tu regardes dedans.
Il serait idiot de prétendre que parce qu'un logiciel est libre, il ne contient ni bugs ni arnaques. Mais la disponibilité des sources te donne une option supplémentaire par rapport à la même situation avec un logiciel propriétaire.
Si, ça change deux choses:
- L'organisation qui te fournit le binaire d'un driver libre n'est pas la même que celle qui te fournit le driver d'un logiciel propriétaire. Quand ta distrib te fournit un driver propriétaire nvidia, tu fais confiance à nvidia. Quand elle te fournit un driver libre, tu lui fais confiance à elle.
- Le fait que les sources puissent être regardées n'est pas une garantie qu'elles seront regardées, mais c'est une indication du risque de se faire chopper si tu y caches quelque chose de malfaisant. Si tu es une boîte qui veut cacher un petit bout de spyware dans ton logiciel, le risque de te faire prendre est beaucoup plus grand si tu diffuses sous forme de code et pas sous forme de binaire. Nécessairement, ça diminue le nombre d'arnaques volontaires.
(Bien sûr si tu diffuses sous forme de code ET de binaire, rien ne garantit que le binaire correspond au code diffusé...)
[^] # Re: j'ai pas bien compris
Posté par Yusei (Mastodon) . En réponse au journal Changement de licence des drivers opensource VIA. Évalué à 2.
Si ça t'amuse de racheter ton matériel tous les trois mois, moi ça ne m'amuse pas. Par conséquent, je préfère savoir que mon matériel est utilisable avec des drivers que je peux regarder/modifier.
(Concernant le troisième point, je n'ai rien compris à ce que tu écris, je crois qu'il manque des mots.)
[^] # Re: correction :
Posté par Yusei (Mastodon) . En réponse au journal METTEZ A JOUR VOS ZUBUNTUS !. Évalué à 2.
[^] # Re: j'ai pas bien compris
Posté par Yusei (Mastodon) . En réponse au journal Changement de licence des drivers opensource VIA. Évalué à 10.
Ça devient ton problème à toi quand tu as envie d'utiliser une plateforme qui n'est pas supportée, ou quand ta plateforme qui était supportée avant ne l'est plus dans les nouvelles versions.
Bien sûr, tu peux répondre que dans ce cas, tu t'arrangeras pour avoir une plateforme supportée, donc une plateforme Intel. Mais dans ce cas, ce qui était "le problème du constructeur" est devenu ton problème à toi, puisque tu ne peux plus choisir la plateforme que tu veux.
Tu confonds matériel et logiciel. Si j'ai acheté une carte vidéo 200 euros, j'aime bien me dire qu'elle va fonctionner aussi longtemps que je voudrai m'en servir. Avec des drivers propriétaires, le jour où le constructeur décide que ce n'est plus assez rentable, ma carte vidéo n'est plus supportée. J'ai donc le choix entre rester avec une vieille version de mon système (pour laquelle le driver existe) ou racheter une nouvelle carte vidéo.
Par contre, mettre à jour le kernel, c'est gratuit. Je vais peut-être passer quelques heures à galérer si je casse un truc, mais si je veux passer à un kernel plus récent, je n'aurai en principe pas besoin de racheter de matériel. Parce que la compatibilité ascendante est bonne, les nouveaux kernels supportent le matériel qui était supporté par les précédents [si le driver est libre].
Tsk tsk, c'est trivial pour tout le monde: si t'as pas le droit de regarder le code, tu n'as aucun moyen de vérifier ce qu'il fait.
Peut-être voulais-tu dire que ce n'était pas vital de savoir ce que fait le driver. Tu as tout à fait le droit de vouer une confiance illimitée au constructeur de ta carte vidéo, après tout. Tu le regretteras peut-être le jour où les cartes seront remplies de DRM, mais peut-être pas.
[^] # Re: une petite réponse
Posté par Yusei (Mastodon) . En réponse au journal OpenOffice et MS Office, 10 ans de retard, mes explications. Évalué à 2.
Par exemple "je commande un nouveau paragraphe", "je commence un tableau" (jusque là c'est facile), ou "je commence une nouvelle formule de maths" (ça se complique).
Pas nécessairement, mais par contre on aura besoin d'un format/protocole intermédiaire. Par exemple dans le cas de la formule de maths, on ne peut pas avoir un évènement pour chaque type d'opération (puissance, fraction, ...). Mais si le parser, quand il rencontre une formule de maths, peut te donner la formule soit en MathML soit en LaTeX, alors tu es libre d'en faire ce que tu veux.
Et si tu développes un éditeur de texte qui ne sait pas éditer les formules de maths, tu peux utiliser une bibliothèque externe pour faire un rendu de la formule en image, par exemple.
Au final ce genre de filtre ressemblerait à une convertion du format d'origine vers un format intermédiaire générique, puis vers la structure de données propre au programme. Le programme étant libre, évidemment, d'ignorer une partie des informations. Si je veux faire un office-grep, je n'ai pas besoin d'incorporer dans ma structure de données les détails de mise en page, j'ai juste besoin d'y mettre le contenu en texte.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Tant qu'on n'a pas créé une intelligence artificielle qui soit plus "intelligente" qu'un humain, "théoriquement", le programmeur peut toujours faire mieux que n'importe quel compilateur.
Il vaut mieux s'intéresser à ce que peut faire le programmeur "en un temps raisonnable", et pour définir le critère "raisonnable" je propose "qui ne nécessite pas plus de X% du temps consacré au développement".
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 6.
Dans le cas particulier où la grammaire du langage L ne permet pas d'exprimer des concepts de plus haut niveau que le langage C, on est d'accord. Mais en règle générale, on n'est pas d'accord: je prétend qu'on peut faire un langage de haut niveau qui compile vers du C et qui tourne plus vite que code C saisi par un humain.
Je disais le contraire... Si tu avais raison, ça ne servirait à rien (au niveau des optimisations) de coder dans un langage de haut niveau puisque de toutes façons au final on se retrouve avec du code machine qui manipule des bits.
Je ne peux pas tellement trouver d'exemples plus explicites que ceux de mon précédent message (d'autant plus que ce n'est pas mon domaine). L'idée générale, si on a la chaîne de compilation suivante:
[code en L] --(étape 1)--> [code en C] --(étape 2)--> [code en M] -> (étape 3: exécution)
Admettons qu'on a à faire un programme P, et qu'on le donne à un développeur, qui produit un programme PL en langage L, et à un autre développeur qui produit un programme PC en langage C. Appelons PLC le programme PL compilé vers du C.
Si le langage L permet de manipuler des concepts de plus haut niveau que le langage C, alors le compilateur L peut essayer durant l'étape 1 de faire des optimisations sur PL qui font que PLC compilé en M produira du code plus rapide que PC compilé en M.
Je reprend l'exemple de l'héritage. Soit L un langage objet, et soit c un objet de classe C qui hérite de B qui hérite de A. Quand j'appelle c.toto(), on doit chercher si C implémente toto(), sinon B, sinon A. Une fois qu'on a trouvé toto(), on peut décider soit de faire un appel de fonction, soit d'inliner la fonction si c'est plus efficace.
Si on peut toujours résoudre le problème de trouver la fonction à appeler à l'étape 1, alors on peut produire du code C avec des appels de fonction directs ou bien du code inliné.
Si on essaye de coder la même chose directement en C, étant donné que le C n'a pas de concept d'héritage et que son préprocesseur n'est pas assez puissant, on est obliger de chercher la fonction toto() à l'étape 3 (runtime), ce qui signifie qu'on se traine des pointeurs de fonctions, et qu'on ne peut pas inliner. Autrement dit, si tu veux gérer l'héritage, le problème "trouver toto" doit être résolu à une étape, et le C ne permet pas de le résoudre à l'étape 2. Si tu le résouds à l'étape 3, tu perds en performance. Il ne reste que l'étape 1 pour optimiser.
(Disclaimer: un programmeur peut théoriquement faire le boulot du compilateur L à l'étape 1 et produire lui-même à la main le code C correspondant. De la même manière qu'un programmeur peut théoriquement recoder n'importe quoi entièrement en assembleur. C'est simplement trop compliqué et trop long à faire dans la vraie vie.)
[^] # Re: une petite réponse
Posté par Yusei (Mastodon) . En réponse au journal OpenOffice et MS Office, 10 ans de retard, mes explications. Évalué à 3.
[^] # Re: Et pas en WebMail
Posté par Yusei (Mastodon) . En réponse au journal Le concept de GMail. Évalué à 3.
Je ne sais pas comment fonctionnent les tags de GMail, mais les recherches nommées c'est très très bien.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Un langage de plus haut niveau que le C a un avantage énorme pour l'optimisation: le compilateur connaît plus de choses sur le "sens" des instructions que le compilateur de C. Par exemple, un compilateur de C a peu d'informations sur une boucle for quand le critère d'arrêt n'est pas une constante, et donc il lui est difficile de savoir comment dérouler la boucle de manière optimale. Un compilateur pour un langage de plus haut niveau pourrait avoir des informations supplémentaires sur la boucle, par exemple le fait qu'elle contient toujours un nombre pair d'itérations, etc. Dans ce cas, l'optimisation est souvent plus simple.
L'exemple que j'ai pris est un peu simpliste: on peut se dire que ce genre de cas peut aussi être géré en C par le développeur. Dans des cas plus compliqués, déléguer la tâche au compilateur est très appréciable. Comme les développeurs ont toujours une contrainte de temps, moins ils passent de temps à produire du code illisible mais optimisé et mieux c'est.
Pour prendre un autre exemple, les templates du C++ sont à la fois un outil qui aide à coder plus vite et un outil qui aide à optimiser. Si ça ne servait qu'à coder plus vite (au détriment de la vitesse d'exécution), l'intérêt serait beaucoup plus limité. Pourquoi est-ce que ça optimise aussi la vitesse d'exécution ? Parce que le traitement par le moteur de templates est effectué à la compilation, pas à l'exécution.
Quand le langage ne permet pas d'exprimer l'information nécessaire, le compilateur ne peut pas effectuer le travail pendant l'étape de compilation, et donc tu as le choix entre faire le travail toi même ou bien utiliser le langage pour faire le travail pendant l'exécution. Faire le travail soi même, c'est souvent long et compliqué, et faire le travail à l'exécution, ça implique souvent une perte de performance. Donc plus un langage donne d'informations au compilateur et plus il est à même de produire du code rapide si le compilateur est malin.
Dernier exemple, l'héritage: en C, tu ne peux pas exprimer l'héritage dans le langage, mais tu peux le simuler avec des pointeurs de fonctions et des casts bien placés. Par contre, le compilateur n'a aucune notion d'héritage, et donc l'héritage est forcément géré en partie pendant l'exécution. Ça veut dire que tu vas avoir des pointeurs de fonction dans tes objets, et que pour appeler une méthode d'objet, tu vas devoir accéder au pointeur de la fonction correspondante. Ça veut dire entre autres que tu ne peux pas inliner le code de ces méthodes. Ça implique une perte de performances.
Si le compilateur du langage L connaît l'héritage, alors il peut produire du code C qui évite dans la plupart des cas l'usage de pointeurs de fonctions pour simuler l'héritage, donc du code C qui sera plus facile à optimiser pour le compilateur C, et qui au final sera plus rapide. Faire la même chose pour le programmeur est théoriquement possible, mais en pratique irréalisable car trop long et trop compliqué.
[^] # Itérateurs et ruby
Posté par Yusei (Mastodon) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
[^] # Re: KDE
Posté par Yusei (Mastodon) . En réponse au journal Quel dommage que Opera ne soit pas libre. Évalué à 6.
- Proc: Athlon-MP qui tourne à 663 MHz
- RAM: 256 Mo -32 pour la vidéo
- Swap: 128 Mo
- /usr et /var: un peu moins de 3 Go
Ensuite, j'ai monté la RAM à 512 Mo (-32 pour la vidéo toujours). Depuis, mon swap ne se remplit que quand j'ouvre de très grosses images dans Gimp.
T'en fais pas va, même si t'es mal noté pour l'instant, plus tard l'histoire reconnaîtra ton audace, et tu seras autant cité qu'Einstein, Wilde et Clémenceau réunis.
[^] # Re: Gnih?
Posté par Yusei (Mastodon) . En réponse au journal Quel dommage que Opera ne soit pas libre. Évalué à 3.
Connais-tu le gestionnaire de fenêtres ion ? Sinon, ça pourrait t'intéresser.
Au lieu de fenêtres, on a des cadres. Dans un cadre, on peut avoir plusieurs applications, qui sont toutes "maximisées", et accessibles par des onglets. Quand tu as un seul cadre, ça revient à avoir toutes les applis maximisées et une barre des tâches pour switcher. Mais ça devient assez intéressant quand on a plus d'un cadre à l'écran, et c'est complètement contrôlable au clavier. Évidemment, c'est aussi très économique en ressources.
[^] # Re: Gnih?
Posté par Yusei (Mastodon) . En réponse au journal Quel dommage que Opera ne soit pas libre. Évalué à 7.
Le firefox de debian se met à jour comme le reste du système, via un package. Je ne sais pas comment ça fonctionne chez les autres distribs.
Par contre, je connais des Windowsiens qui sont capables de t'affirmer longuement à quel point c'est mieux que chaque application gère elle même son installation, ses mises à jour et sa désinstallation... La plus grosse part des utilisateurs de FF étant sous Windows, autant leur faire plaisir.