Et si tu le fais en administrateur consciencieux, tu vérifies en plus que ta distrib' n'exploite pas déjà un fichier dédié pour cela, ce qui t'éviteras d'avoir à écrire un script exprès et garantira la compatibilité avec les reste des outils qu'elle propose ...
iptables définit des chaînes qui sont directement exploitées en mémoire par le module du noyau. Si tu redémarres, c'est normal qu'elles soient vides. Tu les mets toutes dans un seul fichier et tu les repasses en une fois au démarrage.
Quelle distribution utilises-tu ? Si c'est une Fedora, par exemple, le fichier en question existe déjà : /etc/sysconfig/iptables
Il y a même plein d'options sympas dans /etc/sysconfig/iptables-config
j'ai l'impression que toutes les instructions cpu sont exécutée par ma workstation (rapidité de KDE) mais que les instructions GPU sont exécutées par le portable (bzflag lag à crevé)
Ni l'un ni l'autre, à mon avis, mais OpenGL doit fonctionner sur la machine qui héberge la carte 3D, si carte 3D il y a, ce qui n'est probablement pas le cas de ton portable. Si tu désactives l'accélération 3D sur ta workstation, le truc va ramer aussi, même si c'est un peu moins.
En outre, même si tu faisais faire un rendu purement soft avec Mesa sur ta grosse machine, il faudrait ensuite renvoyer en permanence le résultat à travers le réseau vers ton portable et là, il te faudrait le débit du port AGP, pas celui d'Ethernet. Et même là, les jeux gourmands en ressources saturent déjà le port en envoyant des directives à la carte graphique. Balancer le rendu en temps réel pourrait dépasser la limite disponible rien qu'en local.
Bref, tu pourrais peut-être gagner quelques FPS mais rien de transcendant ...
La semaine dernière, la plupart des dépêches sur l'affaire de la fraude à la Société générale présentaient Jerôme Kerviel comme un petit génie de l'informatique[1] :
C'est pas un secret : on s'est tous rendus compte du premier coup que Jerôme Kerviel, c'est en fait le pseudonyme de Jean-Kevin ...
Un grand merci à toutes les personnes ayant fournit un retour sur le forum
Moment Capello, mais fournir au participe passé s'écrit "fourni", sans t final. Comme tous les verbes du deuxième groupe, notamment "subir".
Je le précise parce que non seulement on voit l'erreur très fréquemment, mais je me suis même fait annuler certains amendements que j'avais fait sur des articles Wikipédia. Certains croient y dur comme fer.
C'est une faute courante car les trois verbes en "ir" les plus fréquents dans le langage courant sont en fait des verbes du troisième groupe : "écrire","lire","dire". Ils finissent tous par "ire" et par "ir".
Dans le cas de "subir", c'est encore pire parce que les gens confondent avec l'adjectif "subit, subite" qui n'a rien à voir.
Le journal, c'est surtout le log des actions effectuées ou sur le point de l'être. C'est assez rare que l'on y copie les données proprement dites. En cas d'interruption sauvage, on peut ainsi savoir ce que l'on était en train de faire et nettoyer la place en conséquence sans incertitude.
Ca sert surtout à garantir l'intégrité du système de données lui-même plutôt que la disponibilité de ce que l'on était en train d'écrire au moment de la panne.
Elle est vieille, a été reprise partout, et est bien antérieure à Windows (95, en tout cas), pour autant que je sache. Il me semble qu'elle est authentique, mais je n'arrive plus à en trouver l'origine.
On l'attribuerait à un policitien newfie qui lurait dit cela sérieusement dans un congrès. A vérifier, donc.
Il faut souligner que l'AFDEL, c'est l' "ASSOCIATION FRANCAISE DES EDITEURS DE LOGICIELS ". L'activité principale desdits éditeurs étant de vendre des logiciels, on comprend mieux la position de l'auteur et de ce point de vue, le texte apparaît plus modéré qu'en première lecture.
Par contre, dire que la commission Attali tourne le dos à l'innovation en favorisant le logiciel libre, c'est quand même gonflé. Il n'y a guère que chez MS qu'on pouvait lire ce genre de chose. Même sur Linuxfr, on n'oserait pas faire le contraire.
La première version de Paranoïa est positivement parfaite sous tous rapports. L'Ordinateur l'affirme. Il affirme également que la seconde version est encore plus parfaite. Oseriez-vous mettre en doute les propos de l'Ordinateur ?
C'est-à-dire que "plastique" est un adjectif qui peut s'appliquer à n'importe quoi et qui signifie modelable, façonnable ...
Effectivement, l'origine du mot américain vient bien de l'explosif plastique, mais du coup, on pourrait utiliser cette terminologie pour n'importe quel explosif mou (ce qui est peut-être ce que l'on cherche), alors qu'avec le temps, les américains ont généralement associé le mot au C4. Dans ce cas, on l'utilise tel quel et on le met même en italique pour montrer que c'est un terme étranger.
Perdu : ce sont des fautes brevetées aux Etats-Unis, et considérées comme une oeuvre de l'esprit en Europe, dont sujettes aux droits d'auteur. Il te faudra attendre 70 ans après la mort de leur auteur pour pouvoir les exploiter, ce qui est une raison de plus pour écrire correctement d'ailleurs. Vive l'orthographe libre !
Là, en plus son problème ne concerne pas seulement ses tables, mais ses formulaires. Pour rappel (ou pas) les formulaires sous Access, c'est l'une des six entités que l'on peut créer au sein d'une "base", et qui prennent la forme de boîtes de dialogue dont les composants peuvent être directement liés à la base.
Plus que de gérer le stock, il cherche donc à faire une interface dynamique. C'est faisable, mais c'est du vrai développement et ça ne se fait pas en une minute.
Je suis prêt à parier que cette application doit en plus être partagée et distribuée, de manière à ce que les informations de tous les postes soient automatiquement mises à jour chaque fois qu'un vendeur saisit une commande, et que l'atomicité et l'exclusivité des transactions soient bien entendues garanties, cela va sans dire ...
Sinon, tu peux installer le package idoine, si ce n'est déjà fait :
sudo apt-get install manpages-fr
Mais attention : souviens-toi qu'elles ne sont pas toutes traduites, et qu'elles évoluent souvent. Donc même si la majorité de ta doc sera francophone, il restera toujours quelques pages en anglais, et ce sera vrai sur tous les systèmes.
Ok, j'ai fait une erreur dans un ordre de grandeur, ce n'est pas bien grave en soi. C'était pour donner une idée de ma pensée dans un commentaire Linuxfr, par pour soutenir une thèse.
Ce que je voulais dire, c'est que si l'on suit une progression géométrique style loi de Moore, on va finir par rencontrer ce genre de souci dans un intervalle de temps comparable à celui qu'il a fallu pour passer de 16 à 32 bits, c'est-à-dire pas grand chose. Même avec mille atomes par bit de mémoire, ça reste compliqué à mettre en oeuvre.
Pour autant, ça ne remet pas en cause l'utilité d'une architecture 64 bits. On est même à 128 sur certaines machines (consoles de jeux, en particulier) parce que c'est pratique pour des utilisations ciblées et que celles-ci sont suffisamment rentables à elles seules pour justifier la conception de telles machines.
En ce qui concerne l'adressage proprement dit, 4 Go de mémoire sont déjà atteints et exploités depuis quelque temps. Rien que ça justifie le 64 bits. Par contre, en considérant 2^64 octets de mémoire, un facteur très limitant restera le temps qu'il faut pour y accéder.
Evidemment, on paralélisera, on fera des MMU plus puissantes, etc. M'enfin, j'espère que d'ici à ce que la limite soit atteinte, on sera passé à une autre architecture que celle d'un PC.
C'est grosso-modo ce que j'explique au-dessus (mais je conçois que mon commentaire est un peu long et qu'on a envie de le lire en diagonale).
Encore faux. Les "double" ont toujours tenu sur un seul registre, puisqu'ils ont toujours eu des registres dédiés au sein de l'unité de calcul à virgule flottante (en tout cas depuis que cette dernière existe, c'est-à-dire bien longtemps).
C'est ce que j'explique au-dessus. C'est quelque chose dont on fait abstraction parce que l'on s'appuie sur le coprocesseur mathématique qui, lui, est effectivement en 64 bits depuis longtemps. Mais les données n'y passent pas leur vie.
Le même prix ? C'est vite dit. Il prend deux fois plus de place en mémoire, ce qui n'est pas très gênant certes, mais surtout les opérations effectuées sur les double sont plus lourdes que sur les float, ce qui fait que la plupart des CPU peuvent en exécuter moins par cycle.
Même chose.
Encore faux, seuls les pointeurs doublent de taille, les entiers selon les cas restent sur 32 bits (int) ou passent à 64 (long),
.
Les long changent donc de format, les pointeurs aussi, et tout ce qui manipulé en interne à la compilation du code dans les registres. De toutes façons, ces formats de nombres concernent ici le langage C. Un changement d'architecture doit être examiné sur toutes les plateforme de développement.
quand aux flottants leur taille est inchangée comme expliqué plus haut.
C'est un raccourci un peu rapide, je te le concède, mais il me semble 2^64 atomes est plus que ce tu peux mettre dans le boîtier d'un PC. Je me trompe peut-être ...
Moi, je partage ton point de vue depuis longtemps. Passer de 32 à 64 est très différent de passer de 16 à 32. Ce qu'il faut prendre en considération, c'est :
- A prix égal et, surtout, si le système est compatible 32, cela ne vaut pas le coup de se priver. Ca permet de voir venir les nouveautés, et de se familiariser avec la programmation des nouveaux jeux d'instructions et la nouvelle architecture, ce qui est toujours très intéressant ...pour peu que l'on programme encore un minimum en assembleur ! Si c'est pour tout demander à gcc et faire de la compatibilité ascendente en nivelant par le bas, ça n'a aucun intérêt.
- Un nouveau jeu d'instruction et surtout des registres supplémentaires permettent d'être très efficace. Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.
- 64 bits, ça permet de dépasser 4 Go d'adressage direct et on en aura forcément besoin à terme. 512 Mo de RAM tend à devenir la norme et même les portables "conçus pour le jeu" chez Dell, par exemple, déjà sont livrés avec 2048 Mo.
Maintenant, je ne suis pas sûr que ce soit une bonne chose en soi que laisser cet état de fait devenir la norme. Dépasser 4Go, ce n'est pas du tout la même chose que de dépasser 64Ko. Même en progressant, la consommation de RAM devrait croître de manière linéaire, pas exponentielle ! Pour la plupart des gens, ce ne sont que des chiffres, que se valent à différentes époques, à la manière des francs et euros constants.
- Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique. Quand tu regardes des vidéos, certes (même si elles ne durent que 5 minutes, tu aspires quand même à ce qu'elles soient fluides dans l'intervalle, et qu'elles ne consomment pas trop de temps CPU, ni trop de bus), mais également quand tu travailles sous GIMP, ou même simplement lorsque tu déplaces une fenêtre ! Une fenêtre en 1280*768 et en 32 bits, mine de rien, ça fait beaucoup de mémoire ! Et comme, lorsque la résolution augmente, elle le fait dans les sens verticaux et horizontaux, cette quantité augmente au carré, encore une fois.
Bref, à partir d'une certaine quantité de données, travailler en 64 bits peut soulager ton processeur et augmenter, même d'un point de vue uniquement théorique, la rapidité d'exécution d'un algorithme, et ce même en dessous de 4Go de RAM.
important : Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits. Sinon, il y a conversion par des circuits externes et évidement, les perfs chutent.
- Les "double" tiennent enfin, à nouveau, sur un seul registre. J'ai toujours considéré cela comme une faiblesse des formations en programmation. J'ai un float et un double. Le double a une mantisse beaucoup plus large pour le même prix. Alors, je choisis le double, au point que les nouveaux programmeurs ne savent même plus que float existe.
Les tailles 32 et 64 bits des flottants sont ainsi parce qu'elles sont nomalisées, mais personne ne sait vraiment comment elles sont traitées en profondeur. Depuis qu'il y a un coprocesseur, les gens ne s'en soucient plus. Même les environnement de développement intégrés proposent des double par défaut. N'empêche que les accès bus et la mémoire consommée en demeurent effectivement doublés.
A l'époque des 8 bits, on utilisait déjà les mêmes formats, et il fallait de toutes façons une boucle pour traiter l'un comme l'autre. Sur un 32 bits, un float tient dans un registre (tel que EAX), pas un double.
Puisque le format de ces nombres est normalisé quelque soit l'architecture, on peut espérer des gains sur les programmes qui utilisent massivement le double. La plupart, pour ce que j'ai pu en voir.
- Enfin, 65535, c'est tout de suite atteint. 4 milliards beaucoup moins vite, mais ça reste courant. 2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.
- Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.
C'est inquiétant parce que la croissance exponentielle de la mémoire requise est due en grande partie aux dépendances entre les différentes couches d'abstraction. Si on continue à en ajouter, et si en plus les couches existantes consomment plus de mémoire sans même gagner une ligne de code, alors on va atteindre physiquement les limites de la mémoire adressable comme on a atteint celles de la finesse de la gravure, et ce avant même de passer aux 128 bits.
Donc, faire des frais pour passer explicitement en 64 bits, ça ne sert à rien. Par contre, si c'est dans un plan prévu de remplacement de tes machines, ce n'est (presque) que des avantages.
je constate aussi que la vae n'est pas un dispositif simple, de part l'écart entre les référentiels de formation (menant aux diplômes d'état) et les tâches, missions, projets divers effectués dans le boulot. Pas facile non plus, c'est logique, pour un établissement de formation de passer du stade de lieu de transmission de savoir et de savoir-faire au stade de lieu de délivrance de diplôme à quelqu'un qui n'a jamais mis les pieds chez eux.
Tu mets le doigt dessus, mais plus loin encore, ta validation va effectivement se dérouler dans une école où l'on cherchera clairement à savoir comment tu as obtenu ton « savoir académique », dixit une conseillère VAE, à l'époque où j'ai cherché à faire la même chose que toi. Certes, l'examen est adapté à ta situation mais dans l'absolu, tu devrais être capable de passer le même partiel que les étudiants normaux.
Faisable, donc, mais pas sans préparation. La simple expérience professionnelle ne suffira pas. Ça vaut le coup quand même, à condition d'être bien conseillé et dès le départ.
une dernière question : que pensez vous des certifications "techniques" glanées de ci de là (type certifications novell, microsoft, ou lpi) ?
Je dis peut-être une bêtise, mais il me semble qu'à la base, c'est Microsoft qui a lancé le principe. En tout cas, ce sont les premières du genre que j'avais rencontré. À l'époque, les « Microsoft Certified Professional », ça me faisait bondir, maintenant on en trouve un peu partout, donc, ça rétablit l'équilibre.
La réponse est simple : ce sont effectivement des bouts de papier sans valeur, enfin plus précisément, ils n'en ont que pour les gens qui s'intéressent à la technologie qu'ils concernent.
L'important est que ce ne sont pas des diplômes qui te permettront a priori de prétendre à quelque chose en particulier. Ce ne sont pas non plus des équivalents à des attestations d'état. Par contre, cela peut faire gagner beaucoup de temps à un recruteur qui peut voir d'un coup le panel de questions auxquelles tu as répondu correctement. Et c'est pratique si tu convoites un poste précis, ou que ton employeur veut te confier une tâche bien définie. Après, cela te mets en meilleure position pour négocier éventuellement ta place et ton salaire, mais ça reste à toi de le faire.
Ce qui est intéressant avec ces certifs, c'est qu'elles sont très spécialisées, beaucoup plus en rapport avec le sujet qu'un diplôme général, mais elles sont aussi de fait très périssables et çà, ça me dérange un peu. L'autre problème, c'est que tu ne peux jamais savoir à l'avance ce qu'elles valent réellement : cela n'a aucun intérêt de savoir où se trouve le bouton de tel panneau de telle version de telle application, comme on en a déjà vu dans certains questionnaires. Et ça m'ennuie de m'investir scolairement dans un truc qui sera périmé au bout de deux ans.
En bref, un plus pour toi, si tu le souhaites ou si tu cibles quelque chose de précis, mais en aucun cas un passage obligé. Pour les quelques CV que j'ai vu circuler, ça reste encore peu fréquent.
Moi, ce qui me fait tiquer le plus, c'est le point numéro 4 :
4. Our different products may have the same GPL source. You may receive the same GPL source CD-R when you request GPL source on different products.
Il me semble que la GPL n'impose pas seulement la redistribution du code source original, mais bien du code modifié ! Maintenant, ce n'est pas incompatible, un même logiciel peut effectivement être embarqué dans différentes boiboîtes à usages différents, mais c'est à surveiller.
Sinon, oui, 20$ pour obtenir les sources, c'est clairement fait pour faire un max de profit tout en dissuadant le quidam moyen de regarder comment c'est fait.
Bah, de toutes façons, je parie que le code modifié doit exploiter un max de firmwares, eux, bien propriétaires, mais je suis probablement mauvaise langue.
[^] # Re: iptables-save
Posté par Obsidian . En réponse au message Comment sauvegarder mes règles ip6tables. Évalué à 3.
Et si tu le fais en administrateur consciencieux, tu vérifies en plus que ta distrib' n'exploite pas déjà un fichier dédié pour cela, ce qui t'éviteras d'avoir à écrire un script exprès et garantira la compatibilité avec les reste des outils qu'elle propose ...
[^] # Re: iptables-save
Posté par Obsidian . En réponse au message Comment sauvegarder mes règles ip6tables. Évalué à 3.
Ok, j'avais mal lu.
A noter que iptables-save te renvoie le contenu des chaînes sur la sortie standard. A charge à toi de la rediriger vers un fichier.
# iptables-save
Posté par Obsidian . En réponse au message Comment sauvegarder mes règles ip6tables. Évalué à 2.
iptables définit des chaînes qui sont directement exploitées en mémoire par le module du noyau. Si tu redémarres, c'est normal qu'elles soient vides. Tu les mets toutes dans un seul fichier et tu les repasses en une fois au démarrage.
Quelle distribution utilises-tu ? Si c'est une Fedora, par exemple, le fichier en question existe déjà : /etc/sysconfig/iptables
Il y a même plein d'options sympas dans /etc/sysconfig/iptables-config
# OpenGL ?
Posté par Obsidian . En réponse au message Xorg et xdmcp, optimisation OpenGL.. Évalué à 2.
Ni l'un ni l'autre, à mon avis, mais OpenGL doit fonctionner sur la machine qui héberge la carte 3D, si carte 3D il y a, ce qui n'est probablement pas le cas de ton portable. Si tu désactives l'accélération 3D sur ta workstation, le truc va ramer aussi, même si c'est un peu moins.
En outre, même si tu faisais faire un rendu purement soft avec Mesa sur ta grosse machine, il faudrait ensuite renvoyer en permanence le résultat à travers le réseau vers ton portable et là, il te faudrait le débit du port AGP, pas celui d'Ethernet. Et même là, les jeux gourmands en ressources saturent déjà le port en envoyant des directives à la carte graphique. Balancer le rendu en temps réel pourrait dépasser la limite disponible rien qu'en local.
Bref, tu pourrais peut-être gagner quelques FPS mais rien de transcendant ...
# Petit Genie Hacker
Posté par Obsidian . En réponse au journal Spécialiste de l'informatique banquaire.... Évalué à 10.
C'est pas un secret : on s'est tous rendus compte du premier coup que Jerôme Kerviel, c'est en fait le pseudonyme de Jean-Kevin ...
# De bon aloi
Posté par Obsidian . En réponse à la dépêche Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE. Évalué à 2.
Moment Capello, mais fournir au participe passé s'écrit "fourni", sans t final. Comme tous les verbes du deuxième groupe, notamment "subir".
Je le précise parce que non seulement on voit l'erreur très fréquemment, mais je me suis même fait annuler certains amendements que j'avais fait sur des articles Wikipédia. Certains croient y dur comme fer.
C'est une faute courante car les trois verbes en "ir" les plus fréquents dans le langage courant sont en fait des verbes du troisième groupe : "écrire","lire","dire". Ils finissent tous par "ire" et par "ir".
Dans le cas de "subir", c'est encore pire parce que les gens confondent avec l'adjectif "subit, subite" qui n'a rien à voir.
http://www.leconjugueur.com/php/newconjugue.php?lang=fr&(...)
[^] # Re: Recruteront-ils...
Posté par Obsidian . En réponse au journal 13 000 PC sous SuSE Linux !. Évalué à 3.
# Tout s'explique !
Posté par Obsidian . En réponse au journal Future Combat Systems. Évalué à 10.
Ah ah ! Ils croyaient qu'on ne les aurait pas vu ? Ben, c'est raté ! :-)
# Journal
Posté par Obsidian . En réponse au message journalisation coupure pendant la copie. Évalué à 8.
Ca sert surtout à garantir l'intégrité du système de données lui-même plutôt que la disponibilité de ce que l'on était en train d'écrire au moment de la panne.
[^] # Re: Mouais...
Posté par Obsidian . En réponse au journal Excellente nouvelle pour Microsoft. Évalué à 2.
On l'attribuerait à un policitien newfie qui lurait dit cela sérieusement dans un congrès. A vérifier, donc.
# AFDEL
Posté par Obsidian . En réponse au journal Le rapport Attali fait dire d'énormes bêtises à L'AFDEL. Évalué à 10.
Par contre, dire que la commission Attali tourne le dos à l'innovation en favorisant le logiciel libre, c'est quand même gonflé. Il n'y a guère que chez MS qu'on pouvait lire ce genre de chose. Même sur Linuxfr, on n'oserait pas faire le contraire.
[^] # Re: Et beh ...
Posté par Obsidian . En réponse au journal Excellente nouvelle pour Microsoft. Évalué à 3.
Tellement vrai, dans certains cas ... :-)
[^] # Re: Mouais...
Posté par Obsidian . En réponse au journal Excellente nouvelle pour Microsoft. Évalué à 4.
Effectivement, l'origine du mot américain vient bien de l'explosif plastique, mais du coup, on pourrait utiliser cette terminologie pour n'importe quel explosif mou (ce qui est peut-être ce que l'on cherche), alors qu'avec le temps, les américains ont généralement associé le mot au C4. Dans ce cas, on l'utilise tel quel et on le met même en italique pour montrer que c'est un terme étranger.
[^] # Re: Mouais...
Posté par Obsidian . En réponse au journal Excellente nouvelle pour Microsoft. Évalué à 5.
[^] # Re: suggestions
Posté par Obsidian . En réponse au message BD sur ACCESS et VBA. Évalué à 2.
Plus que de gérer le stock, il cherche donc à faire une interface dynamique. C'est faisable, mais c'est du vrai développement et ça ne se fait pas en une minute.
Je suis prêt à parier que cette application doit en plus être partagée et distribuée, de manière à ce que les informations de tous les postes soient automatiquement mises à jour chaque fois qu'un vendeur saisit une commande, et que l'atomicité et l'exclusivité des transactions soient bien entendues garanties, cela va sans dire ...
# web et package
Posté par Obsidian . En réponse au message je veux le man des commandes en francais. Évalué à 6.
Tu peux les trouver n'importe où en ligne, notamment ici :
http://www.linuxfr-france.org.invalid/article/man-fr/
Sinon, tu peux installer le package idoine, si ce n'est déjà fait :
sudo apt-get install manpages-fr
Mais attention : souviens-toi qu'elles ne sont pas toutes traduites, et qu'elles évoluent souvent. Donc même si la majorité de ta doc sera francophone, il restera toujours quelques pages en anglais, et ce sera vrai sur tous les systèmes.
[^] # Re: Mouais...
Posté par Obsidian . En réponse au journal Excellente nouvelle pour Microsoft. Évalué à 10.
# Défait ?
Posté par Obsidian . En réponse au journal le site de hitechpros défait !. Évalué à 3.
[^] # Re: Explications sur 64 bits
Posté par Obsidian . En réponse au journal x86_64 en général et sur Mdv en particulier. Évalué à 3.
Ce que je voulais dire, c'est que si l'on suit une progression géométrique style loi de Moore, on va finir par rencontrer ce genre de souci dans un intervalle de temps comparable à celui qu'il a fallu pour passer de 16 à 32 bits, c'est-à-dire pas grand chose. Même avec mille atomes par bit de mémoire, ça reste compliqué à mettre en oeuvre.
Pour autant, ça ne remet pas en cause l'utilité d'une architecture 64 bits. On est même à 128 sur certaines machines (consoles de jeux, en particulier) parce que c'est pratique pour des utilisations ciblées et que celles-ci sont suffisamment rentables à elles seules pour justifier la conception de telles machines.
En ce qui concerne l'adressage proprement dit, 4 Go de mémoire sont déjà atteints et exploités depuis quelque temps. Rien que ça justifie le 64 bits. Par contre, en considérant 2^64 octets de mémoire, un facteur très limitant restera le temps qu'il faut pour y accéder.
Evidemment, on paralélisera, on fera des MMU plus puissantes, etc. M'enfin, j'espère que d'ici à ce que la limite soit atteinte, on sera passé à une autre architecture que celle d'un PC.
[^] # Re: Explications sur 64 bits
Posté par Obsidian . En réponse au journal x86_64 en général et sur Mdv en particulier. Évalué à 2.
C'est ce que j'explique au-dessus. C'est quelque chose dont on fait abstraction parce que l'on s'appuie sur le coprocesseur mathématique qui, lui, est effectivement en 64 bits depuis longtemps. Mais les données n'y passent pas leur vie.
Même chose.
.
Les long changent donc de format, les pointeurs aussi, et tout ce qui manipulé en interne à la compilation du code dans les registres. De toutes façons, ces formats de nombres concernent ici le langage C. Un changement d'architecture doit être examiné sur toutes les plateforme de développement.
Oui. Par moi. Relis bien.
[^] # Re: Explications sur 64 bits
Posté par Obsidian . En réponse au journal x86_64 en général et sur Mdv en particulier. Évalué à 2.
[^] # Re: Explications sur 64 bits
Posté par Obsidian . En réponse au journal x86_64 en général et sur Mdv en particulier. Évalué à 7.
- A prix égal et, surtout, si le système est compatible 32, cela ne vaut pas le coup de se priver. Ca permet de voir venir les nouveautés, et de se familiariser avec la programmation des nouveaux jeux d'instructions et la nouvelle architecture, ce qui est toujours très intéressant ...pour peu que l'on programme encore un minimum en assembleur ! Si c'est pour tout demander à gcc et faire de la compatibilité ascendente en nivelant par le bas, ça n'a aucun intérêt.
- Un nouveau jeu d'instruction et surtout des registres supplémentaires permettent d'être très efficace. Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.
- 64 bits, ça permet de dépasser 4 Go d'adressage direct et on en aura forcément besoin à terme. 512 Mo de RAM tend à devenir la norme et même les portables "conçus pour le jeu" chez Dell, par exemple, déjà sont livrés avec 2048 Mo.
Maintenant, je ne suis pas sûr que ce soit une bonne chose en soi que laisser cet état de fait devenir la norme. Dépasser 4Go, ce n'est pas du tout la même chose que de dépasser 64Ko. Même en progressant, la consommation de RAM devrait croître de manière linéaire, pas exponentielle ! Pour la plupart des gens, ce ne sont que des chiffres, que se valent à différentes époques, à la manière des francs et euros constants.
- Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique. Quand tu regardes des vidéos, certes (même si elles ne durent que 5 minutes, tu aspires quand même à ce qu'elles soient fluides dans l'intervalle, et qu'elles ne consomment pas trop de temps CPU, ni trop de bus), mais également quand tu travailles sous GIMP, ou même simplement lorsque tu déplaces une fenêtre ! Une fenêtre en 1280*768 et en 32 bits, mine de rien, ça fait beaucoup de mémoire ! Et comme, lorsque la résolution augmente, elle le fait dans les sens verticaux et horizontaux, cette quantité augmente au carré, encore une fois.
Bref, à partir d'une certaine quantité de données, travailler en 64 bits peut soulager ton processeur et augmenter, même d'un point de vue uniquement théorique, la rapidité d'exécution d'un algorithme, et ce même en dessous de 4Go de RAM.
important : Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits. Sinon, il y a conversion par des circuits externes et évidement, les perfs chutent.
- Les "double" tiennent enfin, à nouveau, sur un seul registre. J'ai toujours considéré cela comme une faiblesse des formations en programmation. J'ai un float et un double. Le double a une mantisse beaucoup plus large pour le même prix. Alors, je choisis le double, au point que les nouveaux programmeurs ne savent même plus que float existe.
Les tailles 32 et 64 bits des flottants sont ainsi parce qu'elles sont nomalisées, mais personne ne sait vraiment comment elles sont traitées en profondeur. Depuis qu'il y a un coprocesseur, les gens ne s'en soucient plus. Même les environnement de développement intégrés proposent des double par défaut. N'empêche que les accès bus et la mémoire consommée en demeurent effectivement doublés.
A l'époque des 8 bits, on utilisait déjà les mêmes formats, et il fallait de toutes façons une boucle pour traiter l'un comme l'autre. Sur un 32 bits, un float tient dans un registre (tel que EAX), pas un double.
Puisque le format de ces nombres est normalisé quelque soit l'architecture, on peut espérer des gains sur les programmes qui utilisent massivement le double. La plupart, pour ce que j'ai pu en voir.
- Enfin, 65535, c'est tout de suite atteint. 4 milliards beaucoup moins vite, mais ça reste courant. 2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.
- Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.
C'est inquiétant parce que la croissance exponentielle de la mémoire requise est due en grande partie aux dépendances entre les différentes couches d'abstraction. Si on continue à en ajouter, et si en plus les couches existantes consomment plus de mémoire sans même gagner une ligne de code, alors on va atteindre physiquement les limites de la mémoire adressable comme on a atteint celles de la finesse de la gravure, et ce avant même de passer aux 128 bits.
Donc, faire des frais pour passer explicitement en 64 bits, ça ne sert à rien. Par contre, si c'est dans un plan prévu de remplacement de tes machines, ce n'est (presque) que des avantages.
[^] # Re: re
Posté par Obsidian . En réponse au message [Recherche formation]. Évalué à 2.
Tu mets le doigt dessus, mais plus loin encore, ta validation va effectivement se dérouler dans une école où l'on cherchera clairement à savoir comment tu as obtenu ton « savoir académique », dixit une conseillère VAE, à l'époque où j'ai cherché à faire la même chose que toi. Certes, l'examen est adapté à ta situation mais dans l'absolu, tu devrais être capable de passer le même partiel que les étudiants normaux.
Faisable, donc, mais pas sans préparation. La simple expérience professionnelle ne suffira pas. Ça vaut le coup quand même, à condition d'être bien conseillé et dès le départ.
Je dis peut-être une bêtise, mais il me semble qu'à la base, c'est Microsoft qui a lancé le principe. En tout cas, ce sont les premières du genre que j'avais rencontré. À l'époque, les « Microsoft Certified Professional », ça me faisait bondir, maintenant on en trouve un peu partout, donc, ça rétablit l'équilibre.
La réponse est simple : ce sont effectivement des bouts de papier sans valeur, enfin plus précisément, ils n'en ont que pour les gens qui s'intéressent à la technologie qu'ils concernent.
L'important est que ce ne sont pas des diplômes qui te permettront a priori de prétendre à quelque chose en particulier. Ce ne sont pas non plus des équivalents à des attestations d'état. Par contre, cela peut faire gagner beaucoup de temps à un recruteur qui peut voir d'un coup le panel de questions auxquelles tu as répondu correctement. Et c'est pratique si tu convoites un poste précis, ou que ton employeur veut te confier une tâche bien définie. Après, cela te mets en meilleure position pour négocier éventuellement ta place et ton salaire, mais ça reste à toi de le faire.
Ce qui est intéressant avec ces certifs, c'est qu'elles sont très spécialisées, beaucoup plus en rapport avec le sujet qu'un diplôme général, mais elles sont aussi de fait très périssables et çà, ça me dérange un peu. L'autre problème, c'est que tu ne peux jamais savoir à l'avance ce qu'elles valent réellement : cela n'a aucun intérêt de savoir où se trouve le bouton de tel panneau de telle version de telle application, comme on en a déjà vu dans certains questionnaires. Et ça m'ennuie de m'investir scolairement dans un truc qui sera périmé au bout de deux ans.
En bref, un plus pour toi, si tu le souhaites ou si tu cibles quelque chose de précis, mais en aucun cas un passage obligé. Pour les quelques CV que j'ai vu circuler, ça reste encore peu fréquent.
# Sources semi-otages ?
Posté par Obsidian . En réponse au journal A la recherche d'un NAS.... Évalué à 2.
Il me semble que la GPL n'impose pas seulement la redistribution du code source original, mais bien du code modifié ! Maintenant, ce n'est pas incompatible, un même logiciel peut effectivement être embarqué dans différentes boiboîtes à usages différents, mais c'est à surveiller.
Sinon, oui, 20$ pour obtenir les sources, c'est clairement fait pour faire un max de profit tout en dissuadant le quidam moyen de regarder comment c'est fait.
Bah, de toutes façons, je parie que le code modifié doit exploiter un max de firmwares, eux, bien propriétaires, mais je suis probablement mauvaise langue.
[^] # Re: Ouaiis...
Posté par Obsidian . En réponse au journal qui l'aurait cru.... Évalué à 2.