et vient pas me dire : dégats => faut réparer => d'où manque de moyens ;-)
Et si on dit
dégats => scandale/mépris de la population plus agées => "les jeunes c'est tous des cons qui respectent rien de toute façon, de mon temps c'était autre chose" => devinez où on va faire les prochainnes coupes budgetaires => Tiens pendant qu'on y est si on fermait aussi la recherche en France => Baisse d'impots pour les consomateurs votants de moins de 60 ans (mais plus de 25 quand même)
mais est-ce qu'il faut pas un jour se dire, c'est bon, on touche plus aux changements internes, et on dit que cette version est stable ? Quand est-ce qu'on décide ça ?
C'est ce qu'on appelle le "Freeze". C'est le moment ou l'on décide que l'on ne fait plus que debug et que l'on ne touche plus aux interfaces.
Ca se passe généralement en fin de béta avant le cycle des releases candidates.
Parceque fluxbox n'est pas stable. En informatique les dinosaures qui font la différence entre un hacker et un cracker font aussi la différence entre un logiciel fiable et un logiciel stable.
Un logiciel fiable est un logiciel qui fonctionne et fournit toujours le même résultat en réponse aux mêmes saisies. Fluxbox est un logiciel fiable.
Un logiciel stable est une version de logiciel qui est compatible au niveau API et/ou ABI avec les versions similaires de ce logiciel.
Par exemple si l'application en version 1.0.0 fait les choses d'une certaine façon, et que les bibliothèques de la version 1.0.0 compilent d'une certaine manière, on s'attend à ce que celà soit vrai au minimum pour la 1.0.1 et de préférence aussi pour la 1.1.0 (sauf correctuion de bug majeure). C'est ce que l'on apelle la stabilité logiciel. Ce qui est stable ce n'est pas le fonctionnement du logiciel, mais la façon dont il fonctionne.
A l'inverse Fluxbox change assez fréquamment son fonctionnement interne, soit pour coller au plus prèt aux standards freedesktop, soit pour utiliser les bibliothèques enlightenment (par exemple).
Le numéro de version en 0.9x sert donc à dire aux dévelloppeurs qui voudraient construire des applications par dessus fluxbox "attention, on risque de changer notre code plusieurs fois vous risquez donc de devoir recoder votre programme à chaque version."
Si c'est sous gnome que ca t'embête, pourquoi ne mettrais-tu pas l'alias dans ton .xinitrc juste avant ton exec gnome-session ?
NB : commeje ne connais pas Gnome, et encore moins GDM, si tu utilises GDM il se peut qu'il faille en fait utiliser .xsession, .gdm, .gnome-gdm ou même .pipo&molo_font_du_ski.
j'ai mis l'alias dans ~/.profile mais ce fichier ne semble pas être utilisé
Tu dois pouvoir forcer la lecture du truc avec source dans le /etc/profile mettre un if [ -f ~/.profile ] source ~/.profile peut aider.
Ceci étant il y a surement un fichier fait pour çà dans Debian, si un dinosaure pouvait nous éclairer à ce sujet (RTFM Protected)
ba j'avais des perfs vraiments pourris...
Ca ne m'étonne pas vraiment. Le kernel utilisé par OliveBSD est (ou en tout cas semble être) le kernel standard. C'ets à dire que sur plateforme x86 on va se frapper tous les hacks un poil crade (mais nécessaire) pour émuler le NX-bit (zone mémoire non exécutable).
Seulement comme c'est tout l'OS qui est chargé en mémoire deux fois (une fois en Ramdisk et une fois en execution) on se prend un impact de perf mosntrueux (Tous les checks NX sont doublés et la taille d'occupation mémoire prend cher).
A celà il faut bien sur ajouter qu'OpenBSD met en "chroot-jail" un maximum de services, donc les binaires les plus courants s'executent plusieurs fois en mémoire. Normalement ca ne change pas grand chose (C'est quelques kilo-octects à chaque fois), mais là ca impacte fortement.
Pour résumer : on a 380Mo de Ram-disk au minimum et environ 200Mo pris par le systeme si on lance X.org. Bref à moins de 512Mo on est dans le rouge d'office. Et le Go est très vite rempli... Comem en plus chaque accès mémoire (swap ou real) est doublement controlé par les Hacks NX (une fois en sortie de Ramdisk, une fois en entrée en ram "normale"), on se prend le mur....
Et pis je vois pas le coté securisé par rapport à NetBSD par exemple...
Bien installé, que demandé de plus à un NetBSD au niveau de la
securité...? Des performances...?
Une fois bien installé, n'importe quel système est sécurisé. Le problème est la difficulté et le temps qu'il faut pour faire cette "bonne" installation. OpenBSD te fourni de base un firewall/NAT ultra performant et simplissime à régler, un DN/Bind bien isolé et un serveur Apache également isolé et une interface SSH au top, des systèmes d'authentification double/triple en pagaille et depuis peu des systèmes de redondance/synchronisation des tables de routages/etats firewall/interfaces IP au à la pointe.
De plus sous OpenBSD 99% des packages de serveurs arrivent directement dans des chroot/jail sécurisés
L'air de rien, ca fait gagner un temps précieux.
C'est un bon OS, mais c'est dommage qu'il soit vraiment orienté
sur de petite niche d'utilisation bien specifique...
Il n'est pas du tout orienté utilisateur final si c'est ce que tu veux dire, mais honnêtement OpenBSD fait un excellent Routeur/Firewall/Annuaire/Serveur de fichiers/Passerelle/Serveur HTTP/Serveur FTP/Serveur de token/Interface Noeud VPN/Relais Wi-Fi...
Liste de mots avec extraction du mot générique :
Tout d'abord il faut se constituer une liste de mots dans une base de données, des mots tous simples et els organiser suivant plusieurs critères. Par exemple genre, forme, couleur, taille, classe générique.
Ensuite pour confirmer l'email on envoit une liste des mots avec un critère commun et une question.
Il peut se passer deux choses :
a) soit la virtualisation des machines prend bien et est un succès. Et alors IBM qui a environ dix ans d'avance sur tout le monde va faire de la charpie de la concurrence. On aurait alors des machines virtuelles standard, beaucoup plus évoluées que les machines virtuelles actuelles (type JVM ) avec des puces dédiées pour la gestion d'accès concurent aux ressources et des hyperviseurs de machine virtuelles tournant sur un OS sur carte mère qui viendrait remplacer le bios.
Cette solution apporterait trois avantages majeurs :
- intercompatibilité quasi parfaite de toutes les architectures au niveau bytecode (pas besoin d'écrire quarante version pour tirer partie des spécifité, c'est le just-in-time qui s'en charge à la linéarisation du code)
- Sécurité accrue (possibilité de séparer tous les services accédés sur une VM chacn)
- Redondance accrue (avec recréation à la volée d'une VM défficiente sur un autre serveur en cas de forte charge/problème technique).
Dans ce cas là la répartition serait de l'ordre de 70% de parts de marchés pour IBM - 30% pour SUN. L'architecture x86/x86-64 serait mise hors-jeu très vite à cause de ses grosses defficience en terme de gestion temps réel/partage dynamique des ressources.
b) La virtualisation des machines ne prend pas, et alors les divers programmeurs viseront toujours le marché le plus prometteur (ie l'architecture la plus répandue) et là comme d'hab ce sera la pire des architectures qui gagnera la bataille (ici en l'occurence les processeur INTEL en EMT-64). Tout le reste sera trop cher et restera cantonné a des travaux très spécifiques (gourmands en ressources ou necessitant une grosse parallélisation)
Très malheureusement, et malgré de gros progrès en matière de VM l'hypothèse b) reste la plus probable....
Bon en fait, avec les derniers drivers ça marche... mais c'est inutilisable. En effet dès que j'active RenderAccel, ça plante dans la première minute.
Et sans RenderAccel... ben... voilà quoi !
Il y a pas mal de problèmes de ce type quis otn liés à l'utilisation du frame buffer (par la console par exemple). Il est important de savoir que
a) Xorg n'est absolument pas "frame buffer aware" ie il est incapable de savoir si le frame buffer est activé et quelles zones mémoire il utilise
b) quand Xorg utilise des fonctions avancées (surtout vraie dans les drivers proprios, mais aussi sur les cartes ATI avec les drivers libres) il va taper directement la mémoire lui même, voir va réinitialiser des zones mémoires et des maps GPU a la volée.
Il en résulte que Xorg avec les effets 3D/Composite et la console(ou le lecteur vidéo, ou un jeu) en frame buffer ca ne fait pas bon ménage du tout.
Désactiver le frame-buffer pour la console dans le kernel résoud souvent pas mal de problèmes.
Grosso ùod ca propose uen interface graphique en lieu et place du getty classique et ca permet de lancer un shell, faire un reset de la machine, eteindr ela machien etc.
Seul défaut, il est en mode frame buffer. Comme le serveur X.org ne prend pas en compte le mode frame buffer, il y a parfois quelques telescopages.
Si par contre elle est dans le code du programme, alors GPL v2 ou v3 elle DOIT etre révéler.
En GPLv2 si la clef est extérieure au programme (par exemple via la signature du binaire obtenue), il n'est pas nécessaire de la révéler même si certaines fonctionnalités du binaire sont liées à la validité de cette signature.
En GPLv3 dans le draft, à partir du moment ou il existe des fonctionnalités liés à la validité d'une signature, alors les meccanismes d'obtention de la signature doivent être révélées. (ie il faut fournir la clef privée).
C'est la grosse différence, et c'est sur ce point que linus Torvalds râle.
Il n'a jamais écrit ici que GPLv3 = publier ses clés privées.
Pour faire du DRM, il faut à un moment ou à un autre authentifier la chaine de restitution. Cette chaine aura forcément pour base le noyeau (voir le matos sous jacent, mais là on rentre dans le lourd).
Donc pour faire du DRM il faut authentifier le binaire (ie signer le noyeau).
Le DRM a pour but d'empécher les personnes non authorisées d'accéder à certaines fonctionnalités (notamment la lecture de certains médias).
Or la GPLv3 dans son draft interdit que des fonctionnalités puissent être bloquées sur la version binaire, la possibilité d'accès devant apparaitre dans le source. Donc il faut que la méthode et les outils pour la signature apparaissent dans le source. A l'heure actuelle la seule méthode qui permette de faire celà est de donner avec le source la partie privée de la clef servant à la signature....
Donc en GPLv3 pour faire des DRM il faut donner en clair la clef publique qui sert à signer les binaires. Comme Linus Torvalds veut laisser la porte ouverte aux DRM dans le noyeau, et qu'il comprend que personne ne veuille donner sa clef privée (et pour cause, les meccanismes de DRM ne serviraient plus à rien) il refuse la GPLv3.
Il n'y a pas d'allégorie ici, c'est vraiment de la révélation de la clef privée qu'il s'agit.
Ceci étant ca fait quand même 4 ans qu'on est au courant que le noyeau est GPLv2 only et ne passera pas GPLv3, et ca fait plus de deux ans que l'on sait que Linus comprend le besoin de DRM et ne laissera pas quoi qu ece soit bloquer définitivement l'accès des DRM au noyeau Linux.
Le GPLv2 avait déjà causé pas mal d'émois entre RMS et Linus, à la suite d'une déclaration de Linus disant qu'il ne voulait pas être embarqué dans les délires philo-sociologique de RMS et que donc le kernel était en GPLv2 et point. RMS avait alors déclaré que Linus était seulement un ingénieur (ie : le mouvement open source ca lui passe au dessus)
Un peu plus tard dans le thread "flame linus to a crisp" Linus avait déclaré qu'il ne voyait aucun inconvenniant à faire rentrer les DRM dans le noyeau.
Notamment :
I've had some private discussions with various people about this already, and I do realize that a lot of people want to use the kernel in some way to just make DRM go away, at least as far as Linux is concerned. Either by some policy decision or by extending the GPL to just not allow it.
traduction : J'ai déjà eu plusieurs discussions avec diverses personnes sur le sujet, et je réalise parfaitement que beaucoup de gens veulent se servir du kernel pour faire disparaitre les DRM, du moins en ce qui concerne Linux. Soit en instaurant des règles soit en étendant la GPL pour qu'elle ne le permette pas.
Le post date d'avril 2003.
Même si la GPLv3 n'est qu'un brouillon, il y a très peu de chances qu'elle soit reprise par le kernel. Du moins pas tant que la GPLv3 voudra prendre position contre les DRM (ce qui parait à peu près innévitable.)
mad = fou dangereux. Insane = fou.
De plus traditionellement en anglais américain (et par extension de plus en plus en anglais) mad sert à désigner des folies passagères mais très fortes. "I'm madly in love with you" = "je suis fou amoureux de toi". "I am mad about this" = "ce truc me rend fou".
Insane sert plus à décrire un état permanent qui requiert une attention clinique.
décalé/àcoté de la plaque/sans fondement : different/out of the picture/not justified.
Et pour autant pour moi ca s'écrit toujours au temps pour moi.
Avec l'impot que l'Etat aurait du percevoir sur tous les CD et tous els livres qui n'ont pas été vendus mais téléchargés sur le net, on aurait pu boucher le trou de la sécu et refaire les lits d'hopitaux en or massif avec monture en diamant !
Allez hop dans l'ordre : Le travail au noir (CA évalué à 155 milliards d'¤ par an) coûte 35 milliards à la sécu (2,5 fois son déficit) et 20 milliards à l'Etat.
a) Il s'agit d'un manque à gagner (ie un non perçu sur les charges salariales et patronnales)
b) La plus grosse partie du travail au noir en France vient d'heures supplémentaires/missions annexes non déclarées - En ce qui concerne les paiements à la sécu, les travailleurs "au noir" occasionnels (ce qui font une nuit blanche pour finri un projet à temps) sont pas en reste.
c) Un CA de 155 milliads d'¤ devrait rapporter 55 miliards à la sécu+l'état. Donc 35% du CA ne revient jamais à l'entreprise en temps normal. A méditer quand même...
Le "Syndicat Unifié des Impôts" évalue à 28 milliards le montant des fraudes fiscales des particuliers(!)
La France possède 14 organismes de prélèvement d'impot, lesquels organismes rattrappent grosso modo en ammende (+10% de frais de retard +20% d'interet +50% d'ammende) ce qu'ils peuvent perdre en fraude et erreurs (ben oui avec 14 organismes, il y a des fois on fait des bétises même sans le vouloir.)
Si personne ne faisait d'erreur/ne fraudait il n'y aurait plus d'amendes. Je suis pas sur que l'état/l'URSSAF y gagnerait beaucoup.
Si l'on considère les 1424 docteurs en post doc à l'étranger depuis 1997, sachant qu'un sur 4 est resté, et en valorisant à 152 000 ¤ le coût de formation d'un Bac+8, je vous laisse calculer
Bof on forme bien en France des ingénieur avant de leur expliquer gentillement que si ils ont pas de boulot il va falloir qu'ils fassent caissiers chez prisu (les sales parasites), il faut pas s'étonner si dérrière ils ont toutes les peines du monde à rembourser leur formation via le simpots et qu'ils ne rêvent que de se barrer. Quand on investi dans l'humain il faut entretennir son investissement. En France on ne veut pas de recherches (au sens large du terme) alors les grosses têtes se barrent. Plus tard quand des hopitaux/labos se montent à l'étranger, les moyenscerveaux se barrent aussi.
Les assureurs, grâce à une procédure, le "recours contre tiers" arrivent à piquer 1 milliard à la sécu
Les salauds ! C'est honteux ! C'est pas la sécu qui par des procédures de recours contre tiers arriverait à piquer du fric au assureurs qui couvrent les stades qui s'éffondrent, les usines qui explosent ou les instruments défectueux.
La sécurité sociale EST une assurance. Parfois ses assurés (hopitaux, médecins, assujettis) font des conneries, alors elle raque. Comme toute les assurances.
Par exemple Une association dédié au "rayonnement de l'outre mer dans le 92, reçoit 457 000 ¤ par an. Association bien sûr présidée par un député UMP
Outre le magnifique "c'est de l'argent qu'on sait pas ou il va chez l'assoce UMP", on serait quand même tenté de dire "et alors ?" Il y a abus de fonds publics ou pas ? Il y a scandale ? Il y a malversasion ? Ou bien est-ce que les que l'ensemble des députés UMP étant forcément des incapables avides d'argent, cette association (comme toute autre association dirigé par un memebre de l'UMP) ne peut être qu'un horrible montage destiné, à coup d'emplois fictifs, à enrichir la familel et les amis du dit député ?
Je ne parle même pas du coût pour la société des senior qu'on met en préretraite parce qu'ils sont trop vieux (270545 payés à 48,4 ¤ de la journée :4,8 milliard au total).
On pourrait les mettre au chomage pour plus cher si tu préfères...
Ne parlons pas des licenciement boursier
Je connais pas çà ? C'est nouveau ? Le CAC40 s'est fait viré de la bourse de Paris ?
du ministère des anciens combatants qui sert plus à rien
L'ensemble des mutilés de guerre, ainsi que leurs enfants et familles te remercient de leur annoncer ainsi qu'ils sont inutiles. Les divers rappatriés aussi.
Bref, avant de se lancer dans le débat décliniste, mieux vaudrait-il pas refaire proprement et sainement les comptes en appelant un chat un chat ?
Tu veux dire essayer d'expliquer au gens que les demi-vérités prémachées qu'on leur sort dans les journaux à scandale sont fausses par omissions ? La plupart sont beaucoup trop bêtes pour celà, ils tombent dans le panneau à chaque fois.
En plus il est plus valable, car les albums de monsieurZ (dont je m'occupe de la diffusion sur jamendo) ne sont pas déposés à la sacem (mais l'artiste est bien inscrit à la sacem).
C'est possible çà ? Je croyais que la SACEM obligeait ses inscrits à lui donner de facto la gestion des droits de toutes leurs oeuvres futures ?
Je ne vois pas comment cette personne peut être à la Sacem et ne pas avoir les droit sde ses disques gérés par la Sacem (même si les disques en eux-même ne sont pas enregistrés auprès de la Sacem)
Effectivement toutes mes confuses. Le droit de retractation de 14 jours en concerne que les services et les crédits. En tant normal c'est 7 jours. En ce qui concerne les produits logiciels, audio ou video décachetés normalement ca ne marche pas du tout.
Ceci étant les produits vendus par VPC doivent tout de même "être de qualité satisfaisante" ie ne pas comporter de défauts (même mineurs) et pouvoir satisfaire à tous les usages usuels. Là par contre avec un non-CD protégé on est loin du compte.
Les non-CD pouvant raisonablement être considérés dans la plupart des cas comme n'étant pas de qualité satisfaisante (leur protection a pour but de bloquer certains usages usuels) on peut donc les renvoyer à la tête du vendeur. Ceci étant je en sais pas si le vendeur est tenu de rembourser le non-CD ou si il doit le changer contre un vrai CD...
Enfin bon en conclusion, le délais de 15 jours sur le site de la FNAC c'est quand même un peu du flan...
"Si vous rencontrez ce problème, nous nous engageons à vous reprendre et à vous rembourser le CD acheté sur Fnac.com, dans les 15 jours qui suivent la livraison de votre article."
Ca c'est vraiment un chouette cadeau de leur part, très commerçant et tout. Surtout quand on sait que légalement en France le temps de retractation (ie le temsp pendant lequel on peut renvoyer la marchandise et se la faire rembourser) pour toutes les marchandises vendu par correspondance est de .... 15 jours.
En d'autres termes sur les non-CD pourris qui ne marchent pas ou ne sont pas copiables FNAC.com ira jusqu'à respecter la loi \o/
En fait il existe pleins de variantes plus ou moins connues :
Au temps pour moi : c'est moi qui ait fait la faute
Autant pour moi : Je vais avoir la même chose qu'une personne préalablement désignée
Ôte-t-en pour moi : Je crois que tu es assis à ma place
Ôte taon pour moi : Ca me rendrait un fier service, ces bestioles font très mal quand elles mordent
Haute tempe pour moi : J'ai la bosse des maths, et j'en suis pas peu fier
Oh ! Tant pour moi ? : C'est gentil, mais il ne fallait pas.
OTAN pour Mao : Et un blocus qui marche, un !
Hôte en Pourmois : Pourmois, petit village batave mondialement connu pour ses refuges acceuillant.
Haut Tempura : Beignet japonais destiné à l'empereur lui même.
O.T.A.N pour M.O.A : L'organisation des transformation analogique vers numérique est à la charge de la maitrise d'ouvrage
Au temps d'Burma : Quand il y avait le Nestor, s'tait pas pareil; pour sur !
La liste est non exaustive bien sur, mais je pense avoir couvert les formes les plus fréquentes.
Lors de la précédente consultation (dont l'enrobage était différent, mais le principe similaire) il avait été démontré avec brio que les 95% de gens contre le brevet logiciel ne représentaient pas une force ecconomique suffisante pour pouvoir être pris au sérieux.
Ceci étant ça ne mange pas de pain de voter contre, mais je vais attendre un peu avant de fêter le retour en force des grands principes démocratiques.
Donc on pourra mettre des print un peu partout pour surveiller ce qui se passe.
Debugger un programme multithreadé temps réel à coup de print ? BONNE CHANCE.
Sur ce genre de chose, le simpel fait d'ajouter un print change le comportement du programme/la priorité des threads et leur ordre d'execution.
L'idéal pour ce genre de chose c'est de pouvoir faire tourner le programme sur une VM, ou au moins de pouvoir "geler" uen partie de la machine réelle pour la dissequer calmement...
Les autres approches ont tendances à générer encore plsu de bugs qu'elles n'en résolvent.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging
J'imagine que certains threads (système ou programmatiques) viendront mettre à jour les booléens de temps en temps non ?
Tous les problèmes de debugging arrivent à ce moment là (gestion de ressources, condition de courses, passage de messages foirés etc.)
Quand je vois celà : section HEADER
+ name := FOURMI;
- category := AGENT // (1)
section INHERIT
* parent_fourmi:AGENT; // (2)
section PUBLIC
- is_in:AGENT := FOURMILLIERE // (3)
et les différents méccanismes mis en place dans ton langage je me pose une question, as-tu jamais lu un livre sur les fondements de la programation paradigmatique ou multiparadigmatique ?
Par exemple ton déclarateur is_in pour décrire le slot à la construction de l'agent m'a l'air très casse gueule et peu intuitif.
De plus la variation des comportements me parait également bancale.
Par exemple pour le passage
- ((stat = 0) & (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
// Code of behaviour A
)
Postface
{
stat := 1;
timein := 0;
};
- (stat = 1) <-
// behaviour B
(
// Code of behaviour B
)
J'ai peur. Tout d'abord quid de la gestion des popmessages dans ce cas là ? Faut-il les prendre en compte à la main dans dans le code comportemental ou sont-ils gérés en time sharing par le thread en parallèle ? Sont-ils gérés par interruption système ? Sont-ils dans une boucle invisible ? Dans les deux premiers cas quid de la fiabilité d'éxécution et dans le dernier cas quid de la garantie temps-réel ? Mêmes questions pour le timeout(30)
Ensuite pour les code comportementaux la notion de variable de décision me parait étrange dans un paradigme qui se veut porche du raisonnement humain
Pourquoi ne pas créer des slots comportementaux, pendant fonctionnels des slots agents.
Faire un truc du genre
--------------------------------------------------------
section BSLOT_HEADER
+ name := BEHAVIOUR_A;
- category := BSLOT
section RELATED_TO
* parent_fourmi:AGENT; // (2)
section ACTIVE
{//code du comportement a si actif}
section STOP
{//code du comportement a avant de passer la main}
section RESUME
{//code du comportement a en reprise de main}
section SLEEP
{//code de comportement a du programme en attente (message apr exemple)}
------------------------------------------------------------
Le code précédent deviendrait :
-------------------------------------------------
- (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
is_active(BEHAVIOUR_A)
)
Postface
{
stop(BEHAVIOUR_A)
};
Preface
{
//condition d'arret du comportement B
}
// behaviour B
(
// Code of behaviour B
)
Postface
{
//cleaning
}
resume(BEHAVIOUR_A)
----------------------
Celà aurait a) l'avantage de ne pas se trimballer de variables (qui vont forcément géner sur ce genre de paradigme de programmation) et b) de pouvoir garder la main sur un comportement que l'on a stoppé brutalement pour des impératifs temps réel.
Mais bon il se peut que ce soit difficile/impossible à réaliser.
(N.B / il se peut qu'il y ait des monstruosité dans le pseudo-code écrit, je n'ai jamais fait de LISSAC dans ma vie, je me suis juste inspiré des exemples donnés. )
un prototype... j'ai beau être légèrement pro amd, j'aime pas ce terme associé à un processeur intel...
J'ai beau être totalement pro-intel, ilf au tbien reconnaitre que le Pentium-D n'a que deux qualificatif possibles : prototype pour tester le marché ou mauvaise blague. Il s'agit ni plus ni moins que de deux coeur Prescott (ie les coeurs que l'on se trimballe depuis deux ans sans la moindre amélioration exceptée une montée en fréquence) collés l'un à l'autre et posés sur le même bus ram.
Il n'existe aucun bridge entre les deux coeurs, la bande passante est partagée entre les deux coeurs de façon séquentielle (un coup l'un, un coup l'autre) sans la moindre trace d'optimisation sur les chipsets intel. Au final on se retrouve avec un système qui arrive péniblement à égaler les performances d'un classique SMP sur uen carte mère bi-pro basique.
Et comme on aime bien Intel on ne va même pas évoquer les instructions 64 bits EMT (parceque combiner deux registres de deux procs qui n'ont aucun moyen de communiquer l'un avec l'autre directement c'est pas vraiment optimal...)
A mon sens il vaut beaucoup mieux prendre un Bi-Xeon sur carte mère haut de gamme que de prendre un Xeon dual-core qui va être asphyxié par le manque de bande passante vers la mémoire.
outre ceci, j'aime répeter, mais je sais pas pourquoi, que de la ram ecc, c'est une très très bonne idée pour un serveur.
Là je ne peux qu'approuver. Quand on voit les dégats que peut faire une barrête de ram deffectueuse. Le plus drôle c'est sur les bases de données qui stoquent des blobs. Effet garanti...
J'ai pas écrit "ingénieur", mais bac+5.
Le départ de cette conversation qui n'est absolument pas un troll du tout, mais pas du tout alors, était quand même l'assertion qui disait qu'un ingénieur qui avait obtenu son diplome pour écrire du code s'était probablement planté de voie.
L'arithmétique des pointeurs, c'est bidon. suffit de se rappeler la différence entre "*p" et "p" et "&p"
Oui en indirection 1, parceque quand tu veux connaitre l'adresse du nombre précédent située dans la matrice suivante ca devient un peu plus casse gueule. Je ne te cache pas que j'en suis toujorus à peu près incapable et que je me rabat sur des typedef assez facilement.
Pour la gestion des exceptions, je me permet d'avoir des doutes... Je pense pas que ce soit en BTS qu'on voit comment sont mis en oeuvre les mécanismes d'exceptions à l'interprétation ou à la compilation, et donc le coût que ca génère...
Le fait qu'ils ne comprennent pas ne les empêchent en aucun cas de produire un code très efficace. Il y a des "recettes de cuisine" pas forcément optimale, mais généralement suffisament bonne pour marcher dans 99% des cas. A l'inverse le fait de comprendre peut poser des problèmes majeurs. La gestion d'exception est quelque chose d'assez spécial. Le nombre de programmes que j'ai vu essayer de gérer l'ensemble des exceptions à la main pour se vautrer lamentablement à la première exception système sur une fonction en callback....
Mais qu'il soit meilleur en code qu'un bac+5 universitaire en info, j'émet des doutes...
Je n'ai que très rarement eu à faire à des programmeurs bac+5 en info. J'en ai connu deux.
Le premier était un monstre, il avait réussi à faire rentrer un programme d'analyse de risque stochastique dans une feuille vbe. A ma connaissance la feuille est toujours utilisée en salle de marché. Le deuxième était probablement un monstre. Il a essayé de créer un système de recoupement des ordres dans la base de données avant consolidation pour faire une prévision du rippo (argent prété par les banques à d'autres banques) du jour. A ma connaissance il est toujours en train d'essayer.
Je n'ai aucun doute sur le fait que si un jour il y arrive ce sera du très bon boulot, j'ai juste des doutes sur le fait qu'il y arrive.
Je ne sais si les deux individus que j'ai eu sous la main sont représentatifs de la population globale, mais ils semblaient avori les plus grandes peines à faire la différence entre un programme optimal et un programme qui marche. La notion de programme optimal mais qui ne marche pas ne leur traverse pa sun instant l'esprit. Derrière on se retrouve soit avec des projets géniaux sur le papier mais que l'on va mettre des années à implémenter (Le Hurd, c'est pas le projet universitaire par excellence ?) , soit avec des ovnis, certes à la pointe de leur domaine le jour ou ils rentrent en production, mais difficilement maintenable en cas de besoin.
Pour finir je citerais mon ancien maitre de stage :
L'ingénieur, c'est une personne capable de faire des specs même si c'est un universitaire qui a fait le modèle, et le techos c'est le mec capable d'implémenter des specs même si c'est un ingénieur qui les a faites
et D.Knuth Beware of bugs in the above code; I have only proved it correct, not tried it
Qui résument assez bien mon point de vue sur les universitaires.
Personne n'a jamais remis en cause le fait qu'une formation d'ingénieur permettait de comprendre, choisir ou optimise run algorithme mieux qu'une formation de type BTS/IUT ou autre. Il s'agit ici d'un vrai travail d'ingénérie. Par contre, comme quand plus haut, tu indiques que les ingénieurs écriront du meilleur code que les techniciens j'ai un énorme doute.
Voyons les choses calmement, un ingénieur "voie royale" va faire deux ans de prépas puis pendant 3 ans va après toucher un peu à tout en informatique et dans certains domaines anexes (théorie du signal, théorie des graphes, stochastiques etc.)
La personne qui vient de formation IUT ne va étudier que quelques points très précis et pratiques, mais va les étudier à fond.
Au final à la sortie de l'IUT il ne sera pas forcément capable de reconnaitre un tri à bulle, mais par contre à quelques exceptions près il pliera n'importe quel ingénieur sur des domaines comme l'arithmétique de pointeurs, la gestion des exceptions ou encore les implémentations de classes virtuelles sur ses langages de prédilection.
A mon sens, celà fait du mec qui sort de l'IUT un meilleur codeur que l'ingénieur BAC+5 une fois que le problème a été complètement mis en forme. Après, que la mise en forme du problème soit hors de portée du technicien dans 90% des cas nous sommes d'accord. Mais çà n'est (normalement) pas son travail.
[^] # Re: Récupération du mouvement
Posté par Jerome Herman . En réponse au journal [HS] Le droit de grève. Évalué à 3.
Et si on dit
dégats => scandale/mépris de la population plus agées => "les jeunes c'est tous des cons qui respectent rien de toute façon, de mon temps c'était autre chose" => devinez où on va faire les prochainnes coupes budgetaires => Tiens pendant qu'on y est si on fermait aussi la recherche en France => Baisse d'impots pour les consomateurs votants de moins de 60 ans (mais plus de 25 quand même)
Ca parait moins carricatural ?
[^] # Re: À quand une version stable ?
Posté par Jerome Herman . En réponse au journal Fluxbox 0.9.15. Évalué à 2.
C'est ce qu'on appelle le "Freeze". C'est le moment ou l'on décide que l'on ne fait plus que debug et que l'on ne touche plus aux interfaces.
Ca se passe généralement en fin de béta avant le cycle des releases candidates.
[^] # Re: À quand une version stable ?
Posté par Jerome Herman . En réponse au journal Fluxbox 0.9.15. Évalué à 7.
Parceque fluxbox n'est pas stable. En informatique les dinosaures qui font la différence entre un hacker et un cracker font aussi la différence entre un logiciel fiable et un logiciel stable.
Un logiciel fiable est un logiciel qui fonctionne et fournit toujours le même résultat en réponse aux mêmes saisies. Fluxbox est un logiciel fiable.
Un logiciel stable est une version de logiciel qui est compatible au niveau API et/ou ABI avec les versions similaires de ce logiciel.
Par exemple si l'application en version 1.0.0 fait les choses d'une certaine façon, et que les bibliothèques de la version 1.0.0 compilent d'une certaine manière, on s'attend à ce que celà soit vrai au minimum pour la 1.0.1 et de préférence aussi pour la 1.1.0 (sauf correctuion de bug majeure). C'est ce que l'on apelle la stabilité logiciel. Ce qui est stable ce n'est pas le fonctionnement du logiciel, mais la façon dont il fonctionne.
A l'inverse Fluxbox change assez fréquamment son fonctionnement interne, soit pour coller au plus prèt aux standards freedesktop, soit pour utiliser les bibliothèques enlightenment (par exemple).
Le numéro de version en 0.9x sert donc à dire aux dévelloppeurs qui voudraient construire des applications par dessus fluxbox "attention, on risque de changer notre code plusieurs fois vous risquez donc de devoir recoder votre programme à chaque version."
[^] # Re: Puisqu'on cause de Gnome...
Posté par Jerome Herman . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 2.
NB : commeje ne connais pas Gnome, et encore moins GDM, si tu utilises GDM il se peut qu'il faille en fait utiliser .xsession, .gdm, .gnome-gdm ou même .pipo&molo_font_du_ski.
j'ai mis l'alias dans ~/.profile mais ce fichier ne semble pas être utilisé
Tu dois pouvoir forcer la lecture du truc avec source dans le /etc/profile mettre un
if [ -f ~/.profile ] source ~/.profile peut aider.
Ceci étant il y a surement un fichier fait pour çà dans Debian, si un dinosaure pouvait nous éclairer à ce sujet (RTFM Protected)
[^] # Re: Puisqu'on cause de Gnome...
Posté par Jerome Herman . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 10.
dans tout bon terminal.
Par contre ca va être plus dur de lancer gedit après aussi.
[^] # Re: Test
Posté par Jerome Herman . En réponse à la dépêche Un live-cd pour OpenBSD : OliveBSD. Évalué à 10.
Ca ne m'étonne pas vraiment. Le kernel utilisé par OliveBSD est (ou en tout cas semble être) le kernel standard. C'ets à dire que sur plateforme x86 on va se frapper tous les hacks un poil crade (mais nécessaire) pour émuler le NX-bit (zone mémoire non exécutable).
Seulement comme c'est tout l'OS qui est chargé en mémoire deux fois (une fois en Ramdisk et une fois en execution) on se prend un impact de perf mosntrueux (Tous les checks NX sont doublés et la taille d'occupation mémoire prend cher).
A celà il faut bien sur ajouter qu'OpenBSD met en "chroot-jail" un maximum de services, donc les binaires les plus courants s'executent plusieurs fois en mémoire. Normalement ca ne change pas grand chose (C'est quelques kilo-octects à chaque fois), mais là ca impacte fortement.
Pour résumer : on a 380Mo de Ram-disk au minimum et environ 200Mo pris par le systeme si on lance X.org. Bref à moins de 512Mo on est dans le rouge d'office. Et le Go est très vite rempli... Comem en plus chaque accès mémoire (swap ou real) est doublement controlé par les Hacks NX (une fois en sortie de Ramdisk, une fois en entrée en ram "normale"), on se prend le mur....
Et pis je vois pas le coté securisé par rapport à NetBSD par exemple...
Bien installé, que demandé de plus à un NetBSD au niveau de la
securité...? Des performances...?
Une fois bien installé, n'importe quel système est sécurisé. Le problème est la difficulté et le temps qu'il faut pour faire cette "bonne" installation. OpenBSD te fourni de base un firewall/NAT ultra performant et simplissime à régler, un DN/Bind bien isolé et un serveur Apache également isolé et une interface SSH au top, des systèmes d'authentification double/triple en pagaille et depuis peu des systèmes de redondance/synchronisation des tables de routages/etats firewall/interfaces IP au à la pointe.
De plus sous OpenBSD 99% des packages de serveurs arrivent directement dans des chroot/jail sécurisés
L'air de rien, ca fait gagner un temps précieux.
C'est un bon OS, mais c'est dommage qu'il soit vraiment orienté
sur de petite niche d'utilisation bien specifique...
Il n'est pas du tout orienté utilisateur final si c'est ce que tu veux dire, mais honnêtement OpenBSD fait un excellent Routeur/Firewall/Annuaire/Serveur de fichiers/Passerelle/Serveur HTTP/Serveur FTP/Serveur de token/Interface Noeud VPN/Relais Wi-Fi...
# Une technique qui marche pas mal
Posté par Jerome Herman . En réponse au journal des idées pour éviter la création automatique de compte par des bots ?. Évalué à 1.
Tout d'abord il faut se constituer une liste de mots dans une base de données, des mots tous simples et els organiser suivant plusieurs critères. Par exemple genre, forme, couleur, taille, classe générique.
Ensuite pour confirmer l'email on envoit une liste des mots avec un critère commun et une question.
Par exemple :
Ou encore
Si on a un bon nombre de critères et une grosse base d'objets, ca limite les création par robot pendant un moment.
# Ma vision des choses à moi que j'ai
Posté par Jerome Herman . En réponse au journal Et le 64bits ??. Évalué à 7.
a) soit la virtualisation des machines prend bien et est un succès. Et alors IBM qui a environ dix ans d'avance sur tout le monde va faire de la charpie de la concurrence. On aurait alors des machines virtuelles standard, beaucoup plus évoluées que les machines virtuelles actuelles (type JVM ) avec des puces dédiées pour la gestion d'accès concurent aux ressources et des hyperviseurs de machine virtuelles tournant sur un OS sur carte mère qui viendrait remplacer le bios.
Cette solution apporterait trois avantages majeurs :
- intercompatibilité quasi parfaite de toutes les architectures au niveau bytecode (pas besoin d'écrire quarante version pour tirer partie des spécifité, c'est le just-in-time qui s'en charge à la linéarisation du code)
- Sécurité accrue (possibilité de séparer tous les services accédés sur une VM chacn)
- Redondance accrue (avec recréation à la volée d'une VM défficiente sur un autre serveur en cas de forte charge/problème technique).
Dans ce cas là la répartition serait de l'ordre de 70% de parts de marchés pour IBM - 30% pour SUN. L'architecture x86/x86-64 serait mise hors-jeu très vite à cause de ses grosses defficience en terme de gestion temps réel/partage dynamique des ressources.
b) La virtualisation des machines ne prend pas, et alors les divers programmeurs viseront toujours le marché le plus prometteur (ie l'architecture la plus répandue) et là comme d'hab ce sera la pire des architectures qui gagnera la bataille (ici en l'occurence les processeur INTEL en EMT-64). Tout le reste sera trop cher et restera cantonné a des travaux très spécifiques (gourmands en ressources ou necessitant une grosse parallélisation)
Très malheureusement, et malgré de gros progrès en matière de VM l'hypothèse b) reste la plus probable....
[^] # Re: ATI...
Posté par Jerome Herman . En réponse au journal Le point sur les drivers de carte graphique libres. Évalué à 3.
Et sans RenderAccel... ben... voilà quoi !
Il y a pas mal de problèmes de ce type quis otn liés à l'utilisation du frame buffer (par la console par exemple). Il est important de savoir que
a) Xorg n'est absolument pas "frame buffer aware" ie il est incapable de savoir si le frame buffer est activé et quelles zones mémoire il utilise
b) quand Xorg utilise des fonctions avancées (surtout vraie dans les drivers proprios, mais aussi sur les cartes ATI avec les drivers libres) il va taper directement la mémoire lui même, voir va réinitialiser des zones mémoires et des maps GPU a la volée.
Il en résulte que Xorg avec les effets 3D/Composite et la console(ou le lecteur vidéo, ou un jeu) en frame buffer ca ne fait pas bon ménage du tout.
Désactiver le frame-buffer pour la console dans le kernel résoud souvent pas mal de problèmes.
# Connais-tu Qingy ?
Posté par Jerome Herman . En réponse au journal Petite suggestion : terminaux virtuels. Évalué à 7.
Grosso ùod ca propose uen interface graphique en lieu et place du getty classique et ca permet de lancer un shell, faire un reset de la machine, eteindr ela machien etc.
Seul défaut, il est en mode frame buffer. Comme le serveur X.org ne prend pas en compte le mode frame buffer, il y a parfois quelques telescopages.
[^] # Re: J'ai pas compris...
Posté par Jerome Herman . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 5.
En GPLv2 si la clef est extérieure au programme (par exemple via la signature du binaire obtenue), il n'est pas nécessaire de la révéler même si certaines fonctionnalités du binaire sont liées à la validité de cette signature.
En GPLv3 dans le draft, à partir du moment ou il existe des fonctionnalités liés à la validité d'une signature, alors les meccanismes d'obtention de la signature doivent être révélées. (ie il faut fournir la clef privée).
C'est la grosse différence, et c'est sur ce point que linus Torvalds râle.
[^] # Re: J'ai pas compris...
Posté par Jerome Herman . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 6.
Pour faire du DRM, il faut à un moment ou à un autre authentifier la chaine de restitution. Cette chaine aura forcément pour base le noyeau (voir le matos sous jacent, mais là on rentre dans le lourd).
Donc pour faire du DRM il faut authentifier le binaire (ie signer le noyeau).
Le DRM a pour but d'empécher les personnes non authorisées d'accéder à certaines fonctionnalités (notamment la lecture de certains médias).
Or la GPLv3 dans son draft interdit que des fonctionnalités puissent être bloquées sur la version binaire, la possibilité d'accès devant apparaitre dans le source. Donc il faut que la méthode et les outils pour la signature apparaissent dans le source. A l'heure actuelle la seule méthode qui permette de faire celà est de donner avec le source la partie privée de la clef servant à la signature....
Donc en GPLv3 pour faire des DRM il faut donner en clair la clef publique qui sert à signer les binaires. Comme Linus Torvalds veut laisser la porte ouverte aux DRM dans le noyeau, et qu'il comprend que personne ne veuille donner sa clef privée (et pour cause, les meccanismes de DRM ne serviraient plus à rien) il refuse la GPLv3.
Il n'y a pas d'allégorie ici, c'est vraiment de la révélation de la clef privée qu'il s'agit.
[^] # Re: et le complément ...
Posté par Jerome Herman . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 4.
Le GPLv2 avait déjà causé pas mal d'émois entre RMS et Linus, à la suite d'une déclaration de Linus disant qu'il ne voulait pas être embarqué dans les délires philo-sociologique de RMS et que donc le kernel était en GPLv2 et point. RMS avait alors déclaré que Linus était seulement un ingénieur (ie : le mouvement open source ca lui passe au dessus)
Un peu plus tard dans le thread "flame linus to a crisp" Linus avait déclaré qu'il ne voyait aucun inconvenniant à faire rentrer les DRM dans le noyeau.
Notamment :
traduction :
J'ai déjà eu plusieurs discussions avec diverses personnes sur le sujet, et je réalise parfaitement que beaucoup de gens veulent se servir du kernel pour faire disparaitre les DRM, du moins en ce qui concerne Linux. Soit en instaurant des règles soit en étendant la GPL pour qu'elle ne le permette pas.
Le post date d'avril 2003.
Même si la GPLv3 n'est qu'un brouillon, il y a très peu de chances qu'elle soit reprise par le kernel. Du moins pas tant que la GPLv3 voudra prendre position contre les DRM (ce qui parait à peu près innévitable.)
cf : http://www.cs.helsinki.fi/linux/linux-kernel/2003-16/1069.ht(...)
[^] # Re: Traduction
Posté par Jerome Herman . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 10.
De plus traditionellement en anglais américain (et par extension de plus en plus en anglais) mad sert à désigner des folies passagères mais très fortes. "I'm madly in love with you" = "je suis fou amoureux de toi". "I am mad about this" = "ce truc me rend fou".
Insane sert plus à décrire un état permanent qui requiert une attention clinique.
décalé/àcoté de la plaque/sans fondement : different/out of the picture/not justified.
Et pour autant pour moi ca s'écrit toujours au temps pour moi.
# Et encore, ils ont pas dit le plus gros !
Posté par Jerome Herman . En réponse au journal Repenser le problème de la dette de l'Etat. Évalué à 6.
Allez hop dans l'ordre :
Le travail au noir (CA évalué à 155 milliards d'¤ par an) coûte 35 milliards à la sécu (2,5 fois son déficit) et 20 milliards à l'Etat.
a) Il s'agit d'un manque à gagner (ie un non perçu sur les charges salariales et patronnales)
b) La plus grosse partie du travail au noir en France vient d'heures supplémentaires/missions annexes non déclarées - En ce qui concerne les paiements à la sécu, les travailleurs "au noir" occasionnels (ce qui font une nuit blanche pour finri un projet à temps) sont pas en reste.
c) Un CA de 155 milliads d'¤ devrait rapporter 55 miliards à la sécu+l'état. Donc 35% du CA ne revient jamais à l'entreprise en temps normal. A méditer quand même...
Le "Syndicat Unifié des Impôts" évalue à 28 milliards le montant des fraudes fiscales des particuliers(!)
La France possède 14 organismes de prélèvement d'impot, lesquels organismes rattrappent grosso modo en ammende (+10% de frais de retard +20% d'interet +50% d'ammende) ce qu'ils peuvent perdre en fraude et erreurs (ben oui avec 14 organismes, il y a des fois on fait des bétises même sans le vouloir.)
Si personne ne faisait d'erreur/ne fraudait il n'y aurait plus d'amendes. Je suis pas sur que l'état/l'URSSAF y gagnerait beaucoup.
Si l'on considère les 1424 docteurs en post doc à l'étranger depuis 1997, sachant qu'un sur 4 est resté, et en valorisant à 152 000 ¤ le coût de formation d'un Bac+8, je vous laisse calculer
Bof on forme bien en France des ingénieur avant de leur expliquer gentillement que si ils ont pas de boulot il va falloir qu'ils fassent caissiers chez prisu (les sales parasites), il faut pas s'étonner si dérrière ils ont toutes les peines du monde à rembourser leur formation via le simpots et qu'ils ne rêvent que de se barrer. Quand on investi dans l'humain il faut entretennir son investissement. En France on ne veut pas de recherches (au sens large du terme) alors les grosses têtes se barrent. Plus tard quand des hopitaux/labos se montent à l'étranger, les moyenscerveaux se barrent aussi.
Les assureurs, grâce à une procédure, le "recours contre tiers" arrivent à piquer 1 milliard à la sécu
Les salauds ! C'est honteux ! C'est pas la sécu qui par des procédures de recours contre tiers arriverait à piquer du fric au assureurs qui couvrent les stades qui s'éffondrent, les usines qui explosent ou les instruments défectueux.
La sécurité sociale EST une assurance. Parfois ses assurés (hopitaux, médecins, assujettis) font des conneries, alors elle raque. Comme toute les assurances.
Par exemple Une association dédié au "rayonnement de l'outre mer dans le 92, reçoit 457 000 ¤ par an. Association bien sûr présidée par un député UMP
Outre le magnifique "c'est de l'argent qu'on sait pas ou il va chez l'assoce UMP", on serait quand même tenté de dire "et alors ?" Il y a abus de fonds publics ou pas ? Il y a scandale ? Il y a malversasion ? Ou bien est-ce que les que l'ensemble des députés UMP étant forcément des incapables avides d'argent, cette association (comme toute autre association dirigé par un memebre de l'UMP) ne peut être qu'un horrible montage destiné, à coup d'emplois fictifs, à enrichir la familel et les amis du dit député ?
Je ne parle même pas du coût pour la société des senior qu'on met en préretraite parce qu'ils sont trop vieux (270545 payés à 48,4 ¤ de la journée :4,8 milliard au total).
On pourrait les mettre au chomage pour plus cher si tu préfères...
Ne parlons pas des licenciement boursier
Je connais pas çà ? C'est nouveau ? Le CAC40 s'est fait viré de la bourse de Paris ?
du ministère des anciens combatants qui sert plus à rien
L'ensemble des mutilés de guerre, ainsi que leurs enfants et familles te remercient de leur annoncer ainsi qu'ils sont inutiles. Les divers rappatriés aussi.
Bref, avant de se lancer dans le débat décliniste, mieux vaudrait-il pas refaire proprement et sainement les comptes en appelant un chat un chat ?
Tu veux dire essayer d'expliquer au gens que les demi-vérités prémachées qu'on leur sort dans les journaux à scandale sont fausses par omissions ? La plupart sont beaucoup trop bêtes pour celà, ils tombent dans le panneau à chaque fois.
[^] # Re: Pour nuancer...
Posté par Jerome Herman . En réponse au journal Jamendo atteint 500 albums!. Évalué à 2.
C'est possible çà ? Je croyais que la SACEM obligeait ses inscrits à lui donner de facto la gestion des droits de toutes leurs oeuvres futures ?
Je ne vois pas comment cette personne peut être à la Sacem et ne pas avoir les droit sde ses disques gérés par la Sacem (même si les disques en eux-même ne sont pas enregistrés auprès de la Sacem)
[^] # Re: EMI
Posté par Jerome Herman . En réponse au journal Nouvelle décision de justice contre le système anticopie d'un CD de Warner. Évalué à 4.
Ceci étant les produits vendus par VPC doivent tout de même "être de qualité satisfaisante" ie ne pas comporter de défauts (même mineurs) et pouvoir satisfaire à tous les usages usuels. Là par contre avec un non-CD protégé on est loin du compte.
Les non-CD pouvant raisonablement être considérés dans la plupart des cas comme n'étant pas de qualité satisfaisante (leur protection a pour but de bloquer certains usages usuels) on peut donc les renvoyer à la tête du vendeur. Ceci étant je en sais pas si le vendeur est tenu de rembourser le non-CD ou si il doit le changer contre un vrai CD...
Enfin bon en conclusion, le délais de 15 jours sur le site de la FNAC c'est quand même un peu du flan...
[^] # Re: EMI
Posté par Jerome Herman . En réponse au journal Nouvelle décision de justice contre le système anticopie d'un CD de Warner. Évalué à 6.
Ca c'est vraiment un chouette cadeau de leur part, très commerçant et tout. Surtout quand on sait que légalement en France le temps de retractation (ie le temsp pendant lequel on peut renvoyer la marchandise et se la faire rembourser) pour toutes les marchandises vendu par correspondance est de .... 15 jours.
En d'autres termes sur les non-CD pourris qui ne marchent pas ou ne sont pas copiables FNAC.com ira jusqu'à respecter la loi \o/
C'est beau, on en pleurerait.
Kha
[^] # Re: Oui, mais non.
Posté par Jerome Herman . En réponse au journal faire un serveur ppp avec sa freebox. Évalué à 10.
Au temps pour moi : c'est moi qui ait fait la faute
Autant pour moi : Je vais avoir la même chose qu'une personne préalablement désignée
Ôte-t-en pour moi : Je crois que tu es assis à ma place
Ôte taon pour moi : Ca me rendrait un fier service, ces bestioles font très mal quand elles mordent
Haute tempe pour moi : J'ai la bosse des maths, et j'en suis pas peu fier
Oh ! Tant pour moi ? : C'est gentil, mais il ne fallait pas.
OTAN pour Mao : Et un blocus qui marche, un !
Hôte en Pourmois : Pourmois, petit village batave mondialement connu pour ses refuges acceuillant.
Haut Tempura : Beignet japonais destiné à l'empereur lui même.
O.T.A.N pour M.O.A : L'organisation des transformation analogique vers numérique est à la charge de la maitrise d'ouvrage
Au temps d'Burma : Quand il y avait le Nestor, s'tait pas pareil; pour sur !
La liste est non exaustive bien sur, mais je pense avoir couvert les formes les plus fréquentes.
[^] # Re: Hé !
Posté par Jerome Herman . En réponse au journal brevet logiciel, on remet ça ?. Évalué à 5.
Lors de la précédente consultation (dont l'enrobage était différent, mais le principe similaire) il avait été démontré avec brio que les 95% de gens contre le brevet logiciel ne représentaient pas une force ecconomique suffisante pour pouvoir être pris au sérieux.
Ceci étant ça ne mange pas de pain de voter contre, mais je vais attendre un peu avant de fêter le retour en force des grands principes démocratiques.
[^] # Re: C'est interressant, mais...
Posté par Jerome Herman . En réponse au journal Le langage de mes rêves. Évalué à 10.
Debugger un programme multithreadé temps réel à coup de print ? BONNE CHANCE.
Sur ce genre de chose, le simpel fait d'ajouter un print change le comportement du programme/la priorité des threads et leur ordre d'execution.
L'idéal pour ce genre de chose c'est de pouvoir faire tourner le programme sur une VM, ou au moins de pouvoir "geler" uen partie de la machine réelle pour la dissequer calmement...
Les autres approches ont tendances à générer encore plsu de bugs qu'elles n'en résolvent.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging
J'imagine que certains threads (système ou programmatiques) viendront mettre à jour les booléens de temps en temps non ?
Tous les problèmes de debugging arrivent à ce moment là (gestion de ressources, condition de courses, passage de messages foirés etc.)
# C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Jerome Herman . En réponse au journal Le langage de mes rêves. Évalué à 10.
section HEADER
+ name := FOURMI;
- category := AGENT // (1)
section INHERIT
* parent_fourmi:AGENT; // (2)
section PUBLIC
- is_in:AGENT := FOURMILLIERE // (3)
et les différents méccanismes mis en place dans ton langage je me pose une question, as-tu jamais lu un livre sur les fondements de la programation paradigmatique ou multiparadigmatique ?
Par exemple ton déclarateur is_in pour décrire le slot à la construction de l'agent m'a l'air très casse gueule et peu intuitif.
De plus la variation des comportements me parait également bancale.
Par exemple pour le passage
- ((stat = 0) & (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
// Code of behaviour A
)
Postface
{
stat := 1;
timein := 0;
};
- (stat = 1) <-
// behaviour B
(
// Code of behaviour B
)
J'ai peur. Tout d'abord quid de la gestion des popmessages dans ce cas là ? Faut-il les prendre en compte à la main dans dans le code comportemental ou sont-ils gérés en time sharing par le thread en parallèle ? Sont-ils gérés par interruption système ? Sont-ils dans une boucle invisible ? Dans les deux premiers cas quid de la fiabilité d'éxécution et dans le dernier cas quid de la garantie temps-réel ? Mêmes questions pour le timeout(30)
Ensuite pour les code comportementaux la notion de variable de décision me parait étrange dans un paradigme qui se veut porche du raisonnement humain
Pourquoi ne pas créer des slots comportementaux, pendant fonctionnels des slots agents.
Faire un truc du genre
--------------------------------------------------------
section BSLOT_HEADER
+ name := BEHAVIOUR_A;
- category := BSLOT
section RELATED_TO
* parent_fourmi:AGENT; // (2)
section ACTIVE
{//code du comportement a si actif}
section STOP
{//code du comportement a avant de passer la main}
section RESUME
{//code du comportement a en reprise de main}
section SLEEP
{//code de comportement a du programme en attente (message apr exemple)}
------------------------------------------------------------
Le code précédent deviendrait :
-------------------------------------------------
- (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
is_active(BEHAVIOUR_A)
)
Postface
{
stop(BEHAVIOUR_A)
};
Preface
{
//condition d'arret du comportement B
}
// behaviour B
(
// Code of behaviour B
)
Postface
{
//cleaning
}
resume(BEHAVIOUR_A)
----------------------
Celà aurait a) l'avantage de ne pas se trimballer de variables (qui vont forcément géner sur ce genre de paradigme de programmation) et b) de pouvoir garder la main sur un comportement que l'on a stoppé brutalement pour des impératifs temps réel.
Mais bon il se peut que ce soit difficile/impossible à réaliser.
(N.B / il se peut qu'il y ait des monstruosité dans le pseudo-code écrit, je n'ai jamais fait de LISSAC dans ma vie, je me suis juste inspiré des exemples donnés. )
[^] # Re: Serveur
Posté par Jerome Herman . En réponse au journal P4 HT ou P4 D ?. Évalué à 4.
J'ai beau être totalement pro-intel, ilf au tbien reconnaitre que le Pentium-D n'a que deux qualificatif possibles : prototype pour tester le marché ou mauvaise blague. Il s'agit ni plus ni moins que de deux coeur Prescott (ie les coeurs que l'on se trimballe depuis deux ans sans la moindre amélioration exceptée une montée en fréquence) collés l'un à l'autre et posés sur le même bus ram.
Il n'existe aucun bridge entre les deux coeurs, la bande passante est partagée entre les deux coeurs de façon séquentielle (un coup l'un, un coup l'autre) sans la moindre trace d'optimisation sur les chipsets intel. Au final on se retrouve avec un système qui arrive péniblement à égaler les performances d'un classique SMP sur uen carte mère bi-pro basique.
Et comme on aime bien Intel on ne va même pas évoquer les instructions 64 bits EMT (parceque combiner deux registres de deux procs qui n'ont aucun moyen de communiquer l'un avec l'autre directement c'est pas vraiment optimal...)
A mon sens il vaut beaucoup mieux prendre un Bi-Xeon sur carte mère haut de gamme que de prendre un Xeon dual-core qui va être asphyxié par le manque de bande passante vers la mémoire.
outre ceci, j'aime répeter, mais je sais pas pourquoi, que de la ram ecc, c'est une très très bonne idée pour un serveur.
Là je ne peux qu'approuver. Quand on voit les dégats que peut faire une barrête de ram deffectueuse. Le plus drôle c'est sur les bases de données qui stoquent des blobs. Effet garanti...
[^] # Re: Simple
Posté par Jerome Herman . En réponse au journal une grève ?. Évalué à 5.
Le départ de cette conversation qui n'est absolument pas un troll du tout, mais pas du tout alors, était quand même l'assertion qui disait qu'un ingénieur qui avait obtenu son diplome pour écrire du code s'était probablement planté de voie.
L'arithmétique des pointeurs, c'est bidon. suffit de se rappeler la différence entre "*p" et "p" et "&p"
Oui en indirection 1, parceque quand tu veux connaitre l'adresse du nombre précédent située dans la matrice suivante ca devient un peu plus casse gueule. Je ne te cache pas que j'en suis toujorus à peu près incapable et que je me rabat sur des typedef assez facilement.
Pour la gestion des exceptions, je me permet d'avoir des doutes... Je pense pas que ce soit en BTS qu'on voit comment sont mis en oeuvre les mécanismes d'exceptions à l'interprétation ou à la compilation, et donc le coût que ca génère...
Le fait qu'ils ne comprennent pas ne les empêchent en aucun cas de produire un code très efficace. Il y a des "recettes de cuisine" pas forcément optimale, mais généralement suffisament bonne pour marcher dans 99% des cas. A l'inverse le fait de comprendre peut poser des problèmes majeurs. La gestion d'exception est quelque chose d'assez spécial. Le nombre de programmes que j'ai vu essayer de gérer l'ensemble des exceptions à la main pour se vautrer lamentablement à la première exception système sur une fonction en callback....
Mais qu'il soit meilleur en code qu'un bac+5 universitaire en info, j'émet des doutes...
Je n'ai que très rarement eu à faire à des programmeurs bac+5 en info. J'en ai connu deux.
Le premier était un monstre, il avait réussi à faire rentrer un programme d'analyse de risque stochastique dans une feuille vbe. A ma connaissance la feuille est toujours utilisée en salle de marché. Le deuxième était probablement un monstre. Il a essayé de créer un système de recoupement des ordres dans la base de données avant consolidation pour faire une prévision du rippo (argent prété par les banques à d'autres banques) du jour. A ma connaissance il est toujours en train d'essayer.
Je n'ai aucun doute sur le fait que si un jour il y arrive ce sera du très bon boulot, j'ai juste des doutes sur le fait qu'il y arrive.
Je ne sais si les deux individus que j'ai eu sous la main sont représentatifs de la population globale, mais ils semblaient avori les plus grandes peines à faire la différence entre un programme optimal et un programme qui marche. La notion de programme optimal mais qui ne marche pas ne leur traverse pa sun instant l'esprit. Derrière on se retrouve soit avec des projets géniaux sur le papier mais que l'on va mettre des années à implémenter (Le Hurd, c'est pas le projet universitaire par excellence ?) , soit avec des ovnis, certes à la pointe de leur domaine le jour ou ils rentrent en production, mais difficilement maintenable en cas de besoin.
Pour finir je citerais mon ancien maitre de stage :
L'ingénieur, c'est une personne capable de faire des specs même si c'est un universitaire qui a fait le modèle, et le techos c'est le mec capable d'implémenter des specs même si c'est un ingénieur qui les a faites
et D.Knuth
Beware of bugs in the above code; I have only proved it correct, not tried it
Qui résument assez bien mon point de vue sur les universitaires.
[^] # Re: Simple
Posté par Jerome Herman . En réponse au journal une grève ?. Évalué à 2.
Voyons les choses calmement, un ingénieur "voie royale" va faire deux ans de prépas puis pendant 3 ans va après toucher un peu à tout en informatique et dans certains domaines anexes (théorie du signal, théorie des graphes, stochastiques etc.)
La personne qui vient de formation IUT ne va étudier que quelques points très précis et pratiques, mais va les étudier à fond.
Au final à la sortie de l'IUT il ne sera pas forcément capable de reconnaitre un tri à bulle, mais par contre à quelques exceptions près il pliera n'importe quel ingénieur sur des domaines comme l'arithmétique de pointeurs, la gestion des exceptions ou encore les implémentations de classes virtuelles sur ses langages de prédilection.
A mon sens, celà fait du mec qui sort de l'IUT un meilleur codeur que l'ingénieur BAC+5 une fois que le problème a été complètement mis en forme. Après, que la mise en forme du problème soit hors de portée du technicien dans 90% des cas nous sommes d'accord. Mais çà n'est (normalement) pas son travail.