oui bien sûr. Dans le modèle derrière peuvent s'appliquer les mêmes méthodes de référence et de neutralité que pour wikipedia. On peut aussi ajouter un outil de traçabilité entre le code et des documents.
Disons que int est mappé sur la taille la plus pratique. Le C propose 3 type d'archi 16 32 et 64 bits. Le 16 bit est le minimum même sur µC avec registre 8 bits (qui sont souvent mixte 8/16 bits en fait). 32 bit est la norme pour ceux à registre 32 bits. Ce qui ont des registres 64 bits, utilise int en 32 bits, ce qui est incompatible avec les pointeurs 64 bits.
C'est pour ça qu'il y a 3 "sortes" de C. D'ailleurs, il n'est pas possible de faire un code sans ifdef qui reste compatible avec les 3 tailles de registres.
c'est lui qui sait comment les données sont organiser et qui va répondre au mieux aux demandes.
Non justement. Linux ne cherche pas à optimiser la bande passante global, ou le temps de fin global. Il essaye d'être juste ("fair") entre chaque flux IO. Il va donc faire un peu de tout, pour satisfaire tout le monde. Il va garantir une latence minimum pour tous. Or, on se fout qu'un des job soient très en retard. Sur un HD, on peut augmenter la bande passante réelle avec des "bandes" jusqu'à ~15 Mo. Plus l'accès est linéaire, plus la copie/lecture est rapide.
(par exemple elle se déclenchera quand tu aura vraiment mis de la pression sur ton allocation mémoire).
C'est justement de ce cas pathologique dont on parle : plein d'allocation suffisamment grosse pour aller dans la "zone vieille" mais à collecter ensuite. Je n'ai pas testé d'augmenter franchement la zone jeune, c'est peut être une autre solution (256Ko de mémoire).
Sincèrement la lecture de 10 000 fichiers c'est plus les accès disques qui vont te poser problème que l'allocation mémoire.
Pour mon cas, non. En bidouillant le GC d'OCaml, j'avais des perf en plus (10 % de mémoire), en multipliant la conso mémoire par 10 (en gros, le gc se déclenche beaucoup moins ouvent).
Lancer les lectures de manière asynchrone va probablement te permettre de passer un gap très important.
Dans le cas de lecture sur le même disque, je ne vois pas pourquoi. Je n'ai pas fait le test, mais je persuadé que tu va juste augmenter le nombre de "seek" et ralentir le tout. Cela se voit bien entre plein de copie en parallèle ou une liste de copie.
Les gc générationnels font déjà se boulot avec une granularité plus fine et de manière plus systématique que ce que tu ferra.
Surtout si ta mémoire est read only comme en Ocaml (le parsing se fait uniquement sur les string, sinon, il faudrait tout recoder avec "buffer"). Mais si tu as une génération jamais parcouru par le GC, c'est plus rapide non ?
Les sécurités et autre artifices qui entrent en jeux lors de la création d'un objet peut poser un vrai problème (et ne sont pas forcément facile à prendre en compte (mal grès l'utilisation de pool d'objet).
Dans Ocaml, c'est un déplacement d'un pointeur de pile. Dans le cas de mémoire à faible durée de vie, c'est ultra rapide. C'est ensuite, que cela se complique.
Au pire dans le temps réel dure, on ne fait pas d'allocation de mémoire du tout (Misra C). Ou on le fait uniquement après le démarrage de l'application, puis on y touche plus (type serveur graphique Arinc 661).
Dans le cas auquel je pense, c'est vraiment pour de l'optimisation, je suis bien d'accord. Le fait de faire plusieurs programme aurait ralentit le tout. Je parle de lire 10 000 fichiers en quelques secondes.
Sans piloter le GC, il pourrait être utile d'avoir un moyen de créer des données totalement hors du contrôle du GC. Cela permet d'éviter des scans inutiles. Voir de se passer complètement du GC dans certain cas, par exemple pour les données qui vont rester en vie, durant toute la vie du programme.
C'est logique que les toits des bâtiments ont sauté ? (je voie des murs uniquement)
Il serait bien de faire une écriture plus propre pour le nom des rues. Le truc est flou et moche. J'imagine qu'il faudrait un moyen d'écrire après coup au bon endroit, au lieu d'avoir une grosse image déformée.
On pourrait imaginer le GC pilotable. rust permet un peu ça, et permet aussi d'avoir des zones mémoires hors GC.
ocaml pourrait permettre de réutiliser des variables en tant que bloc mémoire inutile. J'ai souvenir d'écriture d'un parseur, qui lisait des milliers de petit fichiers, qui devait à chaque fois réallouer une nouvelle string pour les lire.
L'espace n'utilise pas la DO178b, mais pas du tout. C'est même à des années-lumière de la DO (j'ai bossé 5 ans dans le secteur spatiale et 8, dans l'aéronautique).
"Notamment la DO178B. La méthode la plus sûre reste l'emploi de méthodes formelles. "
C'est toi qui parlais de DO, je ne parlais pas en général, car tu ne le faisais pas non plus.
C'est gentil de se relire avant de répondre…
Ton deuxième lien ne donne pas d'exemple dans l'aéronautique. L'aéronautique exige, que pour utiliser un outil qui génère des "trucs" qui sont embarqués, il faut que l'outil soient développé selon les mêmes méthodes que la DO préconise (sauf pour les compilateurs C, qui sont une exception "pratique"). Même si la DO178c rend plus facile le développement d'outils, cela reste très difficile. Par exemple, écrire tous les HLR/LLR d'un outil comme un prouveur doit être du délire.
"Tu vois, c'est exactement ce genre d'arrogance que je dénonce ne pensant que les devs se croient plus important que le reste du monde. "
Moi je vois l'effet inverse. On était une petite boite avec 2 IT au service de tout le monde; enquête de satisfaction : 90%. On vient de se faire racheter par un monstre, avec l'IT qui fait un peu ce qui veut, ayant des budgets énormes. Des bugs chiant qui touchent, tout le monde jamais corriger. Ils ne font même pas d’enquête de satisfaction, tellement ils savent qu'ils vont se faire allumer.
"Comptablement, les devs e la R&D aussi coute de l'argent sont donc aussi un centre de cout."
Quand tu vend du logiciel, c'est pas vraiment le cas. En tout cas, au US, les dev ne sont pas vu comme cela du tout, par exemple.
il faut quelqu'un pour s'occuper de chaque chose.
Je suis d'accord. Les dev sont là pour le produit. Les IT sont là pour support des autres services, le problème arrive quand ils pensent se suffire à eux-même. Ils n'existent pourtant uniquement comme support du reste.
Je crois que tu ne sais pas du tout de quoi tu parles. J'ai développé pendant 1 ans ou 2 ans, avec une machine avec 3/4 Go (windows 32 bits avec 4 Go physique). C'était juste un insupportable.
Un simple navigateur web prend 1 Go, les mails passent par là (chrome), avant c'était Lotus… Si tu veux un firefox de plus, c'est un Go de plus. Tu dev sous Eclipse, 1 Go. Tu utilises un word ou excel, c'est mini plusieurs centaines de Mo.
Donc, tu passes ton temps à fermer des applications pour bosser, et à les réouvrir.
Avec 8 Go, je suis maintenant tranquille sauf dans les cas extrèmes (1 eclipse de dev pour créer un autre eclipse de dev pour lancer le produit sous eclipse).
Et comme préciser ailleurs, je développe aussi sous un atom avec 2 Go de RAM avec Ocaml et Emacs.
Non, la GPL n'impose justement pas de mettre la liste des auteurs, c'est une des grosses différences avec la BSD car ce n'est pas un truc qui passe à l'échelle.
" tu veux un fournisseur qui soit capable d'assurer la garantie pour la durée ( genre 3 ans, parfois 5 ans ), ce qui implique d'avoir des stocks et de pas avoir fait faillite. "
Et les boites veulent 5 ans de garanti car ils ne veulent pas changer le matos tous les 3 ans. Donc, ils payent plus chère tous les 5 ans, et on se traine des truc obsolètes pendant 2 ou 3 ans. Le suivi sur 5 ans n'est pas gratuit.
les contrôles du BSA
C'est pas la police qu'est-ce que cela vient faire là pour un pc de dev.
( parce que bon, si chaque machine coute 1000€ et qu'il y a 700 personnes dans la boite, 700 000 euros de matos, c'est pas "négligeable" )
700 personnes, c'est en gros 70 M€ de chiffres d'affaire en moyenne, voir 3x plus pour une banque. Donc bon… il faut savoir relativiser.
Concernant le reste du poste, tu devrait un peu te rappeler que le service IT est un productif, un truc nécessaire mais qui ne produit pas. Le dev est celui qui rapporte des sous à la boite, l'IT est à son service pas l'inverse !
[^] # Re: un tableur en ligne
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Climat et logiciel. Évalué à 2.
oui bien sûr. Dans le modèle derrière peuvent s'appliquer les mêmes méthodes de référence et de neutralité que pour wikipedia. On peut aussi ajouter un outil de traçabilité entre le code et des documents.
"La première sécurité est la liberté"
# un tableur en ligne
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Climat et logiciel. Évalué à 2.
Je rêves d'avoir ce genre d'outil mais avec l'édition du code source en mode wiki. Cela permettrait aussi de valider le modèle qu'il y a derrière.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 7.
Oui enfin les zozo de facebook ont aussi écrit un nouveau langage 100% compatible php pour corriger les bugs. (the hack langage https://linuxfr.org/news/the-hack-language-php-avec-un-peu-de-typage-statique http://hacklang.org/ )
Cette vidéo sur le pourquoi, ils l'ont fait est super intéressante :
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Hack
"La première sécurité est la liberté"
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 3.
Disons que int est mappé sur la taille la plus pratique. Le C propose 3 type d'archi 16 32 et 64 bits. Le 16 bit est le minimum même sur µC avec registre 8 bits (qui sont souvent mixte 8/16 bits en fait). 32 bit est la norme pour ceux à registre 32 bits. Ce qui ont des registres 64 bits, utilise int en 32 bits, ce qui est incompatible avec les pointeurs 64 bits.
C'est pour ça qu'il y a 3 "sortes" de C. D'ailleurs, il n'est pas possible de faire un code sans ifdef qui reste compatible avec les 3 tailles de registres.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
J'imagine que la démonstration de "ça passe" doit être compliqué.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Non justement. Linux ne cherche pas à optimiser la bande passante global, ou le temps de fin global. Il essaye d'être juste ("fair") entre chaque flux IO. Il va donc faire un peu de tout, pour satisfaire tout le monde. Il va garantir une latence minimum pour tous. Or, on se fout qu'un des job soient très en retard. Sur un HD, on peut augmenter la bande passante réelle avec des "bandes" jusqu'à ~15 Mo. Plus l'accès est linéaire, plus la copie/lecture est rapide.
C'est justement de ce cas pathologique dont on parle : plein d'allocation suffisamment grosse pour aller dans la "zone vieille" mais à collecter ensuite. Je n'ai pas testé d'augmenter franchement la zone jeune, c'est peut être une autre solution (256Ko de mémoire).
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Pour mon cas, non. En bidouillant le GC d'OCaml, j'avais des perf en plus (10 % de mémoire), en multipliant la conso mémoire par 10 (en gros, le gc se déclenche beaucoup moins ouvent).
Dans le cas de lecture sur le même disque, je ne vois pas pourquoi. Je n'ai pas fait le test, mais je persuadé que tu va juste augmenter le nombre de "seek" et ralentir le tout. Cela se voit bien entre plein de copie en parallèle ou une liste de copie.
Surtout si ta mémoire est read only comme en Ocaml (le parsing se fait uniquement sur les string, sinon, il faudrait tout recoder avec "buffer"). Mais si tu as une génération jamais parcouru par le GC, c'est plus rapide non ?
Dans Ocaml, c'est un déplacement d'un pointeur de pile. Dans le cas de mémoire à faible durée de vie, c'est ultra rapide. C'est ensuite, que cela se complique.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 3.
Beaucoup de jeu utilise un énorme truc en C++ mais un langage de script pour le reste. Unity https://fr.wikipedia.org/wiki/Unity_%28moteur_de_jeu%29 utilise mono. D'autres utilisent Lua.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 4.
Au pire dans le temps réel dure, on ne fait pas d'allocation de mémoire du tout (Misra C). Ou on le fait uniquement après le démarrage de l'application, puis on y touche plus (type serveur graphique Arinc 661).
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Dans le cas auquel je pense, c'est vraiment pour de l'optimisation, je suis bien d'accord. Le fait de faire plusieurs programme aurait ralentit le tout. Je parle de lire 10 000 fichiers en quelques secondes.
Sans piloter le GC, il pourrait être utile d'avoir un moyen de créer des données totalement hors du contrôle du GC. Cela permet d'éviter des scans inutiles. Voir de se passer complètement du GC dans certain cas, par exemple pour les données qui vont rester en vie, durant toute la vie du programme.
"La première sécurité est la liberté"
# retour ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal X3D et osm. Évalué à 2.
C'est logique que les toits des bâtiments ont sauté ? (je voie des murs uniquement)
Il serait bien de faire une écriture plus propre pour le nom des rues. Le truc est flou et moche. J'imagine qu'il faudrait un moyen d'écrire après coup au bon endroit, au lieu d'avoir une grosse image déformée.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 1.
On pourrait imaginer le GC pilotable. rust permet un peu ça, et permet aussi d'avoir des zones mémoires hors GC.
ocaml pourrait permettre de réutiliser des variables en tant que bloc mémoire inutile. J'ai souvenir d'écriture d'un parseur, qui lisait des milliers de petit fichiers, qui devait à chaque fois réallouer une nouvelle string pour les lire.
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 3.
oula.
L'espace n'utilise pas la DO178b, mais pas du tout. C'est même à des années-lumière de la DO (j'ai bossé 5 ans dans le secteur spatiale et 8, dans l'aéronautique).
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 3.
Dans la liste d'exemple, il ne parle pas d'aéronautique. Il parle d'espace, mais cela n'est pas les mêmes règles.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 4.
Tu as des exemples de complexités ?
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 2.
Tu as écris ça :
C'est toi qui parlais de DO, je ne parlais pas en général, car tu ne le faisais pas non plus.
C'est gentil de se relire avant de répondre…
Ton deuxième lien ne donne pas d'exemple dans l'aéronautique. L'aéronautique exige, que pour utiliser un outil qui génère des "trucs" qui sont embarqués, il faut que l'outil soient développé selon les mêmes méthodes que la DO préconise (sauf pour les compilateurs C, qui sont une exception "pratique"). Même si la DO178c rend plus facile le développement d'outils, cela reste très difficile. Par exemple, écrire tous les HLR/LLR d'un outil comme un prouveur doit être du délire.
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 1.
J'aimerais bien savoir pourquoi j'ai été "moinsé". Quelqu'un connait un seul exemple d'usage de la méthode B sous DO178 ?
"La première sécurité est la liberté"
[^] # Re: Sérieux?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 3.
Moi je vois l'effet inverse. On était une petite boite avec 2 IT au service de tout le monde; enquête de satisfaction : 90%. On vient de se faire racheter par un monstre, avec l'IT qui fait un peu ce qui veut, ayant des budgets énormes. Des bugs chiant qui touchent, tout le monde jamais corriger. Ils ne font même pas d’enquête de satisfaction, tellement ils savent qu'ils vont se faire allumer.
Quand tu vend du logiciel, c'est pas vraiment le cas. En tout cas, au US, les dev ne sont pas vu comme cela du tout, par exemple.
Je suis d'accord. Les dev sont là pour le produit. Les IT sont là pour support des autres services, le problème arrive quand ils pensent se suffire à eux-même. Ils n'existent pourtant uniquement comme support du reste.
"La première sécurité est la liberté"
[^] # Re: Sérieux?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 1.
Le rapport avec le poste ?
"La première sécurité est la liberté"
[^] # Re: développement n'est pas de la bureautique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 2.
La technique, c'est sale.
"La première sécurité est la liberté"
[^] # Re: comprend pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 2.
"nice" ne gère pas vraiment les IO, de plus, un processus de 13 Go avec 4 Go réelle doit prendre un temps de malade.
"La première sécurité est la liberté"
[^] # Re: comprend pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 3.
Je crois que tu ne sais pas du tout de quoi tu parles. J'ai développé pendant 1 ans ou 2 ans, avec une machine avec 3/4 Go (windows 32 bits avec 4 Go physique). C'était juste un insupportable.
Un simple navigateur web prend 1 Go, les mails passent par là (chrome), avant c'était Lotus… Si tu veux un firefox de plus, c'est un Go de plus. Tu dev sous Eclipse, 1 Go. Tu utilises un word ou excel, c'est mini plusieurs centaines de Mo.
Donc, tu passes ton temps à fermer des applications pour bosser, et à les réouvrir.
Avec 8 Go, je suis maintenant tranquille sauf dans les cas extrèmes (1 eclipse de dev pour créer un autre eclipse de dev pour lancer le produit sous eclipse).
Et comme préciser ailleurs, je développe aussi sous un atom avec 2 Go de RAM avec Ocaml et Emacs.
"La première sécurité est la liberté"
[^] # Re: Droit d'auteur ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GNU GPL et commercialisation : mauvaise compréhension des licences, l'exemple WPScan. Évalué à 3.
Non, la GPL n'impose justement pas de mettre la liste des auteurs, c'est une des grosses différences avec la BSD car ce n'est pas un truc qui passe à l'échelle.
"La première sécurité est la liberté"
[^] # Re: Sérieux?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à -1.
Et les boites veulent 5 ans de garanti car ils ne veulent pas changer le matos tous les 3 ans. Donc, ils payent plus chère tous les 5 ans, et on se traine des truc obsolètes pendant 2 ou 3 ans. Le suivi sur 5 ans n'est pas gratuit.
C'est pas la police qu'est-ce que cela vient faire là pour un pc de dev.
700 personnes, c'est en gros 70 M€ de chiffres d'affaire en moyenne, voir 3x plus pour une banque. Donc bon… il faut savoir relativiser.
Concernant le reste du poste, tu devrait un peu te rappeler que le service IT est un productif, un truc nécessaire mais qui ne produit pas. Le dev est celui qui rapporte des sous à la boite, l'IT est à son service pas l'inverse !
"La première sécurité est la liberté"
[^] # Re: comprend pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 2.
Tous les I5 ne sont pas quadruple coeur, et la fréquence n'est pas la même non plus.
Et en général, le reste va avec 4Go maximum, et pas de ssd.
"La première sécurité est la liberté"