lasher a écrit 2753 commentaires

Avant que certains opérateurs ADSL et mobiles (au moins Free, mais peut-être d'autres) ne commencent à faire des prix réellement moins chers, il y avait clairement une sorte d'entente sur les prix (et Orange/SFR/Bouygues ont été condamnés, avec une tape sur la main justement à cause de ça). Pendant le début des années 2000, l'oligopole Orange/SFR/Bouygues n'offrait quasiment rien de différent pour leurs forfaits (seuls les terminaux vendus avec ces derniers pouvaient vaguement différer). Et de manière générale, pour couvrir tout le territoire français, tout le monde n'a pas les sous pour assurer le service requis, ce qui rend un oligopole ou un monopole quasi-obligatoire (dans le cas de la téléphonie mobile au moins, et même quelque part dans le cas des FAI: mis à part SFR, Orange, Bouygues et Free, il reste qui ? FDN ? Ouais, à la limite).

Et tous ces trucs s'opèrent dans le petit monde des hautes technologies. Dans le monde de la santé, c'est un tout autre problème. Oui, je vais parler des USA parce que c'est ce que je connais de mieux, mais à cause des collusions entre hôpitaux (même publics, mais gérés « comme une entreprise ») et les intérêts privés (industries pharmaceutiques, etc.), certains produits sont facturés quelques centaines de dollars là où en France ça coûterait 5€. Je n'arrive pas à retrouver le lien, mais dès que je mets la main dessus, je le posterai ici.

Je paie ~115$ / mois en mutuelle santé, ce qui n'est pas cher du tout. Si je vais voir un généraliste, je vais payer ~100$. Si j'avais pas de mutuelle, ce serait ~300$. Je ne parle même pas d'un spécialiste. Wouhou. À côté de ça quand j'étais en France et que je cotisais, je payais … rien. En gros, j'ai une assurance maladie « moyenne ». L'effet pervers de l'assurance privée à l'américaine se situe à ce niveau : si jamais je quitte la fac où je bosse pour devenir ingé dans une boite, il y a de fortes chances que :

1. Je puisse enfin « cotiser » (401K) pour ma retraite
2. Ma boite me propose de payer une mutuelle directement, qui sera bien meilleure que celle que j'ai en ce moment. Résultat: je paierais sans doute rien pour voir un généraliste.

Bref : plus t'es bien payé aux USA, plus les avantages en nature sont bien aussi. Sauf que tout le monde n'est pas ingénieur, et tout le monde ne gagne pas ~100-150k$ / an.

Je te laisse regarder cette interview de Rand Paul au Daily Show. Reviens ensuite nous expliquer en quoi des assurances privées vont nous optimiser tout ça.

Pourtant perl était un bon exemple à ne pas reproduire.

Bon je suppose que c'est juste un bel appeau à troll (on est trolldi après tout). Mais bon, j'en ai un peu marre des gens qui disent que Perl c'est pas lisible.

1. Perl n'est pas lisible uniquement si on n'écrit pas lisiblement. Comme C, comme C++, comme OCaml.
2. Perl a une syntaxe et un vocabulaire. Un langage ou une langue, ça s'apprend. Sinon, perso je trouve que le Roumain, c'est pas lisible. En même temps, j'ai jamais cherché à apprendre la langue. Mais bon, ça s'écrit avec des caractères latins, c'est donc que ça doit être sensiblement pareil que le Français, non ?

Oui, il y a quelques symboles particuliers à connaître en Perl, en particulier $_ (variable utilisée par défaut dans lors de l'itération sur une collection ou lors de la lecture d'un fichier), @_ (tableau des paramètres passés à une fonction), $! (errno), $(résultat d'une évaluation avec les backticks), $@ (erreur au retour de l'appel àeval) et pour certains cas très particuliers lors de traitements d'entrées/sorties$/` (séparateur de ligne, "\n" par défaut), et $| (E/S bufferisées ou pas). Il y en a plein d'autres. Mais perso je ne les utilise pas, et je les vois rarement employés.

Pire: en tant qu'utilisateur de bibliothèques/modules Perl, les modules eux-même font souvent usage de plein de symboles, mais le code utilisateur lui se conte de bêtes my $instance = MON::MODULE->new(...); $instance->ma_methode(...);

Bref, laissez mon Perl tranquille !

Le bouquin est utilisable par quiconque connaît déjà le C standard. Donc en gros, si on sait « à peu près » ce qu'est un pointeur, on peut lire ce bouquin. Je considère que ce bouquin est légèrement en-dessous du niveau de ceux de Stevens, avec des parties clairement spécifiques à Linux (même si la plupart du temps, on parle d'appels POSIX). Quelque part, je suppose qu'on pourrait le considérer comme une version « résumée » des UNIX programming (IPC+Network).

