un eeepc (1015pem, 1Go de ram, proc dual core 64bit cadencé a 1.55GHz)
une tour "récente" d'a peu près 2 ans (4Go de ram, proc dual core 64bit 3GHz de mémoire) mais bas de gamme: tout le monde n'a pas envie de claquer 500€ dans une machine pour supporter le tout nouveau gadget que les développeurs d'un outil ont trouvé joli et donc pertinent (oh, la transparence, c'est si zoli… inutile donc vital!)
une tour "designed for windows Me", et fournie avec windows 2000NT (vite remplacé par une debian stable). Âge estimé: 12 ans, mais c'est une récup récente (ça me servira de jukebox quand j'aurai le temps de passer un câble réseau dans le mur).
Ca réponds à ta question?
Sinon, pour les machines portables, il parait que les batteries préfèrent qu'on ne charge pas trop la ram ou le proc, pour une meilleure autonomie.
Accessoirement, quand je code, j'aime bien que les interfaces graphiques bouffent pas la moitié des ressources de ma machine. La compilation C++ est assez longue comme ça, pas besoin d'en rajouter, pas vrai?
Honnêtement, j'ai vraiment juste voulu nourrir le troll :)
Je comprend l'intérêt des gros framework, utiles pour les applications de type mastodonte (les plus courantes, celles qui intègrent le gestionnaire de fenêtre directement pour mieux faire doublon avec l'OS) mais je trouve regrettable que pas mal de petites applications suivent le même chemin.
Et surtout, je trouve très très regrettable qu'il y ait très peu de toolkit graphiques qui ne soient pas des framework… je ne suis même pas sûr d'en connaître un seul en fait.
Pour fermé, je suis pas tout à fait d'accord. Il risque d'y avoir confusion avec sources fermées. Et dans ce cas, on peut citer ce qui fut le cas de paint.net pendant un moment, ouvert mais pas open, ni libre.
Ouvert mais pas open? C'est à dire? Il montrait son source et tu n'avais pas le droit de l'utiliser? Ca colle assez bien avec les mots "open source" pris à la lettre, je trouve…
Sinon, je ne connais pas cette référence, y'a moyen que tu explicites un peu plus?
À moins de s'en tenir strictement au sens utilisé en droit
En même temps, quand on parle de licences, on parle de droit, de contrat, pas de couture, aux dernières nouvelles…
Tu as acheté le logiciel, mais tu as un conflit avec un logiciel / matériel qui n'était pas affiché sur la boite, voire même le service client qui connait le problème te donne des solutions qui ne marche pas parce que le soucis vient de chez eux.
Question intéressante. Il faudrait demander à une assos de consommateurs je pense.
Je ne parlerai pas non plus des logiciels utilisés au travail où je n'ai pas vraiment le choix si je veux gagner ma croute.
Et tu as raison de ne pas en parler, car tu as accepté un contrat ou tu accepte de les utiliser. C'est totalement hors-sujet.
Et les mainteneurs de Debian, qu'en pensent-ils ? Jusqu'à quel point autoriseront-ils le choix entre plusieurs solutions, sachant que cette multitude de solutions complique leur travail de maintenance ?
Debian hosts experimental kernel choices for it's distribution while pushing the boundaries to support more hardware devices. There are development packages for architectures for the FreeBSD kernel (kfreebsd-i386 and kfreebsd-amd64) and Hurd kernel, making Debian the only operating system that offers three different kernels
On dirait que la surcharge de travail de maintenir 3 kernels différents ne leur fait pas peur en tout cas. (citation de la page en de wikipedia sur debian)
Avoir un système quasi-exempt de bug est un des objectifs affichés de Debian, donc je trouve plutôt cohérent de maintenir plusieurs systèmes d'init. Mais, oui, ça coûte aussi du temps, et pas qu'un peu. Mais je crois que Debian à une réputation à tenir, a ce sujet: prendre son temps avant de sortir une stable :p
kFreeBSD est encore un peu jeune, mais j'ai bien l'impression qu'il attire pas mal de monde.
Oui, ça serait intéressant d'avoir le nombre d'utilisateurs de kFreeBSD. Peut-être est-il possible d'avoir une estimation en regardant les statistiques des serveurs qui distribuent les mises-à-jour ?
C'est un ressenti que j'ai en suivant la ml en fait, je n'ai donc aucune preuve. Surtout que comme j'ai dis, je pense que ce ressenti est biaisé par le fait que je sois moi-même intéressé.
systemd est un logiciel trop complexe pour qu'on lui confie des tâches critiques
Je n'ai pas dis ça, ou en tout cas n'ai pas voulu le dire. J'ai voulu dire que systemd dépend de trop de logiciels, et que si ils continuent à ajouter des fonctionnalités qui rajoutent des dépendances, oui, ça va être un problème.
Il ne faut pas oublier que l'usage poste de travail/serveur n'est pas le seul usage de linux: il semble aussi y avoir du monde pour l'utiliser dans l'embarqué, par exemple, et dans ces situations les ressources sont critiques: ajouter dbus (je garde cet exemple) juste pour pouvoir démarrer le système ne me semble pas trop acceptable.
Debian voulant être un OS universel, on peut donc assez logiquement supposer qu'abandonner le support d'autres mécanismes ayant le même rôle mais qui sont plus légers est hors de question.
Il se trouve que le noyau Linux est encore plus complexe que systemd.
C'est sûr, mais dans le cas du noyau il me semble que la complexité est justifiée. Accessoirement, le manque de modularité de systemd est ce qui gêne le plus: impossible de l'utiliser sans dbus par exemple. Si je garde la comparaison du noyau, je peux très bien l'utiliser sans les firmware wifi.
Je me demande combien de lignes de code au minimum (tous modules désactivés, probablement inutilisable donc) prend linux, comparé à quand on y mets tout?
Sur ce point, effectivement, je me suis mal exprimé. Disons plutôt que, pour une distribution, choisir systemd comme solution par défaut diminue le travail de maintenance de la distribution.
Je pense que seul le fait de ne maintenir que systemd permets de réduire la charge de travail.
Au passage, je pense aussi que maintenir plusieurs ports d'un système permets de détecter plus de bugs.
Du coud, je ne sais pas quoi penser : de quand date la naissance de kFreeBRSD ?
Wikipedia nous indique que la version parue est une technology preview. On peut dire que le bébé est encore prématuré quoi :D
Note quand même que je n'éprouve pas de haine envers Lenart, je suis un utilisateur trop jeune de linux pour comprendre ce que les gens ont contre lui. Systemd me semble un outil très intéressant (sérieux, les scripts d'init sont horribles pour un néophyte) pour la facilité qu'il offre aux utilisateurs de contrôler leur système. Mon seul et unique regret à son sujet est vraiment le problème des dépendances forcées.
Pour moi, le toolkit graphique joue quand je sélectionne un logiciel à installer sur ma machine. Diminuer les dépendances est une question de perf pour moi.
t'interdisent de faire un paquet de truc, comme étudier son fonctionnement
Pour ce point précis, si c'était vrai, nouveau par exemple n'existerait pas, ainsi que le support des .doc de libreoffice, qui sont issus de la rétro-ingénierie.
tu as payé pour l'avoir.
Non. Tu as payé pour avoir le droit de l'utiliser.
Un message réfléchi n'empêche pas de faire des erreurs de traduction que je sache?
A bien y réfléchir, je me demande si "logiciel privatif" ne serait pas plus pertinent que "privateur". Déjà, le mot existe, et sa signification en droit me semble utilisable dans le contexte qui nous intéresse:
(Droit) Qui accorde une faculté, un usage, un droit à une personne, à l’exclusion des autres.
Dans le cadre de licences logicielles fermées, on est exactement dans ce contexte, on dirait: le droit de modifier est restreint à une personne, à l'exclusion des autres. Ca colle.
Par opposition, les licences garantissant les 4 libertés permettent à tout le monde d'avoir ce droit. Ca colle encore.
Donc, définitivement non, privateur n'a pas le droit de cité. En plus, il colore mes messages avec du rouge…
Par rapport au culte de la personnalité, l'exemple du wikitionnaire m'a fait sourire, il tombe fort à propos:
Doctrine du péché : étant capable de tout le mal n'en rien faire, et voilà le bien ; volonté privatrice − je n'aime point cela — (André Gide, dans Réflexions sur quelques points de littérature et de morale, 1897).
Sauf que dans la vraie vie, la FSF et les sister associations n'ont rien de commun (si ce n'est une vision similaire qui fait que la FSF les considère comme sister).
Dans la vraie vie, tu viens de me l'apprendre. Combien penserons la même chose que moi selon toi? Puis franchement, leurs méthodes sont-elles si différentes que ça (vraie question hein)?
Dans la vraie vie, les apparences sont importantes (essaies de changer le thème graphique d'un logiciel, change le logo et le nom, change 2-3 boîtes de dialogue, et montre le à un utilisateur en lui disant qu'il intègre pleins de fonctionnalités sympa comparé à son concurrent -qui n'est autre que le même logiciel- et tu verras).
Dans la vraie vie, les systèmes pyramidaux font tourner le monde (pour les gouvernements et les multinationales c'est assez évident je pense non?)
Bref, il faut arrêter de penser hiérarchie. Bienvenue à 21e siècle, à l'heure de l'opendata, du maillage, de la décentralisation.
La décentralisation du net, elle consiste à avoir ses mails sur google mail, ses documents sur google docs, et avoir ses amis sur facebook. Mouarf.
Les seules mailles que je vois, perso, c'est celles du filet qui sert à nous supprimer au fil du temps les quelques libertés qui nous restent (je parle pas qu'en terme de licences logicielles).
Si seulement le 21e siècle pouvais permettre de supprimer la hiérarchie, je serais assez heureux, crois-moi, mais… j'y crois pas.
Hum, non, justement, ce sont ceux qui connaissent autre chose que linux. Pour le reste du troll, on a beau être vendredi, je vais me retenir (et je t'assure que c'est pas toujours simple) :)
un initié (encore novice
En même temps, initié veut pas dire expert :p
Comment devient t'on un initié si on est déjà utilisateur de Linux mais qu'on le trouve à peine potable par rapport à Windows ?
Bah retourne à windows, c'est sûrement ce qu'il te faut.
Le correcteur orthographique n'est pas une fonctionnalité exclusivement linuxienne. En plus ils ne corrigent pas encore les erreurs du type que tu as corrigé il me semble.
A ce sujet, c'est moche de faire le grammar nazi en faisant une faute aussi laide…
openMP n'est pas une api C. Ce sont des directives de compilation pour générer du code multithread.
Et on peut pas faire la même chose avec OCaml? (pour la confusion: l'encart rapide sur wikipedia UK dit "Written in C, C++, Fortran" et "Type API" mais je te crois sur parole: n'ayant jamais utilisé et ayant déjà relevé des erreurs ou imprécisions sur wikipedia, je préfère faire confiance à quelqu'un tant que ses propos sont pas aberrants :) )
Il y a eu des études portant sur la productivité (cocomo) quelque soit le langage,
J'ai entendu parle de cocomo… quand j'ai parlé du problème du sucre syntaxique plus important des langages objet genre C++ (public/protected/private sur une ligne propre, accolades souvent seuls sur leurs lignes, déclarations/définitions dans des fichiers distincts -donc 2 lignes de code par prototype-, …) il m'a répondu que c'était plutôt utilisé par les commerciaux et a clairement remis en cause l'intérêt. J'ai gardé le nom dans un coin de mémoire morte mais sans creuser plus du coups.
Si tu as des ressources intéressantes à ce sujet je suis preneur, si tu estimes que ça permets vraiment d'estimer les coûts d'un projet en fonction des langages utilisés.
Tu penses que c'est un démon de quel dieu? Tzeentch ou Khorne ?
Il fallait bien que quelqu'un lui donne l'occasion de se manifester une seconde fois sur ce fil :)
Surtout que bon, il a raison, et que je fais généralement aussi la guerre à cette généralisation…
Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.
Je connais assez mal openMP, mais qu'est-ce qui empêche OCaml de l'utiliser? Pas moyen d'utiliser une API C dans OCaml? Mais alors, comment faire pour utiliser l'API de l'OS sous-jacent?
Désolé, mais je trouve cet argument plutôt contre que pour OCaml. Même Java et C# savent exploiter une API C… Ce serait dû au fait de ne pas être impératif?
Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.
From more-concise at page left to less-concise at the right, from slower at page top to faster at the bottom.
Les langages les plus rapides et concis sont en bas à gauche, non? J'ai toujours du mal avec droite et gauche en anglais…
Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.
Argument intéressant.
Mais je voulais surtout dire que je ne considère pas la taille d'un code comme un indice par rapport au fait qu'il soit lisible: perl produit des codes pouvant parser des documents complexes en peu de lignes, mais il est tout bonnement horrible à lire… A contrario, java est très simple à lire, mais j'ai l'impression qu'il se transforme souvent en romans à l'eau de rose, et mieux vaut avoir 2 écrans larges pour coder confortablement.
Mais les problèmes de logiciels dans ce domaine,
De quel domaine parles-tu? Dans la discussion, on parlait de façon assez générale il me semble… cette série de bench est intéressante, je suis d'accord, je rappelais juste (pour la même raison que je parlais de mauvaise foi en défendant le C++ sur tous les points) que les bench sont toujours là pour montrer l'efficacité dans un domaine précis.
Ici, ça semble être le calcul scientifique?
Toutes les filiales de la FSF du monde n'auront aucun poids sur le choix du W3C… les seuls qui peuvent faire quelque chose seront les éditeurs d'un des 3 navigateurs de tête.
Je doute très franchement que Mozilla parvienne dans le cas ou ils le souhaitent bien sûr, à convaincre le W3C face aux intérêts économiques.
A part des lois dans assez de pays, je doute que ce soit possible en fait. Et les lois ne seront jamais dans la direction d'accorder plus de libertés (en considérant que freiner les DRM améliore la liberté, bien entendu) aux citoyens, c'est pas trop à la mode en ce moment… les majors ont plus de chances d'y arriver: eux ont les sous.
[^] # Re: Vous avez vraiment rien d'autre à foutre ?
Posté par freem . En réponse au journal Privateur.... Évalué à -1.
Toi, t'essaies de nous la faire alenvers non? Et si tu nous montrait l'exemple au lieu d'être grossier?
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
J'ai 3 machines:
Ca réponds à ta question?
Sinon, pour les machines portables, il parait que les batteries préfèrent qu'on ne charge pas trop la ram ou le proc, pour une meilleure autonomie.
Accessoirement, quand je code, j'aime bien que les interfaces graphiques bouffent pas la moitié des ressources de ma machine. La compilation C++ est assez longue comme ça, pas besoin d'en rajouter, pas vrai?
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
On peut oui, mais wxwidgets semble être bien plus utilisé que les EFL.
Accessoirement, c'est portable.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Honnêtement, j'ai vraiment juste voulu nourrir le troll :)
Je comprend l'intérêt des gros framework, utiles pour les applications de type mastodonte (les plus courantes, celles qui intègrent le gestionnaire de fenêtre directement pour mieux faire doublon avec l'OS) mais je trouve regrettable que pas mal de petites applications suivent le même chemin.
Et surtout, je trouve très très regrettable qu'il y ait très peu de toolkit graphiques qui ne soient pas des framework… je ne suis même pas sûr d'en connaître un seul en fait.
[^] # Re: Où ?
Posté par freem . En réponse au journal Privateur.... Évalué à 3.
C'est vrai.
Très franchement, les USA ne sont vraiment pas un pays qui me fait rêver, cela dit :) (a part d'un monde sans eux, éventuellement)
[^] # Re: Non-libre
Posté par freem . En réponse au journal Privateur.... Évalué à 1.
Ouvert mais pas open? C'est à dire? Il montrait son source et tu n'avais pas le droit de l'utiliser? Ca colle assez bien avec les mots "open source" pris à la lettre, je trouve…
Sinon, je ne connais pas cette référence, y'a moyen que tu explicites un peu plus?
En même temps, quand on parle de licences, on parle de droit, de contrat, pas de couture, aux dernières nouvelles…
[^] # Re: Tu n'es pas le seul!
Posté par freem . En réponse au journal Privateur.... Évalué à 2.
Question intéressante. Il faudrait demander à une assos de consommateurs je pense.
Et tu as raison de ne pas en parler, car tu as accepté un contrat ou tu accepte de les utiliser. C'est totalement hors-sujet.
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
On dirait que la surcharge de travail de maintenir 3 kernels différents ne leur fait pas peur en tout cas. (citation de la page en de wikipedia sur debian)
Avoir un système quasi-exempt de bug est un des objectifs affichés de Debian, donc je trouve plutôt cohérent de maintenir plusieurs systèmes d'init. Mais, oui, ça coûte aussi du temps, et pas qu'un peu. Mais je crois que Debian à une réputation à tenir, a ce sujet: prendre son temps avant de sortir une stable :p
C'est un ressenti que j'ai en suivant la ml en fait, je n'ai donc aucune preuve. Surtout que comme j'ai dis, je pense que ce ressenti est biaisé par le fait que je sois moi-même intéressé.
Je n'ai pas dis ça, ou en tout cas n'ai pas voulu le dire. J'ai voulu dire que systemd dépend de trop de logiciels, et que si ils continuent à ajouter des fonctionnalités qui rajoutent des dépendances, oui, ça va être un problème.
Il ne faut pas oublier que l'usage poste de travail/serveur n'est pas le seul usage de linux: il semble aussi y avoir du monde pour l'utiliser dans l'embarqué, par exemple, et dans ces situations les ressources sont critiques: ajouter dbus (je garde cet exemple) juste pour pouvoir démarrer le système ne me semble pas trop acceptable.
Debian voulant être un OS universel, on peut donc assez logiquement supposer qu'abandonner le support d'autres mécanismes ayant le même rôle mais qui sont plus légers est hors de question.
C'est sûr, mais dans le cas du noyau il me semble que la complexité est justifiée. Accessoirement, le manque de modularité de systemd est ce qui gêne le plus: impossible de l'utiliser sans dbus par exemple. Si je garde la comparaison du noyau, je peux très bien l'utiliser sans les firmware wifi.
Je me demande combien de lignes de code au minimum (tous modules désactivés, probablement inutilisable donc) prend linux, comparé à quand on y mets tout?
Je pense que seul le fait de ne maintenir que systemd permets de réduire la charge de travail.
Au passage, je pense aussi que maintenir plusieurs ports d'un système permets de détecter plus de bugs.
Wikipedia nous indique que la version parue est une technology preview. On peut dire que le bébé est encore prématuré quoi :D
Note quand même que je n'éprouve pas de haine envers Lenart, je suis un utilisateur trop jeune de linux pour comprendre ce que les gens ont contre lui. Systemd me semble un outil très intéressant (sérieux, les scripts d'init sont horribles pour un néophyte) pour la facilité qu'il offre aux utilisateurs de contrôler leur système. Mon seul et unique regret à son sujet est vraiment le problème des dépendances forcées.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -2.
Et comment oublier wxwidgets?
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -6.
Pour moi, le toolkit graphique joue quand je sélectionne un logiciel à installer sur ma machine. Diminuer les dépendances est une question de perf pour moi.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 4.
PygObject? Je suppose que cet objet est rose et à la queue en tire-bouchon… ah, j'ai trouvé, c'est une tirelire!
/me ->[]
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -3.
Ce que je regrette avec les outils graphiques "modernes" c'est qu'ils tiennent absolument à faire le café…
Réseau, IHM, multi-thread… ça va jusqu'a réimplémenter les outils standards comme vector et string!
J'ai parfois l'impression que Qt souffre d'un NIH assez pointu… (longue vie à la tradition du vendredi)
[^] # Re: Non-libre
Posté par freem . En réponse au journal Privateur.... Évalué à 1.
Perso, je dis "fermé", ça m'évite la négation.
Privatif me semble pas mal (cf plus haut) :)
[^] # Re: Où ?
Posté par freem . En réponse au journal Privateur.... Évalué à 2.
Pour ce point précis, si c'était vrai, nouveau par exemple n'existerait pas, ainsi que le support des .doc de libreoffice, qui sont issus de la rétro-ingénierie.
Non. Tu as payé pour avoir le droit de l'utiliser.
[^] # Re: AMHA
Posté par freem . En réponse au journal Privateur.... Évalué à 4.
Oui, il choque, clairement.
Un message réfléchi n'empêche pas de faire des erreurs de traduction que je sache?
A bien y réfléchir, je me demande si "logiciel privatif" ne serait pas plus pertinent que "privateur". Déjà, le mot existe, et sa signification en droit me semble utilisable dans le contexte qui nous intéresse:
Dans le cadre de licences logicielles fermées, on est exactement dans ce contexte, on dirait: le droit de modifier est restreint à une personne, à l'exclusion des autres. Ca colle.
Par opposition, les licences garantissant les 4 libertés permettent à tout le monde d'avoir ce droit. Ca colle encore.
Donc, définitivement non, privateur n'a pas le droit de cité. En plus, il colore mes messages avec du rouge…
Par rapport au culte de la personnalité, l'exemple du wikitionnaire m'a fait sourire, il tombe fort à propos:
[^] # Re: Mozilla
Posté par freem . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à 0.
Allez, c'est vendredi…
Dans la vraie vie, tu viens de me l'apprendre. Combien penserons la même chose que moi selon toi? Puis franchement, leurs méthodes sont-elles si différentes que ça (vraie question hein)?
Dans la vraie vie, les apparences sont importantes (essaies de changer le thème graphique d'un logiciel, change le logo et le nom, change 2-3 boîtes de dialogue, et montre le à un utilisateur en lui disant qu'il intègre pleins de fonctionnalités sympa comparé à son concurrent -qui n'est autre que le même logiciel- et tu verras).
Dans la vraie vie, les systèmes pyramidaux font tourner le monde (pour les gouvernements et les multinationales c'est assez évident je pense non?)
La décentralisation du net, elle consiste à avoir ses mails sur google mail, ses documents sur google docs, et avoir ses amis sur facebook. Mouarf.
Les seules mailles que je vois, perso, c'est celles du filet qui sert à nous supprimer au fil du temps les quelques libertés qui nous restent (je parle pas qu'en terme de licences logicielles).
Si seulement le 21e siècle pouvais permettre de supprimer la hiérarchie, je serais assez heureux, crois-moi, mais… j'y crois pas.
[^] # Re: Mozilla
Posté par freem . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à 1.
Cet article devrait éclaircir ta lanterne…
[^] # Re: Utopie ?
Posté par freem . En réponse à la dépêche État des jeux sous Linux. Évalué à 0.
Hum, non, justement, ce sont ceux qui connaissent autre chose que linux. Pour le reste du troll, on a beau être vendredi, je vais me retenir (et je t'assure que c'est pas toujours simple) :)
En même temps, initié veut pas dire expert :p
Le correcteur orthographique n'est pas une fonctionnalité exclusivement linuxienne. En plus ils ne corrigent pas encore les erreurs du type que tu as corrigé il me semble.
A ce sujet, c'est moche de faire le grammar nazi en faisant une faute aussi laide…
[^] # Re: Il y a aussi quelques jeux libres
Posté par freem . En réponse à la dépêche État des jeux sous Linux. Évalué à 1. Dernière modification le 26 avril 2013 à 09:59.
Oh mon dieu, ils ont trouvé des noms de site et de page impressionnant! Dommage qu'il y ait "f.org" en trop cela dit.
PS: le commentaire en question… ton lien marche pas ici.
[^] # Re: Mozilla
Posté par freem . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à -2.
Référence à un certain codec? :D
Y'a des chances… mais rassures-toi en te rappelant les préceptes des prophètes Larry Page et Sergey Brin: "Don't be evil".
[^] # Re: un inconvénient des templates
Posté par freem . En réponse au journal Visiteurs en C++. Évalué à 1.
Et on peut pas faire la même chose avec OCaml? (pour la confusion: l'encart rapide sur wikipedia UK dit "Written in C, C++, Fortran" et "Type API" mais je te crois sur parole: n'ayant jamais utilisé et ayant déjà relevé des erreurs ou imprécisions sur wikipedia, je préfère faire confiance à quelqu'un tant que ses propos sont pas aberrants :) )
J'ai entendu parle de cocomo… quand j'ai parlé du problème du sucre syntaxique plus important des langages objet genre C++ (public/protected/private sur une ligne propre, accolades souvent seuls sur leurs lignes, déclarations/définitions dans des fichiers distincts -donc 2 lignes de code par prototype-, …) il m'a répondu que c'était plutôt utilisé par les commerciaux et a clairement remis en cause l'intérêt. J'ai gardé le nom dans un coin de mémoire morte mais sans creuser plus du coups.
Si tu as des ressources intéressantes à ce sujet je suis preneur, si tu estimes que ça permets vraiment d'estimer les coûts d'un projet en fonction des langages utilisés.
[^] # Re: Mozilla
Posté par freem . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à -1. Dernière modification le 25 avril 2013 à 16:37.
Tu penses que c'est un démon de quel dieu? Tzeentch ou Khorne ?
Il fallait bien que quelqu'un lui donne l'occasion de se manifester une seconde fois sur ce fil :)
Surtout que bon, il a raison, et que je fais généralement aussi la guerre à cette généralisation…
[^] # Re: un inconvénient des templates
Posté par freem . En réponse au journal Visiteurs en C++. Évalué à -1.
Je connais assez mal openMP, mais qu'est-ce qui empêche OCaml de l'utiliser? Pas moyen d'utiliser une API C dans OCaml? Mais alors, comment faire pour utiliser l'API de l'OS sous-jacent?
Désolé, mais je trouve cet argument plutôt contre que pour OCaml. Même Java et C# savent exploiter une API C… Ce serait dû au fait de ne pas être impératif?
Les langages les plus rapides et concis sont en bas à gauche, non? J'ai toujours du mal avec droite et gauche en anglais…
Argument intéressant.
Mais je voulais surtout dire que je ne considère pas la taille d'un code comme un indice par rapport au fait qu'il soit lisible: perl produit des codes pouvant parser des documents complexes en peu de lignes, mais il est tout bonnement horrible à lire… A contrario, java est très simple à lire, mais j'ai l'impression qu'il se transforme souvent en romans à l'eau de rose, et mieux vaut avoir 2 écrans larges pour coder confortablement.
De quel domaine parles-tu? Dans la discussion, on parlait de façon assez générale il me semble… cette série de bench est intéressante, je suis d'accord, je rappelais juste (pour la même raison que je parlais de mauvaise foi en défendant le C++ sur tous les points) que les bench sont toujours là pour montrer l'efficacité dans un domaine précis.
Ici, ça semble être le calcul scientifique?
[^] # Re: un inconvénient des templates
Posté par freem . En réponse au journal Visiteurs en C++. Évalué à 0. Dernière modification le 25 avril 2013 à 16:17.
Attends… t'es en train de dire qu'un langage générant du C était plus rapide que le C?
Tu cherches à me faire bugger par une boucle infinie ou quoi? XD
[^] # Re: Mozilla
Posté par freem . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à 3.
Un médiateur?
Toutes les filiales de la FSF du monde n'auront aucun poids sur le choix du W3C… les seuls qui peuvent faire quelque chose seront les éditeurs d'un des 3 navigateurs de tête.
Je doute très franchement que Mozilla parvienne dans le cas ou ils le souhaitent bien sûr, à convaincre le W3C face aux intérêts économiques.
A part des lois dans assez de pays, je doute que ce soit possible en fait. Et les lois ne seront jamais dans la direction d'accorder plus de libertés (en considérant que freiner les DRM améliore la liberté, bien entendu) aux citoyens, c'est pas trop à la mode en ce moment… les majors ont plus de chances d'y arriver: eux ont les sous.