Je vais créer un site web pour centraliser tout ce qui concerne le projet.
Ouais parce que c'est le bordel et il faut réorganiser tout :-)
-1 blague difficile pour le néophyte
le CLR .net est là pour résoudre ce problème mais personne ne veut en entendre parler sur ce site.
Le but est simple : une seule instance en mémoire des infrastructures.
Smalltalk c'est planté sur cet objectif, peut-être MS arrivera à quelquechose.
Il semblerait hélas que certains n'aient pas compris ce problème et préfèrent fustiger Mono que d'essayer (ben oui, c'est pas gangé) de passer la seconde dans le secteur de l'informatique.
Ceci à plusieurs avantages : ça leur permet de vivre sur leurs acquis (le C et son environnement pile d'appels, représentation mémoire etc.) mais surtout de continuer à faire partie d'une élite qui serait sinon vite balayée par une génération formée plus tôt à une informatique plus moderne.
Il reste un pb MS n'est pas précisément connue pour ça capacité à faire progresser l'informatique. Le fait de mettre un PC sur chaque bureau sans former les utilisateur à la "science du traitement automatisé" ou à la "science de l'information" peut difficilement être qualifié de progrès. C'est pas en noyant un domaine de boulets qu'on fait progresser une science. Bien au contraire.
Donc le CLR .net est incontestablement une bonne idée mais il ne faut pas en faire n'importe quoi et c'est pas en faisant l'autruche que l'on l'aprivoisera.
Java est asymptotiquement plus efficace en gestion de la mémoire qu'une désallocation explicite (grace au GC).
Par-contre il bouffe au démarrage (surtout si t'es en JIT).
Tout ce que vous faites en désallocation explicite, le GC peut le faire (en général plus vite que vous) mais lui il sait faire des trucs que vous pouvez pas faire sans utiliser un ref_counter et un détecteur de cycles.
L'avantage du GC c'est qu'il n'utilise que l'infrastructure d'un détecteur de cycles (parcours du graphe et marquage) et pas une série de compteurs.
D'autre part tu peux régler le ratio bouffage de temps/bouffage de mémoire et jouer sur la durée de vie de la mémoire.
Même en temps réel, on commence à pourvoir controler le temps de réponse (avec des systèmes spéciaux).
Il faut vraiment étudier ls GC avant de pouvoir dire qu'on en a pas besoin.
Même eux n'y croient pas aux brevets :
"As an example, an algorithm developed by an auto manufacturer used for testing shocks may be kept as a corporate secret rather than patented because patents are in public domain and it would be difficult to prove that a competitor was using it."
Et la pérennité de l'inovation ?
Ils viennent de découvrir qu'il y avait une contrepartie à l'exclusivité de l'usage dans les brevets !
Il est beau le pays qui repousse ses frontières où tout est possible ...
y'a 8000 mort par an en voiture, bientôt on donnera le nombre des morts annuels à cause de l'informatique, donc oui, la qualité m'intéresse.
Même un éditeur de texte tout con s'il chie au moment de la sauvegarde de 1 caractère ça pourrait faire des morts.
Je ne m'intéresse pas que à ça mais je m'y intéresse beaucoup d'où mon intérêt pour les "méthodes de production" du logiciel (langages, compilos, environnements etc.).
Si personne n'a la volonté de nettoyer la crasse dans laquelle le secteur de l'informatique se situe, on va dans le mur. Le "logiciel dont on peut voir le code source" aurait pû être la voix mais non, on a autant de merde dans ce secteur (qui comprend pas mal de libre en plus) que dans les trucs fermés. J'en viens presque à adhérer avec le tissu de conneries de MS : tant que tout le monde produira de la merde, autant la cacher ça limite la découverte des failles de sécrité. Quand les informaticiens se pencherons massivement sur les outils, les langages, les environnements etc. peut-être qu'on sera prêt à faire de la qualité.
Mais pour l'instant, y'a toujours les P4 qui bootent en 16 bits et un bloatware de 100Mo de C dans /usr/src/linux qui est prêt à te pêter à la tronche à chaque démarrage.
Maintenant si j'ai utilisé le mot open-source c'est parceque j'ai pensé que c'était plus clair mais si je me suis planté parce que je ne sait que organisme a utilisé un terme simple pour en faire un truc vachement moins simple et qu'en plus j'était pas au courant désolé.
Donc ce que j'ai dit avant c'était valable pour "les machins dont on peut lire le code source" ça va ? c'est pas déposé par un consortium de sauveurs du monde ça ? les-machins-dont-on-peut-lire-le-code-source.org n'a pas l'air déposé donc j'espère que je suis pas fait avoir et que ça veut pas dire un truc plus compliqué dont je me fous.
Nan mais y'a pas que GTK+ qui soit douteux :
wu-ftpd
xinetd
bind
php
wmcoincoin
le module eci
le noyau (les 100Mo dans /usr/src/linux)
...
Mais je ne remets pas en cause le libre, juste le fait de dire open-source => qualité, c'est faux.
La qualité est indépendante de l'aspect open-source.
D'autre part j'ai pas parlé de libre (ou alors par erreur) mais uniquement d'open-sorce (simplement un truc dont tu peux voir les sources comme Windows dans une certaine mesure, QNX, les logiciels libres etc.).
Nan mais vu le niveau de culture de la population ici présente, je prèfère passer 1h en IRC avec JJB à lui expliquer les bases du fonctionnel que de parler de haut niveau avec [pas d'attaques perso] (qui est soit-disant rigoureux mais utilise _toujours_ le C quelque soit l'application mais te fait chier avec des GNU/le Linux ou un truc du genre).
Je reviens à l'instant de la lecture d'un ouvrage sur GTK, j'ai envie de vomir, c'est du pointeur dans tous les axes, du pointeur vers l'instance de la classe parente etc. et de la macro.
Les mecs n'ont _rien_ compris à la théorie des langages de programmation ! Un langage est là pour automatiser des taches répétitives, les langages objets sont compris dedans, créer des structures de données qui ressenblent à de l'objet dans un langage qui ne l'est pas relève du crétinisme (ou de l'opportunisme étant donné la mode de l'objet) alors qu'une application écrite en langage objet pourra souvent ne pas avoir une tronche objet une fois en mémoire.
Même si je ne suis pas encore un caïd du domaine, j'ai au moins compris la différence entre le niveau langage et le niveau run-time.
Franchement, je me détourne de plus en plus du libre, dégoûté par cette atmosphère de branlage de nouilles .
Il devient de plus en plus clair que l'open-source n'a rien à voir avec la qualité.
Je préfèrerais utiliser une application closed-source écrite pas Robert C. Martin que xinetd ou wu-ftpd par ex.
Aucune idée mais vu que dans le secteur n'importe qui appelle n'importe quoi n'importe comment ...
Les mecs changent 2 octets par trame (l'entête de préférence) et prétendent avoir inventé un nouveau codec.
Des mecs qui font autre chose qu'un produit de convolution avec une fonction quelquonque (une ondelette à la mode) sur des carrés (y'en a bien un qui va pondre des rectangles maintenant) et une estimation quelquonque (Kalman si possible avec un-modèle-top-secret-à-nous) du movement de ses carrés (par groupe si possible).
Au niveau du son c'est souvent pareil en 1D sauf qu'il n'y a pas d'estimation du mouvement.
tu mets se que tu veux pour le son, au niveau MPEG, le plus avancé et le mp3 : MPEG1 audio layer 3.
Mais tu peux mettre autre chose (standart si possible).
ça fait un peu pub mais en regardant de plus près une pub avec une faute c'est pas crédible, ou alors la faute n'est là que pour diminuer l'aspect "pub".
Plus important : programmateur mécanique ou programmateur électronique car si c'est mécanique y'a de l'usure et faut le changer de temps en temps.
Ceci dit si c'est un bon programmateur ça doit être un électronique car ils ne dérivent pas dans la temps et sont plus précis
Ca me fait penser qu'il va falloir que je change le chapeau de ma page web, il commence à être ancien.
Est-ce que le Hurd a une solution élégante pour le problème que traite CBS ?
Si oui c'est gràce aux tokens, grace au micro-noyau ou grace à la présence des 2 simultanément ?
"Quand on fait un serveur, il faut savoir sacrifier certaines choses sur l'autel de la sécurité. Je pense qu'une légère perte de performances est largement compensée par le gain"
alors pourquoi utiliser du C ?
perl et très bien, python est très bien
"En passant, je suis tres loin de penser qu'il faudrait eliminer C/C++(bien au contraire), le jour ou d'autres langages auront le meme rapport temps de dev/performance/flexibilite n'est pas encore arrive."
laisse moi rire
va faire un tour sur le language shootout, compte les lignes de codes.
Avec un langage faiblement type tu passe ta vie a checher le bug vicieux.
Sans les contrats en objet, tu cherche qui a foutu la merde dans ton appli.
Sans les closures (ou un substitut) tu n'a pas vraiment de flexibilite.
Et j'en ai de centaines des trucs comme ca (references faibles, faineantise, types generiques etc.)
Pour la flexibilite t'a jamais du utiliser un autre langage alors.
Quand aux perfs ... laisse moi rire ! Faut arreter les benchmark sur les boucles courtes.
c'est pas ça le problème, c'est qu'il est plus facil d'écrire des conneries en C qu'en beaucoup d'autre langages (tous sauf asm et Forth à ma connaissance).
Il faut utiliser son intelligence sur d'autres trucs que sur des indices de tableaux et autres conneries d'allocation (sur avec les pb d'allocation explicite d'on j'ai déjà discuté ailleur) et même d'implémentation.
Etre trop proche du métal fait réfléchir localement au lieu de prendre de la hauteur (genre optimiser les structures de données au lien de schéma général).
Quand je parle d'Ocaml, c'est un nouveau défit, mélanger classes et modules, rien qu'en restant imprératif c'est déjà autre chose que de préfixer ces noms de fonctions par le nom de la biblothèque et se taper des macro #define super dangereuses quand ça se complique.
L'important c'est la facilité avec laquelle on évite le bug, se cracher violement sur une exception est déjà plus saint que de corrompre le tas ou la pile. Surtout si ça crache systématiquement.
Il est d'autre part important de limiter les effets de bords, ils obligent à une réflexion permanente à l'état dans lequel on va retrouver un bout de mémoire à l'entrée dans une fonction.
D'autre part, il y a une culture "élitiste" qui veut que programmer en C soit le top et qu'en plus ce soit difficile. Alors qu'apprendre au plus tôt des langages modernes et variés ferait avancer beaucoup plus vite l'informatique. Le C est un langage quasiment inutile à l'informatique, les codeurs de noyeaux et autres drivers sont marginaux et devraient utiliser ADA.
L'histoire de coder un SGBD en C est à mon sens une vaste connerie (ça vaut des millions les données qu'il y a dedans, autant éviter q'une erreur conne foute tout en l'air).
Bon j'arrête là parce que siono y'en a pour 10 pages et j'ai parlé que de caml comme alternative.
[^] # Re: petite précision...
Posté par Dugland Bob . En réponse à la dépêche Introduction au F-CPU. Évalué à -1.
# je vais participer au F-CPU
Posté par Dugland Bob . En réponse à la dépêche Introduction au F-CPU. Évalué à -8.
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 1.
Le but est simple : une seule instance en mémoire des infrastructures.
Smalltalk c'est planté sur cet objectif, peut-être MS arrivera à quelquechose.
Il semblerait hélas que certains n'aient pas compris ce problème et préfèrent fustiger Mono que d'essayer (ben oui, c'est pas gangé) de passer la seconde dans le secteur de l'informatique.
Ceci à plusieurs avantages : ça leur permet de vivre sur leurs acquis (le C et son environnement pile d'appels, représentation mémoire etc.) mais surtout de continuer à faire partie d'une élite qui serait sinon vite balayée par une génération formée plus tôt à une informatique plus moderne.
Il reste un pb MS n'est pas précisément connue pour ça capacité à faire progresser l'informatique. Le fait de mettre un PC sur chaque bureau sans former les utilisateur à la "science du traitement automatisé" ou à la "science de l'information" peut difficilement être qualifié de progrès. C'est pas en noyant un domaine de boulets qu'on fait progresser une science. Bien au contraire.
Donc le CLR .net est incontestablement une bonne idée mais il ne faut pas en faire n'importe quoi et c'est pas en faisant l'autruche que l'on l'aprivoisera.
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 3.
Par-contre il bouffe au démarrage (surtout si t'es en JIT).
Tout ce que vous faites en désallocation explicite, le GC peut le faire (en général plus vite que vous) mais lui il sait faire des trucs que vous pouvez pas faire sans utiliser un ref_counter et un détecteur de cycles.
L'avantage du GC c'est qu'il n'utilise que l'infrastructure d'un détecteur de cycles (parcours du graphe et marquage) et pas une série de compteurs.
D'autre part tu peux régler le ratio bouffage de temps/bouffage de mémoire et jouer sur la durée de vie de la mémoire.
Même en temps réel, on commence à pourvoir controler le temps de réponse (avec des systèmes spéciaux).
Il faut vraiment étudier ls GC avant de pouvoir dire qu'on en a pas besoin.
# le coup du brevet
Posté par Dugland Bob . En réponse à la dépêche Les logiciels sources ouvertes favorisent le terrorisme (la suite). Évalué à 10.
"As an example, an algorithm developed by an auto manufacturer used for testing shocks may be kept as a corporate secret rather than patented because patents are in public domain and it would be difficult to prove that a competitor was using it."
Et la pérennité de l'inovation ?
Ils viennent de découvrir qu'il y avait une contrepartie à l'exclusivité de l'usage dans les brevets !
Il est beau le pays qui repousse ses frontières où tout est possible ...
Quelle bande de branleurs !
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à -5.
Même un éditeur de texte tout con s'il chie au moment de la sauvegarde de 1 caractère ça pourrait faire des morts.
Je ne m'intéresse pas que à ça mais je m'y intéresse beaucoup d'où mon intérêt pour les "méthodes de production" du logiciel (langages, compilos, environnements etc.).
Si personne n'a la volonté de nettoyer la crasse dans laquelle le secteur de l'informatique se situe, on va dans le mur. Le "logiciel dont on peut voir le code source" aurait pû être la voix mais non, on a autant de merde dans ce secteur (qui comprend pas mal de libre en plus) que dans les trucs fermés. J'en viens presque à adhérer avec le tissu de conneries de MS : tant que tout le monde produira de la merde, autant la cacher ça limite la découverte des failles de sécrité. Quand les informaticiens se pencherons massivement sur les outils, les langages, les environnements etc. peut-être qu'on sera prêt à faire de la qualité.
Mais pour l'instant, y'a toujours les P4 qui bootent en 16 bits et un bloatware de 100Mo de C dans /usr/src/linux qui est prêt à te pêter à la tronche à chaque démarrage.
Maintenant si j'ai utilisé le mot open-source c'est parceque j'ai pensé que c'était plus clair mais si je me suis planté parce que je ne sait que organisme a utilisé un terme simple pour en faire un truc vachement moins simple et qu'en plus j'était pas au courant désolé.
Donc ce que j'ai dit avant c'était valable pour "les machins dont on peut lire le code source" ça va ? c'est pas déposé par un consortium de sauveurs du monde ça ? les-machins-dont-on-peut-lire-le-code-source.org n'a pas l'air déposé donc j'espère que je suis pas fait avoir et que ça veut pas dire un truc plus compliqué dont je me fous.
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à -4.
wu-ftpd
xinetd
bind
php
wmcoincoin
le module eci
le noyau (les 100Mo dans /usr/src/linux)
...
Mais je ne remets pas en cause le libre, juste le fait de dire open-source => qualité, c'est faux.
La qualité est indépendante de l'aspect open-source.
D'autre part j'ai pas parlé de libre (ou alors par erreur) mais uniquement d'open-sorce (simplement un truc dont tu peux voir les sources comme Windows dans une certaine mesure, QNX, les logiciels libres etc.).
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 2.
Je ne critique pas l'O-S mais je préviens que ce n'est pas un gage de qualité, et que l'O-S ne semble pas augmenter la qualité des applications.
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à -4.
Je reviens à l'instant de la lecture d'un ouvrage sur GTK, j'ai envie de vomir, c'est du pointeur dans tous les axes, du pointeur vers l'instance de la classe parente etc. et de la macro.
Les mecs n'ont _rien_ compris à la théorie des langages de programmation ! Un langage est là pour automatiser des taches répétitives, les langages objets sont compris dedans, créer des structures de données qui ressenblent à de l'objet dans un langage qui ne l'est pas relève du crétinisme (ou de l'opportunisme étant donné la mode de l'objet) alors qu'une application écrite en langage objet pourra souvent ne pas avoir une tronche objet une fois en mémoire.
Même si je ne suis pas encore un caïd du domaine, j'ai au moins compris la différence entre le niveau langage et le niveau run-time.
Franchement, je me détourne de plus en plus du libre, dégoûté par cette atmosphère de branlage de nouilles .
Il devient de plus en plus clair que l'open-source n'a rien à voir avec la qualité.
Je préfèrerais utiliser une application closed-source écrite pas Robert C. Martin que xinetd ou wu-ftpd par ex.
# c'est quoi cette merde ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à -10.
Ca sert à rien cette news !
[^] # Re: Question naive
Posté par Dugland Bob . En réponse à la dépêche QuickTime 6 ... un standard !. Évalué à 10.
Les mecs changent 2 octets par trame (l'entête de préférence) et prétendent avoir inventé un nouveau codec.
Des mecs qui font autre chose qu'un produit de convolution avec une fonction quelquonque (une ondelette à la mode) sur des carrés (y'en a bien un qui va pondre des rectangles maintenant) et une estimation quelquonque (Kalman si possible avec un-modèle-top-secret-à-nous) du movement de ses carrés (par groupe si possible).
Au niveau du son c'est souvent pareil en 1D sauf qu'il n'y a pas d'estimation du mouvement.
-1 encore un sarcasme
[^] # Re: Question naive
Posté par Dugland Bob . En réponse à la dépêche QuickTime 6 ... un standard !. Évalué à 10.
Mais tu peux mettre autre chose (standart si possible).
[^] # Re: Bon exemple...
Posté par Dugland Bob . En réponse à la dépêche Un bon exemple de nouveaux services possibles grâce aux logiciels libres. Évalué à -2.
[^] # Re: Vérifier la version de bind utilisée
Posté par Dugland Bob . En réponse à la dépêche Vulnérabilité de type DoS sur BIND 9. Évalué à -5.
Ceci dit si c'est un bon programmateur ça doit être un électronique car ils ne dérivent pas dans la temps et sont plus précis
Ca me fait penser qu'il va falloir que je change le chapeau de ma page web, il commence à être ancien.
# chtite question technique
Posté par Dugland Bob . En réponse à la dépêche CBS / Enfin un outil qui nous facilite la vie.. Évalué à 1.
Si oui c'est gràce aux tokens, grace au micro-noyau ou grace à la présence des 2 simultanément ?
[^] # Re: Bon ben...
Posté par Dugland Bob . En réponse à la dépêche GNU/Linux Mag. Évalué à -10.
[^] # Re: historique
Posté par Dugland Bob . En réponse à la dépêche CBS / Enfin un outil qui nous facilite la vie.. Évalué à 10.
<1024 "well known" documentés par des RFC
<49151 enregistré auprès de l'iana http://www.iana.com(...)
>49152 libres
détails en haut de ça qui est la liste des ports
http://www.iana.org/assignments/port-numbers(...)
[^] # Re: c'est quoi un port IP ? TCP et UDP en effet !
Posté par Dugland Bob . En réponse à la dépêche CBS / Enfin un outil qui nous facilite la vie.. Évalué à -10.
[^] # Re: Bon ben...
Posté par Dugland Bob . En réponse à la dépêche GNU/Linux Mag. Évalué à -8.
MySQL : SGBDR (c'est bien des relations)
postgreSQL : SGBDRO (relationnel objet : notion de classe, d'héritage, encapsulation etc.)
par-contre MySQL pue bien et postgreSQL est bien proche du top. :-)
# c'est quoi un port IP ?
Posté par Dugland Bob . En réponse à la dépêche CBS / Enfin un outil qui nous facilite la vie.. Évalué à 10.
Ou c'est qu'on lie un port avec une IP pour autoriser certains utilisateur à ouvrir certaines connexions très précises ?
[^] # Re: merci :)))
Posté par Dugland Bob . En réponse à la dépêche wu-imapd. Évalué à -1.
alors pourquoi utiliser du C ?
perl et très bien, python est très bien
et moi je suis au moins à 2grammes/Litre
[^] # Re: Dommage, je n'ai plus de [-]
Posté par Dugland Bob . En réponse à la dépêche wu-imapd. Évalué à -2.
laisse moi rire
va faire un tour sur le language shootout, compte les lignes de codes.
Avec un langage faiblement type tu passe ta vie a checher le bug vicieux.
Sans les contrats en objet, tu cherche qui a foutu la merde dans ton appli.
Sans les closures (ou un substitut) tu n'a pas vraiment de flexibilite.
Et j'en ai de centaines des trucs comme ca (references faibles, faineantise, types generiques etc.)
Pour la flexibilite t'a jamais du utiliser un autre langage alors.
Quand aux perfs ... laisse moi rire ! Faut arreter les benchmark sur les boucles courtes.
[^] # Re: tampons dynamiques => pas de débordement de buffer : Mort de rire !!!
Posté par Dugland Bob . En réponse à la dépêche wu-imapd. Évalué à -1.
malloc(sizeof(char)*(strlen(argv[1])+1));
mais ce que j'en pense c'est qu'à un moment où à un autre y'a un +1 qui passe à la trappe
[^] # Re: Encore un WU-gruyere !
Posté par Dugland Bob . En réponse à la dépêche wu-imapd. Évalué à -3.
-1 encore un sarcasme (je deviens antissocial ou quoi ?)
[^] # Re: Mort de rire
Posté par Dugland Bob . En réponse à la dépêche wu-imapd. Évalué à 3.
Il faut utiliser son intelligence sur d'autres trucs que sur des indices de tableaux et autres conneries d'allocation (sur avec les pb d'allocation explicite d'on j'ai déjà discuté ailleur) et même d'implémentation.
Etre trop proche du métal fait réfléchir localement au lieu de prendre de la hauteur (genre optimiser les structures de données au lien de schéma général).
Quand je parle d'Ocaml, c'est un nouveau défit, mélanger classes et modules, rien qu'en restant imprératif c'est déjà autre chose que de préfixer ces noms de fonctions par le nom de la biblothèque et se taper des macro #define super dangereuses quand ça se complique.
L'important c'est la facilité avec laquelle on évite le bug, se cracher violement sur une exception est déjà plus saint que de corrompre le tas ou la pile. Surtout si ça crache systématiquement.
Il est d'autre part important de limiter les effets de bords, ils obligent à une réflexion permanente à l'état dans lequel on va retrouver un bout de mémoire à l'entrée dans une fonction.
D'autre part, il y a une culture "élitiste" qui veut que programmer en C soit le top et qu'en plus ce soit difficile. Alors qu'apprendre au plus tôt des langages modernes et variés ferait avancer beaucoup plus vite l'informatique. Le C est un langage quasiment inutile à l'informatique, les codeurs de noyeaux et autres drivers sont marginaux et devraient utiliser ADA.
L'histoire de coder un SGBD en C est à mon sens une vaste connerie (ça vaut des millions les données qu'il y a dedans, autant éviter q'une erreur conne foute tout en l'air).
Bon j'arrête là parce que siono y'en a pour 10 pages et j'ai parlé que de caml comme alternative.