La distribution des résultats doit ressembler à une cloche. On peut baisser un pouillième le niveau et ramasser plus de monde.
OK, gros malentendu visiblement, tu n'as pas compris. C'est un CONCOURS. Le numerus clausus est fixé par le ministère sur la pression du conseil de l'Ordre des médecins. On prend les n premiers, quel que soit le niveau (avec un seuil d'admissibilité, mais vu la popularité du concours de médecine, ça n'a aucune importance).
Techniquement, non, justement, le barême est conçu de manière à étaler les notes dans la queue de la distribution, de manière à amplifier démesurément les différences aux alentours du seuil de sélection ; ça serait débile de couper en plein milieu de la Gaussienne, puisqu'il y aurait plein d'égalités et de conséquences dramatiques à la moindre erreur de correction.
La plus part des maladies sont incurables
La majorité des consultations en médecine générale ont pour cause un problème infectieux (angine, rhume, bronchite, gastro-entérite, mycose...) ou traumatique (cheville foulée). Comme tu le vois, en effet, la plupart de ces maladies sont incurables.
Tu voulais probablement dire "la plupart des maladies mortelles sont incurables". C'est indéniable.
Le reste de ton commentaire est incompréhensible. "On" fait plein de trucs, "Ils" ne font pas ce qu'il faut, Yaka faire des turcs, mais Faukon les fasse. Tu es certain que tu souhaites vraiment discuter d'un sujet dont tu n'as visiblement aucune idée?
En France, l'inscription en fac de médecine est conditonnée à un concours, pas un examen. On peut changer les coefficients des matières du concours autant qu'on veut, on n'aura pas plus de médecins! Et pour avoir enseigné les statistiques en prépa médecine, je peux affirmer que la sélection n'a rien à voir avec les performances en mathématiques. La sélection se fait sur la capacité à répéter les trucs faux ou inutiles qu'on a appris.
Par ailleurs, l'idée que les maths sont sur-représentées dans la formation des médecins est totalement fausse. 8 grandes matières sont représentées au concours : la chimie, la biologie, la physique, les biostatistiques, la physiologie, l'anatomie, la pharmacologie, les sciences sociales, plus une unité d'enseignement "médecine". Les biostats, seule discipline pouvant être comparée de loin avec un truc un peu mathématique, a un coefficient d'environ 2 (sur 26 en tout), soit moins de 10% de la note.
Donc, bon, cette légende de la sélection sur les maths, on peut se passer de la colporter.
De plus je ne voulais pas changer Wikipedia, je désirais juste l'enrichir un peu.
Est-ce que tu contribuerais à un logiciel libre sans t'intéresser aux conventions de la communauté de développeurs? Si tu envoies un patch qui ne respecte pas les conventions de nommage et d'indentation, ni l'esprit du code, et que ta fonctionnalité ne correspond pas à l'idée que les développeurs se font du logiciel, alors ton patch sera rejeté. Ça n'est de la faute que d'une personne : toi.
En l'occurrence, Wikipédia a des règles strictes pour l'admissibilité des articles, qui sont justifiées par la nécessité de pouvoir écrire des articles encyclopédiques (et donc analytiques) sur la base de sources fiables, multiples, et indépendantes. Si tu ne peux pas démontrer l'existence de ces sources, alors l'article n'est pas admissible. Et contrairement à ce qu'on pourrait croire, je trouve que les critères d'admissibilité sont assez laxistes, il y a beaucoup d'articles qui ne sont pas basés sur des sources fiables.
Libre à toi de créer "Nimportequoipédia", de créer une communauté, et de te démerder avec les fiches bousiformes que tu y accumuleras sans relecture critique.
Personnellement je trouve ça lourd, les p'tits malins qui viennent expliquer que les gens qui décident d'implémenter les DRM sur Linux sont trop cons parce que les DRM sont par nature inefficaces, parce que Linux. Du genre « Ha, ha ! J't'ai bien baisé, j'peux quand même regarder House of cards, euh ! ».
Il faut quand même avouer qu'il y a un vrai problème avec les DRM intérgrés dans des logiciels libres. Au delà des aspects éthiques, qui peuvent toujours être discutés, c'est techniquement totalement stupide d'envoyer les infos décryptées dans un logiciel libre. Pour que les DRM soient efficaces, il faut un contrôle intégral de la chaine logicielle et matérielle, de manière à ce que la seule capture possible soit analogique (filmer l'écran), puisqu'à moins de coller des puces DRM dans les yeux, c'est inévitable. Coller des DRM dans Firefox sous Linux, ça revient à encoder tes emails sur ton disque dur avant de les envoyer en clair par internet.
Soit les promoteurs des DRM ne l'ont pas compris (j'en doute), soit ils s'en foutent (mais des systèmes pour capturer la sortie décodée vont forcément devenir très populaires, et ça pourrait même encourager les gens à passer à Linux), soit c'est une stratégie élaborée pour écraser le logiciel libre (logiciel libre = piratage, etc). Le fait que le problème soit intrinsèquement lié à la nature du logiciel libre rend tout ça assez inquiétant. Monsieur Lobby DRM va aller voir les gouvernements, expliquer qu'il a trouvé un moyen pour se protéger des vilains pirates, mais qu'il existe des vilains logiciels de pirates pour ruiner ses légitimes efforts pour protéger sa propriété intellectuelle. Deux solutions, on interdit les logiciels libres (mais bon, ça va se voir), soit on l'exempte de proposer des solutions interopérables, et on lui fout la paix si ses trucs proprios ne sont disponibles que sous Windows 8.1.2.associé à un hardware verrouillé.
De manière générale, je déteste les liens vidéos vers des contenus informatifs. Je sais lire, et je sais lire beaucoup plus vite que les gens ne parlent. Je sais aussi lire en diagonale, et je suis capable de sauter à la fin d'un texte sans me taper les parties qui me saoulent. Je ne comprends pas l'intérêt de vidéos de mecs qui parlent.
Mais des gens parlent de 3% du traffic Tor qui serait "mauvais"
Tu n'as même pas lu le lien. Il s'agit de 3% de malwares. Rien à voir avec la légalité du trafic.
Moi je pense que la majorité des 2.5 Millions d'utilisateurs journaliers de Tor sont juste des gens qui veulent eviter d'etre espionnés
Ouais, évidemment. Tor est simple, rapide, et pas du tout contraignant.
Je suppose que c'est la meme chose si tu visites des sites en https plutot que http, si la connection est chiffrée, c'est forcement pour cacher des trucs pas bien ?
Une connexion cryptée, c'est un échange d'infos confidentielles entre deux interlocuteurs de confiance. Tor c'est principalement pour cacher sa véritable identité à son destinataire. Ça n'a rien à voir.
Moi je connais des gens qui achetent tout un tas de trucs en bitcoins, et que des trucs légaux. Juste par ce que c'est pratique.
Ah ouais, c'est super-pratique d'avoir un portefeuille qui vaut 300€ le lundi, 800€ le mardi, et 50€ le mercredi. Avec des frais de l'ordre de 10% (cf les tarifs de la Maison du Bitcoin) pour convertir tes vrais sous en Bt. Nan nan, y'a pas à dire, c'est super pratique.
les virements vers un compte d'une banque dans un autre pays c'est compliqué
Internet -> login/passwd -> virement international -> montant, date -> valider. Ça marche pour la plupart des pays, avec des frais de change largement comparables au Bt.
Pour les grosses transactions, il faut parfois remplir un formulaire pour justifier auprès des douanes pourquoi tu verses autant. C'est ça le problème?
Et pour les transactions vers le Zimbabwe du sud, ça peut être plus compliqué, oui. D'ailleurs, tout le monde fait des transferts vers des pays dont on ne connait pas le nom tous les jours.
Donc ouais, des vrais arguments, il y en a? L'idée de l'ami qui achètes des timbres à 0.50€ trois fois par semaine dans des pays improbables, j'ai du mal à trouver ça pertinent.
C'est un peu comme si l'argent était automatiquement sur un compte avec de bon taux d'interret. C'est pas mieux ?
Ah non, c'est pas mieux du tout. C'est même complètement catastrophique : ça coupe la consommation, ça encourage à l'échange de services non-monétarisés (donc au travail au noir), ça pousse à une diminution des prix et des salaires, ça encourage l'épargne aux dépens de l'investissement, et ça coupe complètement le robinet du crédit. D'où déflation, récession, chômage, avec une possibilité non-négligeable de retour au moyen-âge.
Alors oui, c'est bien si on a treize ans et qu'on est nihiliste. Dans ce milieu, il court l'idée saugrenue que les gens qui contrôlent et réglementent la finance et les banques centrale sont des imbéciles apprentis sorciers. Par contre, par un raisonnement qui m'échappe totalement, les gens qui inventeraient dans leur garage un système monétaire parasite, sans contrôle, et économiquement absurde, seraient des bienfaiteurs humanistes.
Il aurait été parfaitement possible de concevoir le Bt de manière à ce que la création de Bt soit proportionnelle au volume de transactions. Sauf qu'il a été décidé que le Bt devait être une ressource limitée, et que les concepteurs et leurs copains se réservaient une partie significative que la richesse globale représentée par les Bt. C'est une escroquerie cachée derrière un algorithme intéressant, une vraie prouesse intellectuelle orientée vers l'enrichissement personnel d'un seul homme et de son entourage, prouesse d'autant plus intéressante qu'elle n'est pas ostensiblement illégale. Ce n'est pas une pyramide de Ponzi, c'est une "pyramide de Nakamoto", un montage astucieux, quelque part entre les produits pourris de la finance qui ont récemment plongé le monde dans le chaos économique, et les systèmes pyramidaux où l'enrichissement des fondateurs est assuré par la cupidité des derniers entrés.
c'est justement le fait d'acheter des truc en btc qui permet au btcs stockés de prendre de la valeur.
Non. C'est la conception déflationniste du Bt qui lui permet de prendre de la valeur. Le seul ancrage du Bt dans la réalité est le coût du minage (électricité, matériel, bande passante, etc). Par conception, ce coût augmente (beaucoup). Bt est donc conçu pour augmenter, c'est mécanique.
Et au contraire, c'est la pénurie de Bt circulants qui favorise la spéculation. Obtenir des Bt est difficile, donc cher.
rien ne dit qu'il vont prendre de la valeur, et s'ils le font peut-être qu'il vont en perdre avant.
Certes, c'est un objet spéculatif très volatil. Mais il est conçu pour être déflationniste et rare. Il est aussi conçu pour rendre ses concepteurs 1000 fois plus riches que Bill Gates en cas de succès. Bref, il est conçu pour prendre de la valeur.
si tu as besoin d'acheter des œufs, rien ne t’empêche d'acheter des btc avec les sous que tu comptais investir dans 1 douzaines d’œufs puis de dépenser lesdits btc pour acheter des œufs (enfin après il faut calculer les commissions toussa)
Non, rien ne t'en empêche, à part un raisonnement rationnel. Non seulement c'est coûteux, mais c'est aussi stupide en terme d'investissement. Mieux vaut continuer d'utiliser une monnaie contrôlée par une banque centrale (inflationniste) pour les transactions quotidiennes, et stockers les Bt (déflationnistes) pour spéculer.
d'une manière général c'est pas parce qu'un bien prend de la valeur avec le temps qu'il est con de le vendre (sinon, il faudrait être profondément con pour vendre sa maison, son or, sa voiture de collection, ses tableaux de maîtres)
En excluant les problèmes financiers (qui t'obligent évidemment à liquider tes placements) ou les raisons fiscales ou matérielles, oui, on peut essayer des martingales pour maximiser son profit en anticipant les risques. Si tu as acheté 1000 Bt pour 1000€ il y a deux ans, tu peux revendre 100 Bt à 1000€ pièce maintenant : ça te fait 99 000€ de bénéfice net, et un potentiel démentiel de profit futur. Liquider tous ses Bt maintenant? Pourquoi pas, mais ça me semble correspondre à aucune stratégie rationnelle. Ceci dit, rien n'est rationnel avec le Bt.
D'après ce que j'ai compris en lisant la presse en ligne, ce n'est pas l'activité Bitcoin qui est en cause, c'est juste qu'il s'agit d'une sorte d'escroquerie qui utilisait entre autres des Bt.
OK, donc les Bitcoins peuvent servir à des activités illégales? Super. Bientôt, on va s'apercevoir que Tor héberge des activités criminelles. Ouhlala!
Personnellement, je n'arrive pas à comprendre comment on peut avoir peur du contrôle des États au point de vanter les mérites de systèmes qui permettent à n'importe qui (y compris à des gens pas très recommandables) d'échapper, justement, au contrôle des États. Il y a probablement 1000 pédophiles pour un opposant chinois sur Tor. En ce qui concerne les Bitcoins, c'est peut-être moins tranché, mais il y a certainement une très grosse majorité des gens qui ne sont pas réellement utilisateur (qui utilisent les Bt simplement comme un support de spéculation). Franchement, vu l'évolution des taux de change du Bt, qui s'amuserait à effectuer des payements en Bt? Il faut être complètement dingue ; avoir un portefeuille de Bt offre la possibilité de multiplier sa valeur par 1000 en quelques années, il faut être profondément c*** pour acheter des oeufs ou des DVD avec! J'imagine que la plupart des transactions (en volume) sont donc motivées par l'absence de traçabilité. Et il ne doit pas avoir beaucoup d'activités légales qui justifient de devoir perdre des possibilités de spéculation aussi gigantesques...
En tout cas, si les Bt saisis par la justice sont systématiquement détruits, il va bientôt falloir compter en nanoBt, parce qu'il ne va plus y avoir beaucoup de Bt sur le marché!
Il est d'ailleurs d'autant plus regrettable que d'après l'article, la loi va être totalement abrogée, alors qu'elle partait d'une bonne intention. Sa mise en place a juste été débile. Il aurait suffi d'un portail Internet auquel on s'identifiait (avec par exemple un numéro de sécu) pour juguler le problème : non seulement on pourrait facilement repérer les comptes dont l'activité n'a rien à voir avec une demande légitime (et donc saisir un juge pour "abus de droit" ou équivalent), mais en plus on aurait pu mettre en place des bases de connaissance accessibles aux citoyens, ce qui aurait évité de devoir répondre plusieurs fois aux mêmes questions. Par exemple, pour l'histoire des caméras de vidéosurveillance, si on entre une fois les coordonnées GPS dans le système, on n'a plus à répondre aux questions.
Les pays du Nord passent souvent pour des pragmatiques, mais il semble que les députés néerlandais ont vraiment ruiné une bonne idée avec leur truc. L'article explique même que certaines demandes étaient cachées (par exemple, dans un devis ou une candidature spontannée), ce qui suppose qu'il n'y avait même pas besoin de remplir un formulaire spécifique! C'est profondément crétin ; s'il peut y avoir un dédommagement financier, on peut s'attendre à avoir un minimum de procédures à respecter!
C'est pas R le langage ou le runtime qui est rapide, ce sont les libs d'algèbre linéaire qu'il y a dessous (et je prends le pari que c'est du C).
Comme tous les langages, R a une bibliothèque standard—qu'elle soit implémentée en C, en Fortran, en assembleur, ou en javascript ne change pas.
L'objectif n'est pas de comparer des trucs sur une base idéologique, c'est de déterminer en pratique si un langage est adapté au développement de telle ou telle application. Seule une minorité d'applications ont un temps d'exécution critique : pour un uptime de 9 jours sur mon PC de bureau, seules 19 applications (sur 267) ont pris plus de 30 s de temps CPU (soit 0.13s par heure!). Et je suis certain que pour toutes ces applications, seuls quelques % du code sont réellement concernés. Seule une fraction de pourcent des millions de lignes de code que j'utilise au quotidien sur ma machine mérite d'être rapide, le reste pourait être codé en visual Basic que je ne verrais pas la différence.
Je maintiens donc que C est très largement sur-utilisé. C'est un outil très technique, indispensable dans certains domaines, mais son utilisation systématique par le commun des développeur n'est pas justifié. Évidemment, s'ils tombent systématiquement sur des gens qui leur disent que C est une sorte de graal qui tend vers l'optimalité, ou qu'on n'est pas un vrai développeur si on ne code pas en C, on ne va pas sortir de cette situation.
Je sais bien, mais c'est le benchmark initial qui était complètement stupide, je n'ai fait que suivre les instructions! (calculer 500 fois la somme des 1/n2 pour n = 1 à 10000).
Du coup, un bon compilo s'apercevrait qu'on ne fait rien, je pense, et le test concerne tout autant le langage que le compilateur.
Le code initial en R incluait une double boucle, comme si c'était du C. Du coup, R mettait 3h à faire ce calcul stupide, ce qui n'est pas étonnant. Ce que j'ai essayé de montrer, c'est que ça n'était pas de la faute de R, mais du programmeur. Codé correctement, cet algo stupide est tout aussi rapide que du C.
Après, il existe forcément des algorithmes pour lesquels R est beaucoup plus lent que C. C'est évident, c'est un langage interprété. Mais il existe aussi de nombreux cas où en pratique R sera plus rapide que le code C, parce qu'il appelle des routines optimisées. Je ne connais pas les rouages internes de R, mais il est très efficace pour les opérations vectorisées (apply, lapply, sapply, etc), et ça ne m'étonnerait pas qu'il implémente des optimisations de bas niveau pour ça. Il est aussi diaboliquement bon pour des casse-têtes algorithmiques (par exemple tirer au hasard des éléments d'un vecteur avec ou sans remise avec pondération, avec une vitesse que je n'ai jamais réussi à approximer en C++).
Encore une fois, les langages sont tous Turing compplets, on peut tout faire avec n'importe quoi. Mais il est malsain de penser que de tout coder en C montre qu'on est un programmeur balèze. Ça montre juste qu'on est un programmeur qui ne connait que le C :)
C'est vrai, mais typiquement ton exemple en R est illisible.
Sérieux, tu n'arrives pas à lire quelque chose comme:
replicate(500, sum(1/((1:10000)^2))?
Là c'est vraiment une question d'habitude, pour moi c'est vraiment limpide. Il y a des trucs en R qui sont vraiment illisibles (notamment à cause de l'accumulation de parenthèses), mais je parse très bien cette ligne.
Il y a de grande chance que ton compilateur ai détecté que tu demandes 500x la même chose et ne le fasse pas.
Il n'est pas si malin que ça. Si on remplace 500 par 500000, ça prend 0.45 sec. Le vrai temps est donc autour de 0.004s, certainement trop court pour être mesuré efficacement avec system.time.
l'investissement dans la chaîne de production ne se rentabilise pas sur la première vente mais s'étale sur plusieurs années.
Hors matières premières? C'est clair qu'il est impossible de prendre en compte les charges et les investissements dans le calcul, mais un assembleur qui achète des carte-mères à 50,ドル des proc à 50,ドル et des boitiers à 20,ドル a-t-il le droit de vendre les PC assemblés à 100€ hors des périodes de solde?
Il ne faut pas exagérer, il y a souvent un facteur 10 entre un script et un langage compilé.
C'est loin d'être vrai. Il suffit de comparer des opérations comparables (cf un de mes anciens commentaires sur un benchmark où R se gamellait, et où j'avais réussi en codant selon les paradigmes du langage à réduire le temps d'exécution de 7 secondes à 0.00 (sic) seconde : http://linuxfr.org/news/version-1-0-de-julia#comment-1327186).
C'est clair, si tu implémentes un algo de tri en perl, il va être 10 fois moins rapide qu'en C. Mais ce n'est pas comme ça qu'on fait un tri en perl, c'est tout.
Toutafé. En bio-informatique par exemple, il est très courant d'employer des langages interprétés (principalement R et python) même pour les algorithmes critiques. Évidemment, c'est en partie attribuable au fait que les gens ne sont pas nécessairement développeurs de profession et que ces langages sont plus accessibles, mais c'est aussi lié au fait que (contrairement à ce qu'on peut souvent entendre), ces langages ne sont pas si lents que ça en pratique, car la très très grande majorité des algorithmes consiste à assembler des briques déja optimisées : du tri, des expressions régulières, des sommes, des opérations sur des matrices, etc. Si on ajoute la compilation just-in-time et la parallelisation relativement accessible, on se situe dans des domaines de performance qui sont du même ordre de grandeur que les langages compilés traditionnels, pour un temps de développement très inférieur.
Qu'est-ce qui te permet de juger qu'ils ne devraient pas être en C ? Tu es sans doute un des rares à pouvoir choisir au début d'un développement qu'elle sera la complexité du logiciel au final
Le meilleur langage est celui que tu connais, mais il y a des limites.
Les exemples auxquels je pense, c'est par exemple des applis essentiellement basées sur des GUI. Imagine par exemple un truc qui édite des fichiers de config. Tu crées un clicodrome, il n'y a pas de calcul ou d'algorithme particulier. Dans ce cas, tu te vois gérer la mémoire, détuire les pointeurs vers les widgets au fur et à mesure de leur fermeture, etc? Tu n'as aucune contrainte de temps d'exécution, 99% du temps cpu va être consacré à l'affichage des éléments qui sont appelés par une bibliothèque (qui elle pourra être en C).
Un autre exemple (celui auquel je pensais, en fait) sont tous ces jeux de stratégie, type implémentation de jeux de plateaux ou jeux de rôle. Au niveau algo et calcul, il y a que dalle, c'est juste de l'interface autour d'un moteur de jeu. J'ai contribué parfois à ces trucs, en plus, souvent, c'est "Dédé apprend à programmer", c'est plein de segfaults et de pointeurs tout nus qui se balladent partout, les tableaux sont initialisés avec des dimensions constantes (souvent plusieurs millions de cases, hein, faut voir grand), etc.
De toute façon, la langage ne fait pas l'optimisation. C'est l'algorithme qui fait ça.
Justement, raison de plus pour ne pas s'emm* avec ces langages proches de la machine, qui n'ont d'utilité réelle que dans une minorité de cas. Et surtout si on n'est pas développeur de formation et de profession. Personnellement, je vois C comme un outil spécialisé, pour des développeurs système ou embarqué, ou réservés à des cas très particuliers. Pour coder un truc avec une GUI et trois algos triviaux, il me parait beaucoup plus censé de démarrer sur un langage de script (python? ruby?) plutôt que de se demander si on ne va pas avoir un jour besoin de faire de la logique bitwise.
L'approche de plus en plus désincarnée des langages abstraits a beau essayer de cacher ce qui a sous le capot, au final ça marche pourtant comme ça
Oui, mais c'est ce qui s'appelle l'"abstraction". La question centrale est celle des contraintes du langage, est-ce qu'un langage doit représenter la manière dont la machine fonctionne, ou est-ce que le langage doit fournir des outils pour implémenter formellement ce que le programmeur pense? Bon, en plus, tout ça est proche de la machine, il faut avoir en tête les différences entre les architectures, ça me parait être une complexité dingue pour une histoire de trois nombres entre 0 et 255.
D'une manière plus spécifique, oui, il me paraitrait évident de manipuler du bit de couleur dans Gimp. Dans un émulateur de terminal, je ne vois pas. La manière "correcte" de traiter les couleurs dans ce contexte est, à mon avis, de créer un objet qui contient trois variables de la bonne taille, avec une méthode d'import (qui elle peut éventuellement tripoter les bits—ce n'est pas sale), et des méthodes d'export. Si un émulateur de terminal passe plus de 0.01% de son temps à jouer avec les couleurs, c'est certainement qu'il y a un problème dans l'émulateur, et pas dans l'optimisation de la fonction qui gère les couleurs.
Peut-être n'existe-t-il pas une relation divine entre le langage et la performance d'un logiciel?
Ce que je trouve amusant, c'est que dès qu'on discute performance, il semble que tous les développeurs bossent sur de l'embarqué, des drivers de carte graphique, ou sur le noyau. Mais ce développement là représente quoi, en vrai? Quelle proportion des logiciels qu'on utilise tous les jours a besoin des quelques % de différence de temps d'exécution entre C et C++? Le noyau, le serveur X, et puis heuuu... Ça serait débile de croire que si LibreOffice est poussif, c'est parce qu'il n'est pas codé en C.
Si tu fais un tour sur un dépôt de logiciels libres et que tu regardes les langages, tu t'apercevras que 90% (au pifomètre rouillé) des projets en C n'ont absolument aucune raison d'être en C.
Bah oui, mais c'est la différence entre une entreprise et un salarié. Une entreprise peut facturer au temps ou au forfait, un salarié loue sa force de travail. Ça permet par exemple de payer les gens même quand ils font un travail inutile pour la boite (par exemple, un projet qui sera finalement abandonné) : les salariés ne facturent pas à leur entreprise.
Le développement de la micro-entreprise et de l'auto-entreprenariat pose de vrais problèmes qu'on ne peut pas écarter d'un simple revers de la main avec un argument libéral. En particulier, il se pose le problème du dumping. Une entreprise n'a pas le droit de vendre à perte, mais un autoentrepreneur a le droit de facturer des services à perte (par exemple, sous le salaire minimum). Il est évident que beaucoup d'autoentrepreneurs font un tel dumping, rien que pour conserver leur entreprise en vie dans l'espoir d'un démarrage ultérieur.
Je ne vois rien de mal à préférer une personne qui répond au besoin (même si ce dernier est de prioriser labaisse de prix à la qualité).
Ce qu'il y a de "mal", c'est que ça remet en cause le modèle économique de la profession. Je ne suis pas en train de comparer les devis de deux entreprises, là. Quand on met en concurrence deux boites, on va comparer les prestations proposées à ce qu'on souhaite, et dans les deux cas, on s'attend à ce que le travail soit de qualité professionnelle.
Là, on parle carrément de mettre en concurrence un système qui nie complètement le principe du droit du travail. Tu as affaire (au mieux) à des autoentrepreneurs plus ou moins légaux, voire carrément à du travail au noir pas du tout déclaré. Le travail se fait à l'arrache, dans des conditions absolument pas contrôlées (horaires journaliers?), payé à la tâche, sans salaire minimum.
Pour moi, l'équivalent, ça serait un grand hôlel qui file de temps en temps un balai et 5€ à un SDF pour mettre un coup dans l'arrière-cour, plutôt que d'embaucher une personne pour ça. Qu'est-ce que tu t'en fous d'avoir un balayeur professionnel? Tu es content, le SDF est content, où est le mal? Le mal, c'est que dans notre société, le travail a un coût et doit s'effectuer en respectant des règles. Ce coût peut être supérieur à la valeur que tu associes au travail, mais tu dois supporter cette différence par respect pour les personnes qui travaillent. C'est certes une logique non-libérale, mais le libéralisme seul ne peut pas définir l'éthique de nos sociétés (en tout cas, la plupart des européens semblent le voir comme ça).
Non, mais ça pose un vrai problème en fait : c'est le prix de l'expertise et du travail.
On vit dans un monde paradoxal où le chômage est rampant, mais où on veut garder des salaires raisonnables. Le problème n'est pas seulement la délocalisation des services, c'est simplement le prix que l'on veut bien mettre dans le travail d'une personne.
Le développement est un bon exemple. Tu as besoin de développer une fonctionnalité pour un programme existant. Combien ça peut te coûter de le faire faire dans les règles de l'art? Très cher, probablement. Des dizaines de milliers d'euros, même pour un truc qui ne parait pas hors de portée (une personne.mois, un truc comme ça). Combien ça va te coûter de le faire à l'arrache, avec un stagiaire, ou avec une offre dématérialisée sur Internet? Probablement 10 fois moins cher. Évidemment, la prestation sera de moins bonne qualité. Mais là n'est pas la question, parce que tu n'avais peut-être pas besoin qu'elle soit spécifiquement de qualité supérieure. Tu voulais juste avoir quelque chose de plus ou moins fonctionnel pour pas cher.
Avec la montée du chômage et la démocratisation des connaissances via internet, les experts ne sont plus compétitifs pour les trucs triviaux. Un exemple idiot, ta machine à laver ne fonctionne plus. Si tu es une personne âgée, tu vas appeler un réparateur. Si tu as un ordinateur, tu vas taper le nom de la machine, explorer les forums, te faire une idée de la panne, et tenter de dépanner toi-même. La moitié du temps, ça va fonctionner (évidemment, l'autre moitié, non, mais ça n'est pas la question). Au pire, tu vas trouver un bricolo du dimanche qui y connait un peu plus que toi et qui va te dépatouiller sur une partie des cas restants. Bref, tu cantonnes l'expert professionnel qui bosse selon les règles de l'art aux cas les plus complexes. Son expertise a encore de la valeur, évidemment : le jour où tu veux un travail bien fait, tu payeras. Mais dans notre monde où tout est jetable, où les entreprises ne cherchent plus à durer 40 ans, où personne dans une entreprise se souhaite y rester plus que quelques années, qui se soucie réellement que le boulot soit fait par les meilleurs experts? Qui est prêt à payer 10 fois ou 100 fois plus cher pour un service qui est, quoi, 2 ou 3 fois meilleur, avec souvent des délais plus longs ou des contraintes légales qui n'existent pas pour les services à l'arrache? Il n'y a plus que quelques professionnels que tu acceptes de payer plus que ce que tu es payé, parce qu'il y a des impératifs de sécurité qui nécessitent une qualité irréprochable : les médecins, les avocats, les architectes, les notaires, et éventuellement les garagistes. Pour le reste, on vit très bien avec l'imperfection.
1) Je ne vois pas l'avantage de coder des applications non-système en C. Pourquoi pas en assembleur, tant qu'on y est? C'est sûr, C permet de faire des trucs comme #define TRUERED(x) (((x) & 0xff0000) >> 8). Ça marche pour draguer?
2) Il n'y a pas nécessairement de rapport entre le nombre de lignes de code et l'efficacité ou la facilité de maintenance. Par exemple, pour st, on se retrouve avec un fichier st.c de 4000 lignes, et des centaines de fonction dedans. À part pour l'exploit de faire tenir un émulateur de terminal dans un fichier, c'est quoi l'intérêt?
3) L'exploit a un coût. Par exemple, le texte qui s'affiche quand on lance "st -h" est codé en dur. Du coup, quand on change une option, il faut modifier le code, et modifier le texte en dur. Il existe probablement des dizaines de bibliothèques qui permettent d'automatiser ça; beaucoup d'entre elles sont d'ailleurs seulement dans un .h et ne nécessitent pas de dépendance externes, elles peuvent juste être #include-ées.
Bref, l'exploit est intéressant en tant que tel, mais il est peut-être raisonnable de trouver un juste milieu. Les buffer overflow dans les applis météos parce qu'un geek a imaginé qu'il savait faire du C, ça va deux secondes, mais je préfère quand les gens utilisent des langages adaptés.
Ouuhhh, j'en connais qui vont parler de systemd :-)
Par rapport à DOS, c'est compliqué, mais par rapport à Windows, je trouve que depuis quelques années les distributions Linux ont fait beaucoup de progrès au niveau du temps de démarrage. Ce n'est pas instantané, certes, mais c'est très acceptable. Mon PC de boulot met plus de temps à lancer le bios et les trucs matériels que de démarrer le noyau et le serveur graphique. En gros, ça met autant de temps à lancer le système qu'à lancer libre office, c'est quand même notable.
La lourdeur des distributions, c'est autre chose. Les stratégies "à la Ubuntu", avec un bureau qui se comporte comme une surcouche à un système complet, sont évidemment à remettre en cause. D'une manière générale, un OS est un gros truc complexe, et à moins de disposer d'une puissance de développement extraordinaire, on est souvent obligé d'accumuler des couches pas bien conçues pour que ça marche (typiquement, des trucs comme PulseAudio). Les distribs ne vont pas développer et débugger tous les logiciels, elles ne font qu'assembler des briques. Si les briques sont mal foutues ou incompatibles, on ne peut pas blâmer les distrubutions...
Pour la lenteur des vieilles machines, j'ai toujours mis ça sur le compte du facteur psychologique, mais c'est vrai que je n'ai jamais pensé au vieillissement des composants.
[^] # Re: Elitisme
Posté par arnaudus . En réponse au journal Médailles Fields en vue. Évalué à 10.
OK, gros malentendu visiblement, tu n'as pas compris. C'est un CONCOURS. Le numerus clausus est fixé par le ministère sur la pression du conseil de l'Ordre des médecins. On prend les n premiers, quel que soit le niveau (avec un seuil d'admissibilité, mais vu la popularité du concours de médecine, ça n'a aucune importance).
Techniquement, non, justement, le barême est conçu de manière à étaler les notes dans la queue de la distribution, de manière à amplifier démesurément les différences aux alentours du seuil de sélection ; ça serait débile de couper en plein milieu de la Gaussienne, puisqu'il y aurait plein d'égalités et de conséquences dramatiques à la moindre erreur de correction.
La majorité des consultations en médecine générale ont pour cause un problème infectieux (angine, rhume, bronchite, gastro-entérite, mycose...) ou traumatique (cheville foulée). Comme tu le vois, en effet, la plupart de ces maladies sont incurables.
Tu voulais probablement dire "la plupart des maladies mortelles sont incurables". C'est indéniable.
Le reste de ton commentaire est incompréhensible. "On" fait plein de trucs, "Ils" ne font pas ce qu'il faut, Yaka faire des turcs, mais Faukon les fasse. Tu es certain que tu souhaites vraiment discuter d'un sujet dont tu n'as visiblement aucune idée?
[^] # Re: Elitisme
Posté par arnaudus . En réponse au journal Médailles Fields en vue. Évalué à 10.
En France, l'inscription en fac de médecine est conditonnée à un concours, pas un examen. On peut changer les coefficients des matières du concours autant qu'on veut, on n'aura pas plus de médecins! Et pour avoir enseigné les statistiques en prépa médecine, je peux affirmer que la sélection n'a rien à voir avec les performances en mathématiques. La sélection se fait sur la capacité à répéter les trucs faux ou inutiles qu'on a appris.
Par ailleurs, l'idée que les maths sont sur-représentées dans la formation des médecins est totalement fausse. 8 grandes matières sont représentées au concours : la chimie, la biologie, la physique, les biostatistiques, la physiologie, l'anatomie, la pharmacologie, les sciences sociales, plus une unité d'enseignement "médecine". Les biostats, seule discipline pouvant être comparée de loin avec un truc un peu mathématique, a un coefficient d'environ 2 (sur 26 en tout), soit moins de 10% de la note.
Donc, bon, cette légende de la sélection sur les maths, on peut se passer de la colporter.
[^] # Re: 0 A.D. sur Wikipédia, bandeau admissibilité ? :(
Posté par arnaudus . En réponse au journal Stunt Rally (course de voitures) réutilise les graphiques de 0.A.D (stratégie, antiquité). Évalué à 1.
Est-ce que tu contribuerais à un logiciel libre sans t'intéresser aux conventions de la communauté de développeurs? Si tu envoies un patch qui ne respecte pas les conventions de nommage et d'indentation, ni l'esprit du code, et que ta fonctionnalité ne correspond pas à l'idée que les développeurs se font du logiciel, alors ton patch sera rejeté. Ça n'est de la faute que d'une personne : toi.
En l'occurrence, Wikipédia a des règles strictes pour l'admissibilité des articles, qui sont justifiées par la nécessité de pouvoir écrire des articles encyclopédiques (et donc analytiques) sur la base de sources fiables, multiples, et indépendantes. Si tu ne peux pas démontrer l'existence de ces sources, alors l'article n'est pas admissible. Et contrairement à ce qu'on pourrait croire, je trouve que les critères d'admissibilité sont assez laxistes, il y a beaucoup d'articles qui ne sont pas basés sur des sources fiables.
Libre à toi de créer "Nimportequoipédia", de créer une communauté, et de te démerder avec les fiches bousiformes que tu y accumuleras sans relecture critique.
[^] # Re: Pas spécifique linux
Posté par arnaudus . En réponse au journal Les DRM dans HTML 5. Évalué à 4.
Il faut quand même avouer qu'il y a un vrai problème avec les DRM intérgrés dans des logiciels libres. Au delà des aspects éthiques, qui peuvent toujours être discutés, c'est techniquement totalement stupide d'envoyer les infos décryptées dans un logiciel libre. Pour que les DRM soient efficaces, il faut un contrôle intégral de la chaine logicielle et matérielle, de manière à ce que la seule capture possible soit analogique (filmer l'écran), puisqu'à moins de coller des puces DRM dans les yeux, c'est inévitable. Coller des DRM dans Firefox sous Linux, ça revient à encoder tes emails sur ton disque dur avant de les envoyer en clair par internet.
Soit les promoteurs des DRM ne l'ont pas compris (j'en doute), soit ils s'en foutent (mais des systèmes pour capturer la sortie décodée vont forcément devenir très populaires, et ça pourrait même encourager les gens à passer à Linux), soit c'est une stratégie élaborée pour écraser le logiciel libre (logiciel libre = piratage, etc). Le fait que le problème soit intrinsèquement lié à la nature du logiciel libre rend tout ça assez inquiétant. Monsieur Lobby DRM va aller voir les gouvernements, expliquer qu'il a trouvé un moyen pour se protéger des vilains pirates, mais qu'il existe des vilains logiciels de pirates pour ruiner ses légitimes efforts pour protéger sa propriété intellectuelle. Deux solutions, on interdit les logiciels libres (mais bon, ça va se voir), soit on l'exempte de proposer des solutions interopérables, et on lui fout la paix si ses trucs proprios ne sont disponibles que sous Windows 8.1.2.associé à un hardware verrouillé.
[^] # Re: chromium
Posté par arnaudus . En réponse au journal Les DRM dans HTML 5. Évalué à 10.
De manière générale, je déteste les liens vidéos vers des contenus informatifs. Je sais lire, et je sais lire beaucoup plus vite que les gens ne parlent. Je sais aussi lire en diagonale, et je suis capable de sauter à la fin d'un texte sans me taper les parties qui me saoulent. Je ne comprends pas l'intérêt de vidéos de mecs qui parlent.
[^] # Re: Contre-sens
Posté par arnaudus . En réponse au journal Bitcoin : plateforme d'échange illégale démantelée en France. Évalué à 6.
Tu n'as même pas lu le lien. Il s'agit de 3% de malwares. Rien à voir avec la légalité du trafic.
Ouais, évidemment. Tor est simple, rapide, et pas du tout contraignant.
Une connexion cryptée, c'est un échange d'infos confidentielles entre deux interlocuteurs de confiance. Tor c'est principalement pour cacher sa véritable identité à son destinataire. Ça n'a rien à voir.
Ah ouais, c'est super-pratique d'avoir un portefeuille qui vaut 300€ le lundi, 800€ le mardi, et 50€ le mercredi. Avec des frais de l'ordre de 10% (cf les tarifs de la Maison du Bitcoin) pour convertir tes vrais sous en Bt. Nan nan, y'a pas à dire, c'est super pratique.
Internet -> login/passwd -> virement international -> montant, date -> valider. Ça marche pour la plupart des pays, avec des frais de change largement comparables au Bt.
Pour les grosses transactions, il faut parfois remplir un formulaire pour justifier auprès des douanes pourquoi tu verses autant. C'est ça le problème?
Et pour les transactions vers le Zimbabwe du sud, ça peut être plus compliqué, oui. D'ailleurs, tout le monde fait des transferts vers des pays dont on ne connait pas le nom tous les jours.
Donc ouais, des vrais arguments, il y en a? L'idée de l'ami qui achètes des timbres à 0.50€ trois fois par semaine dans des pays improbables, j'ai du mal à trouver ça pertinent.
[^] # Re: Contre-sens
Posté par arnaudus . En réponse au journal Bitcoin : plateforme d'échange illégale démantelée en France. Évalué à 10.
Ah non, c'est pas mieux du tout. C'est même complètement catastrophique : ça coupe la consommation, ça encourage à l'échange de services non-monétarisés (donc au travail au noir), ça pousse à une diminution des prix et des salaires, ça encourage l'épargne aux dépens de l'investissement, et ça coupe complètement le robinet du crédit. D'où déflation, récession, chômage, avec une possibilité non-négligeable de retour au moyen-âge.
Alors oui, c'est bien si on a treize ans et qu'on est nihiliste. Dans ce milieu, il court l'idée saugrenue que les gens qui contrôlent et réglementent la finance et les banques centrale sont des imbéciles apprentis sorciers. Par contre, par un raisonnement qui m'échappe totalement, les gens qui inventeraient dans leur garage un système monétaire parasite, sans contrôle, et économiquement absurde, seraient des bienfaiteurs humanistes.
Il aurait été parfaitement possible de concevoir le Bt de manière à ce que la création de Bt soit proportionnelle au volume de transactions. Sauf qu'il a été décidé que le Bt devait être une ressource limitée, et que les concepteurs et leurs copains se réservaient une partie significative que la richesse globale représentée par les Bt. C'est une escroquerie cachée derrière un algorithme intéressant, une vraie prouesse intellectuelle orientée vers l'enrichissement personnel d'un seul homme et de son entourage, prouesse d'autant plus intéressante qu'elle n'est pas ostensiblement illégale. Ce n'est pas une pyramide de Ponzi, c'est une "pyramide de Nakamoto", un montage astucieux, quelque part entre les produits pourris de la finance qui ont récemment plongé le monde dans le chaos économique, et les systèmes pyramidaux où l'enrichissement des fondateurs est assuré par la cupidité des derniers entrés.
[^] # Re: Contre-sens
Posté par arnaudus . En réponse au journal Bitcoin : plateforme d'échange illégale démantelée en France. Évalué à 8.
Non. C'est la conception déflationniste du Bt qui lui permet de prendre de la valeur. Le seul ancrage du Bt dans la réalité est le coût du minage (électricité, matériel, bande passante, etc). Par conception, ce coût augmente (beaucoup). Bt est donc conçu pour augmenter, c'est mécanique.
Et au contraire, c'est la pénurie de Bt circulants qui favorise la spéculation. Obtenir des Bt est difficile, donc cher.
Certes, c'est un objet spéculatif très volatil. Mais il est conçu pour être déflationniste et rare. Il est aussi conçu pour rendre ses concepteurs 1000 fois plus riches que Bill Gates en cas de succès. Bref, il est conçu pour prendre de la valeur.
Non, rien ne t'en empêche, à part un raisonnement rationnel. Non seulement c'est coûteux, mais c'est aussi stupide en terme d'investissement. Mieux vaut continuer d'utiliser une monnaie contrôlée par une banque centrale (inflationniste) pour les transactions quotidiennes, et stockers les Bt (déflationnistes) pour spéculer.
En excluant les problèmes financiers (qui t'obligent évidemment à liquider tes placements) ou les raisons fiscales ou matérielles, oui, on peut essayer des martingales pour maximiser son profit en anticipant les risques. Si tu as acheté 1000 Bt pour 1000€ il y a deux ans, tu peux revendre 100 Bt à 1000€ pièce maintenant : ça te fait 99 000€ de bénéfice net, et un potentiel démentiel de profit futur. Liquider tous ses Bt maintenant? Pourquoi pas, mais ça me semble correspondre à aucune stratégie rationnelle. Ceci dit, rien n'est rationnel avec le Bt.
# Contre-sens
Posté par arnaudus . En réponse au journal Bitcoin : plateforme d'échange illégale démantelée en France. Évalué à 4.
D'après ce que j'ai compris en lisant la presse en ligne, ce n'est pas l'activité Bitcoin qui est en cause, c'est juste qu'il s'agit d'une sorte d'escroquerie qui utilisait entre autres des Bt.
OK, donc les Bitcoins peuvent servir à des activités illégales? Super. Bientôt, on va s'apercevoir que Tor héberge des activités criminelles. Ouhlala!
Personnellement, je n'arrive pas à comprendre comment on peut avoir peur du contrôle des États au point de vanter les mérites de systèmes qui permettent à n'importe qui (y compris à des gens pas très recommandables) d'échapper, justement, au contrôle des États. Il y a probablement 1000 pédophiles pour un opposant chinois sur Tor. En ce qui concerne les Bitcoins, c'est peut-être moins tranché, mais il y a certainement une très grosse majorité des gens qui ne sont pas réellement utilisateur (qui utilisent les Bt simplement comme un support de spéculation). Franchement, vu l'évolution des taux de change du Bt, qui s'amuserait à effectuer des payements en Bt? Il faut être complètement dingue ; avoir un portefeuille de Bt offre la possibilité de multiplier sa valeur par 1000 en quelques années, il faut être profondément c*** pour acheter des oeufs ou des DVD avec! J'imagine que la plupart des transactions (en volume) sont donc motivées par l'absence de traçabilité. Et il ne doit pas avoir beaucoup d'activités légales qui justifient de devoir perdre des possibilités de spéculation aussi gigantesques...
En tout cas, si les Bt saisis par la justice sont systématiquement détruits, il va bientôt falloir compter en nanoBt, parce qu'il ne va plus y avoir beaucoup de Bt sur le marché!
[^] # Re: Délais
Posté par arnaudus . En réponse au journal Les Pays-Bas inventent le DDOS sur les services administratifs. Évalué à 5.
Il est d'ailleurs d'autant plus regrettable que d'après l'article, la loi va être totalement abrogée, alors qu'elle partait d'une bonne intention. Sa mise en place a juste été débile. Il aurait suffi d'un portail Internet auquel on s'identifiait (avec par exemple un numéro de sécu) pour juguler le problème : non seulement on pourrait facilement repérer les comptes dont l'activité n'a rien à voir avec une demande légitime (et donc saisir un juge pour "abus de droit" ou équivalent), mais en plus on aurait pu mettre en place des bases de connaissance accessibles aux citoyens, ce qui aurait évité de devoir répondre plusieurs fois aux mêmes questions. Par exemple, pour l'histoire des caméras de vidéosurveillance, si on entre une fois les coordonnées GPS dans le système, on n'a plus à répondre aux questions.
Les pays du Nord passent souvent pour des pragmatiques, mais il semble que les députés néerlandais ont vraiment ruiné une bonne idée avec leur truc. L'article explique même que certaines demandes étaient cachées (par exemple, dans un devis ou une candidature spontannée), ce qui suppose qu'il n'y avait même pas besoin de remplir un formulaire spécifique! C'est profondément crétin ; s'il peut y avoir un dédommagement financier, on peut s'attendre à avoir un minimum de procédures à respecter!
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Comme tous les langages, R a une bibliothèque standard—qu'elle soit implémentée en C, en Fortran, en assembleur, ou en javascript ne change pas.
L'objectif n'est pas de comparer des trucs sur une base idéologique, c'est de déterminer en pratique si un langage est adapté au développement de telle ou telle application. Seule une minorité d'applications ont un temps d'exécution critique : pour un uptime de 9 jours sur mon PC de bureau, seules 19 applications (sur 267) ont pris plus de 30 s de temps CPU (soit 0.13s par heure!). Et je suis certain que pour toutes ces applications, seuls quelques % du code sont réellement concernés. Seule une fraction de pourcent des millions de lignes de code que j'utilise au quotidien sur ma machine mérite d'être rapide, le reste pourait être codé en visual Basic que je ne verrais pas la différence.
Je maintiens donc que C est très largement sur-utilisé. C'est un outil très technique, indispensable dans certains domaines, mais son utilisation systématique par le commun des développeur n'est pas justifié. Évidemment, s'ils tombent systématiquement sur des gens qui leur disent que C est une sorte de graal qui tend vers l'optimalité, ou qu'on n'est pas un vrai développeur si on ne code pas en C, on ne va pas sortir de cette situation.
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3.
Je sais bien, mais c'est le benchmark initial qui était complètement stupide, je n'ai fait que suivre les instructions! (calculer 500 fois la somme des 1/n2 pour n = 1 à 10000).
Du coup, un bon compilo s'apercevrait qu'on ne fait rien, je pense, et le test concerne tout autant le langage que le compilateur.
Le code initial en R incluait une double boucle, comme si c'était du C. Du coup, R mettait 3h à faire ce calcul stupide, ce qui n'est pas étonnant. Ce que j'ai essayé de montrer, c'est que ça n'était pas de la faute de R, mais du programmeur. Codé correctement, cet algo stupide est tout aussi rapide que du C.
Après, il existe forcément des algorithmes pour lesquels R est beaucoup plus lent que C. C'est évident, c'est un langage interprété. Mais il existe aussi de nombreux cas où en pratique R sera plus rapide que le code C, parce qu'il appelle des routines optimisées. Je ne connais pas les rouages internes de R, mais il est très efficace pour les opérations vectorisées (apply, lapply, sapply, etc), et ça ne m'étonnerait pas qu'il implémente des optimisations de bas niveau pour ça. Il est aussi diaboliquement bon pour des casse-têtes algorithmiques (par exemple tirer au hasard des éléments d'un vecteur avec ou sans remise avec pondération, avec une vitesse que je n'ai jamais réussi à approximer en C++).
Encore une fois, les langages sont tous Turing compplets, on peut tout faire avec n'importe quoi. Mais il est malsain de penser que de tout coder en C montre qu'on est un programmeur balèze. Ça montre juste qu'on est un programmeur qui ne connait que le C :)
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3. Dernière modification le 03 juillet 2014 à 14:36.
Sérieux, tu n'arrives pas à lire quelque chose comme:
replicate(500, sum(1/((1:10000)^2))?Là c'est vraiment une question d'habitude, pour moi c'est vraiment limpide. Il y a des trucs en R qui sont vraiment illisibles (notamment à cause de l'accumulation de parenthèses), mais je parse très bien cette ligne.
Il n'est pas si malin que ça. Si on remplace 500 par 500000, ça prend 0.45 sec. Le vrai temps est donc autour de 0.004s, certainement trop court pour être mesuré efficacement avec system.time.
[^] # Re: Encore des pleurnichards ....
Posté par arnaudus . En réponse au journal Que pensez-vous de cette citation de Axelle LEMAIRE ?. Évalué à 2.
Hors matières premières? C'est clair qu'il est impossible de prendre en compte les charges et les investissements dans le calcul, mais un assembleur qui achète des carte-mères à 50,ドル des proc à 50,ドル et des boitiers à 20,ドル a-t-il le droit de vendre les PC assemblés à 100€ hors des périodes de solde?
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
C'est loin d'être vrai. Il suffit de comparer des opérations comparables (cf un de mes anciens commentaires sur un benchmark où R se gamellait, et où j'avais réussi en codant selon les paradigmes du langage à réduire le temps d'exécution de 7 secondes à 0.00 (sic) seconde : http://linuxfr.org/news/version-1-0-de-julia#comment-1327186).
C'est clair, si tu implémentes un algo de tri en perl, il va être 10 fois moins rapide qu'en C. Mais ce n'est pas comme ça qu'on fait un tri en perl, c'est tout.
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 6.
Toutafé. En bio-informatique par exemple, il est très courant d'employer des langages interprétés (principalement R et python) même pour les algorithmes critiques. Évidemment, c'est en partie attribuable au fait que les gens ne sont pas nécessairement développeurs de profession et que ces langages sont plus accessibles, mais c'est aussi lié au fait que (contrairement à ce qu'on peut souvent entendre), ces langages ne sont pas si lents que ça en pratique, car la très très grande majorité des algorithmes consiste à assembler des briques déja optimisées : du tri, des expressions régulières, des sommes, des opérations sur des matrices, etc. Si on ajoute la compilation just-in-time et la parallelisation relativement accessible, on se situe dans des domaines de performance qui sont du même ordre de grandeur que les langages compilés traditionnels, pour un temps de développement très inférieur.
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 6.
Le meilleur langage est celui que tu connais, mais il y a des limites.
Les exemples auxquels je pense, c'est par exemple des applis essentiellement basées sur des GUI. Imagine par exemple un truc qui édite des fichiers de config. Tu crées un clicodrome, il n'y a pas de calcul ou d'algorithme particulier. Dans ce cas, tu te vois gérer la mémoire, détuire les pointeurs vers les widgets au fur et à mesure de leur fermeture, etc? Tu n'as aucune contrainte de temps d'exécution, 99% du temps cpu va être consacré à l'affichage des éléments qui sont appelés par une bibliothèque (qui elle pourra être en C).
Un autre exemple (celui auquel je pensais, en fait) sont tous ces jeux de stratégie, type implémentation de jeux de plateaux ou jeux de rôle. Au niveau algo et calcul, il y a que dalle, c'est juste de l'interface autour d'un moteur de jeu. J'ai contribué parfois à ces trucs, en plus, souvent, c'est "Dédé apprend à programmer", c'est plein de segfaults et de pointeurs tout nus qui se balladent partout, les tableaux sont initialisés avec des dimensions constantes (souvent plusieurs millions de cases, hein, faut voir grand), etc.
Justement, raison de plus pour ne pas s'emm* avec ces langages proches de la machine, qui n'ont d'utilité réelle que dans une minorité de cas. Et surtout si on n'est pas développeur de formation et de profession. Personnellement, je vois C comme un outil spécialisé, pour des développeurs système ou embarqué, ou réservés à des cas très particuliers. Pour coder un truc avec une GUI et trois algos triviaux, il me parait beaucoup plus censé de démarrer sur un langage de script (python? ruby?) plutôt que de se demander si on ne va pas avoir un jour besoin de faire de la logique bitwise.
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3.
Oui, mais c'est ce qui s'appelle l'"abstraction". La question centrale est celle des contraintes du langage, est-ce qu'un langage doit représenter la manière dont la machine fonctionne, ou est-ce que le langage doit fournir des outils pour implémenter formellement ce que le programmeur pense? Bon, en plus, tout ça est proche de la machine, il faut avoir en tête les différences entre les architectures, ça me parait être une complexité dingue pour une histoire de trois nombres entre 0 et 255.
D'une manière plus spécifique, oui, il me paraitrait évident de manipuler du bit de couleur dans Gimp. Dans un émulateur de terminal, je ne vois pas. La manière "correcte" de traiter les couleurs dans ce contexte est, à mon avis, de créer un objet qui contient trois variables de la bonne taille, avec une méthode d'import (qui elle peut éventuellement tripoter les bits—ce n'est pas sale), et des méthodes d'export. Si un émulateur de terminal passe plus de 0.01% de son temps à jouer avec les couleurs, c'est certainement qu'il y a un problème dans l'émulateur, et pas dans l'optimisation de la fonction qui gère les couleurs.
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Tu fais pas :-) Dans un langage évolué, tu structures tes variables de manière à ce que leur sémantique ne soit pas cryptique :-)
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 6.
Peut-être n'existe-t-il pas une relation divine entre le langage et la performance d'un logiciel?
Ce que je trouve amusant, c'est que dès qu'on discute performance, il semble que tous les développeurs bossent sur de l'embarqué, des drivers de carte graphique, ou sur le noyau. Mais ce développement là représente quoi, en vrai? Quelle proportion des logiciels qu'on utilise tous les jours a besoin des quelques % de différence de temps d'exécution entre C et C++? Le noyau, le serveur X, et puis heuuu... Ça serait débile de croire que si LibreOffice est poussif, c'est parce qu'il n'est pas codé en C.
Si tu fais un tour sur un dépôt de logiciels libres et que tu regardes les langages, tu t'apercevras que 90% (au pifomètre rouillé) des projets en C n'ont absolument aucune raison d'être en C.
[^] # Re: Encore des pleurnichards ....
Posté par arnaudus . En réponse au journal Que pensez-vous de cette citation de Axelle LEMAIRE ?. Évalué à 6.
Bah oui, mais c'est la différence entre une entreprise et un salarié. Une entreprise peut facturer au temps ou au forfait, un salarié loue sa force de travail. Ça permet par exemple de payer les gens même quand ils font un travail inutile pour la boite (par exemple, un projet qui sera finalement abandonné) : les salariés ne facturent pas à leur entreprise.
Le développement de la micro-entreprise et de l'auto-entreprenariat pose de vrais problèmes qu'on ne peut pas écarter d'un simple revers de la main avec un argument libéral. En particulier, il se pose le problème du dumping. Une entreprise n'a pas le droit de vendre à perte, mais un autoentrepreneur a le droit de facturer des services à perte (par exemple, sous le salaire minimum). Il est évident que beaucoup d'autoentrepreneurs font un tel dumping, rien que pour conserver leur entreprise en vie dans l'espoir d'un démarrage ultérieur.
[^] # Re: Encore des pleurnichards ....
Posté par arnaudus . En réponse au journal Que pensez-vous de cette citation de Axelle LEMAIRE ?. Évalué à 10.
Ce qu'il y a de "mal", c'est que ça remet en cause le modèle économique de la profession. Je ne suis pas en train de comparer les devis de deux entreprises, là. Quand on met en concurrence deux boites, on va comparer les prestations proposées à ce qu'on souhaite, et dans les deux cas, on s'attend à ce que le travail soit de qualité professionnelle.
Là, on parle carrément de mettre en concurrence un système qui nie complètement le principe du droit du travail. Tu as affaire (au mieux) à des autoentrepreneurs plus ou moins légaux, voire carrément à du travail au noir pas du tout déclaré. Le travail se fait à l'arrache, dans des conditions absolument pas contrôlées (horaires journaliers?), payé à la tâche, sans salaire minimum.
Pour moi, l'équivalent, ça serait un grand hôlel qui file de temps en temps un balai et 5€ à un SDF pour mettre un coup dans l'arrière-cour, plutôt que d'embaucher une personne pour ça. Qu'est-ce que tu t'en fous d'avoir un balayeur professionnel? Tu es content, le SDF est content, où est le mal? Le mal, c'est que dans notre société, le travail a un coût et doit s'effectuer en respectant des règles. Ce coût peut être supérieur à la valeur que tu associes au travail, mais tu dois supporter cette différence par respect pour les personnes qui travaillent. C'est certes une logique non-libérale, mais le libéralisme seul ne peut pas définir l'éthique de nos sociétés (en tout cas, la plupart des européens semblent le voir comme ça).
[^] # Re: Encore des pleurnichards ....
Posté par arnaudus . En réponse au journal Que pensez-vous de cette citation de Axelle LEMAIRE ?. Évalué à 10.
Non, mais ça pose un vrai problème en fait : c'est le prix de l'expertise et du travail.
On vit dans un monde paradoxal où le chômage est rampant, mais où on veut garder des salaires raisonnables. Le problème n'est pas seulement la délocalisation des services, c'est simplement le prix que l'on veut bien mettre dans le travail d'une personne.
Le développement est un bon exemple. Tu as besoin de développer une fonctionnalité pour un programme existant. Combien ça peut te coûter de le faire faire dans les règles de l'art? Très cher, probablement. Des dizaines de milliers d'euros, même pour un truc qui ne parait pas hors de portée (une personne.mois, un truc comme ça). Combien ça va te coûter de le faire à l'arrache, avec un stagiaire, ou avec une offre dématérialisée sur Internet? Probablement 10 fois moins cher. Évidemment, la prestation sera de moins bonne qualité. Mais là n'est pas la question, parce que tu n'avais peut-être pas besoin qu'elle soit spécifiquement de qualité supérieure. Tu voulais juste avoir quelque chose de plus ou moins fonctionnel pour pas cher.
Avec la montée du chômage et la démocratisation des connaissances via internet, les experts ne sont plus compétitifs pour les trucs triviaux. Un exemple idiot, ta machine à laver ne fonctionne plus. Si tu es une personne âgée, tu vas appeler un réparateur. Si tu as un ordinateur, tu vas taper le nom de la machine, explorer les forums, te faire une idée de la panne, et tenter de dépanner toi-même. La moitié du temps, ça va fonctionner (évidemment, l'autre moitié, non, mais ça n'est pas la question). Au pire, tu vas trouver un bricolo du dimanche qui y connait un peu plus que toi et qui va te dépatouiller sur une partie des cas restants. Bref, tu cantonnes l'expert professionnel qui bosse selon les règles de l'art aux cas les plus complexes. Son expertise a encore de la valeur, évidemment : le jour où tu veux un travail bien fait, tu payeras. Mais dans notre monde où tout est jetable, où les entreprises ne cherchent plus à durer 40 ans, où personne dans une entreprise se souhaite y rester plus que quelques années, qui se soucie réellement que le boulot soit fait par les meilleurs experts? Qui est prêt à payer 10 fois ou 100 fois plus cher pour un service qui est, quoi, 2 ou 3 fois meilleur, avec souvent des délais plus longs ou des contraintes légales qui n'existent pas pour les services à l'arrache? Il n'y a plus que quelques professionnels que tu acceptes de payer plus que ce que tu es payé, parce qu'il y a des impératifs de sécurité qui nécessitent une qualité irréprochable : les médecins, les avocats, les architectes, les notaires, et éventuellement les garagistes. Pour le reste, on vit très bien avec l'imperfection.
[^] # Re: suckless !! More is less !
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 9.
Mouais.
1) Je ne vois pas l'avantage de coder des applications non-système en C. Pourquoi pas en assembleur, tant qu'on y est? C'est sûr, C permet de faire des trucs comme
#define TRUERED(x) (((x) & 0xff0000) >> 8). Ça marche pour draguer?2) Il n'y a pas nécessairement de rapport entre le nombre de lignes de code et l'efficacité ou la facilité de maintenance. Par exemple, pour st, on se retrouve avec un fichier st.c de 4000 lignes, et des centaines de fonction dedans. À part pour l'exploit de faire tenir un émulateur de terminal dans un fichier, c'est quoi l'intérêt?
3) L'exploit a un coût. Par exemple, le texte qui s'affiche quand on lance "st -h" est codé en dur. Du coup, quand on change une option, il faut modifier le code, et modifier le texte en dur. Il existe probablement des dizaines de bibliothèques qui permettent d'automatiser ça; beaucoup d'entre elles sont d'ailleurs seulement dans un .h et ne nécessitent pas de dépendance externes, elles peuvent juste être #include-ées.
Bref, l'exploit est intéressant en tant que tel, mais il est peut-être raisonnable de trouver un juste milieu. Les buffer overflow dans les applis météos parce qu'un geek a imaginé qu'il savait faire du C, ça va deux secondes, mais je préfère quand les gens utilisent des langages adaptés.
[^] # Re: Loi de Wirth
Posté par arnaudus . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Ouuhhh, j'en connais qui vont parler de systemd :-)
Par rapport à DOS, c'est compliqué, mais par rapport à Windows, je trouve que depuis quelques années les distributions Linux ont fait beaucoup de progrès au niveau du temps de démarrage. Ce n'est pas instantané, certes, mais c'est très acceptable. Mon PC de boulot met plus de temps à lancer le bios et les trucs matériels que de démarrer le noyau et le serveur graphique. En gros, ça met autant de temps à lancer le système qu'à lancer libre office, c'est quand même notable.
La lourdeur des distributions, c'est autre chose. Les stratégies "à la Ubuntu", avec un bureau qui se comporte comme une surcouche à un système complet, sont évidemment à remettre en cause. D'une manière générale, un OS est un gros truc complexe, et à moins de disposer d'une puissance de développement extraordinaire, on est souvent obligé d'accumuler des couches pas bien conçues pour que ça marche (typiquement, des trucs comme PulseAudio). Les distribs ne vont pas développer et débugger tous les logiciels, elles ne font qu'assembler des briques. Si les briques sont mal foutues ou incompatibles, on ne peut pas blâmer les distrubutions...
Pour la lenteur des vieilles machines, j'ai toujours mis ça sur le compte du facteur psychologique, mais c'est vrai que je n'ai jamais pensé au vieillissement des composants.