Je trouve que son vrai avantage est qu'il est relativement complet (il explique même comment écrire des paquets IP en mode « raw » dans un passage), et écrit par et pour un francophone. J'étais en 2è année d'IUT quand j'ai lu une partie de ce bouquin, et avec mon expérience limitée en C, c'était suffisant pour réaliser mon projet à l'époque.

Tu me parles de LaTex, mais il y a aussi Libreoffice, Firefox, etc …

Je crois que tu es sur quelque chose de grave là. Après tout, si le firewall libreoffice n'est pas à jour…

Mince, j'avais pas vu ton commentaire… Désolé du doublon. :)

C'est surtout qu'une guerre ouverte (façon GM1 ou GM2) c'est « facile » d'entraîner des soldats pour la mener, surtout si une partie de la population locale aide les soldats. Dès qu'il s'agit d'envahir un pays qui est globalement hostile, ou en tout cas hostile à l'idée que l'armée doit rester sur place une fois qu'elle a destitué la « menace » / l'armée d'occupation / le dictateur / etc., ça se corse. Exemples : Vietnam, Irak (arrivée à Bagdad sans problème; trouver Hussein, sans problème; rester pour démanteler l'armée locale: ça devient de la guerrilla…).

Pour la mixité sociale, et le mélange bourgeois-prolo, je demande à voir. Le petit bourgeois (qui sans doute avait déjà des contacts sporadiques avec le prolo), peut-être. Les autres arrivaient à être placés directement en gradés, dans des bureaux, etc., bref ils n'échappaient pas forcément à tout ce qui était entraînement etc, mais par contre ils restaient « au-dessus » de la populace (en termes de traitement, de grade, d'environnement de vie, etc.).

[…] certains jeux linux comme Braid ne marchaient pas.

cmcm © (chez moi ça marchait)

Et lorsque j'avais eu un problème avec l'un des jeux (je ne sais plus lequel) à l'époque, on m'avait redirigé vers la bonne personne, qui m'avait fourni un moyen de corriger ça (une histoire de version 64 bits qui ne marchait pas mais 32 bits + compat oui).

Non je parle bien de résultats allant au-delà d'un epsilon de différence. J'admets que la façon de remplir mes vecteurs était sans doute un peu extrême et que dans un cas « réel » les différences entre exposants ne serait sans doute pas aussi marquées. Cependant la différence entre une réduction séquentielle et parallèle peut être extrêmement grande en fonction de l'implémentation.

Sauf que les micro-archi « core » (Core, Core 2, Nehalem, Sandy Bridge, Ivy Bridge) ont justement été créées parce que l'approche P4 ça marchait pas, et ça consommait comme un malade en énergie.

