Biologiquement me semble un bien grand mot : un jour n'a pas la meme durée partout sur la planète, et dépend de la saison...
C'est-à-dire que c'est la durée de l'éclairage qui varie, mais un jour a toujours exactement la même durée : 24 heures. La période est donc invariable, mais la phase demeure également : du Groenland jusqu'en antarctique, le maximum d'intensité lumineuse est toujours atteint à midi pile, heure solaire.
Celui qui vit sous terre ne se prive pas seulement de lumière, mais également d'une horloge très précise. Si ton spéléologue s'est adapté à 25 heures, je pense que c'est plus par habitude qu'autre chose ...
Par contre, bien sur, pour la consommation, c'est pas terrible. Mais bon, tu ne peux pas tout avoir.
En même temps, ça reste raisonnable, comme exigence, n'est-ce pas ?
Franchement, les "basse conso", ça me laisse perplexe.
Outre le fait que l'on essaie de nous faire gober que la lueur blafarde d'un tube fluorescent, puisque c'est de cela qu'il s'agit, vaut la chaude lumière d'une ampoule électrique à incandescence (dont le rendement est certes désastreux), il me semble que :
- Ca reste largement plus cher (ne serait-ce qu'à produire) :
- C'est largement moins recyclable !
Une ampoule, c'est du métal, du verre, un peu d'isolant dans le culot, et le cas particulier du filament en tungstène. On peut facilement envisager une filière de retraitement. Pour les plus classiques, une sorte de ciseau comme pour les oeufs à la coque suffit à séparer l'ampoule proprement dite (le verre) du reste du dispositif.
Une basse conso, c'est un gros carter en plastique qui embarque un régulateur électronique complexe et un tube très épais (beaucoup plus que les "néons" classiques) avec son revêtement fluorescent.
Autant que je sache, il n'y a pas de filière répandue pour faire le recyclage de ces produits. Comme il n'y a rien de prévu à ce sujet coté tri sélectif, tout cela passe directement à l'incinérateur. Même si les plus modernes filtrent leurs fumées, je ne suis pas sûr que ce que l'on gagne en énergie compense la polution supplémentaire produire par rapport à une ampoule classique ...
Oui, mais je t'avoue que je préfère largement le Flash au *.wmv et autres conneries embedded directement dans les pages HTML des sites de musique, amateur ou non, et qui oblige leur webmestre à préciser "ce site n'est accessible qu'avec Win XXX" ce qui, pour le coup, est vraiment un comble.
Le principal inconvénient du Flash, outre le fait qu'il ne soit pas libre (et encore, les spécifications du format restent disponibles) est son manque de diffusion sur les plate-formes s'éloignant un tant soi peu de l'IA32.
Hormis cela, c'est quand même un outil vectoriel puissant et très bien réalisé. Et pour l'usage que l'on en fait sur le web, c'est tout de même un poil plus optimisé qu'un GIF animé ...
Tu as l'air de savoir que cette opération s'appelle une jointure donc je ne t'apprendrai rien en te disant que c'est la clé de voûte des bases de données.
Donc, si tu comptes recourir massivement à ce genre d'outil, un petit MySQL/PostgreSQL sera largement plus approprié ...
Match when the TCP flags are as specified. The first argument is the flags which we should examine, written as a comma-separated list, and the second argument is a comma-separated list of flags which must be set. Flags are: SYN ACK FIN RST URG PSH ALL NONE. Hence the command iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST SYN will only match packets with the SYN flag set, and the ACK, FIN and RST flags unset.
[!] --syn
Only match TCP packets with the SYN bit set and the ACK,RST and FIN bits cleared. Such packets are used to request TCP connection initiation; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be unaffected. It is equivalent to --tcp-flags SYN,RST,ACK,FIN SYN. If the "!" flag precedes the "--syn", the sense of the option is inverted.
Le must, à mon avis : on laisse les processus en vie et on fait une règle iptable qui va bien avec un -j DROP de circonstance pour faire disparaître les paquets ciblés dans un accident malencontreux.
D'autant qu'à aucun moment tu ne lui as craché dessus ...
Il est normal à toutes les époques de trouver des gens qui découvrent le logiciel libre, puisqu'à toutes les époques on trouve des gens qui débutent dans l'informatique d'une manière générale. Et le fait est que l'OS de Redmond ne leur permet pas de voir d'emblée tout ce qui peut se faire sur un ordinateur ... et ce n'est pas non plus chez les revendeurs que l'on va trouver du conseil de qualité. Donc, il est effectivement de salubrité publique d'éclairer la lanterne d'une brebis égarée lorsque l'on en croise une. La plupart du temps, l'individu concerné est loin d'être un imbécile, et il semble que ce soit le cas pour ce blogueur.
Si en plus, ça peut être drôle, il n'y a pas de raison de se priver ... :-)
Sinon, tu peux toujours essayer un top en ligne de commande et identifier un processus bouffeur de ressources, voire le trier par mémoire consommée (« O » puis « n », il me semble).
Enfin, en même temps, si tu as appelé ta machine « vieuxpaf », il ne faut pas s'attendre à ce qu'elle y mette de la bonne volonté non plus, hein ... :-)
Franchement, je me demande si tu lis mes commentaires avant d'y répondre.
Tu as réussi à me faire dire exactement le contraire de ce que j'exprime, et ce pratiquement à chacun des mes paragraphes. Donc, et comme tu sembles être très impulsif, je vais rectifier point par point, ensuite je cesse d'alimenter ce thread.
Et compte pas mettre un p4 la ou tu fait de l'embarqué avec des asic spécifiques .... comme des routeurs ou des commutateurs atm !
C'est justement ce que je dis plus haut.
La plupart des programmeurs, aujourd'hui, ne connaissent que la puissance de leur PC de dernière génération, alors que cette puissance est difficile à atteindre.
Ah moins que chez toi les routeurs ca sert à rien dans 'la société de l'information'.
À ce point, c'est pratiquement de la diffamation.
Sachant qu'il y a des convertisseur rs-232 <-> usb à faible cout je pense que ton exemple est plutot mauvais...
J'ai volontairement omis ce cas de figure car il est fallacieux (et évidemment, tu sautes dedans à pieds joints) : « ce n'est pas compliqué puisque ce n'est pas toi qui le réalise » ! Les électroniciens dont tu parles, si.
Quand au couts, ca sert juste à montrer , que c'est bien beau de critiquer [...] le cout de production toussa, et ils te font ta puce.
Là encore, à aucun moment, je n'ai « critiqué » cette politique de coût
Je te la fais en plus court : Il n'y a pas de trust, qu'il soit de fait ou volontairement maintenu, il y a dépendance mondiale à une technologie très avancée, et de ce fait maitrisée par un petit nombre d'acteurs seulement.
C'est plus clair ou il faut encore que je développe ?
Euh ca a quoi à voir avec la choucroute ? [...] Comme disais kennedy 'Celui qui crois que la vie est juste est bien mal renseigné'.
Complètement hors-sujet (troll anti-trust).
Tres drole celle la :D
Un jour bill gates a dis 'Personne a besoin de plus de 640 ko'.
Et on a tous vu ce que ça a donné.
Et le multicore, pourquoi faire ?
Ca vient de deux chose
-> une limitation physique de la fréquence
-> un ordinateur actuel est un systemùe multitache, et peut donc profiter de plusieurs unité d'executions.
On a commencé à le voir arrivé avec l'HT par exemple
- Tout le monde le sait.
- L'escalade en fréquence touche à sa fin (pour un moment en tout cas, avant que l'on ne trouve une nouvelle technologie), et c'est un exemple de ressource qui se tarit.
En tout cas c'est un troll très réussi, que tu nous as pondu là. Je te laisse avoir le dernier mot si ça t'amuses (mais dans ce cas, merci de faire un effort sur le français, par respect pour tes lecteurs).
nsuite , à l'énorme différence avec le logiciel, le matériel coute à reproduire. Faire une fonderie ca demande des investissement énormes ! La maintenir à jour aussi.
Par exemple pour le projet ogp , ils avait donné le cout d'un masque (cad juste pour qu'un fondeur fonde ta puce) : plus de 1 millions de $.
Je le sais bien, mais qu'est-ce que cela change au problème ? On ne fait pas face à un trust de ces compagnie mais plutôt au fait que la société de l'information, dont l'émergence est comparable à une révolution industrielle, s'appuie entièrement sur le savoir-faire de deux acteurs mondiaux ! Et à mon sens, c'est beaucoup plus grave ...
Il ne s'agit même plus de rétention du savoir. Fondre un processeur pour PC aujourd'hui, c'est un peu comme enrichir de l'uranium. Il ne suffit plus de lire la doc'. Même les brevets perdent leur efficacité dans le cas présent puisque l'on atteint un stade où, dans la majorité des cas, un processeur devient obsolète avant qu'un industriel concurrent parvienne à maîtriser suffisamment les techniques pour en produire à son tour.
pour terminé je suis bien d'accord qu'on devrais jeter le x86 et repartir sur des bases neuves. Mais ca casserait toute la compatibilité, et donc les entreprises (qui ont un poid assez important) et les menages (l'autre partie) apprécieront que moyennement => peu de demande => les couts fixes sont moins amortis => prix plus elevé => encore moins de demande.
Ce ne sont pas mes propos.
Lacher la « vieille » archi x86 permettrait probablement de gagner drastiquement en performances, mais c'est une opération qui ne pourra avoir lieu qu'une seule fois. Cela ne résoudra pas le problème de fond.
Les besoins d'un électronicien (au niveau d'un microcontroleur) et d'un informaticien sont totalement différent.
Le code que sorte les electronicien n'as strictement rien à voir comparé a ce qui est par exemple sur un simple téléphone portable ou un pda!
Là encore, tu prends le problème à l'envers. D'abord, ce n'est pas tout-à-fait vrai. L'exemple classique est celui de la dépréciation de port série RS-232 au profit de l'USB. Pratique pour les utilisateurs, mais ingérable au niveau conception, spécialement en ce qui concerne les petites séries. Fort heureusement, il existe désormais des microcontrôleurs qui prennent la partie matérielle en charge, mais la procédure d'énumération, la négotiation de l'alimentation, et le dialogue entre les deux applications sont très compliquées à définir. Il faut non seulement une cadence de travail minimum mais également une quantité non négligeable de mémoire pour stocker le logiciel qui ne servira qu'à la gestion de l'interface.
Ensuite, il faut voir qu'un téléphone portable bat à une cadence bien moindre qu'un ordinateur de bureau. Même si Intel a annoncé des puces pour mobile atteignant le gigaHertz, la majorité des circuits fonctionnent bien en deçà. À cela, s'ajoute le fait que l'appareil doit être sobre en énergie, ne pas chauffer, et pouvoir tenir dans une boite d'allumettes. C'est un peu la quadrature du cercle. Et si quelques fondeurs y parviennent, on se ramène tout de même au problème précédent.
En tout état de cause, il faut bien se rendre compte que si les développeurs ont cessé de chercher à optimiser leur programmes, c'est uniquement dû au fait que les microélectroniciens, eux, font la course à la puce la plus performante. Le mouvement s'essoufle déjà coté fréquence, la tendance actuelle étant axée multicore. Le jour où ils n'y parviendront plus du tout, on pourrait connaître une petite crise économique ...
Toute la question est « C'est quoi, un processeur hautes performances » ?
Il faut bien se rendre compte que si l'on avait eu la même approche de la programmation il y n'y a pas plus de vingt ans, il n'y aurait toujours pas d'ordinateurs dans nos maisons aujourd'hui.
Les deux conséquences majeures que je vois d'ici sont :
- La perte dramatique de savoir-faire dans le métier.
- La dépendance totale du monde à deux ou trois fondeurs de microprocesseurs.
Ce dernier point est très préoccupant pour moi, d'ailleurs, et je ne comprends pas que l'on en fasse pas état plus souvent. Il commence à devenir clair que le monopole de Redmond est inacceptable (stratégiquement) voire dangereux (monoculture), mais rien vis-à-vis du marché du hardware.
Il faut bien se rendre compte que produire un microprocesseur aussi complexe qu'un x86 de dernière génération et le cadencer à 3 GHz est en soi une prouesse technologique. La plupart des autres produits fonctionnent largement en dessous de ce rythme.
Si les fondeurs américains entament un blocus, leur cible se retrouvera totalement privée d'informatique, car elle n'aura plus le savoir métier nécessaire à écrire du logiciel pour des microprocesseurs plus modestes.
Les microcontrôleurs PIC, par exemple, sont très à la mode en ce moment chez les électroniciens et ne battent pourtant qu'à 4 ou 20 MHz (à peu de choses près la fréquence de fonctionnement d'un Amstrad CPC).
Apprendre à être sobre en informatique pourrait bien devenir un enjeu futur après avoir été complètement mis de coté, un peu comme le respect de l'environnement, qui redevient une priorité en ces années 2000.
Si tu ne mets rien au début, le système va essayer de déterminer la nature du contenu du fichier pour pouvoir l'exécuter (essaie la commande file). Dans le pire des cas, s'il arrive à déterminer qu'il s'agit d'un script shell sans savoir lequel en particulier, il est fort probable que le bash soit défini comme étant ton shell de connexion et que ce soit donc lui qui soit sollicité par défaut.
Afin d'optimiser ma base, est 'il plus interressant de stocker un tableau avec l'enssemble des choix dans ma base. Ainsi, je n'aurais qu'une seule entrée enregistrée par utilisateur.
En soi non, car tu brises le modèle relationnel et tu saisis une information qui n'est exploitable que par l'application (et difficilement éditable par le DBA, avec çà).
Actuellement, si un utilisateur choisi toutes les options de ma liste, j'enregistre une centaines d'entrées dans ma base de données.
Ce n'est pas forcément un problème. Dans le pire des cas, si tu répertories 1000 utilisateurs et qu'ils sélectionnent tous la totalité des options, tu obtiendras une table de 100 000 entrées. En considérant que tu utilises des IDs sur 32 bits pour coder ton numéro d'utilisateur comme ton numéro d'option, ta table atteindra péniblement les 800 Ko. Le moindre *.ogg traînant sur ton disque en fait minimum le triple ...
D'autre part, si tu stockes tes infos dans un tableau, tu gagneras sur le l'ID utilisateur, certes (gain minimum de 50%), mais tu stokeras à chaque fois le tableau entier ! Ce qui revient précisément à faire ce que tu cherches à éviter.
En outre, il faut garder à l'esprit que les informations des différents tuples sont stockées de manière contigüe sur ton disque. Donc stocker un tableau de dix entiers dans un enregistrement ou insérer dix entrées dans une table d'une colonne de type entier va se traduire exactement de la même façon sur ton support.
C'est le mauvais coté de la programmation orientée objet, d'ailleurs. On considère l'entité en tant que telle mais on en oublie sa nature, et on devient beaucoup plus sensible au cardinal de son ensemble qu'à son coût unitaire en ressources.
La seule chose qui va être déterminante dans le choix de l'architecture de ta base est la distribution de tes données dans le sens statistique du terme. Nombre d'utilisateurs à choisir des options, nombre moyen d'options sélectionnées par utilisateurs, scoring de tes options (important) : est-ce que 80 % des utilisateurs sélectionnent 20 % des options proposées ou bien est-ce uniformément réparti ? etc.
Par contre, l'intérêt du champ unique est d'éviter d'avoir à recourir à une boucle Fetch(). Certains langages permettent de charger un resultset en une opération mais, bien souvent; celle-ci est implémentée à son tour par une boucle dans le niveau d'abstraction immédiatement inférieur, donc le gain n'est pas réel. En transférant le tout d'un coup tu réduis de manière significative le trafic réseau et la charge système. Par contre, ce n'est palpable que si tu fais la même opération pour des centaines d'utilisateurs à la suite.
En résumé, cela peut-être efficace d'un point de vue technique pure, à condition de rester dans un système statique. Si tu veux par exemple faire évoluer ta base et empêcher certains utilisateurs de sélectionner certaines options, tu pourras aisément poser une contrainte d'intégrité pour que le SGBD rejette les entrées illégales. Si tu utilises un format particulier, tu court-circuites ces fonctionnalités et tu restes donc seul garant de la cohérence de ta base.
[^] # Re: Débilité sans nom
Posté par Obsidian . En réponse au journal Les geeks vont il participer à cet élan d'écologisme. Évalué à 1.
C'est-à-dire que c'est la durée de l'éclairage qui varie, mais un jour a toujours exactement la même durée : 24 heures. La période est donc invariable, mais la phase demeure également : du Groenland jusqu'en antarctique, le maximum d'intensité lumineuse est toujours atteint à midi pile, heure solaire.
Celui qui vit sous terre ne se prive pas seulement de lumière, mais également d'une horloge très précise. Si ton spéléologue s'est adapté à 25 heures, je pense que c'est plus par habitude qu'autre chose ...
[^] # Re: Débilité sans nom
Posté par Obsidian . En réponse au journal Les geeks vont il participer à cet élan d'écologisme. Évalué à 4.
[^] # Re: Flash ?
Posté par Obsidian . En réponse au journal Vous connaissiez cette chanson de Stallman ?. Évalué à -3.
[^] # Re: Question
Posté par Obsidian . En réponse au journal Les geeks vont il participer à cet élan d'écologisme. Évalué à 5.
En même temps, ça reste raisonnable, comme exigence, n'est-ce pas ?
Franchement, les "basse conso", ça me laisse perplexe.
Outre le fait que l'on essaie de nous faire gober que la lueur blafarde d'un tube fluorescent, puisque c'est de cela qu'il s'agit, vaut la chaude lumière d'une ampoule électrique à incandescence (dont le rendement est certes désastreux), il me semble que :
- Ca reste largement plus cher (ne serait-ce qu'à produire) :
- C'est largement moins recyclable !
Une ampoule, c'est du métal, du verre, un peu d'isolant dans le culot, et le cas particulier du filament en tungstène. On peut facilement envisager une filière de retraitement. Pour les plus classiques, une sorte de ciseau comme pour les oeufs à la coque suffit à séparer l'ampoule proprement dite (le verre) du reste du dispositif.
Une basse conso, c'est un gros carter en plastique qui embarque un régulateur électronique complexe et un tube très épais (beaucoup plus que les "néons" classiques) avec son revêtement fluorescent.
Autant que je sache, il n'y a pas de filière répandue pour faire le recyclage de ces produits. Comme il n'y a rien de prévu à ce sujet coté tri sélectif, tout cela passe directement à l'incinérateur. Même si les plus modernes filtrent leurs fumées, je ne suis pas sûr que ce que l'on gagne en énergie compense la polution supplémentaire produire par rapport à une ampoule classique ...
[^] # Re: Flash ?
Posté par Obsidian . En réponse au journal Vous connaissiez cette chanson de Stallman ?. Évalué à 0.
Le principal inconvénient du Flash, outre le fait qu'il ne soit pas libre (et encore, les spécifications du format restent disponibles) est son manque de diffusion sur les plate-formes s'éloignant un tant soi peu de l'IA32.
Hormis cela, c'est quand même un outil vectoriel puissant et très bien réalisé. Et pour l'usage que l'on en fait sur le web, c'est tout de même un poil plus optimisé qu'un GIF animé ...
# man join, effectivement.
Posté par Obsidian . En réponse au message Comment fusionner 2 tables. Évalué à 2.
Tu as l'air de savoir que cette opération s'appelle une jointure donc je ne t'apprendrai rien en te disant que c'est la clé de voûte des bases de données.
Donc, si tu comptes recourir massivement à ce genre d'outil, un petit MySQL/PostgreSQL sera largement plus approprié ...
[^] # Re: malpropre !
Posté par Obsidian . En réponse au message Killer un processus sans fermer la socket ?. Évalué à 2.
man page powah ! :-)
[^] # Re: malpropre !
Posté par Obsidian . En réponse au message Killer un processus sans fermer la socket ?. Évalué à 4.
[^] # Re: Les deux autres
Posté par Obsidian . En réponse à la dépêche Première implémentation du langage Fortress. Évalué à 3.
[^] # Re: Re
Posté par Obsidian . En réponse au journal Mon dieu, un logiciel gratuit!. Évalué à 3.
Il est normal à toutes les époques de trouver des gens qui découvrent le logiciel libre, puisqu'à toutes les époques on trouve des gens qui débutent dans l'informatique d'une manière générale. Et le fait est que l'OS de Redmond ne leur permet pas de voir d'emblée tout ce qui peut se faire sur un ordinateur ... et ce n'est pas non plus chez les revendeurs que l'on va trouver du conseil de qualité. Donc, il est effectivement de salubrité publique d'éclairer la lanterne d'une brebis égarée lorsque l'on en croise une. La plupart du temps, l'individu concerné est loin d'être un imbécile, et il semble que ce soit le cas pour ce blogueur.
Si en plus, ça peut être drôle, il n'y a pas de raison de se priver ... :-)
[^] # Re: Snif
Posté par Obsidian . En réponse au journal Microsoft, mort dans 3 ans ?. Évalué à 10.
[^] # Re: Vieux Paf ?
Posté par Obsidian . En réponse au message Out of Memory !!!!. Évalué à 2.
# Vieux Paf ?
Posté par Obsidian . En réponse au message Out of Memory !!!!. Évalué à 8.
[^] # Re: Plop !
Posté par Obsidian . En réponse au journal "L'informatique Paradoxale". Évalué à 2.
Tu as réussi à me faire dire exactement le contraire de ce que j'exprime, et ce pratiquement à chacun des mes paragraphes. Donc, et comme tu sembles être très impulsif, je vais rectifier point par point, ensuite je cesse d'alimenter ce thread.
C'est justement ce que je dis plus haut.
La plupart des programmeurs, aujourd'hui, ne connaissent que la puissance de leur PC de dernière génération, alors que cette puissance est difficile à atteindre.
À ce point, c'est pratiquement de la diffamation.
J'ai volontairement omis ce cas de figure car il est fallacieux (et évidemment, tu sautes dedans à pieds joints) : « ce n'est pas compliqué puisque ce n'est pas toi qui le réalise » ! Les électroniciens dont tu parles, si.
Là encore, à aucun moment, je n'ai « critiqué » cette politique de coût
Je te la fais en plus court : Il n'y a pas de trust, qu'il soit de fait ou volontairement maintenu, il y a dépendance mondiale à une technologie très avancée, et de ce fait maitrisée par un petit nombre d'acteurs seulement.
C'est plus clair ou il faut encore que je développe ?
Complètement hors-sujet (troll anti-trust).
Et on a tous vu ce que ça a donné.
- Tout le monde le sait.
- L'escalade en fréquence touche à sa fin (pour un moment en tout cas, avant que l'on ne trouve une nouvelle technologie), et c'est un exemple de ressource qui se tarit.
En tout cas c'est un troll très réussi, que tu nous as pondu là. Je te laisse avoir le dernier mot si ça t'amuses (mais dans ce cas, merci de faire un effort sur le français, par respect pour tes lecteurs).
[^] # Re: Plop !
Posté par Obsidian . En réponse au journal "L'informatique Paradoxale". Évalué à 2.
Je le sais bien, mais qu'est-ce que cela change au problème ? On ne fait pas face à un trust de ces compagnie mais plutôt au fait que la société de l'information, dont l'émergence est comparable à une révolution industrielle, s'appuie entièrement sur le savoir-faire de deux acteurs mondiaux ! Et à mon sens, c'est beaucoup plus grave ...
Il ne s'agit même plus de rétention du savoir. Fondre un processeur pour PC aujourd'hui, c'est un peu comme enrichir de l'uranium. Il ne suffit plus de lire la doc'. Même les brevets perdent leur efficacité dans le cas présent puisque l'on atteint un stade où, dans la majorité des cas, un processeur devient obsolète avant qu'un industriel concurrent parvienne à maîtriser suffisamment les techniques pour en produire à son tour.
Ce ne sont pas mes propos.
Lacher la « vieille » archi x86 permettrait probablement de gagner drastiquement en performances, mais c'est une opération qui ne pourra avoir lieu qu'une seule fois. Cela ne résoudra pas le problème de fond.
Là encore, tu prends le problème à l'envers. D'abord, ce n'est pas tout-à-fait vrai. L'exemple classique est celui de la dépréciation de port série RS-232 au profit de l'USB. Pratique pour les utilisateurs, mais ingérable au niveau conception, spécialement en ce qui concerne les petites séries. Fort heureusement, il existe désormais des microcontrôleurs qui prennent la partie matérielle en charge, mais la procédure d'énumération, la négotiation de l'alimentation, et le dialogue entre les deux applications sont très compliquées à définir. Il faut non seulement une cadence de travail minimum mais également une quantité non négligeable de mémoire pour stocker le logiciel qui ne servira qu'à la gestion de l'interface.
Ensuite, il faut voir qu'un téléphone portable bat à une cadence bien moindre qu'un ordinateur de bureau. Même si Intel a annoncé des puces pour mobile atteignant le gigaHertz, la majorité des circuits fonctionnent bien en deçà. À cela, s'ajoute le fait que l'appareil doit être sobre en énergie, ne pas chauffer, et pouvoir tenir dans une boite d'allumettes. C'est un peu la quadrature du cercle. Et si quelques fondeurs y parviennent, on se ramène tout de même au problème précédent.
En tout état de cause, il faut bien se rendre compte que si les développeurs ont cessé de chercher à optimiser leur programmes, c'est uniquement dû au fait que les microélectroniciens, eux, font la course à la puce la plus performante. Le mouvement s'essoufle déjà coté fréquence, la tendance actuelle étant axée multicore. Le jour où ils n'y parviendront plus du tout, on pourrait connaître une petite crise économique ...
[^] # Re: Plop !
Posté par Obsidian . En réponse au journal "L'informatique Paradoxale". Évalué à 6.
Il faut bien se rendre compte que si l'on avait eu la même approche de la programmation il y n'y a pas plus de vingt ans, il n'y aurait toujours pas d'ordinateurs dans nos maisons aujourd'hui.
Les deux conséquences majeures que je vois d'ici sont :
- La perte dramatique de savoir-faire dans le métier.
- La dépendance totale du monde à deux ou trois fondeurs de microprocesseurs.
Ce dernier point est très préoccupant pour moi, d'ailleurs, et je ne comprends pas que l'on en fasse pas état plus souvent. Il commence à devenir clair que le monopole de Redmond est inacceptable (stratégiquement) voire dangereux (monoculture), mais rien vis-à-vis du marché du hardware.
Il faut bien se rendre compte que produire un microprocesseur aussi complexe qu'un x86 de dernière génération et le cadencer à 3 GHz est en soi une prouesse technologique. La plupart des autres produits fonctionnent largement en dessous de ce rythme.
Si les fondeurs américains entament un blocus, leur cible se retrouvera totalement privée d'informatique, car elle n'aura plus le savoir métier nécessaire à écrire du logiciel pour des microprocesseurs plus modestes.
Les microcontrôleurs PIC, par exemple, sont très à la mode en ce moment chez les électroniciens et ne battent pourtant qu'à 4 ou 20 MHz (à peu de choses près la fréquence de fonctionnement d'un Amstrad CPC).
Apprendre à être sobre en informatique pourrait bien devenir un enjeu futur après avoir été complètement mis de coté, un peu comme le respect de l'environnement, qui redevient une priorité en ces années 2000.
# Quel titre !
Posté par Obsidian . En réponse au journal [HS] Je présente mes excuses aux actionnaires et aux employés pour ces problèmes, survenus sous ma tutelle. Évalué à 5.
[^] # Re: /bin/bash
Posté par Obsidian . En réponse au message Script Bash. Évalué à 2.
[^] # Re: cinisme
Posté par Obsidian . En réponse au journal La routine.... Évalué à 3.
[^] # Re: l'architecture de Firefox dangereuse
Posté par Obsidian . En réponse au journal Un système véritablement sécurisé devrait.... Évalué à 2.
[^] # Re: Mot courant...
Posté par Obsidian . En réponse au journal Framasoft mis en demeure de constater un certain manque de lucidité. Évalué à 2.
Et « office » tout autant puisque cela signifie « bureau » (la pièce, pas la table) !
Par contre, j'ai effectivement bondi en lisant le message, mais la mention
... me laisse croire qu'il s'agit effectivement du second degré.
# Mauvaise idée.
Posté par Obsidian . En réponse au message Stocker un tableau dans une base sql. Évalué à 6.
En soi non, car tu brises le modèle relationnel et tu saisis une information qui n'est exploitable que par l'application (et difficilement éditable par le DBA, avec çà).
Ce n'est pas forcément un problème. Dans le pire des cas, si tu répertories 1000 utilisateurs et qu'ils sélectionnent tous la totalité des options, tu obtiendras une table de 100 000 entrées. En considérant que tu utilises des IDs sur 32 bits pour coder ton numéro d'utilisateur comme ton numéro d'option, ta table atteindra péniblement les 800 Ko. Le moindre *.ogg traînant sur ton disque en fait minimum le triple ...
D'autre part, si tu stockes tes infos dans un tableau, tu gagneras sur le l'ID utilisateur, certes (gain minimum de 50%), mais tu stokeras à chaque fois le tableau entier ! Ce qui revient précisément à faire ce que tu cherches à éviter.
En outre, il faut garder à l'esprit que les informations des différents tuples sont stockées de manière contigüe sur ton disque. Donc stocker un tableau de dix entiers dans un enregistrement ou insérer dix entrées dans une table d'une colonne de type entier va se traduire exactement de la même façon sur ton support.
C'est le mauvais coté de la programmation orientée objet, d'ailleurs. On considère l'entité en tant que telle mais on en oublie sa nature, et on devient beaucoup plus sensible au cardinal de son ensemble qu'à son coût unitaire en ressources.
La seule chose qui va être déterminante dans le choix de l'architecture de ta base est la distribution de tes données dans le sens statistique du terme. Nombre d'utilisateurs à choisir des options, nombre moyen d'options sélectionnées par utilisateurs, scoring de tes options (important) : est-ce que 80 % des utilisateurs sélectionnent 20 % des options proposées ou bien est-ce uniformément réparti ? etc.
Par contre, l'intérêt du champ unique est d'éviter d'avoir à recourir à une boucle Fetch(). Certains langages permettent de charger un resultset en une opération mais, bien souvent; celle-ci est implémentée à son tour par une boucle dans le niveau d'abstraction immédiatement inférieur, donc le gain n'est pas réel. En transférant le tout d'un coup tu réduis de manière significative le trafic réseau et la charge système. Par contre, ce n'est palpable que si tu fais la même opération pour des centaines d'utilisateurs à la suite.
En résumé, cela peut-être efficace d'un point de vue technique pure, à condition de rester dans un système statique. Si tu veux par exemple faire évoluer ta base et empêcher certains utilisateurs de sélectionner certaines options, tu pourras aisément poser une contrainte d'intégrité pour que le SGBD rejette les entrées illégales. Si tu utilises un format particulier, tu court-circuites ces fonctionnalités et tu restes donc seul garant de la cohérence de ta base.
Bon courage.
[^] # Re: liens entrants et sortants
Posté par Obsidian . En réponse au journal Pourquoi l'on vous interdit de mettre de liens vers certains sites. Évalué à 3.
[^] # Re: DRM is not where it should be ...
Posté par Obsidian . En réponse au journal L'avis de Bill Gates sur les DRM. Évalué à 2.
[^] # Re: Et sinon...
Posté par Obsidian . En réponse au journal Moinsage : et vous, vous faîtes comment ?. Évalué à 4.
Donc, sur la plupart des distribs Linux sur PC, un AltGr+Shift+0 (le « à ») donne un « À ».