Bon, le problème de la vitesse de la mémoire qui croît linéairement alors que la capacité de calcul d'un processeur double tous les 18 mois n'est pas nouveau (c'était déjà un problème pour les systèmes SMP à la fin des années 90).

Tu es sûr de toi pour le CPU généraliste qui est aussi performant énergétiquement ? Entre le prédicteur de branchement, les 4-8Mio de cache L3, les 512-1Mio de cache L2 (en cumulé), les systèmes de prefetching automatiques, le moteur OoO… Une instruction en elle-même peut coûter « autant » dans les deux cas, mais le processus de fetch/decode/execute/mem/wb est clairement différent, et idem pour la mémoire sur la puce.

Tu as combien de RAM? J'ai un processeur de course (Core i7@2.8GHz, 2 cœurs/4 threads), et 4Gio de RAM. Tout fonctionne impec. J'ai aussi un GPU intégré par Intel. Ce que je me dis, c'est que mon PC a un an, et que dans ~2-3 ans, ce genre de puissance sera clairement accessible pour des objets « mobiles » (tablette/portable).

Le benchmark me donne ~24 fps en 1366×768 (plein écran).

À l'époque j'avais demandé à Emmanuel où il en était du portage, et sa réponse était globalement « personne n'a répondu qu'il était intéressé, alors j'ai lâché l'affaire. »

Lingua::Romana::Perligata—Perl for the XXI-imum Century est ton amie.

Ne pas confondre en français « standard » et « norme ». Le premier implique plus ou moins « de fait » implicitement, alors que le dernier implique une concertation par comité (on dit norme POSIX, pas standard POSIX, même si certaines API ont tendance à avoir été un standard avant, par exemple l'API pour les sockets).

$EDITOR SayLeBien.pm

# SayLeBien.pm
package SayLeBien;
use v5.14;
use strict;
use warnings;

sub new {
    my ($class,$self) = @_;
    $self->{praise} = "Perl, say le Bien!" unless $self->{praise};
    bless $self,$class;
}

sub tell_it_how_it_is {
    my $self = shift;
    say $self->{praise};
}

sub set_praise {
    my $self = shift;
    $self->{praise} = shift;
}

1; # End of SayLeBien

perl -I. -MSayLeBien -e 'SayLeBien->new->tell_it_how_it_is'

Mes parents ont eu 2 Lada il y a loooongtemps (fin des années 80/début 90). La première était pas géniale (porte arrière qui coince, entre autres). La deuxième était certes moche, mais fonctionnelle. Aucun problème à signaler. Accessoirement, les Lada pour les lambda (ha, ha) étaient bof, mais les machins qu'ils faisaient pour le tout-terrain gagnaient régulièrement des prix (4×4, etc.).

Donc Lada by BMW ? Oui, complètement.

Que le caissier ne sache pas répondre à la question, c'est normal. Que son chef (ou le chef du chef …) ne sache pas non plus, je trouverais ça assez ridicule.

Pour le HW, ben faut quand meme se demander pourquoi ils ont suivi Mozilla et pas Ubuntu…

T'es sûr que c'est pas « juste » parce que Mozilla/Firefox c'est une marque connue de tous (car ils ont réussi à s'implanter aussi sur les desktops Windows et Mac OS), alors que Ubuntu pas trop ? C'est peut-être ce que tu sous-entendais, mais mal alors. :-)

OK, je précise :

1. Oui dans les manuels Intel, on a des mots de 16 bits, des double-mots de 32 bits, etc. C'est une terminologie propre à Intel à cause l'ISA qui doit respecter la compatibilité ascendante. Du coup oui, on a des addl, addq générés par défaut pour (par exemple) les architectures x86_64. Dans le contexte du « vocabulaire » d'Intel c'est complètement logique.
2. Quand « je » parle de mots de n bits, je parle de la taille des mots utilisés « par défaut » par l'architecture. Donc certes l'archi x86_64 sait adresser sur des mots de taille 16 bits, mais ce n'est pas la taille « normale » d'un mot sur cette architecture en pratique (je ne sais pas si ma distinction est claire).

Et du coup, Qt réinvente les conteneurs standards […]

Ce n'est pas bêtement dû au fait que la STL n'était pas présente à l'époque et qu'une fois que tu as tes propres conteneurs avec une certaine sémantique, c'est très chiant de tout recoder ?

[…] et n'utilise pas les exceptions

Oui alors ça, c'est un argument assez faible je trouve. Doom 3 n'utilise pas les exceptions non plus…

J'utilise uint*_t lorsque je programme aussi. Mais je parle aussi de « mot de X bits », parce que c'est l'expression « correcte » pour décrire combien de bits sont manipulés à la fois. :) Du coup « byte » vaut TOUJOURS 8 bits dans notre contexte (vu qu'on utilise le terme « mot » sinon), ce qui arrange les choses.

Ce n'est pas ce qu'il voulait dire je pense. Que ce soit en Anglais ou en Français, pour parler de la taille unitaire des données manipulables par un micro-processeur, on parle de « mot de n bits ». Sur un DSP, que le proc travaille sur des mots de 16 ou 32 bits est extrêmement courant. Sur un PC, les mots de 32 ou 64 bits sont la norme; etc.